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.
I don't agree with the premise. Software isn't a static thing, it's something that is constantly evolving and creating great software, like creating great anything, requires a lot of effort, a lot of time and a lot of dedication. This is what you pay for when you pay for software. You don't pay for the actual copying of software, you pay for the effort that went into creating it.
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.”
I personally would love to be able to donate more to open source (specifically Postgres and some of its related projects) but I haven't found a way yet which meets my few simple criteria.
* 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.
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.
This article was pretty interesting and I figured I'd take a brief moment to write out something I've been struggling with trying to accomplish in hopes that maybe someone could shed some light about how to approach it...
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.
I'm interested in taking time off to learn programming. Surviving while doing that is a challenge. One concept I've bounced around is an investment approach. For example, people could make donations (e.g., $10), with each increment being "a share" of my future earnings (e.g., 0.1%), potentially for a limited amount of time (e.g., 10 years).
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't sell software like you sell physical items, software is too easy to copy.
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)
The problem I see with selling support is that a well-designed tool shouldn't really require support at all. Ideally the API is clear enough, the documentation well-written enough, and the scope small enough that support isn't required or even worth paying for. But as soon as you monetize support, your incentives aren't nicely aligned with the customers.
The other problem with the support solution is that many programmers dont want to be tech support people, they want to be programmers. you can hire people to do the tech suppprt people, but then you become a business person/manager, rather than a programmer. Even still, building this kind of multiperson business only makes sense for larger projects. I do think it has its place and has prooven successful in some situations but its no silver bullet.
This, but for businesses. Companies should try to avoid e.g. paying something like $5000 per seat to license AutoCAD; instead the consumers of that particular type of software should work cooperatively to fund developers who will build a program with the required features and then release it as free or open software.
The problem is of course how to prevent free riding. Why not just let my competitors throw their money at producing a high quality free CAD system while I just sit here and reap the benefits.
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.
To me, the problem of free riders is irrelevant if you end up spending less on quality software; hopefully others will step up and help pay for improvements but it seems unlikely that this will become an issue that significantly tilts the competitive balance.
As for how companies work in the meantime, there are packages out there that can do the basics; in the CAD space, I've been able to achieve a fair bit with OpenSCAD, believe it or not. I chose this package because it feels more like programming shapes than drawing them with a mouse, but I wish that it had more features. As for requirements and bug patches, there are already companies out there using business models that are some variant of having "customers" pay specifically for features they want and also pay to expedite patches for bugs that affect them.
There is another fundamental problem with this idea: the planning work that needs to be done to figure out what to program with this patronage is itself a lot of work. Project management, requirements analysis, design, testing, installation, configuration, administration: when done properly, is far, far more work than the programming itself.
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.
Our startup CodersClan also funds open source projects although from a different angle. We Crowd-source the support for personal code problems (like a paid Stack Overflow) and we give a share back to the related Open Source projects.
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.
About 20 years ago a small startup called Netscape and a large company called Sun were supposed to have solved the software problem. Everybody was predicting the demise of Microsoft. It was thought that with the internet, we would soon be delivering software over the web instantaneously. "A software paradise is just a few years away!" we all thought.
Fast forward to today. Netscape is dead, and Javascript is good for posting photos online and watching videos. And coordinating projects. And this. And that. But not the basic tasks of what became known as the standard productivity suite: Excel, PowerPoint, Word and Outlook. These four basic operations of a computer are still very important. So important that Apple feels the need to provide its own clones. The relationship between Microsoft productivity apps and Macintosh computers is rocky to say the least.
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.
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.