Both Hardin and Olson concluded that groups don’t self-organize to maintain the common goods they depend on.Īs Olson writes in the beginning of his book, The Logic of Collective Action: Some of the most instrumental research was Garrett Hardin’s tragedy of the commons and Mancur Olson’s work on collective action. Over the years, I have read many of them to figure out what open source communities can learn from successfully managed public goods and common goods. Hundreds of research papers and books have been written on the governance of public goods and common goods. Lessons from decades of common goods management In other words, open source communities should find ways to route customers to Makers. When a customer signs up with a customer free-rider or Taker, the project doesn’t stand to benefit. When the customer signs up with a Maker, we know that a certain percentage of the revenue associated with that customer will be invested back into the open source project. Because a customer can’t be shared among companies, it matters a great deal for the open source project where that customer ends up. However, when the success of an open source project depends largely on one or more corporate sponsors, the open source community should not forget or ignore that customers are a common good. Software free-riders can have positive network effects on a project. When some portion of those other users contribute back, the open source project benefits. Furthermore, a software free-rider makes it more likely that other people will use your open source project (by word of mouth or otherwise). Hence, it’s better to have a person use your open source project than your competitor’s software. Because the software is a public good (non-rivalrous), a software free-rider doesn’t exclude others from using the software. We define software free-riders as those who use the software without ever contributing back, and customer free-riders (or Takers) as those who sign up customers without giving back.Īll open source communities should encourage software free-riders. Next, I’d like to extend the distinction between “open source software being a public good” and “open source customers being a common good” to the free-rider problem. Everyone can use open source software (non-excludable), but when an open source end user becomes a customer of Company A, that same end user is unlikely to become a customer of Company B (rivalrous). However, through the lens of open source companies, open source projects are also common goods. Everyone can use open source software (non-excludable), and someone using an open source project doesn’t prevent someone else from using it (non-rivalrous). I’ve long believed that open source projects are public goods. Open source: A public good or a common good? In contrast, public goods are non-rivalrous someone listening to the radio doesn’t prevent others from listening to the radio. Common goods are rivalrous if one individual catches a fish and eats it, the other individual can’t.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |