What this process is, and where you can find it in your everyday life. Where did it start? A brief history of nerds changing the world. How does it work? The mechanics of freedom. How can I use it? Some practical advice.
are free to collaborate, we create and solve problems that no one person may be able to solve on their own Share. We learn more from each other when information is open Collaborate. Through “meritocracy”, the best ideas win Through Communities formed around a common purpose Let everyone else do the same.
for developers. One for users. One for casual watchers. The heart of the project. A complete history of all changes. Anyone can read, only committers can write. The to-do list. Where users and developers interact. Where you’ll learn why a change was made. ISSUE TRACKER
evolution. • Open a dialogue between inside and outside perspectives. • Invite different levels of participation. • Develop both public and private community spaces. • Focus on value. • Combine familiarity and excitement. • Create a rhythm for the community. Etienne Wenger, Richard McDermott, and William M. Snyder Cultivating Communities of Practice, 1st ed. (Harvard Business Press, 2002)
option” for consensus failure. Everyone loses in a fork, so when it happens, it is usually the only alternative. Keeps despots honest. By threatening the loss of their user and contributor community, project leaders become very accommodating. Proof that you have freedom. If you can fork the code, your fate is in your hands. For better or worse.
decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement). Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. IETF Working Group Guidelines and Procedures http://tools.ietf.org/html/rfc2418
web server on the planet was “a patch-y” fork of the NCSA web server. Android The popular mobile operating system forked Linux over irreconcilable design goals. WebKit The KDE project’s web browser engine was forked by Apple for its Safari web browser. KDE is considering “un-forking” the projects. X.org The ubiquitous windowing system for UNIX and Linux forked the XFree86 project over a licensing dispute.
It tells us how contributions are handled. Licensing determines the business model. If you compel source redistribution, how do you build a business? Licensing should be easy. If it’s too complicated, you lose contributors.
can make a copy. Include the source code. If you have the binary, you should have the code. Allows derived works. Let people change what they’re given. Non-discriminatory. You can’t restrict who can use it. Must not restrict other software. You can’t restrict what can use it. Technology-neutral. The “how” shouldn’t change anything.
"a change to one element in Mozilla is likely to impact three times as many other elements as a similar change in Linux. We conclude that the first version of Mozilla was much less modular than a comparable version of Linux." MacCormack, Rusnak, and Baldwin. “Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code” http://opensource.mit.edu/papers/maccormackrusnakbaldwin2.pdf “Mozilla, after its release as open source, was rapidly and successfully redesigned to become much more modular - at least as modular as Linux, in fact.... the differences in code appear to result from differences in organization.” Nick Carr, http://www.roughtype.com/archives/2006/01/open_sources_du.php
has tracked the code quality of open source software since 2004. Proprietary software, on average, has 20,000 to 30,000 defects per million lines of code. This has been true since 1960. 2004 Linux has 985 defects in 5.7 MLOC, or 99.3% lower than a proprietary system. 2005 Linux grew 4.7%, but defect density went down 2.3%. 2006 Funded by DHS, Coverity adds the LAMP stack and 32 OSS projects, and defect density stayed the same. 2008 Now covers 250 projects, with 434 defects per MLOC. Worst performer has 1237 defects per MLOC. 2009 Now covers 280 projects, with defect density down 16%.
use policy. Open source software is commercial software. Create a release policy. When can employees and contractors contribute? When should they? Track your software and license use. But you’re already doing that, right?
USE POLICY: BASICS Strategy Why are we bothering with a policy? Background What’s the state of the organization now? Process Who does the policy govern, who’s keeping track, and how decisions get made.
commercial software. Licenses are licenses. Manage licensing questions. Just like proprietary software, pay attention to the license. Which licenses will you accept, and under what circumstances? Define the support requirements. When is support required? At what level? Help projects decide what SLAs they need, and how those SLAs can be fulfilled. OPEN SOURCE STRATEGY - III CREATE A USE POLICY: PROCUREMENT
or do you require media? Where will the code be stored? Define the code evaluation process. How will you determine the code’s fitness? The quality of the community? Suitability of the license? Accommodate different use cases. Research and development is different than production. Encourage experimentation. OPEN SOURCE STRATEGY - IV CREATE A USE POLICY: SOURCING
Who approves contributions? Define the norms. Should changes be encouraged at all? When developers work with the outside, do they use their official email addresses? Expect new projects. Ensure a clear, obvious, and simple process for approving the release of brand-new projects. OPEN SOURCE STRATEGY - V CREATE A RELEASE POLICY
progress? What will indicate progress in different use cases? Define the tools. Where will downloaded code live? Where will you track license use? How can your staff discover what work their colleagues have already done? Define the reporting. How frequently will you report on your OSS use? What do you want people to know? OPEN SOURCE STRATEGY - VI TRACK SOFTWARE AND LICENSE USE
of policy creation. FOSSBazaar http://fossbazaar.org/ http://fossology.org/ A project to simplify open source policies. Open Source for America http://opensourceforamerica.org/resources http://opensourceforamerica.org/helpdesk References and a helpdesk for policy writers. OPEN SOURCE STRATEGY - VII RESOURCES
for America http://opensourceforamerica.org/ Helps government and industry use and make open source together. CivicCommons http://civiccommons.org/ Building an open source government stack. Mil-OSS http://mil-oss.org/ DoD and intelligence open source advocates.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki “I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix...” From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki “I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix...”