7 lessons from Mozilla on community building
Open source is very popular these days, but it remains a bit of a mystery how to actually build a successful open-source project. I once reviewed some research on how to create winning open-source projects, but delivering results against basic principles remains a crap shoot of sorts.
I was therefore gratified to see John Lilly, CEO of Mozilla, weigh in on the subject with his excellent "Lessons from Mozilla" talk at Heise in Nuremberg, Germany, this week. With more than 220 million users and 40 percent of its code contributed by developers that don't work for Mozilla, the company behind the Firefox browser is an excellent example of open-source success.
Even so, Lilly was quick to warn people away from a cookie cutter approach to open-source success. While he was slated to discuss "how to bring an open-source project into the mainstream," he called out three serious caveats to that premise:
(Credit:
John Lilly)
Given that there is no One True Way to do open source, what are some key principles for aiding, though not ensuring, the success of a project?
Lily cites seven lessons that can be derived from the Mozilla experience. (I've added some context based on his presentation.)
- Superior products matter. Apache, Firefox, WordPress, Wikipedia, etc. What's the common theme? "All are known for being best-in-class for users." If the code is weak, the project will be weak. Period. Open source is an accelerant: it either makes poor code die faster or great code thrive faster.
- Push (most) decision-making to the edges. The important thing is to have "high agreement on core values," while simultaneously allowing developers closest to the code/problem to make independent decisions as to how to resolve issues.
- Communication will happen in every possible way (so make sure it's reusable). To eliminate wasteful re-explanation of why things were done in X manner, and to disseminate information on how or why decisions were made, it's critical to have open communication and the ability to revisit that communication after the fact.
- Make it easy for your community to do important things. Things like localization need to be easy in order to encourage adoption and use. If the community has to go back to the mother ship for every little thing, those little things will not happen.
- Surprise is overrated. Lilly states that "surprise is the opposite of engagement," and therefore Mozilla's goal is to "increase the 'inner circle' of participation." By allowing more people to participate in "core" decisions, the core grows, and the friction to actually get things done by a growing body of people grows along with it.
- Communities are not markets: members are citizens. It's therefore important to treat them like active, valuable participants in open source, not consumers thereof because, as Lilly notes, such citizens "don't just make products better. They make them what they are."
- The key (to successful open-source project building is) the art of figuring out whether and how to apply each of these ideas.
Excellent counsel, and a reminder that while open source is not easy, it can have powerful effects. Mozilla's Firefox would not be the same, if it were just another proprietary browser. It would just be Opera, which has struggled to be relevant in part because it has resisted open source.
Follow me on Twitter at mjasay.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
