Voices of Open Source

OSI Policy Team

How Open Source Is Your Open Source?

Michael DeHaan has an excellent post entitled “How Open Source Is Your Open Source?”. I dare say it is his best post despite getting in a few (Linux) distro biased comments. He proposes a set of community standards that determine the real health and openness of Open Source. In my opinion, a major problem with OSI at the moment is that it perpetuates (mainly indeliberately) that a mere license makes something Open Source. In my view, an Open Source license is really the first step in making software Open Source. Fundamentally, the license provides the “right to fork” in the event that the people running the “Open Source In License Only” ignore the community. However, forking is a pretty wasteful process. It does damage. In the best case scenario, most people vote with their feet. In a worst case, you end up with 2-3 insufficiently resourced projects. Forking is the evolutionary and revolutionary alternative to cooperation.

A lot of “new breed” open source companies and “old school” tech companies that are getting involved in Open Source structure a lot around maintaining control. This can be for many reasons, but a large reason is that Open Source is not, in itself, a business model. Software development does cost money and resources. Finding the right way to fund that is hard. Traditional thinking is that you chain off part of the “property” and charge admission. However, in that process you diminish some of the benefits of Open Source. You loose the synergies of cooperation. These are the golden goose of Wall Street. It is why, despite all of the failures, everyone is still looking for the next Multi-Billion dollar merger. We must question whether Software that is Open Source in License Only, with the same distribution and cooperation characteristics (*1) as proprietary software, actually realizes many of the benefits of Open Source until someone forks it. Is that really Open Source or just Potential Open Source? I guarantee this isn’t what your Open Source vendor’s marketing department told you.

Michael’s post proposes standards that can be summarized and categorized (with annotations and examples at the bottom) as:

project health

  • 1. Critical Mass – a large enough user base to sustain the project.
  • 2. Issue Tracking – a clear issue tracking system that allows everyone to report and track the status of bugs, features and tasks.
  • 3. User Advocacy – “You have users talking about your software with other potential users.”

collaboration

  • 4. Open Forum – An open forum for participation
  • 5. Participative Decision Making – The decisions happen in the Open Forum without separate classes (an inner list).
  • 6. Outside Participation – Many projects are started or funded by some organization. A key check on the health and life of the project is whether those outside that organization are actually submitting patches. This isn’t just User Participation but outside developers. Michael said it best: “[To] do this, you first need happy users and a community that feels like they can ask questions and become engaged.”
  • 7. Site Navigation leads quickly to code and distribution – “It’s easy to find your licensing terms and where to download the code on your website. If it’s not easy to find, chances are your definition of open source is ‘you can download the code’, but the open source development model is not being followed too well. Open source is not a feature to put on a web page on your ‘pay us now’ page, but is something you do every day. And it’s not just about the code, it’s also about the process.”
  • 8. Patches from potential competitors are welcome – *2
  • 9. Upstream patches – Much of Open Source Software is built from other Open Source Software. A key community health factor of the whole is whether contributions can flow back up from the project (say Ubuntu) to the packages it contains (say the wireless driver).*3
  • 10. “Every single bit of your “thing” is open source – Having ‘pro’ versions that are not open source means your advanced features do not benefit from community effects.” *4

organization

  • 11. Unprompted patches are easily integrated – Some projects have strong upstreams but can’t integrate in new ideas in any given release cycle. A key benefit of Open Source is this participative adaptability. You can contribute without having to wait for a vendor to think it through in their long distance plans.
  • 12. Release Plan – “Your users know what the plan for your future release is.”
  • 13. Granular Participation – The ability to participate without joining a committee or the highest traffic mail list known to humanity.

Or as Michael Summarizes, “Bottom line conclusion: strive to be Open in everything you do”.

So what do you think? Should OSI develop standards beyond the current license-centric set of standards known as the “Open Source Definition”?

annotations

  • 1. File a request with the vendor or pay up.
  • 2. We saw an interesting example of this recently in Microsoft’s patch to ADODB.
  • 3. For example, JBoss Application Server contains many packages from Apache. The Ubuntu Linux distro contains a lot of Debian packages along with packages from many other groups.
  • 4. A key illustration of this is Adobe Flex. Although Adobe open sourced Flex from a license standpoint, you can not run a Flex app without a proprietary runtime. There are Free/Open Source efforts such as Gnash, but these operate in a vacuum and Flex apps generally require a fairly modern version of Flash. Another illustration is Sun’s release of OpenJDK which included binaries under a restricted license. Iced Tea addresses this problem…with a sort of fork really.