Fail Faster Lessons from the open source community Gunnar Hellekson Lead Architect, Red Hat Government GTC Southwest 18 February 2010

This isn't about writing code. It's about successful collaborative projects, and what we can learn from them. Do to that, we need to know: ● Who participates, and why. ● How they're managed. ● How feedback drives the process. ● How to create the largest possible community. ● How to create effective collaboration. ● How to derive the greatest value from your project.

Anarchist girl goes here Licensed CC-BY 2.0

Licensed CC-BY-SA 2.0

Governance.

Picture of Clay goes here, captioned: Enemy of Democracy Licensed CC-BY-NC-ND 2.0

Picture of Clay goes here, captioned: Enemy of Democracy “Democracy is the enemy of useful work.” Licensed CC-BY-NC-ND 2.0

Working groups make 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

Working groups make 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 Illustration of forking A fork is a weapon against tyrants. Licensed CC-BY-NC-ND 2.0.

Architecture of participation.

Display a feedback loop here. A better, smaller feedback loop.

“Often times, the end products of these investments fall short of user and customer expectations due to: ● Not understanding the end user needs ● Not having access to requirements or feedback from users prior to, or during the research and development ● Not having access or awareness into the military's top-requested and desired capabilities ● Lack of awareness into what investments are being made by the DoD in their research labs ● Lack of access to the actual users and customers who have expressed the need for a specific capability” Edge Innovation Network

Architecture of collaboration.

Everyone can help. Not just developers.

"Have a problem. Get a bunch of people interested in the problem. When they show up, have something useful for them to do." -- Greg DeKoenigsberg Image licensed CC-BY-NC 2.0.

opengovtracker screenshot Even non-experts can help.

FEC Story Getting permission.

Your project is a platform.

“The Springfield Rifle cost $20 each at the Springfield Armory where they were officially made. Overwhelmed by the demand, the armory opened its weapons patterns up to twenty private contractors. The most notable producer of contract Model 1861 Springfields was Colt, who made several minor design changes in their version, the "Colt Special" rifled musket. These changes included redesigned barrel bands, a new hammer, and a redesigned bolster. Several of these changes were eventually adopted by the Ordnance Department and incorporated into the model 1863 rifled musket." — "Springfield Model 1861"

Plugin illustration Letting accidents happen.

The open source way, software as a platform. Even a document can be a platform.

Activity creates activity.

The importance of rhythm Licensed CC-BY-NC-ND 2.0

“Whoops. This is science.” Image licensed CC-BY-NC 2.0.

Open Source as a community of practice. Design for 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)

...a little less formally: Contributors are customers. They're not doing it out of the goodness of the heart. They want something. When they show up, have something for them to do. A transparent process, run by a despot, works better than a democracy. Make sure everyone know the rules for collaboration. Especially in government. Let everyone make mistakes. If they don't, they'll never innovate. Just make sure they fail small and quickly.