Open Source Community, Simplified

Growing and maintaining an open-source community depends essentially on three things:

  1. Getting people interested in contributing
  2. Removing the barriers to entering the project and contributing
  3. Retaining contributors so that they keep contributing

If you can get people interested, then have them actually contribute, and then have them stick around, you have a community. Otherwise, you don’t.

If you are just starting a project or need to improve the community of an existing project, you should address these points in reverse order. If you get people interested in a project before you do the later two steps, then people won’t be able to enter and won’t stick around when they do enter. You won’t actually expand your community. So first, we want to be sure that we can retain both existing and new contributors. Once we’ve done that, then we want to remove the barriers to entry, so that interested people can actually start contributing. Only then do we start worrying about getting people interested.

So let’s talk about how you accomplish each step in reverse order:

Retaining Contributors

For the Bugzilla Project, this was our biggest challenge. Once somebody started contributing, what made them keep contributing? How did we keep people around?

Well, we had an interesting advantage in answering these questions, in that we are one of the older open-source projects in existence, having been around since late 1998. So we had a tremendous wealth of actual data to work with. We mined this data in two ways: First, we did a survey of all our past developers who had left the project, asking them why they had left. This was just a free-form survey, allowing people to answer any way they wanted. Then, we created a graph of the number of contributors over time, for the whole ten years of the project, and correlated the rise and fall of the graphs to various actions we took or didn’t take over time.

Once all this was done, I sent an email that out to the developers Bugzilla Project, describing the results of the research. You can read the whole email if you’d like, but I’ll summarize the findings here:

  • Don’t freeze the trunk for long periods.

    The Bugzilla Project has a fairly-standard system of having stable branches that receive little change (for example, the “3.4” branch where we commit bug fixes and do minor releases like 3.4.1, 3.4.2, etc.), and a main-line “trunk” repository where all new features go, and which eventually becomes our next major release.

    In the past, before a major release, we would “freeze” the trunk. This meant that no new features could be developed for several weeks or months until we felt that trunk was stable enough to call a “release candidate.” Then we would create a new stable branch from the trunk and re-open the main-line trunk for features. However, while trunk was frozen, there was no feature development happening anywhere in the Bugzilla Project.

    Graph analysis showed very clearly that every time we would freeze, the community would shrink drastically and it would take several months after we un-froze for the size of the community to recover. It happened uniformly, every single time we would freeze, over many years and many releases.

    Traditional wisdom in open-source is that people like to work on features and don’t like to fix bugs. I wouldn’t say that that’s exactly true, but I would say that if you only let people fix bugs, then most of them won’t stay around.

    We addressed this issue by never freezing the trunk. Instead, we branch immediately at the point that we normally would have “frozen” the trunk. The trunk always stays open for new feature development. Yes, this means that for a while, our attention becomes split between the trunk and the latest branch. We’re committing the same bug fixes to the branch and the trunk. We are also doing feature development on the trunk simultaneously with those bug fixes. However, we’ve found that not only does the community expand more rapidly this way, but we also actually get our releases out more quickly than we used to. So it’s a win-win situation.

  • Turnover is inevitable.

    The survey found that the number one reason that contributors leave is that they no longer have time to contribute, or that they were contributing as part of their job and now they have changed jobs. Essentially, it is inevitable that most contributors eventually leave.

    So if it community members are definitely going to be leaving, the only way to consistently expand the community is to figure out how to retain new contributors. If you don’t get new members to stick around, then the community will continuously shrink as old contributors leave, no matter what else you do.

    So while retaining existing contributors is important–after all, you want people to stick around and contribute for as long as reasonably possible–what matters the most is retaining new contributors. How do you do that? Well, that’s a lot of what the rest of these points are about.

  • Respond to contributions immediately.

    The Bugzilla Project has a system of code reviews that requires that all new contributions be reviewed by an experienced developer before they can become part of Bugzilla. There have been various complaints about the system over the years, but analyzing the survey data showed that people leave the project because getting a review takes too long, not because the reviews are too hard. In fact, the reviews can be as hard as you want as long as they happen almost instantly after somebody submits a contribution.

    People don’t (usually) mind having to revise a contribution. They even generally don’t mind revising it several times. But they do mind if they post a patch, don’t get a review for three months, and then they have to revise it, only to wait another three months to be told that they have to revise it again. It’s the delay that matters, not the level of quality control.

    There are other ways of responding rapidly to contributions, too. For example, immediately thanking somebody for posting a patch can go a long way toward retaining new contributors and “converting” them into long-term developers.

  • Be extremely kind and visibly appreciative.

    For nearly every person who responded to our survey, the factors involved in not staying–beyond “my job changed” or “I didn’t have time”–were surprisingly personal. I know that we all work with computers, and perhaps we’d like to think that engineering should be a totally cold scientific profession where we all do our jobs correctly according to the requirements of the machine, and not worry about our emotional or personal involvements. However, nothing could be further from the truth–the personal interactions that people have with community members, the amount they feel appreciated, and the amount they feel assaulted, are actually the most important aspects of retaining community members.

    When people contribute on a volunteer basis, they aren’t getting paid in money, they are getting paid in admiration, appreciation, the sense of a job well done, and the knowledge that they are helping create a product that affects millions of people. When somebody has contributed a patch, you need to thank them. It doesn’t matter if the patch is total crap and has to be re-written entirely, you need to thank them. They have put some work into this, and if you don’t appreciate that, they will leave before they even start. After all, most people get little enough appreciation at their workplace–they stay there because they get paid in money! They don’t need to work for free with some other organization if it also doesn’t appreciate their work, or even worse, assaults every aspect of their contribution before even thanking them for it.

    Of course, you still need to correct people on the faults in their contributions. “Kindness” does not include putting bad code into your system. That isn’t kind to anybody, including the contributor whose skills probably need to improve, and who may go on believing that something they did in error was in fact correct. You have to still be careful reviewers and very good coders.

    What this does mean is that in addition to telling people what’s wrong with their contribution, it’s important to appreciate what’s right about their contribution, even if it’s simply the fact that they took the time to contribute. And you have to actually tell the contributor that you appreciate the contribution. The more frequently and genuinely that you do this, the more likely you are to retain the contributor.

  • Encourage a total absence of personal negativity.

    One thing that drives people away from a project with lightning speed is when they get personally attacked for attempting to do something positive. A “personal attack” can be as little as an unpleasant joke about their code, instead of just a straightforward technical description of what is wrong. Saying something like, “What is wrong with you?” instead of actually leaving some helpful comment. Disguising personal criticism as “an attempt to help them code better” or “help them get along with others.” No matter how well-justified these actions may seem to be, they are all personal attacks that are extremely dangerous to your community.

    Now truthfully, coding and working on a collaborative project with people who have different viewpoints can get really frustrating sometimes, and I’ve been an offender in this area just as much as anybody has been. But we all have to learn that it’s not okay to insult other developers as people just because we’re personally frustrated with them.

    The solution isn’t just to say “everybody, now bottle up your frustrations until you explode,” though. There are lots of practical solutions. One of the best is to set up some specific system for handling problematic contributors. If there’s some contributor that Bob just can’t live with, there needs to be somebody in the community who Bob can go to to help work things out. We’ll call this go-to person the “community moderator.” So Bob tells the moderator about the problem, and maybe the moderator sees that other contributor really was being a terrible person or bad coder, and so this “community moderator” gently corrects that contributor. But it’s also possible that there was some communication problem between Bob and the other contributor that the moderator just needs to help resolve.

    This “moderator” system isn’t the only way to deal with the problem. You can resolve the problem in numerous ways–the most important thing is that you do resolve it. Without some channel or method for dealing with personal frustrations, individual contributors will take these frustrations out on each other. You will in fact foster an environment where it’s okay for one contributor to personally attack another contributor, because that’s the only avenue they have to resolve their problems, and nobody’s stopping them.

Basically, those last two points can be summed up as: be really, abnormally, really, really kind, and don’t be mean.

We’ve been applying all of these principles in the Bugzilla Project for the past several months, and we saw an increase in the number of retained contributors almost immediately after we started applying them. I’m finally starting to feel like the community is growing again, after shrinking almost continuously since 2005 due to violations of all of the above points.

Removing the Barriers

The next step is to remove the barriers to entry. What prevents people from getting started on the project?

Usually, the biggest barrier is a lack of documentation and direction. When people already want to contribute, their next step is figuring out how to contribute. They will go to your project’s website and look around. They will wonder, “Who do I talk to about this? How do I start contributing? What do you guys want me to work on?”

For the Bugzilla Project, we solved this problem in several ways:

  1. A list of easy starting projects.

    Whenever we see a bug or feature request that looks like it would be easy for a newcomer to solve, we tag it as a “good intro bug” in our bug tracker. This gives us a list of good introductory projects that anybody can come and look at without having to ask us “where do I get started?”

  2. Create and document communication channels.

    People will almost immediately want to talk to somebody else about the project. You should have email lists and also some method of instantaneous communication like an IRC channel. For example, we have an email list for Bugzilla developers and also an IRC channel where almost all our contributors hang out. In fact, we don’t just have a normal IRC channel–we also have a web page that people can use to chat in that IRC channel. That way, people don’t have to install an IRC client just to come talk to us. Setting up that web page enormously increased the number of new people coming into the channel and communicating with us. (And the increase was entirely positive–I can’t think of a single person who used the web gateway to cause us trouble.)

    Then once you have these channels, they need to be documented! People have to know how to get into them, they need to know that they exist. We have a wiki page that explains how to talk to us if you want to contribute. (Note that this is separate from our support page that describes how to get support for the project.)

    Also, as a final but perhaps obvious point, the existing community has to use the communication channels. If the main contributors do all their work in an office and just talk to the people next to then and you don’t use the mailing lists or IRC channels, then the community members aren’t going to want to use those communication systems either. After all, the new contributors aren’t there to talk to each other–they’re there to talk to you!

  3. Excellent, complete, and simple documentation describing exactly how a contribution should be done.

    Fully document every step of your development process, and put that documentation onto a public web site. Don’t invent a new process, just document out what the existing actual process is. How do people get the code? How can they submit patches or other contributions to you? How do those contributions become an official part of the system?

    We have a very simple page that describes the basic steps of our whole process, and links to documents that describe each step in more detail. It also specifically encourages people to get into communication with us, so that we know that they are there and want to help.

  4. Make all this documentation easy to find.

    This is a simple final step, but sometimes projects forget it! You can have all the wonderful developer documentation in the world, but if new contributors can’t find it super-easily, then you’re not actually removing any barriers to entry! We have a big “Contribute!” button on our website that describes all the different ways that people can contribute (not just code!) and links to more information about each of those.

We saw a definite upswing in the number and quality of contributions once we completed all these steps. Also, having everything documented and clearly stated on a public website meant that we no longer had to personally explain it all, every time, to every new contributor.

Direction and documentation aren’t the only things you can do though. Ask yourself, “What is stopping people from contributing?” and remove all the barriers there that you reasonably can.

Getting People Interested

How do you make people think, “Gee, I want to contribute to this project?” That’s the first step they have to take before they can become become contributors. Well, traditional wisdom states that people contribute to open-source projects because:

  • They like helping.
  • They enjoy being part of a community.
  • They want to give back.
  • They think that something is wrong and they need/want to fix it.

So you may want to make it apparent that help is needed, that an enjoyable community is there, that giving back is appropriate and appreciated, and that there are problems that need solving.

Now, to be fair, this is an area that I don’t have fully mapped out or figured out for the Bugzilla Project, yet. So I don’t have a lot of personal experience to draw on. But if we analyze other projects, we can see that some good ways of getting contributors are:

  • Be a super-popular product.

    This may seem obvious, but it is indeed the primary way of getting new contributors. If a zillion people use your product, it’s statistically likely that many of them will want to contribute. The Linux Kernel and WordPress are good examples of this–they have millions of users, so there’s just bound to be a lot of contributors, provided that the “barriers to entry” and the “retaining contributors” aspects of the project have also been handled.

    One way to become a super-popular product–even if you’re just starting out–is to be heavily needed. The Linux Kernel was very much needed when it was first written, which is probably one of the reasons that it became popular as quickly as it did. It desperately needed to exist and didn’t exist yet.

  • Be written in a popular programming language.

    Generally, people are more likely to contribute to a project if it’s written in a language that they already know. WordPress has a huge contributor community, and it’s in PHP. Say what you will about PHP, it is extremely popular. There’s a large number of people who already know the language, which increases the likelihood that some of them will start supplying patches for your code.

    This not the only reason you should choose a particular programming language, but it’s certainly a major motivator if you’re going to have an open-source project. I may think that Eiffel is a remarkable language, but if I wrote an open-source project in it, I would have a very hard time getting contributors.

Beyond those points, there are lots of clever ways of getting people interested in contributing to your projects, including speaking at conferences, publishing blogs, encouraging people on a one-to-one basis, and other methods that basically add up to “contact and encourage.”

I’d love to hear some of your ideas in this area, though. How do you get new people interested in contributing to your project? Has anything been particularly successful?

Summary

An open-source community is somewhat of a fluid thing–there are always going to be people coming and going for one reason or another. What’s important is that the rate of people entering and staying is greater than the rate of people leaving. All of these points help assure that, and hopefully they also make our communities productive and enjoyable places to be for everybody, even ourselves!

-Max

46 Comments

  1. Great blog post! I’ve been experimenting with ways to improve the MozillaQA community. This has given me some ideas — thanks!

    Reply

    • Wow, that is an excellent post. Absolutely fantastic. The cool thing about Damien’s experience is that he comes at it from the other end–he started a project and brought it up to popularity, whereas I came into an existing project and had to figure out how to bring it back to popularity with the community.

      His point about quality of developers vs. quantity of developers is well-taken. I think the best balance might be Python, where the language itself tends to attract high-quality developers, but there are a good number of them.

      -Max

      Reply

    • Thanks! That’s an interesting post–there are some things that I’d disagree with you on, but there are some useful tips there for people who want to have a project. Of course, people should always use their own judgment as to what applies practically and what doesn’t, for themselves.

      -Max

      Reply

  7. Hi Max,

    Thank you very much for doing research about this and documenting it so well. I am active in several projects over at eclipse.org, and your conclusions make a lot of sense to me. There is one more thing that I would add to your list: In my experience, long-term contributors, or larger contributions over and above the usual bugfixes or incremental features, only happen if the current committers on the project leave “gaps” and are very transparent about it. Only if you communicate very clearly which areas you are focusing on and which ones you are not, potential contributors can identify a niche which they can fill. Does this sound plausible to you?

    Reply

    • Hey Boris. Thanks for the awesome comment and the compliments.

      You know, I’ve heard this statement about leaving “gaps” a few times–most famously phrased by Linus Torvalds as something like “if you release things that suck then people will want to fix them” (I don’t remember the exact phrasing).

      So the problem with this is that I haven’t been able to reliably prove that it’s true. There are significant parts of Bugzilla that need a lot of love, and we’ve clearly advertised many times that these parts need love, and yet they haven’t gotten any love for years and years. So I don’t think that “leave gaps” is, by itself, a workable-enough philosophy. I think it’s definitely important to allow people to help and give them somewhere that they can help, but so far, the only thing that leaving gaps has gotten us is gaps.

      -Max

      Reply

      • Hi Max,

        Total agreement with everyone, a very nice piece – I refer to it in an article I wrote recently on writing roadmaps: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/

        Indeed, leaving gaps where people can get involved, not in terms of a module that’s unloved, but in terms of an improvement you think would be useful, has served me well in the past.

        To work well it does need to be mixed with a good and efficient mentoring program, and it’s not straightforward to build one of those. Graham Percival’s presentation at RMLL last year on sustainable developer communities was an eye-opener for me: numbers-backed evaluation of the effectiveness of mentoring programs: http://percival-music.ca/blog/2010-08-01-sustainable-development.html

        Cheers,
        Dave.

        Reply

        • Hey Dave. Thanks for the link to your blog and Graham’s presentation!

          I was totally intrigued by the presentation slides; it sounds like he discovered a lot of the same things that I did during my Bugzilla research! That’s a pretty good independent reproduction, enough that I’d say that we’ve probably got some pretty strong natural laws here for open source communities.

          I suppose that we do indeed have that list of improvements that would be useful–I suppose the problem is that so many of them aren’t appropriate for newbies. Of course, I suppose our “good intro bugs” system is also a good method of “leaving gaps” that we do intentionally, so perhaps that’s the place that falls into for us.

          -Max

          Reply

  9. Good post Max, and long time no chat. It’s been awhile since having that beer in BJ’s Brewhouse last year. I created a presentation awhile ago that echoes some of these points, it was mainly intended to students I worked with who were interested in open source but didn’t how to get involved…

    http://www.slideshare.net/caniszczyk/open-source-from-the-trenches-how-to-get-involved-with-open-source-and-be-successful

    I whole heartedly agree with your point on “be really, abnormally, really, really kind, and don’t be mean.” I keep telling people to kill people with kindness in open source. Anyways, it’s nice to see people writing about stuff like this from the open source community.

    Reply

    • Hey Chris! Yeah, been awhile indeed! 🙂

      That presentation is awesome! I love “Find your passion, contribute to it.”

      I noticed that you used the Fedora “Join” icons for all the different things that people can do on a project–it’s funny because to at least some degree, those evolved out of a comment that I made to some of the Fedora Project leaders during a FUDCon many years ago. 🙂

      And “kill people with kindness,” for sure. 🙂

      And thanks for the comment in general, I’m glad to get so much awesome feedback from all the FOSS people out there. 🙂

      -Max

      Reply

  10. Great read Max.

    [If you think I’m off the mark historically, please scrap my comment]

    I first deployed bugzilla probably in the year around 2000/2001 when working as a new IT guy for a games development studio.

    Please excuse the historical ramble I’m about to proceed on, but I think there’s a point to it.

    I installed it for one of our technical directors to evaluate on Pentium133 in my office(which doubled as my network management workstation). Within probably a week it was in full use by our developers and QA dept for two games we published on the Dreamcast platform. From memory, the two projects were finished, and more than 10,000 bugs were logged before moving it to worthy hardware in the server room.

    If I recall correctly, at the time the bugzilla project was focussed specifically on being the bug tracking system for the Mozilla project.

    Regardless, at the time it looked like the best thing out there available for free, and was able to be modified to be good enough for us, and a whole lot better than the existing in-house scripted bug system that caused a lot of frustration for our developers and QA (affecting quality and productivity of previous development projects). Additonally it was available right now (as opposed to the long-promised solution from our parent company which never arrived).

    Since then, the bugzilla project has moved on a long way with a lot of improvements, and has become a bug tracking system for developers on any project. While reading your post, I was wondering how much this point might have contributed to other developers wanting to jump in – ie, wanting to make it better for their own and everyone else’s use, rather than just making it better for Mozilla bug tracking.

    Reply

    • Hey Brian! Thanks for the story, that was really cool! There were very few people running Bugzilla outside of Mozilla in 2000/2001, you guys must have been one of the few organizations doing it.

      I think you are right, that a lot of motivation came from people wanting to solve their own problems. That’s sort of covered under the “they think that something is wrong and they need/want to fix it,” but you’re making the point in a much broader and more detailed fashion. 🙂

      -Max

      Reply

    • That is a great read, thanks for linking me! 🙂 It’s really interesting to see how many people came to such similar conclusions independently–it seems that we really do have some important across-the-board principles for what makes these communities successful.

      -Max

      Reply

  12. Very interesting read.

    I am very interested in how you performed the data analysis. I am assuming it is just based on queries on the bugzilla database and commit information? Any change you could talk a little more about this 🙂 This would be really helpful for some us who want to get started on performing this type of analysis on our projects.

    Thanks again for writing this up.

    Reply

    • Hey Amit! I did the analysis in both of those ways, yes, but it turned out that the answers were pretty much the same no matter how I did the analysis. The simplest metric was “in each discrete 30 day period, how many different patch authors were there for commits to version control”? I’m not sure that would work reliably on smaller projects (there might be better statistical results from other metrics) but on a project with as many historical contributors as Bugzilla has had, it worked great. I used my VCI module to grab commit information for each discrete commit and then had a mapping table (that I created by hand) of usernames that were duplicates of each other.

      -Max

      Reply

  13. This got linked around in the Dreamwidth project community, and it resonates with a lot of the things that have been going on with us. It’s not like we’re perfect — I know there have been some code review delays, and probably more things — but we’re trying.

    Most of the stuff I mention here is all anecdotal as far as I know; I know the owners were doing some stuff with number-crunching but I don’t believe the social documentation was part of that. The owners presented at OSCon 2010.

    We’re trying for a very welcoming community. Our IRC culture is at the heart of that, though we’re trying to keep the asynchronous parts welcoming as well.

    One of the things I focused on near the beginning, and have been trying to keep up now that we’re going strong, is social documentation as well as other, technical sorts of project documentation. Obviously insults are more alienating, but we didn’t have much of an insult problem. Instead, imagine the effect of walking into a channel full of people who already know each other, all cheerfully talking away, sometimes in wider community jargon, but sometimes with injokes and references and shorthand that is completely opaque to you. It makes you feel like an outsider.

    One can’t of course ban injokes and other similar markers, but one can document them. I commenced documenting the Dreamwidth IRC slang not out of principle, but because the channel was full of people who’d known each other for years from our mother project, and we were getting about as many new people, and I was getting tired of being the one to cheerfully and politely explain the jargon to each new person. If it was jargon from us, it got a definition; if it was jargon from somewhere else, it might get an explanatory link, or at least one including it (because it would be silly to attempt to reproduce the whole Jargon File). My basic rule was, if I had to answer the question twice, it went on our jargon page. Then I programmed it into our infobot, so I had but to speak the command, and the infobot would link to the page. (I also made the infobot respond with the wiki-link for the appropriate bot for “infobot, help $BOTNAME”, for handy reference.)

    (The Jargon File itself is very dear to me, because my first serious consideration of computers as a lifestyle and not just a means for easy and quick writing was after encountering a book entitled The New Hacker’s Dictionary (filed in the ‘humor’ section, rather than ‘reference’ — apparently these things are funny because they are true). I read it cover to cover and realized that I would be home among these people, and set out to make connections and see what I could usefully do to count myself among their number. This, despite being raised by a programmer.)

    My local jargon documentation was humorous, because I happen to have a problem with writing anything particularly long without including some form of humor. I can see value in deliberately including humor if you can make it happen without it sounding forced. If the jargon sounds like it belongs to a group of people who like to have fun while doing interesting things, this can be another form of attraction (or can help swing someone who’s heard about the project but is undecided about participation).

    One of the other tools that has been useful for us in documenting project culture is a quotes database. It was set up for the existing members of the community, but it also became a tool to help attract and acculturate new members. It’s funny, it amuses the existing members, and it helps reinforce a sense of community. It also documents what the project community thinks is the funniest of the funniest, particularly if the qdb software you’re using has ratings.

    A new person who may have only heard of the project in passing, or who has been undecided about joining up, may read through and decide that they like the way this community thinks and what they find funny, and join up. (This isn’t speculation: one of the current regulars was undecided until reading through our qdb and finding that we weren’t hostile and our humor matched theirs well.) It can help a new person match the local culture better, making them more comfortable and the existing project members more comfortable — reading through a qdb isn’t just absorbing the jokes, it’s also picking up on the speech patterns and norms of the regulars — is there a lot of lolspeak, netspeak, leetspeak, or is it standard-form language? What sorts of things are acceptable topics for jokes? What’s the ambient level of meanness? Is it safe for someone of my race, my sex, my appearance, my subculture, my religion, my nationality, to come in, or will I face “humorous” microaggressions, even if they’re never aimed at me specifically? Absence of these things in a qdb doesn’t mean that they’ll be absent in the actual channel, but presence of them means that not only are they there, they can be expected to be free-floating, and considered quality entertainment by enough of the channel that someone’s going to stick them in the qdb. (Related: having an OAuth or OpenID sign-in required to submit quotes to the qdb helps keep accountability and topicality.) So a qdb that contains quotes that drive away some of the new people you might want might not limit their damage to that. They might attract an element that thinks this sort of thing is funny.

    A new person reading through a qdb may also get the benefit of information on the channel equivalent to a few days of concentrated lurking. Assuming there are no hidden horrible things lurking in the qdb, when they come in they’ll be able to blend better.

    We have a lovely team of ops in the IRC channel. There is a backchannel for the ops. If someone says something that doesn’t warrant intervention right then, but a second round would, we mention it there. We coordinate so all the ops don’t jump on someone at once, if it’s something that only warrants a mild “hey, don’t do that”. We try and log decisions and actions in a persistent format, so there’s a locked community blog for us as well.

    As far as making room for people to help goes:

    Codewise, everything we want to do goes into Bugzilla as soon as we think of it, just about. (There are some things where detailed userbase feedback is desired, but those tend to get entered relatively quickly.) Because everything goes in, there are always a number of interesting bugs for all skill levels. We’ve got our bugs labeled by the amount of effort and pre-existing knowledge that it’s likely to take to fix them as well. No one’s taken ownership of them yet, so they’re available for newcomers to take up.

    There’s very little “oh damn another bug, this is wrecking our numbers” culture, so there is little social barrier to entering bugs provided they’re not dups. (Though features have a separate process they go through first, but they still all wind up in Bugzilla.) So someone showing up in channel and announcing “I think I found a bug!” — they don’t get a defensive “How dare you imply our code has bugs!”, they get a helpful crowd trying to figure out if it’s a known issue or a unique one, if it’s something working-as-designed or broken-as-designed (working goes through the new feature process, broken gets punted to Bugzilla if there’s a consensus on how it should work), and help walking through our particular settings.

    While there always will be some “are you a developer or a user”, this attitude is minimal with us; it’s more focused on what people’s area of expertise is, and what they’d like to do to help out. Users experienced with the site are sometimes more conversant with the site’s capabilities and likely directions for improvement than experienced developers who are new to the project. If people don’t know what they’d like to do, or don’t have the skills yet to do what they’d like to, they are invited to stick around and hang out. People who don’t have the skills and/or inclination to code can always cheer on the developers. To help monitor activity in Bugzilla, there’s an IRC bot that announces new bugs, status changes to bugs, and new patches. Often enough this sparks cheering. People have been known to cheer for getting a bug that was bothering them filed, for someone checking out a tough one, someone checking in a patch, and (our favorite) marking one resolved. The cheering is a real ego boost for the developers, because while it’s encouraged, it’s also clearly heartfelt. People sitting around watching without technical skills to start off sometimes start to get the urge to start developing themselves. There’s active encouragement for anyone who feels like trying their hand at developing to do so. Anyone who’s available answers questions, and more experienced developers often set up a mentoring relationship with less experienced developers. They help pick out bugs that are at the new developer’s skill level, and help build them up to the point where they can develop independently and take on neophytes of their own.

    The process of setting up a local version of the Dreamwidth code to hack on is a significant barrier to entry; the owners decided to devote some resources to hosted “Dreamhacks” so people at a beginning developer level could work without having to level up to being able to install it themselves. Again, I’m not the keeper of the numbers, but the program is continuing. (This did nearly backfire a few times: sometimes there are people who want to install it locally for various reasons, and the first person who did so mentioned that she felt discouraged by the people urging her at a Dreamhack. That did get straightened out, and she got her local installation done, and in the process generated some excellent documentation for the people following in her footsteps.)

    There are also regular “code tours”, where recent resolved bugs are explained to the userbase in layman’s terms, mentioning the person who’d been assigned the bug. This is publicity and acknowledgment for the people doing the work, and in some cases can serve as a challenge/reminder: hey, I only did five bugs while someone else did ten? Oh hey, another code tour, and I’m not in it this time? Best to step up my game!

    We participated in the Google Summer of Code project, and that resulted in a rather lot of shallow interest — students vying for a few positions, but dropping away after the students were picked — but at least one of the students stuck around with the project after summer ended, and brought back a team of classmates when a different class required they do some work with a FLOSS project for class credit.

    There’s a commitment to accessibility, which is in part because of our principles/good design principles that say we should be, and part because a decent number of our contributors use various assistive tech themselves and are the first to complain when something breaks stuff so they can’t use the site. It’s a very different experience designing something to be accessible because it has to be, from designing it accessibly because if you don’t, someone you know and care about can’t use this. Word gets around, and people who have been marginalized from other projects gravitate to yours. Working with accessibility-first design has made a decent part of the shop into accessibility-aware, data-centric design advocates. You can watch the ideology spread as people talk to each other. It’s beautiful.

    I hope this ramble proves useful to other projects.
    –Azz

    Reply

    • Hey Azz. Wow, that was a really fantastic description of your community! I really like a lot of the actions you guys have taken to make the whole group welcoming, and I like that you had a strong positive direction for the community from the beginning. The QDB is a good idea for a community like yours, where it’s a sort of social tool that you’re creating. I’ve definitely seen those QDBs create some tight communities (sometimes I liked them, sometimes I didn’t, but they were certainly persistent communities). I like the “code tours” idea, too. 🙂 All in all, everything that you said makes it sound like you’ve worked hard to really create a welcoming community, and you recognize that it requires that sort of effort in order to have one! 🙂

      Have you thought about posting this whole comment up as a blog, yourself, to document what’s worked about the Dreamwidth community?

      -Max

      Reply

  14. “Be really, abnormally, really, really kind, and don’t be mean.” is good advice for an open source project, and it’s good advice on how to live your life in all other aspects as well.

    Reply

  15. Your psychological study is very good.

    You speak only to contribution to coding, I think that you limit too much the help.

    E.g. from what I have seen, it seems that Mozilla products use Javascript like language (which sort ?) but with a huge number of already coded subroutines : this is a very big barrier for new comers. This is too much for me to learn !
    I have nevertheless some notions on coding in high level languages e.g. Exec, Exec2, Rexx on IBM mainframes or more recently on basic Javascript to automate some actions for my personal use. But my work was more to be an interface between the development labs and the commercial people and the users : I was implicated before the coding and as a “technical expert” after the release of product. “Before the coding” was called “architecture” and was the “thinking” on the function including its paper description and bloc diagrams of the future program and discussion with others to improve. I think that I can help in this direction that is not a strong part of Thunderbird ; I have tried to participate in a developer forum but I felled rejected because it was not part of their day by day preoccupation…

    How can I participate ?

    Reply

    • Hey Nigelle. Thanks for the compliment. Not all of the points are related to coding, and of course I know that there are other contributors besides code contributors.

      As far as how to get involved with Mozilla projects in general, I don’t know! I’m not a Firefox or Thunderbird contributor. However, what I would suggest is that you find out what people *want* and then do that. It can be a bit of a humbling experience–you may see that they *need* something, but they may not *want* it. So you have to find things that are both needed *and* wanted, and then decide to do those so that you can become a part of the project.

      -Max

      Reply

  16. To Max Kanat-Alexander
    I was probably wrong but I thought that I have seen your name in comments in Bugzilla on Firefox or Thunderbird…

    At least you seems to know very well bugzilla.
    An idea to recruit help for a project is to ask to people that have written comments but no patch or code to volunteer for “bug preprocessing” : the volunteer will receive (by automatic mail) each week 1 (or n) bug (number, title, link) of the project and should answer (mail or filing a form) during the week simple questions as : Do I understand the description (if not -> comment in this bug asking for clarification) ; Do I have the bug with my configuration (description of it) ; Do I know similar or duplicate bugs ; How do I rate the need for correction ; Etc. . This is equivalent to “bug day” with the advantage of being asynchronous and not time zone dependant. As this require only a few years of experience of the product of the project, thousands of volunteers may be found and decrease the load of true developers in particular in testing or commenting.
    Do you think it is *Wanted* by some projects ?

    Reply

    • Hey Denis! 🙂 Thanks! I’m doing pretty fantastic, and I’m really loving Google. 🙂

      -Max

      Reply

  27. […] Our of our major challenges is to build a community of volunteers who will help us build lessons and the software that supports the site. With this in mind, I pass on an excellent article recently discussed on the FLOSS-Foundations mailing list, which includes much good advice. Although it focuses on software contributors, I think the points mentioned hold true for any contributors to a project: http://www.codesimplicity.com/post/open-source-community-simplified/ […]

    Reply

  29. I realized recently that there is another possible barrier to contribution that you didn’t mention at all, probably because you never encountered it. 😉 And that is: the acceptance or rejection of contributions to the codebase must be based on sound technical reasons, well-explained, not based on caprice or bad engineering principles.

    In other words, if someone comes along to improve the codebase, and submits something that is a definite improvement, there must be reviewers who will see that it IS an improvement and merge it!

    I hypothesize that a condition sufficient to kill off an open source project is: a lead reviewer who doesn’t personally understand or apply the principles in the Code Simplicity book.

    Even if there are other developers on the project who DO apply those principles, if the lead reviewer of new contributions doesn’t understand those principles and doesn’t recognize or appreciate greater simplicity, it will kill off the desire of new contributors to contribute.

    Reply

Leave a Reply