I don’t think either of these models can work.
Fund-to-release is basically the same as crowdfunding, except painted as more focused. Now users, rather than “donate 5$ every month to fooProject” need to deal with a constant stream of “donate X$ to fooProject for Y feature / bug”, so it sharply increases subscription fatigue. I guess it wouldn’t be subscription fatigue then. Shopping fatigue?
And what if bugfix X reaches 90% of the funding, and feature Y reaches 90% of the funding, but neither reaches 100%? With a simpler subscription the project would have a set amount of money to distribute across its internal needs.
And this isn’t even touching on the subject of cost overruns. What happens when your feature estimated at 2 months of dev time is 60% done after 7 weeks? Do you ask for a second donation round?
Rather, for this kind of focused work a project should keep one single treasury to distribute as needed, and have polls for contributors (monetary or otherwise) to vote on which parts to focus on first.
The fund-to-release model shifts all the risk on the authors, who don’t see any monetary reward while the work is ongoing and are not guaranteed any even when the work is finished. Dev work needs a constant stream of funding (to eat, pay rent etc) unless the author starts with a sizeable initial treasury, in which case they can deal with big lump sumps to distribute as they need. But this requires at the very least the guarantee of payment once the work is done which, again, this model does not guarantee.
Sorry I don’t have solutions to propose, but I think the flaws of these alternatives far outweigh their pros.
I realize I sounded overly critical in my comment. Open source sustainability, including in monetary form, is a real issue. It’s very important that we as a community try to find working models, and I commend posts like yours that investigate the possibilities and traverse the solution space. Unfortunately it’s a very difficult problem to solve. I think a model that can work is yet to be found
I don’t think either of these models can work. Fund-to-release is basically the same as crowdfunding, except painted as more focused. Now users, rather than “donate 5$ every month to fooProject” need to deal with a constant stream of “donate X$ to fooProject for Y feature / bug”, so it sharply increases subscription fatigue. I guess it wouldn’t be subscription fatigue then. Shopping fatigue?
And what if bugfix X reaches 90% of the funding, and feature Y reaches 90% of the funding, but neither reaches 100%? With a simpler subscription the project would have a set amount of money to distribute across its internal needs.
And this isn’t even touching on the subject of cost overruns. What happens when your feature estimated at 2 months of dev time is 60% done after 7 weeks? Do you ask for a second donation round?
Rather, for this kind of focused work a project should keep one single treasury to distribute as needed, and have polls for contributors (monetary or otherwise) to vote on which parts to focus on first.
The fund-to-release model shifts all the risk on the authors, who don’t see any monetary reward while the work is ongoing and are not guaranteed any even when the work is finished. Dev work needs a constant stream of funding (to eat, pay rent etc) unless the author starts with a sizeable initial treasury, in which case they can deal with big lump sumps to distribute as they need. But this requires at the very least the guarantee of payment once the work is done which, again, this model does not guarantee.
Sorry I don’t have solutions to propose, but I think the flaws of these alternatives far outweigh their pros.
Thanks for reading, and sharing your feedback.
I realize I sounded overly critical in my comment. Open source sustainability, including in monetary form, is a real issue. It’s very important that we as a community try to find working models, and I commend posts like yours that investigate the possibilities and traverse the solution space. Unfortunately it’s a very difficult problem to solve. I think a model that can work is yet to be found