How to grow communities is a hot topic these days. Francesco Lodolo recently blogged about how the Mozilla Italia community mainly consists of veterans who have been participants for several years, and how hard it is for them to find new contributors.
Illustration: Grow by Amy.Ng
Abdulkadir Topal from the German community also blogged about getting help for localization work on the European Mozilla Community Blog and reached an interesting conclusion about how to turn new and casual contributors into long-time community members: the key is to distribute ownership.
Kadir uses Thomas from the German localization team as a good example of this theory: Thomas is a relatively new community member (“only” two years worth of contributions so far!), yet he is one of the most active members on SUMO today. The key factor for why this happened, according to Kadir, is that Thomas was given full responsibility for the SUMO component within the German localization team.
As Kadir concludes, it’s “one thing to contribute little bits and pieces to a [project], but it’s a completely different thing to own it.”
I find this theory interesting. Maybe it is not a universal law that can be applied to everyone or every type of project/responsibility, but looking back at my initial involvement with Mozilla, ownership was definitely part of what motivated me — but not all of it, as I will explain below.
Kadir mentions in his blog post that it was something as trivial as a product logo that made me discover the Mozilla project in the first place. To me, the little Gecko logo — featured in an article about the planned Netscape 6 browser based on the previously open-sourced Netscape 4.x codebase — communicated “lean and mean,” and the article went on explaining how this new Gecko HTML rendering engine would be modern, compatible, portable, and small enough to be used even in future handsets (and guess what; about nine years later it turns out that they were right!).
Just a few days later, I learned that Netscape 6.x was just a branded and slightly outdated version of something called “Mozilla,” which apparently was the open source project behind the well known Netscape browser. I immediately switched to Mozilla instead, since it was more bleeding edge and therefore more fun for a geek like me.
That’s how it started for me. However, that wasn’t the reason why I sticked. Why did I turn from just interested in Mozilla to a deeply involved contributor? I will try to explain this and get back to Kadir’s theory, but I can say right now that there is a lot more than one reason why I’m still an active Mozilla community member.
It started around year 2000 with the realization that I could actually affect the project by submitting bug reports and providing feedback. Although open source as a concept wasn’t new to me, I had never actually gotten involved myself before. This, combined with the fact that I got to know other people with similar interests, made reading the newsgroup daily a pleasure.
However, I always felt that the original Mozilla suite represented something from the past, and that the way of the future was something lean and mean (yes, that Gecko logo that got originally got my attention!). The word “monolithic” was often used to describe the Mozilla suite, and even the word itself felt big, old and unmanageable to me. When the Phoenix project was announced on MozillaZine, I immediately turned my focus to that instead, and never looked back.
Because the project was still small and new, it was also a good opportunity to get more deeply involved because the signal to noise ratio was higher. Many people in the Mozilla community were still skeptical about Phoenix and preferred the tried and true Mozilla suite. This made the feedback I provided to the Phoenix project much more visible than it had been for the suite, making it a lot more rewarding for me to contribute.
As the project started to shape up with the release of Phoenix 0.3, I found myself heavily involved with things like filing bugs and RFEs, discussing feature implementations with developers, and, most often, answering questions from the growing number of users of Phoenix. As this consumed more and more of my time, I realized that there wasn’t a centralized place for people to get help with Phoenix. I viewed this as my opportunity to finally give something meaningful back to the project, and spent a couple of afternoons creating a small site called Phoenix Help. It was also a more meaningful way to develop my HTML/CSS coding skills compared to creating a website for, say, a Brood War clan (let’s call it UU).
Phoenix Help was very small and seemingly insignificant, but it was quickly noticed and appreciated by fellow community members in the MozillaZine forums. I especially remember getting my first personal e-mail from Asa Dotzler thanking me for doing what I did and encouraging me to continue the great work. This meant a lot for my motivation, because it was a confirmation that what I was doing was appreciated.
Before I knew it, people were linking to my site from all sorts of places (starting with Phoenix 0.5, even the release notes linked to it!), which made it even more important for me to ensure that the site looked good, was easy to use, and that the content was up to date. I was, in fact, responsible for the support site of Phoenix — I “owned” that part of the Phoenix project!
To wrap up, there were several things that motivated me to stay active in the Mozilla community:
- A belief in the mission of the project — to create a web browser that supports and promotes the use of open standards
- An interest in the technology — initially with the Gecko logo as my hook
- The feeling of belonging in a community of people with similar interests
- The desire to give something back to a project that gave (and still gives) me the best browser in the world for free
- The experiences gained by managing a website — HTML, CSS, server configurations, and perhaps most importantly, the English language
- The recognition and respect from Mozilla project members for my contributions
- The pride of being responsible for an important piece of the project
When I look at this list, I realize that it’s impossible to point to one particular motivator for community members, and that everyone probably has their own unique list. More personally, I also note that my motivation model today is the exact same as it was when I got involved seven years ago.
Despite the fact that the list is based on my personal experience, I think that all of the motivators could be taken into consideration for anyone trying to build or grow a community. Depending on the project, some things might be more important than others, but they all affect your community:
Tree Climbing Cat by mokwai
- Does your project add value to people using it? Do people feel like they are making a difference by contributing?
- Is your technology cutting-edge? Is it solving a unique problem? Is your project making people feel “wow, I want to be part of that!” or “I’d love to learn more about that”?
- Is your existing community friendly, welcoming and collaborative? Are tasks and discussions communicated in the open? Do people in your community have fun together?
- What kinds of contributions are welcomed? Does your project offer different ways to get involved?
- What’s in it for the contributors? Aside from the positive feeling of making a difference, do they gain relevant experiences by contributing to your project?
- Do you reach out personally to community members and make them know that their contributions are appreciated? Do you have automated systems in place to show the impact contributors make (e.g. a karma system)?
- Is your project modularized enough to allow people to take ownership of parts of the project?
There you have it — my first attempt to unwrap the mystery of building and growing communities. Is this helpful? Do you have similar experiences? I would love to hear what you think!
djst's nest 