Open source is more than throwing code

Register or Login to like
People working together to build

Open source has achieved a bit of popularity in the tech world, and has even become a bit mainstream. I sadly think this means that many have and will continue to miss the point of what being open source really means. Open source doesn't just mean showing source code. Many people think that such code drops are the only thing necessary for open source buzz to take over. There are sadly so many examples of tacking on the words "open source" to a product's signage that the landscape is littered with them. In addition to exposing your code (or methods in the case of non-software projects) there are really at least two other principles that need to be present for real open source legitimacy.


If you are going to legitametely adopt the open source mantra, you must expect, prepare for, and welcome outsiders into your organization (dare I say--community?). As a matter of fact you should probably spend significant time working on making sure outsiders can really participate. Largely this is going to consist of changing culture, and removing roadmaps as well as identifying and exposing the processes for getting involved. For instance, how does one get commit access? How does one start a sub-project to address a certain niche. While in the beginning most of this participation will be peripheral and likely lightweight you should be ready over time for outsiders to become core contributors to your project. You should also make sure that part of your inclusion is showing who you want to include by making sure that your overall objectives and mission are well stated and understood. You need to clearly establish where you intend to go so you don't end up with an angry community who wants to hold you to the original vision--or at least their perception of the original vision.


The final piece is transparency. Transparency means decisions are made publicly, and hopefully deliberations are as well. If your active community is surprised or caught unaware you've done it wrong. This is a difficult cultural issue for people to adjust to, particularly if the 'news' is bad. Transparency means people should always know where you are headed, be that roadmaps, published goals, ongoing deliberations, etc. Even if all of your work is being done by insiders, a newcomer should still be able to come to your site find out the groups directions and decide if they want to help and find a place to start working towards that goal in 15-20 minutes.

Finally you need to get out of the way, and if you've done it right up to this point you need to actively ensure that you and other insiders are constantly ensuring that you aren't blocking people who want to participate and get things done. Excessive amounts of time granting permission and giving resources that can only be touched by insiders are good warning signs that you are being a hindrance rather than a catalyst. Most people are reluctant to let go, sometimes even scared to do so. It should be obvious though, that this power you are so scared of is one of the reasons and benefits of going open source; why would you miss out on that?

David Nalley is an open source software contributor. He is currently largely contributing to the Fedora Project, and is or has worked in Ambassadors, marketing, Docs, infrastructure, packaging, and is currently serving a term as a member of the Fedora Board.


I think I have read similar "insight" on F/L/OSS in the last century... It's unclear to me why this post was necessary and what its added value is?

"If you are going to legitimately adopt the open source mantra, you must expect, prepare for, and welcome outsiders into your organization (dare I say--community?). As a matter of fact you should probably spend significant time working on making sure outsiders can really participate."

The strength of this article lies in the above quote. Indeed, the article may have been more engaging if it had discussed the inclusion and pathways of participation for <em>non-programmers</em>.

As FLOSS extends beyond the niche of hackers and tinkerers, there is a greater need for input and participation of non-programmers. Currently, non-programmers are relatively unrepresented in the presentation of FLOSS to a broader public. In the broader software sphere, the implementation and instruction of FLOSS is almost exclusively limited to the illuminati of IT (CS departments, engineering, servers, and internal infrastructure). If FLOSS is to make the societal paradigmatic changes it promises to, then it will need to move to a greater audience (as it has begun to in the mobile market).

While this is not a new opinion, I find it good to be reminded occasionally of the tenants. It is so easy to get caught up in the current project and forget about the community and the need to make the decisions in public not in private email conversations, which is so much easier....

The above, even if already said, needs repeating. Especially about transparency.

I don't completely agree about the removal of roadmaps. I think they should still be present, but
<li> transparent
<li>influencable by the community (and not only be some product manager)
<lI>allow for contributions that are not on the roadmap.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.