I found a great resource to answer my own question: Wide Open: Open Source Methods and their Future Potential. They list the following principles:
Principles of Open Source Projects
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
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.
2 Comments:
I found a great resource to answer my own question: Wide Open: Open Source Methods and their Future Potential. They list the following principles:
Principles of Open Source Projects
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 at http://www.demos.co.uk/catalogue/wideopen/
I'll write a longer review later. I just wanted to get his out to you as soon as I could.
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.
Post a Comment
<< Home