Created page with " =Overview= ==Typologies and Definitions== # Open Source Community ; Open Source Software Communities # Free Open Source Research Community # [[Open Source Softw..."
New page
=Overview=
==Typologies and Definitions==
# [[Open Source Community]] ; [[Open Source Software Communities]]
# [[Free Open Source Research Community]]
# [[Open Source Software Development Community]]
# [[Open Source - Community Building]]
Typologies:
# [[Autonomous vs Sponsored Open Source Community]], i.e.: [[Autonomous Open Source Community]] and [[Sponsored Open Source Community]]
# [[Organic vs Synthetic Open Source Communities]]
==Research Articles==
# [[Governance of Sponsored Open Source Communities]]
# 'Research essay: [[Transition of Governance in a Mature Open Software Source Community]]: Evidence from the Debian Case. by B. Sadowski, G. Sadowski-Rasters
# M. Teli and V. D’Andrea, 2008. ‘‘[[Free and Open Source Licenses in Community Life]]: Two empirical cases,’’ First Monday, 13(10), p. 19.'
# ’Mahony, S. &Feraro, F. ‘The [[Emergence of Governance in an Open Source Community]]’, Academy of Management Journal, 50 (5), pp. 1079-1106.
# [[Knowledge Management and Innovation in Open Source Software Communities]]
# The [[Role of Participation Architecture in Growing Sponsored Open Source Communities]].''' By Joel West et al.
# Research paper: [[Relationships between Open Source Software Companies and Communities]]: Observations from Nordic firms. By Linus Dahlander, Mats G. Magnusson.
# Book: [[Organization in Open Source Communities]]. At the Crossroads of the Gift and Market Economies. By Evangelia Berdou.
# Interactions in the [[Cross-Project Coordination Practices of Open-Source Communities]]. by Adrian Yeow
==Discussions==
# [[David Eaves on Community Management in Open Source]]
# [[Bradley Kuhn on Free Software Communities vs. Open Source Companies]]
# [[How Firms Relate to Open Source Communities]]
=Discussion=
==[[Conflict in Open Source Communities]]==
Gil Yehuda:
"Conflict is very much a part of open source communities. It is inevitable and it is sometimes problematic; but there are controls that help mitigate the negative effect. If you don't thrive in conflict situations, you might not like Open Source communities. It's not like playtime where we all bring cookies to share with each other. Instead, you find rage inspired, long email threads, Godwin's law Nazi analogies, Rage Quit forks. Some of the fights get lampooned in The Register, and the best fights remain in the publicly searchable archives of Apache's email server or in some Yahoo!Group or GoogleGroup.
But if you can negotiate the occasional, inevitable conflict, you'll find that it can be used as creative friction and inspire really great Open Source projects.
Historical context sets the stage; conflict is in the DNA of Open Source.
The very start of the movement was a result of Richard Stallman's frustrations at the licensing policies related to AT&T Bell Lab's (policies imposed ironically by the Department of Justice against the telephone company aimed at improving market freedom that consequently created commercial licenses for the Unix operating system). In some sense, RMS did a Rage Quit and created the license designed to undermine the whole field of proprietary software because he wanted to improve a printer driver. The movement started with conflict; a gripe.
The watershed period in the popularity of Open Source was the development of a united movement against Microsoft sparked in part by the "Halloween Documents of the late 1990s and early 00s." Open Source became nearly synonymous with being Anti Microsoft at that time (things have changed since, thankfully, in part to some fantastic Open Source people now working at Microsoft). Conflict against Microsoft grew the movement into a mainstream technology reality.
The very term Open Source is not used by the person who created it -- instead he uses the term Free Software as a result of a philosophical refinement and schism in the movement between the Free Software Foundation and the Open Source Initiative (I see it as parallel to the protestant reformation of the Christian Church or the Shi'a-Sunni schism in Islam, resulting in two groups who both agree with many principles but disagree on many important details). And to further the irony, what started as a clever legal idea to annul some silliness related to software licensing turned into about 30 or more software licenses that reflect sometimes conflicting views of what developers expect of people who use their software. You'll find many bloggers still arguing about Open Source licenses. Conflict and confusion remain as Open Source simply added confusion to software licensing.
Open Source has always had conflict as a trusted sidekick. It uses conflict as a creative force. In fact, Open Source has a property that makes it resistant to traditional conflict resolution tactics (the threat of forced shutdown). For example:
After Oracle found that it had purchased the rights to OpenOffice (an Open Source project aimed at providing all the functionality of Microsoft Office without making you pay Microsoft for it), the community (correctly) assessed that Oracle was going to kill the project (not out of a love for Microsoft, but a contempt for Open Source successes). Since OpenOffice was an Open Source project, it was possible for members of the community to fork the project and create LibreOffice -- a very similar effort that was not subject to Oracle's roadmap. Had this not been an Open Source project, this fork could not have happened. The conflict and resolution enabled both OpenOffice and LibreOffice to exist, since you can't force Open Source projects to fail.
Similar pattern took place more recently with the Hudson and Jenkins project. And even more recently see: GnuTLS, copyright assignment, and GNU project governance. Being resistant to the thread of forced-shutdown, Open Source projects are receptive to fights to the death, since they can't be killed, they can only get wounded. If you know you can't be killed, you are more likely to fight to the death.
The open source development model differs from the traditional way to build software in that you are receptive to (and invite) many more contributions from people whom you have little control over. Although many people are paid to write open source code, many of the people who contribute a project are not paid by the same entity, so there is automatic dispersion of control. This invites conflict since you don't have a project director who stomps his foot and says "I declare this out of scope" or "You all have to write unit tests instead of new functionality" You can't force open source contribution, you can only motivate them. And if you have a conflict, you can't use the "hammer of crushed spirits" that many managers like to swing when projects run into deadlines. In fact you have people who work for competitors who are now working together. Strange, there is less conflict than you'd think there should be.
Thus in any given Open Source project you should expect that at some point you'll have a conflict, and it will get emotional and passionate.
A typical conflict pattern I ran into, not that long ago, with a well known Apache project: Some of the companies involved in developing the project had implemented the code into their production environments. They were largely pleased with the general functionality and looked to make incremental improvements at regular intervals. Their implementations were at very large scale, so performance and stability were essential to preserve.
Other companies involved in the project were consulting companies who were looking to sell their consulting services to new clients who wanted to implement this technology. The prospective clients needed new features implemented before they were ready to install the project. The consulting company invested resources to build those features, so they could take on the new clients. They did not care as much about scale or stability -- they needed the new features and they needed them soon, or they'd lose their clients.
As you can imagine, the contributors fought hard to get their way. Which was more important? new features that make the project more attractive to more people (and we can fix the security, performance, and stability problems later), or a delay of features and a slow methodical improvement that does not introduce too many radical changes? Turns out both are right, they are not right at the same time for the same client, and this is a natural source of conflict.
To deal with this (and other patterns of) inevitable conflict, you need strong leadership to inspire the community (not the hammer of project management). A strong leader knows how to send part of the community off to build the new features, part of the community to make the incremental stability improvements, and when to bring them together so that they are not forking, but working a coordinated play. The reality is that many open source developers are not inspiring leaders, but instead they are fantastic coders. But when your project has that inspiring leader, then you can get though the conflict and sail to success. Those super successful projects we all know and love have great leaders and loyal communities that trust them. But getting there is no simple feat."
(http://www.quora.com/Open-Source/How-much-conflict-exists-in-open-source-communities?)
[[Category:Free Software]]
[[Category:Governance]]
[[Category:Peergovernance]]