Open Source as a Model for an Innovation Commons

Wide Open: Open source methods and their future potential, Geoff Mulgan and Tom Steinberg, with Omar Salem, Demos

1. Transparency
2. Vetting of participants only after they've gotten involved
3. Low cost and ease of engagement
4. A legal structure and enforcement mechanism
5. Leadership
6. Common standards
7. Peer feedback loops
8. A shared conception of goals
9. Incrementalist - small players can still make useful contributions
10. Powerful non-monetary incentives

You can get a copy of the book here

Wide Open - Open Source Principles

Transparency - Visibility and transparency are central to the most well known open source initiatives. While the standard approach to ensuring innovation in competitive industries has been to keep ideas secret as long as possible, and then copyrighted or patented thereafter, the open source model turns this on its head.

Vetting of participants only after they've gotten involved - Traditional organizations erect sophisticated barriers to involvement; systems of recruitment, appraisal and promotion are designed to ensure that only people with adequate qualifications and experience get to work on important projects, or to exercise power. Open source projects work on a very different principle. They allow absolutely anyone to get involved; all that matters is whether or not they deliver high quality work.

Low cost and ease of engagement - Genuine openness in any activity depends on cheap and easy ways of taking part. The opportunities for time-rich people with access to the internet are enormous – all the information you could possibly require to teach yourself anything about how to make computers and software work is available for free, and the best documentation often surrounds the most open projects.

A legal structure and enforcement mechanism - Open source does not mean a free-for-all. Instead it depends on a clearly defined legal framework which shapes the incentives for participation. If open source licenses were not legally enforceable, especially with regard to derivatives, then companies would more or less be able to appropriate the code that was produced and give back nothing in return. This would hugely dent the incentive for programmers to get involved. All open source projects release their data for free, but control its use through licenses that ensure that the improved work remains available for public use.

Leadership - Most open source software has some centralized element of leadership or control. This concentration of power may be around an individual, such as Linus Torvalds, or an organization, such as the Apache Foundation. Whatever the particular structure there is usually a leadership that sets the general direction and ethos, assigns tasks and acts as an editor, approving changes to the source code. It is important that the leadership maintains the trust of contributors in order that they remain involved in the project.

Common standards - Common standards have always been an essential part of successful projects. Successful open source projects like Linux and Wikipedia deal with standards in two successful ways. They rely on open, free-to-use standards, and they create new, open, free-to-use standards for their users.

Peer review and feedback loops - The principle by which the open source collaborative approach manages to produce such high quality work is most famously summed up in the words of coder Eric Raymond: "Given enough eyeballs, all bugs are shallow." By this Raymond means that even complex code, millions of lines in length and of huge complexity, can be debugged reasonably quickly when there are enough people looking at different bits of it.

Incrementalist - small players can make useful contributions - Improvements to the source code of Linux or to a Wikipedia page can be modest, but still be valuable. In many other fields of development, the minimum threshold above which it is possible to make any valid contribution is very high – years of background work, gaining of a PhD or other advanced qualifications, and/or high capital costs. Both Linux and Wikipedia get a bit better every time someone makes a tiny change – and tiny changes are therefore sought and accepted, alongside major contributions.

Powerful non-monetary incentives - The baseline assumption of most major projects, technological or otherwise, is that in order to get lots of work done, you must pay lots of money to the participants. Even this most basic assumption seems to be challenged by the new methods of working. For all the characteristics listed above contribute to an economic phenomenon – the ability of open source methods to replace traditional cash incentives with non-monetary ones. People working on Wikipedia and Linux do so almost entirely for non-monetary reasons. Some may be operating indirectly out of economic self-interest – open source programming allows a developer to signal their abilities to peers and potential employers. But programmers are more commonly driven by motives of social or personal fulfillment including the desire to be respected for their work.

This is a rich book to study if you're interested in an innovation commons.

From Steven List:

"Wow! What a huge topic. One of the best written pieces on this is "The Cathedral and the Bazaar" by Eric Raymond (http://www.catb.org/~esr/writings/cathedral-bazaar/).

I believe that there are two primary reasons that Open Source works: pride and the opportunity to make a difference. I speak not only from experience as a recipient of this benefit, but also as an early contributor.

Pride: There come moments when I realize that there's something that I can do that few other people can do. I can create a beautiful user interface, an elegant bit of code, or I can contribute to an architecture in some significant way. I don't use "pride" in the sinful sense, but in the sense of "pride of competence" or "pride of creativity" or "I'm proud that I can do this and contribute". There's a powerful communal pride in the Open Source community that is also a pride of cooperation.

And let's not forget that there's a certain joy in being able to do something *because I want to, because I can, and not for money*.

Opportunity to make a difference: in this particular community (Innovation Commons), I think that there are more people than in the average population who have the opportunity to make a difference. But imagine yourself an average programmer in some little, out of the way place, working on your small part of a large project for a decent salary. The odds are that you will never experience the pleasure of knowing that your bit of work has made a difference to someone - to anyone.

In the Open Source community, you know that what you've done has made a difference, and frequently to many thousands, tens of thousands, even hundreds of thousands of people. You can point to one thing and say "I did that!"

The sense of community and contribution, of collaboration and communication, is powerful. "