Rate this page del.icio.us  Digg slashdot StumbleUpon

Building a community around your open source project


There are a vast number of fantastic open source projects out there, though for every one that is widely adopted, there are many that remain cloaked in relative obscurity. How can the open source development model best be leveraged to take advantage of community feedback, ideas, and testing, and ultimately gather code contributions? If you are just thinking about open sourcing a new project, what steps can you take to ensure a vibrant community? If you already have an open source project, how can you make your community more active? The community can make any project stronger, but they are not built automatically.

Make things presentable

The simplest thing is often the most overlooked–a quality project web page that tells the viewer what the project is about in a minimal amount of time. Detail as well as appearance is important. Sticking with the default SourceForge template, Trac page, or a CSS-free, white index.html page is OK to start with, though active projects frequently have attractive and involved custom pages. For a great example, look at the Firefox homepage. Your project will likely be smaller than that, but it doesn’t hurt to aim big. Don’t forget to link to your mailing list, chat room, and bug tracker if you have one. Don’t forget the web-based documentation either, as that is the first thing most users will be looking for. Grabbing a domain name versus using a project hosting URL is often a good idea, as they’re relatively cheap these days, and projects with a domain name sometimes feel “bigger.”

Get it checked in

A project can start just by offering up a tarball of code somewhere, but for power users to play with the latest and greatest code, you’ll need a version control system. This allows members of your community to test your latest code as things are checked in and to get a feel for the direction of the project. Many project hosting sites offer such basics as CVS or SVN (which are acceptable), but I would highly recommend looking at Git. Git is the version control system used by the Linux kernel, and it belongs to a class of solutions called distributed version control systems (DVCS). A DVCS allow your developers to commit locally, without a server, in coffee shops, on planes, or wherever they like to work. Git also contains incredibly powerful features like git-format-patch and git-send-email, so others can make modifications to your code locally and send them with a minimum of hassle.

Distributed version control systems really shine when you want to encourage contributions from a wide pool of people but are not able to give everyone commit access on your project. Regardless of your version control choice, you must enable anonymous checkout. Do not require registration to get at your code. This is the way towards closedness. Strive to be open in everything you do.

Join the club

To make your project more accessible to end users, you should also include built packages for users who do not want to build from source. For Fedora™ and Red Hat® Enterprise Linux®, that solution is RPM. If you join the Fedora Project, have your RPMs available there via standard package tools everyone has installed (yum) and also submit them for inclusion in Extra Packages for Enterprise Linux (EPEL).

EPEL is an exciting project that allows Fedora community members to create add-on packages for Red Hat Enterprise Linux, which are also installable via yum. Fedora offers extensive mailing lists and IRC channels for helping new packagers get their projects included, built, and distributed. It is an outstanding resource and provides some additional avenues for getting your project noticed. As a bonus, you get out of the business of having to maintain a build system, which means more time to write interesting code.

Choosing an appropriate license is also important. While a more esoteric license may be acceptable, going with a more standard license like the GPL, LGPL, or MIT license will ensure your software is compatible with a wider array of projects and can help increase adoption.

Get noticed

If you have an open source project, most likely you are a designer/developer and not a marketer. Marketing is part of the job though (sorry!), but it doesn’t have to take a lot of effort. For starters, think of the related mailing lists you are active on. If you aren’t active on any mailing lists, start! Open source lives through free exchange of email. If you see a problem posted that might be solved by your software, it’s perfectly acceptable to mention your app. Other projects may exist as alternatives to your own, and you want to respect them, as you want to also respect other users on the lists. Help, but don’t advertise.

Another outstanding resource is freshmeat, a web page and RSS feed that shows software users everywhere when open source software apps are released and updated. While the freshmeat page and feed are useful, it is more powerful for yet another (and largely unknown) reason. Its RSS feeds are aggregated at an amazing rate by tons of web sites. This means that projects mentioned on Freshmeat have amazing Google PageRank, which can drive a substantial number of hits to your website.

Blogging is also often overlooked. If your blog is a member of one or more open source “planets” (like planet.fedoraproject.org/, it can be aggregated elsewhere for others to read and may also help you even further with Google PageRank. It’s probably not a great idea to talk about your project endlessly, but every now and then it’s a great way to connect with new prospective users. If your project is spearheaded by a company, see if the company has a company blog feed or blog aggregator. If not, it’s a great time to start one. This helps your company gain exposure as well as your project.

Other ways of increasing knowledge of your project include writing for technical publications (like Red Hat Magazine), and word of mouth from your individual users. All word of mouth requires is writing quality software and ensuring you have happy users.


Communication is the most vital part of the open source process. For starters, establish a mailing list. Just providing your own email address won’t do the trick. An open source project hosting site may provide a mailing list for you. If not, consider establishing your own on your web host. Mailman is fairly popular.

A public mailing list is a place for users to congregate with questions, as well as a place to announce new releases and solicit feedback. As your project grows, contributers can use your mailing list to submit patches to your project. While some services may offer forums, mailing lists are usually preferred in open source land, as they don’t require your users to go to different websites to stay up to speed with their latest projects. When you set up a mailing list, it is very important that archives be public. This will help your project attract new users, and it will also help users find their own answers to questions that have already been answered. Be active on your own lists and be responsive to questions.

It is also very beneficial to start an IRC chat room. When you can’t talk with your users face to face, IRC for many is the next best thing-–it allows real-time group communication for free with users and developers all over the world. Freenode provides free IRC chat rooms for open source projects, as does OFTC. With a chat room, users can help themselves with questions as well as get involved deeper with a project. Chat rooms also tend to be easier for debugging long, involved problems as opposed to email. Being around to answer questions can be helpful for new users of your program, and you can easily gather insight and perspective that typically aren’t gathered from email conversation. When trading long amounts of information over chat (like error logs), tools like Pastebin are very helpful. You want to mention the existence of your mailing list and IRC channel on your project home page and encourage folks to become active in both.

Whether by email or on IRC, frequently ask for user input and ideas. Often they will have ideas to take your project in directions you have not imagined or may have innovative solutions to problems. If you can’t personally implement a user request due to inexperience with a feature or time constraints, ask if someone else would like to submit a patch. One of the great features of the open source community is collaboration across organizational boundaries. As more people get used to the idea that their input (and user-contributed code changes) are welcome, your project will become more of a community venture as opposed to a free solution exclusively from your organization. Getting to know your users helps you to know how your project is used. The value of reaching out to your community can not be overstated.

Often there may be projects related to yours, either that do similar things or that have features complementary to your own. Reach out to these projects and see if there are ways for you to inter-operate or perhaps join forces. In some cases, there are definite reasons for differentiation; in others, combined resources can free you up to achieve even greater goals. Make your project extensible and “pluggable” if possible, so that others can extend it in ways that you have not realized.

Finally, in the vein of communication, post your roadmap. Let users (and potential developers) see where your project is going. Perhaps they will have their own ideas or would like to help tackle some of your future tasks. Knowing that a project is active, vital, and has a plan also helps adoption.

Summing things up

The keys to making a great codebase become a vibrant open source community project are mainly those of making yourself and your code available, offering help freely, and providing multiple avenues for others to get involved. This takes time and effort, but the payoffs are great. Working with others who use your code, improve it, and bring new ideas to the table is one of the most rewarding things about being an open source developer. If things go well, you may have great user-added features that you didn’t have the resources to accomplish alone. If you take a bit more time to build a community around your software as opposed to “just” releasing a software component, a great many avenues will open up.

About the author

Michael DeHaan is the author of Cobbler and a member of Red Hat’s Emerging Technologies group where he develops solutions around systems management and virtualization technology.

13 responses to “Building a community around your open source project”

  1. Michael DeHaan says:

    Looks like the URLs are mangled :) Copy and paste them into your browser and you should be able to figure it out.

    Editor’s note: Problem fixed.

  2. Paul W. Frields says:

    A good bit of this material is covered at much greater length and in finer detail in Karl Fogel’s excellent book “Producing Open Source Software,” which I reviewed a while back in Red Hat Magazine.[1] If you’re short of cash and/or time, you can download the text for free from its web site[2], although I’d highly recommend buying it for convenience, easy reference, and to support the author’s worthy efforts.

    [1] http://www.redhat.com/magazine/015jan06/features/review_fogel/

    [2] http://producingoss.com/

  3. Stefan Majewsky says:

    @Michael: You are right, the article’s code is wrong. It uses some kind of typographic quotation marks, like . These should be standard quotation marks as seen on your keyboard, like in .

  4. Stefan Majewsky says:

    Damn, this site does not escape my HTML tags. Here comes the second try.



  5. Michael Iversen says:

    Great article.
    Some food for thought here in relation to my own project.

    @Paul W. Fields: Thanks for the notification about K. Fogel’s book.


  6. ser says:

    Nice article, though I do not agree that projects best should use IRC and mailing lists. I know several very successful projects that *never* used IRC. Besides that I’m involved in a successful project that does not uses IRC nor it uses a mailing list. The main reasons why we don’t use both technologies are:
    * we don’t need them
    * our community does not uses IRC. Most even don’t have an IRC client installed
    * we want to avoid old-fashioned communication technologies as the project’s goal is to create innovative communication technologies

  7. Michael DeHaan says:

    Care to name this open source project and why your methods of communication are superior?

  8. Kevin Smith says:

    Nice introduction, but it missed my pet peeve. It’s not enough to have an attractive web site. The front page should explain what the project is, and importantly, why the reader might be interested in it.

    I am amazed at how many sites miss this. I’ll go to a site, but when I can’t figure out what the tool does, or how it compares to others, or even if it will work on my system, I turn away, disappointed.

    Assume visitors to your site know nothing about your project. Introduce it from the ground up. Repeat visitors can always set a bookmark to a “more interesting” page, like the news feed. The front page should focus on first-timers.

  9. Maddog says:

    I second Kevin’s point. When making a project’s website, put yourself in the shoes of the reader. Never assume that the reader knows any insider information about your project. You have to put all the basic stuff online and make sure it can be easily found.

  10. Michael DeHaan says:


    Very true… there’s been many a time I’ve visited a project page and couldn’t figure out what it did.

    I thought I got that with “a quality project web page that tells the viewer what the project is about in a minimal amount of time”, though it definitely bears repeating.


  11. Building a community around an open source project « /home says:

    […] http://www.redhatmagazine.com/2007/09/21/building-a-community-around-your-open-source-project/ […]

  12. Jakub Narebski says:

    When talking about IRC channel it should IMHO be mentioned that besides dedicated pastebin it is nice to have log (archive) of given IRC channel.

    Karl Fogel’s book “Producing Open Source Software” is truly worth reading, as is interesting discussion on Git mailing list about what distributed SCMs change:

    “Producting Open Source Software” book and distributed SCMs

  13. jeux video says:

    apprendre le poker gratuites

    Angebot strp poker poker texas holdem gratis jeu de la roulette maquinas tragaperras portales web stip poker gratis