I think maybe the whole concept here is based on a false premise, and the solution being offered, even if the premise was true, is a bad one.
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.
I think the problem in the premise is right on: while each package is created once, there are multiple packages which are all different implementations of the same problem (see Photoshop, Gimp, and all other photo manipulation tools; or really any genre of software, there are lots of similar pieces of software).
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.
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.