Building a successful community-driven software project: part 3

This is a multipart post. See part 2

Answer those questions somewhere in your project page. You won't risk people looking for the wrong solution coming to you and asking strange things, and you'll be able to dismiss requests as "out of scope" if they exceed your vision. Sharing such vision with your users is a necessity, or you'll be called a traitor by somebody, someday. As a user, I want to know what requirements was the project designed to accomodate. If I start building a large corporate webapp with tons of users around a small framework designed for personal, low-traffic blogs, I'm probably doomed to fail.

Explain how releases are done. Do you just keep a stable main branch and pull development and bugfix branches in it as soon as they're ready, so you just sometimes tag the main branch and have a release at that point? Or do you create milestone-oriented branches as soon as you release, e.g. version 1.0.0 is got a release-1.0 branch where you apply bugfixes only and release 1.0.1, 1.0.2 from that? Or have you got a "stable" release and a "development" release, but you sometimes pull stable features from development to stable?

All of that is important from the point of view of the user. I want to understand whether an API can change in an incompatible manner from 1.0.0 to 1.0.1. I want to know if I ever get a 1.0.1 release after 1.0.0 or I'll need to pick 1.1.0 with all its changes.

And make it sure you provide its address in README files and such! You don't need a domain name, even though it makes things simpler. It doesn't need to be wonderful - a working one will suffice. You can use Google Sites, or any which Google Code, bitbucket or github provide out of the box.

This may seem a stupid proposition, but in the modern era many users have access to the code for a project without having ever seen the project homepage - central repositories like cheeseshop for Python and maven for Java make this possible.  Then, when it's time to report an issue or ask a question, the user is puzzled and doesn't know where he should head to.

Make sure the homepage contains all the info a user needs. Where does discussion take place, how should I file a ticket, where are docs, what's the latest release, etcetera - everything should be linked there. Sometimes projects use multiple servers to store their data - the repo is on bitbucket.org, the mailing list on sourceforge.net, and the bugtracker is self-hosted. Of course it's better to disable whatever it's not in use, but the point it is: the homepage should be the authoritative reference for everything regarding your project.

And keep it updated! That's why having a domain name of your own, or a subdomain - e.g. myproject.myowndomain.com - might be a good choice - you can just redirect people if your hosting goes down or you'd like to change something.

Having stale information on your homepage will just delay people trying to help and maybe prevent some of them from telling you something.  I really hate when the homepage says the latest stable version is "3.0.5" but the central repo offers "3.0.6" - WTF? If you don't have the time to keep that in sync, just point to a webpage of the central repo and don't duplicate releases on your homepage - nobody says you must.

Next: part 4