First the premise; "software only needs to be paid for once" -in most cases I'd argue it is. A closed-source package for example (say, like, Windows) is a simple one-time purchase. Lots of people may be paying, and yes this company making it makes a profit, but the cost to 1 user is only a tiny fraction of the cost that it cost to make. Of course most closed-source software doesn't make money at all, never mind the scale of money windows makes, so Windows is an outlier here in terms of profit vs cost.
Indeed most companies probably end up making a loss, and going out of business. Maybe that means the model is broken, or maybe it's just inevitable that most of the software being created, closed or open, is pretty much crap.
Now to the proposed solution. Which can be summarized as "design by committee" - ill put in x$ if you complete feature y which I want. With the community dictating how much they'll spend and on what, I don't think an elegant well-thought-out beautiful product will be the result. Designing a whole system is often best done by the person who has the Vision of where the project is going, even if it takes 10 years to get there.
Yes, developers need to eat. Which is why the big open-source projects are funded in some way (like Mozilla is funded by google.) the little projects tend to get no funding of any kind. And even big projects (like say jquery) get by mostly on donated programmer time, not cash of their own.
I appreciate that many developers are between a rock and a hard place. They want to write whatever they like, and not have to work for some employer, but at the same time they want to get paid. But freedom comes at a price. And "doing whatever you like" is seldom paid for. And indeed the proposed model here is suggesting that a bunch of people will become your boss, and tell you what to do. Which I guess means you might as well just go off and get a job instead.
My bigger qualm is that I'm not sure it's a bad thing that there are multiple implementations of the same problem. Windows solves the problem of "I need to work with my computer" in a vastly different way from the *nixs; nginx and apache solve almost the exact same problem too, and each has different people using them for different things.
I agree with you that the problem with one solution per problem is that those solutions will become huge behemoths that nobody wants to work with. It's much easier to have small, shared libraries than shared programs, especially when you start tailoring those bigger programs for more and more specific use cases.
Also, designing software and features by "crow-sourcing" is a terrible approach. Why? Henry Ford said it best “If I had asked people what they wanted, they would have said faster horses.”
* The money has to specifically go to developers or development and testing related costs, not general advocacy or evangelism.
* It would be nice if donations could go into specific pools, eg in the Postgres example, I might be interested in contributing funds for performance enhancements but have no interest in logical replication.
* Variety of payment methods supported, with annual, repeating donations allowed.
Bountysource (https://www.bountysource.com) comes close, but rarely has many projects for funding.
Its surprising that in 2014, one of the best ways to supporting open source is still to select a company which does work on your favourite OSS project and buy a support contract or something, even though it's not a very efficient way.
To be concrete, if you donate to tor, you can choose where the money will go.
I've been trying to come up with a solid way that would fund my minimum livable income($15000/year) in order to allow me to dedicate 1-2 years full time to nothing but open source & MIT license projects but finding support for open source isn't exactly mainstream.
A lot of times when I approach companies/individuals with the idea they instantly want to know which projects I'd be creating/working on and most people straight up tell me they wouldn't "fund" someone unless it benefits directly them which is kind of a shame.
I've been debating attempting a "Kickstater" for something like this because I think the community in general would benefit greatly from someone in this sort of position with no ties to other commitments.
During the year, I would make blog updates, maintain on open github of learning projects, and contribute to open projects; and my investors could make suggestion of things to learn or projects to work on.
As much as I want to do this, I would feel guilty if I did it personally (I want others in my situation to be able to have similar opportunities), so I've been trying to figure out how to scale such an approach.
You can sell support, which can't be copied in the same way that software can be copied. And if you are writing open source software with reasonable traction, most likely there are companies that use the software (that may have already reached out to you regarding support)
It's also a 'coordination problem'. If I take the time to make something that is ready to buy, that's very easy for end users, rather than trying to coordinate a bunch of people to sit around and wait for something to be created.
And nobody ever wants to pay for it. Customers buying SAS don't want to pay for it. Managers at closed-source, boxed-software companies mostly don't want to pay for it. Managers at consultancies don't want to pay for it, because clients bitch and scream about paying for it (and then bitch and scream when the software sucks because of a lack of it).
Everyone has this mentality that the only thing worth paying for is the programmer's fingers pushing keys on a keyboard into a code file. Either a sea-change on how people view work is necessary, or we need to learn to recast all that other work as programming in some way.
Unfortunately, I don't see either of those happening anytime soon.
BitHub, funds are put into a pool and distributed evenly to anyone who commits. Bithub allows someone to donate to the development, without giving it any direction.
With feedopensource, developers enter into an agreement with a customer, who pays for a short iteration on a feature or fix of their choosing. Feedopensource allows someone to pay for what they want developed.
Java was supposed to make all of this obsolete, but the promises of Java security failed to pan out.
The fact remains that a truly plug-in-oriented productivity suite has never been tried before. If there were any justice in the world, then knock-off social media apps wouldn't be a hot industry at all; actually useful marginal functionality for the applications people depend on every day to get work done would get a huge amount of attention and substantial mind-share in the developer community.
We don't need to play with the economic model. The exchange of money for software is fundamentally sounds, as sound as the basic market principles Adam Smith detailed hundreds of years ago. We don't need new organizational models. The basic principles of capitalism that formed over the last 200 years are sound and up to the task.
What we need is infrastructure. New technology. We need a way to deliver software that is substantially more flexible and adaptable to the user's needs while ensuring that malicious programs are either impossible to write or unable to wreak substantial havoc. The process model of today's major operating systems simply isn't up to the task. What we need are new operating system and new programming languages.
Sadly, this is very much the case of "we'll know it when we see it". The C/Unix architecture that dominates today became a success almost in spite of its creators. What is needed is a new approach, a willingness to consider new solutions to old problems.
Anyway, if I can play with computer programs the same way I play with legos, then I'll be happy. And because playing with legos is so simple, this will lead to a situation where the distinction between programmers and non-programmers will blur and eventually disappear. But that's a long way off.