Ultimately, the health of an open source project is measured by the production of useful code, and the broad adoption of that code. This is easy to spot in many examples, projects like the Linux Kernel, Apache Tomcat, Samba, GNU gcc, etc are so useful, and have become so broadly adopted that they are literally the milieu in which the modern world is embedded.
It’s easy to spot the successes. And it’s also easy to notice that there are thriving communities collaborating around such successes. It’s much more interesting to ask what contributes to successful open source communities.
I would maintain, that successful open source communities lower the barriers to useful participation. They lower the activation energy for innovative activity. Some of the ways they do this are rather obvious, and some are less so.
Technical Barriers to participation:
- Is it easy to figure out where to get the source code?
- Is the code easily understandable to someone likely to be capable of contributing?
- Is it clear how to build the code?
- Can someone qualified to contribute easily figure out how to usefully modify the code?
- Is it clear and straightforward to contribute changes back upstream?
- And are all of these true even if you aren’t already part of the ‘in crowd’ for the project?
Social Barriers to participation:
- Is the community open to communication and participation from outsiders?
- Is it clear and obvious how to become part of the conversation around the development of the software? Is it easy?
- Can consumers get reasonable access to and attention from developers?
Legal Barriers to participation:
- Are you using a standard license ((L)GPL, Apache, BSD, etc)?
- Is your entire code base licensed under that license?
- Is it clear to contributors what license they must contribute under?
- Is it clear to consumers what license they are consuming under, and what they have to do to comply?
Evaluating Community Health:
The higher the barriers to collaboration a community raises, the harder it is for it to become successful. When starting an open source project, or evaluating whether to consume or contribute to one, it can be helpful to consider the barriers to participation, as early indicators of whether or not the project is likely to become or remain successful.
What other barriers to participation do you feel are important to be kept low for open source success?
Along with several key industry players we announced the formation of and participation in ONF, the Open Networking Foundation with the purpose of promoting a new approach to networking, called software defined networking, open standards based of course, and implicitly open source since all compute loads (or clouds) need and want both, as we are continuously reminded.
Tags: cloud, ONF, Open, Open Networking Foundation, open source, open standards, OpenFlow
Every time I think about the relationship between Open Standards and Open Source I am reminded of a fascinating talk by Paul Saltman, a biochemist from Caltech, invited to speak to a Chinese forum years ago, about national food policy for China, later published in Caltech’s Engineering & Science, titled The Yang of Nutrition…The Yin of Food.
I am not a nutritionist, or biochemist, or expert on food -- though in more than one occasion I’ve been known to venture in the art - but I do know a little about open standards and open source - let’s just say enough to be sentient of the wholeness and synergy in which these opposites attract and coexist, perhaps not unlike The Cathedral and the Bazaar.
By the very nature of our industry, open standards are not just important, they are indispensable, the foundation upon which every internetworking protocol is based, the pre-requisite of interoperability, so naturally we take open standards seriously, the yang side, as it were. But what is often overlooked, just as the case with the yin of food in Saltman’s parallel, is the yin of open source, some of which is in fact the implementation, the other side, or yin as it were, of these open standards and more, with things like jabber or tigerstripe just to name a few. We’d like to tell you more about what we’re doing with these and other open projects, soon to be covered in this blog.
Tags: internetworking, ip, jabber, Open, Open at Cisco, open source, open standards, tigerstripe, yang, yin
Welcome to Open at Cisco, a place where we would like to keep you aware of things related to open source, open standards, open technologies and open developments in general. I’ve been at Cisco for several years now, involved in open source; when I started I did not realize how much Cisco has contributed since its inception. I think the BGP story and how it all started a while back exemplifies the collaborative spirit and nature of our contributions, granted some of them in open standards and some in other open endeavors, nevertheless, open standards and open source, particularly in our industry, go hand in hand, or as the IETF tenet goes, we do believe in rough consensus and running code.
Some of those examples have been listed on our website and as our pace of collaboration and contribution increases and diversifies, we’d like to share it with you. As we do, we would like to take the time to point out not just the typical contributions we’ve made to important and established things such as the Linux Kernel, Apache projects, Eclipse, or open standards such as SCTP, but to newer communities as well, such as the Open Stack collaboration mentioned last week, so be sure to check our website and of course, this blog. We really encourage you to join the conversation by commenting on this blog.
Tags: open development, open source, open standards, open technologies