The problem with software development, is that the ways used to fund it are either more suited to physical products, or are otherwise out of line with the interests of the users of the software. Here are my thoughts on the ways this fails, and also an idea for another approach.
A Summary of the Current Methods
There are currently only a couple of ways of funding software:
- VC-funded free service
- proprietary software licensed for a fee
- open source, funded by charity, or by the creative drive of it’s author.
Each of these methods create a different kind of software.
Essentially, different sources of funding mean different motivations, and these result in different decisions by the developers.
The “Free” Service
VC-funded software seems very good at first, but, they aren’t really doing it for free.
The investors are looking to make money, and there is often
a “business model” question hanging over the software.
This question is nearly always resolved by changing the software
from something that enables users, to something that manipulates the user.
If this is the sort of software you would like to use (and be used by),
then you are already well catered to! Your Welcome!
Someone builds the software, then you buy it from them.
What could be simpler? This works well with physical goods,
because the exchange is easy to enforce. For example, I have made a bicycle,
and you want to buy it. You give me some pieces of paper with pictures
of George Washington, or Chairman Mao or whatever, and I give you a bicycle.
This is naturally in line with the physics of physical items, but software is totally
different. Instead of giving you the bike, I copy the bike to you.
Now there are two copies. What’s more, you can also copy the bike to someone else.
Now there are a lot of people riding my bike, without me being able to recover the value that I think I deserve for creating it.
So, to make the private source model work, you have to add extra copy protection “features” to make the software behave more like a physical good. Like turnstiles on a subway,
these copy-protection features prevent you from accessing the natural physics of software. This takes extra work, and so you end up paying not just for the product itself,
but also for the work to cripple the product so that it’s more difficult to copy.
If the value of the software is high enough (enterprise),
then they can just use lawyers instead of copy protection. I’m not sure which is worse.
This is widely used for games, or enterprise applications.
Apple’s App Store is a great example of an elaborate system
for making software difficult to copy.
You purchase a crippled phone that can only install software that apple likes, and then you can pay for software, and also 30% to apple for the service of stopping you from being able to install anything else.
Instead of going to the hassle of charging for software,
open source just gives it away.
This eliminates the costs of erecting turnstiles. It also reduces the cost of evaluating software. You don’t have to pay for something to try it out. Open Source has created all the best operating systems, programming languages, developer tools, and databases.
But the scope of Open Source is pretty much limited to this.
Open Source is created by enthusiasts, and it does get paid for,
A project usually starts because someone thinks it might be fun to implement. But then, if that project becomes useful, it becomes in the interest of other well funded parties. Any large project requires an extraordinary attention to detail and refinements.
It would not be possible to pursue such a project at hobby scale.
though, still, there is a huge amount of valuable software essentially created by hobbyists. Tragically, these hobbyists may work a day job writing “free” services or private software.
There have recently been some attempts to move beyond the hobby economics of open source. Each of these are interesting in their own way.
gittip.com enables you to anonymously
donate to someone. This is the digital equivalent of busking.
You can easily give a small amount of money as encouragement to an artist who’s creating things you enjoy. But this doesn’t really influence them in any way.
This is an interesting model, but not many people are earning enough to survive like this (and thus devote themselves fully to their art).
By the way, if you enjoy my creations, please feel free to offer me a token of your appreciation: gittip.com/dominictarr
Kickstarter, Indiegogo, etc.
Another approach is crowd-funding the development of a project.
The developer makes a bunch of promises of what they want to deliver, and how much they think it will cost. People either fund it or not. And then, development begins. If you have been following any software projects like this recently it won’t be hard to think of examples of one that hasn’t really gone according to plan.
All the crowd-funding platforms and geared towards a single, large, funding round. So, all promises and plans must be made up front, well in advance.
The problem with promises made well in advance is that they are hard to keep.
Not necessarily because you didn’t mean them, but just because the situation changes, and when you start coding you learn things you didn’t know when you started.
Like representational democracy, you don’t know if the party you elect (fund)
will keep their promises, or even are capable of achieving them.
Essentially, Kickstarter forces you to use the
The waterfall model is widely understood to result in low quality software that is delivered late and over-budget.
Quality Software must be built iteratively, changing the plan as your learn things, but the economics of crowd-funding platforms prevent this.
Bountysource takes the opposite approach of Kickstarter.
Instead of funding a whole project all at once, you can fund a specific issue,
or feature that you want. It’s really too early to say what will happen with
Bountysource, but my feeling is that Bountysource is too specific where Kickstarter is too vague.
The features of a software project are not isolated. You can’t just buy a feature or bug fix. On the one hand, casual users may not understand which issues are really important,
and on the other there may be a refactor that simplifies multiple features, or eliminates multiple bugs.
At best, this may be suitable for the developer tools that open source is already good at.
If open source is to go truly mainstream, it needs be able to create software that is used by people who are not themselves developers, or even particularity competent with computers.
One More Way!
There is one more way software is funded.
If you have a software problem that is particular to you, or just want your own thing,
you can hire a consulting company and get them to make you a bespoke system.
This can actually work pretty well, provided that communication between the developers and the clients is good, and an iterative process of building a prototype, testing it against
client expectations, and refining/rebuilding the design.
This process is often known as Agile Development.
The developers and the clients both have power in their relationship. The developers have the technical expertise to write the software, but the clients have the checkbook.
If a project is going badly, they can potentially abandon it and find new consultants.
A lot of software is built this way, but it’s not scalable.
The weakness is that is that it must provide sufficient value to
a single party, who must be willing to foot the bill entirely.
It doesn’t support the case where a small amount of value is provided to a large number of people.
But what if it could?
What we need is something that aligns the interests of the developers and with the interests of users.
Something that works with the natural physics of computers and data, not against it.
Something that scales, so that you can use to fund end-user software - not just developer tools.
Something halfway between Kickstarter, and Bountysource, but with the best parts of Agile development. Development and funding must be iterative. The developers should
not have to make promises that will be hard to keep.
Instead, developers should build trust with the clients by making steady, incremental progress. If the progress is in the wrong direction, or the developers
turn out to be incompetent, then clients can abandon the project without having over-committed.
If a project goes well, the clients can continue to fund the project. Since the uncertainty decreases as the developers build the clients trust, they could potentially fund much more than they would with a single round of funding,
where they have to balance their desire for the promised features with their estimation of the projects
I am currently working on a prototype of this idea,
Watch this space!