Building a successful community-driven software project: part 1

There's a lot of buzz about open source software lately. Many projects are supposed to embrace the Bazaar development model, but they really don't, and their leaders just seem to ignore users a lot. This often leads both to wild forking - one new feature, one new fork that's never merged in the original code base - and to multiple incomplete implementations - there're many projects to satisfy a single need, but none of them is complete.

What should you do to make your project successful? Those are my guidelines. I've split the post into pieces since it was growing too large for a single entry.

This is mostly developer-oriented; I think supporting a community of end-users might be slightly different, although concerns might sometimes be similar.


1. Make it easy to discuss about your software.
Something might not be clear about your software, whether it's usage, availability, license, scope, and so on. It must be easy to ask a question, whether it's on a mailing list, on a forum or by any other mean - Launchpad Answers or GetSatifaction are good alternatives - just don't make it too hard to just ask a question!

 If you're using a custom forum or any other portal, make sure it supports a decentralized authentication system, be it OpenID, Google Account, MSN or whatever you like. Very often creating a new username/password couplet, fill in a few forms, clicking to verify an email, etc. etc. may just be too much an hassle for somebody who just wants to ask a small question.

Similarly, if you're using a mailing list, make sure it's not too hard to get subscribed; if possible, just let anyone post a question - then a "reply all" from any list subscriber should reach the poster. Don't moderate subscriptions and posts unless you've got a really good reason to - e.g. too much spam that automatic filters can't handle. Consider using mailing list providers that make it easy to use the ML from the web as well - Yahoo Groups and Google Groups are great examples; they'll give a great overall user experience, and satisfy those who prefer forums and those who prefer mailing lists at the very same time.


2. Answer questions and doubts.
This seems a silly one, but it isn't. Make sure users get a minimum of feedback, be it just a "read the FAQ", or "it's not implemented yet" or "I don't know". Any message left lingering is a big thumbs down for your project.


3. Have a FAQ

This was pretty common during the nineties, I can remember being turned down with a "Read the FAQ" many times when I was young and inexperienced, but it's not such frequent thing anymore. There're some questions that get asked again and again. If you don't mantain a FAQ you can't tell people "Read the FAQ!", and you'll need to answer the same question again, and again, and again. And you won't like it.


Link to part 2 - bug reporting and patch submission.