Entrepreneur, philanthropist, and ex-cosmonaut Mark Shuttleworth has an article about his experience funding the development of SchoolTool, an open source school administration system. Mark first attempted to develop this software by funding a dedicated team, which failed as the developers pursued shiny geeky projects instead of producing working software. To counteract this problem, he will fund multiple, separate teams that collaborate over the internet. This will have two major effects on the project. First, the different teams will keep each other in check—focused on developing working parts of the software because other developers depend on them. Second, the separate teams will be forced to have their discussions on public forums like mailing lists and wikis. This will open up the development process to input and criticism from other developers and customers, as well as build a body of explicit knowledge that will help the community sustain itself without overdependence on the original team.

This seems like a good strategy and I hope that it continues to serve SchoolTool well. But I want to propose another approach: funding the surrogate customer. Open source projects can really take off only when there is a balance of management-style leaders, hardworking programmers, and conscientious end-users. It is the nature of open source that any individual need not fall neatly into one of these boxes, and one may indeed be all three—a person truly scratching his own itch. Mark's approach seems to start with getting some good programmers and building extra support for the leadership. But can we also go the other direction, funding the creation of users?

I think here the philanthropists can take a lesson from commercial software development. Most software development companies have dedicated Quality Assurance (QA) teams, whose job is to test the software being delivered by the development team and find bugs. Really, the purpose of QA is to serve as a surrogate customer—to keep developers in check by complaining the way a customer would, but before you've actually sold anything. Because QA staff are employed, they are also distinguished from regular customers by their willingness to work patiently with developers to sort out problems; they have a stake in the software's success.

This same relationship happens with the best users of open source software. When a user really wants a project to succeed because it will make her own life easier, and she knows she can contribute fruitfully to the project, she will be more patient and generous. If in her use of the software she finds a bug, she may not only report it, but report it in detail. She'll add an explanation of her motivations for using the software in this way, descriptions of workarounds that she's found, and an explanation of the ultimately desired behavior. Software developers can often fix a bug without much of this background information, but a thorough bug report is distinguished from a trivial one by its ability to trigger Aha! moments in the developers' minds. The most valuable bug reports both elucidate real project requirements, giving developers a more accurate direction, and pin that direction to an actual living person that the developer can truly help. They help developers stay effective.

This leads to an interesting question: if we had bags of money, could we ensure this benefit to an open source project by simple paying people? If we buy these surrogate customers for open source projects, how much faster can a project get rolling? How much better will their software be? In other words, is it worth it? Perhaps another philanthropic ex-cosmonaut will help us find out.