Product SiteDocumentation Site

TOSW 0.2.2

The Open Source Way

Creating and nurturing communities of contributors

Edition 1

Logo

Community Architecture

Red Hat Community Architecture team

Copyright © 2009 Red Hat, Inc.

Legal Notice

Copyright © 2009 Red Hat, Inc..
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
PO Box 13588 Research Triangle Park, NC 27709 USA

Abstract
This guide is for helping people to understand how to and how not to engage with community over projects such as software, content, marketing, art, infrastructure, standards, and so forth. It contains knowledge distilled from years of Red Hat experience.
A. Revision History
1. Introduction
1.1. What this book is
1.2. What it is not
1.3. What it is influenced by
1.4. Essential terminology or 'Read this even if you think you know what it means'
1.4.1. Community
1.4.2. Tactics
1.4.3. Strategy
1.4.4. Planets and blogs
1.4.5. Leaderless organizations
1.4.6. Version control
1.4.7. Content v. code repositories
1.4.8. Open collaboration tools
1.4.9. Open marketing
1.4.10. Science
2. Communities of practice
2.1. Introduction
2.2. What is a Community of Practice?
2.3. Elements of the Community of Practice
2.4. Principles for Cultivating Communities of Practice
2.4.1. Design for evolution
2.4.2. Open a dialogue between inside and outside perspectives
2.4.3. Invite different levels of participation
2.4.4. Develop both public and private community spaces
2.4.5. Focus on value
2.4.6. Combine familiarity and excitement
2.4.7. Create a rhythm for the community
2.5. Learn more
3. How to loosely organize a community
3.1. Community soil - true-isms to grow with
3.1.1. Initial building the soil or 'Get it going'
3.1.2. Ongoing soil support principles or 'Get out of the way'
3.2. Community building tools - just enough to get the job done
3.2.1. Initial tooling or 'Get it going'
3.2.2. Ongoing tools or 'Get out of the way'
4. Stuff everyone knows and forgets anyway
4.1. Embrace failure
4.2. Communities require care and feeding to get started ...
4.3. ... And communities need to be left to grow and evolve
4.4. Remember what you learned in Kindergarten
4.5. Take extra extra extra care to have all discussions in the open
4.5.1. Radically visible meetings at all times
4.5.2. No decision point is too small to pre-announce to a mailing list
4.5.3. How to let a mailing list run itself
4.6. Take even more care to do all design and decisions in the open
4.7. Use version control for your content as well as code - everyone watches the changes
4.8. Choose open tools that can be extended
4.8.1. Make sure everyone has an equal and clear method for access to write-commit to open tools
4.8.2. Tie this together with open content
4.9. Focus on healthy and open community interaction
4.9.1. Make governance as clear as possible
4.9.2. Use your lawyers well while avoiding too much legalese
4.9.3. Do not let poisonous people bog down the community
4.9.4. Communicators need to communicate - do not let liaisons go silent
4.9.5. Disable poisonous communication
4.10. Seek consensus - use voting as a last resort
4.11. Reassign your benevolent dictators while evolving toward a consensus-based democracy
4.12. Do not forget to release early and release often
4.12.1. Release early and release often is for more than just code
4.13. Evolve with the growth of your audience and contributors
5. What your business does correctly when practicing the open source way
5.1. Identifies and focuses on key future technology
5.2. Funds key open source development
5.3. Makes mistakes and learns from them
5.4. Is daring about applying the open source way to non-engineering teams
5.5. Works hard to preserve culture in a fast growing company
5.6. Takes people who think they understand the open source way and really teaches them how it works
5.7. Has a strong brand and steers that consistently through community interactions at all levels
6. What your business does wrong when practicing the open source way
6.1. Burns projects and losses momentum in technology leadership by ignoring community fundamentals
6.2. Breaks fundamental rules of community
6.3. Fails to learn from mistakes
6.4. Misses the opportunity to adopt and grow key or future open source technology for your own IT
6.5. Does not include community strategy in all new projects
6.6. Separates community from business
7. Business the open source way
8. Who else to watch
8.1. People
8.2. Groups
9. Books you should read
10. Community Architecture dashboard
11. Data and references
11.1. References
11.2. Data
12. How to tell if a FLOSS project is doomed to FAIL
13. Appendix
Index