The Ten Commandments of Open Innovation

Location: E145 Level: Novice
Average rating: ***..
(3.40, 5 ratings)

Open source is now ubiquitous and is well recognized as a best practice to produce innovative technology in today’s world. However this is not enough. Open innovation, i.e. the collaboration of multiple companies as equals on a given technical commons, exists in a few key historical projects, but seem to be complex to bootstrap in new ones. It yields substantial benefits though: avoid duplication of effort, get greater participation, empowered developers and the promise of standardization. Without it, the community is generally owned by a given party, and others restrict themselves to tactical contributions rather than investing substantially in long-term, strategic contributions.

Based on my experience coordinating collaboration on the OpenStack project since 2010, I reflected back on what we did well, and what I wish we had done differently. This advice can be distilled down to ten basic principles that could apply to any open source project that wants to fully enable open innovation.

1. Thou shalt not control: Abandon the idea of controlling the project, and use the influence of your contributors instead. If you can only remember one, this is the most important.

2. Thou shalt be a true meritocracy: From the very start of the project, contributors should elect their drivers, and those drivers should be empowered to make drastic changes to the project.

3. Thou shalt not invoke the gods in vain: The governance structure should delegate most of its power to the people that actually do the work. The drivers need to be called only when an issue cannot be solved at subproject level.

4. Thou shalt not tolerate poison: Your community needs to have fun. It takes just a few poisonous people to ruin it: adopt a code of conduct early, and get a vocal developer community manager to enforce it.

5. Thou shalt openly design: Opening the code and accepting patches is not enough: everyone needs to participate in the project design. Have public design summits and empower the people there to make decisions.

6. Thou shalt develop in the open: Death to the water cooler ! Everything must happen in public: discussions, blueprinting, code reviews, development trees. Really use IRC, public roadmaps, DVCS, code reviews.

7. Thou shalt not be too agile: Controversial corollary of #6. While some aspects of Agile like TDD apply very well to open innovation projects (and development subgroups may use Agile), it prevents efficient and open global collaboration.

8. Thou shalt automate: You abandoned traditional command-and-control, replace it by process automation. Everything that can be automated, should be automated. Use continuous integration, trunk gating on integration tests.

9. Thou shalt be cadenced: You should release early, often and on time. A demanding cadence gives a rhythm to all stakeholders, and time-based releases are a great community enabler.

10. Thou shalt converge through shared understandings: Isolation, fragmentation and confusion are the three collaboration challenges for your project. Thoroughly documenting your process will generate the clarity necessary to avoid confusion.

A few of those topics have been developed in blog posts at:

Photo of Thierry Carrez

Thierry Carrez


Thierry Carrez has been facilitating collaboration and open innovation since 2010 as the Release Manager for the Openstack project. An Ubuntu Core developer and Debian maintainer, he was previously the Technical lead for Ubuntu Server edition, and an operational manager for the Gentoo Security Team. In a previous life, he used to be an IT Manager for small and large companies. He is working home-based from a small village in the center of France, where he lives with his wife and two daughters.


For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at (707) 827-7065 or

View a complete list of OSCON contacts