X

7 lessons from Mozilla on community building

During a talk at Heise in Nuremberg, Germany, Mozilla CEO John Lilly helps us understand how to create successful open-source projects, with some significant caveats.

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
3 min read

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:

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.)

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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."
  7. 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.