JonathanMelhuish.com

It’s now generally accepted in the software community that the best way to develop software is iteratively, for the simple reason that it’s really hard to design anything perfectly, especially if it’s for somebody else.  The best we can hope for is to create something small that we think the customer wants, show it to them and then change it until it’s what they actually wanted.  It’s a bit like finding your way by heading in roughly the right direction and then correcting your path whenever you find a landmark - rather than looking at the compass, closing your eyes and walking blindly until, inevitably, you fall off a cliff.

So I find it surprising that nobody seems to be pursuing a business model that closely fits this model.  Instead, most people seem to be sticking with some variation of the old-world “make it, box it, sell it” approach, or perhaps a subscription model where all that’s necessary is to keep the customer happy enough that they don’t go elsewhere.  Or, of course, the Free Open Source Software (FOSS) model - give it away and rely on support contracts, goodwill or magic to pay the rent.

Although the FOSS model is the hardest to make money with, it does have a lot of advantages - particularly that you’re much more likely to get free help with development and testing.  In fact, this eager and helpful user community is perfect for providing the constant feedback needed for an Agile development process.  If the user finds a problem with your software or has an idea of how to make it better, they’ll let you know about it - especially if they know it has a good chance of getting fixed.

Unfortunately, therein lies the problem.  With many Open Source projects there are, understandably, relatively few skilled developers that are prepared (or able) to donate large amounts of their time for free - so user’s requests are most likely to go ignored.  As much as they love the idea of FOSS, they’ve got to pay the rent somehow; most likely by sitting in front of a computer at work.  It takes a pretty hardcore geek to come home from a hard day’s programming and want to spend the evening doing the same.  And even if they do, they’ll probably choose to implement a new whizz-bang feature than fix a bug in the User Interface.
I suggest therefore that putting an economic mechanism in place to allow users to financially support the development of Open Source software.  I envisage that it would work something like this:

• a user describes a problem they are experiencing or a way in which they would like to see the software improved, and sets an initial bounty amount, payable upon successful completion
• an expert works with the user to clarify their requirements and to create a series of acceptance tests , and claims some or all of the original bounty
• once the user has agreed that the tests specify their requirements exactly, other users can contribute to the bounty
• developers can then choose a bounty they wish to hunt
• upon successful completion (when all of the tests pass), the developer is paid and the users receive the modified software
• the modifications can, at the discretion of the project community, be incorporated into the normal release of the software, for the benefit of everyone

I suggest that these economic mechanism would not only allow greater development effort, but lead to greater user involvement and, ultimately, better Open Source software.