How to plan your new open source project

Lots of startup projects on the big online free software repositories have been abandoned right after being created, or linger in alpha stage for many years. I have founded four open source projects, of which two have been successful, while the other two just stopped and faded away. From that experience, here’s some practical advice on how to make your project more well-known, how to motivate others to join your project, and how to make sure it stays alive and active for a long time — maybe even reaching a 1.0 release (which should be part of every project’s goal, should it not?).

Planning
Planning can be the most boring part of a project, but it is also the most important part. You have to come up with what the purpose of the project is, a working name, what programming language you are going to use, and how many developers you are going to need in order to get things working effectively. In some cases you’ll need an explanation of why you are doing it.

Initial release
When the initial plans are ready, it’s time to show your code and design to the rest of the world. A good first impression is important if you want people to get interested in your work and excited about the upcoming releases. I highly recommend creating a hierarchy for the distributed file archives. One good way to set things up is
to first have a primary root project directory, which should be the name of your project and its version number. In this directory, create a directory called src/ where all your source code files go, docs/ for the nicely formatted documentation files, and bin/ for the binary files. In the project root directory put the readme file, changelog, and other similar text files, along with makefiles and configure scripts.

Putting files in an archive
Let’s say your project name is “Foo” and the initial release version number is 0.02.
To archive your files in directory foo-0.02 with the tar utility use the command
tar -cvf foo-0.02.tar Foo-0.02/ && gzip -9 foo-0.02.tar. This will create the archive for you and then compress it using GNU Zip. After this procedure you should extract the files from the archive to make sure everything went as planned, using the command tar -zxvf foo-0.02.tar.gz. That should produce an output similar to this:

foo-0.02/
foo-0.02/src/
foo-0.02/docs/
foo-0.02/bin/

Placing the project online
There are a couple of different ways to release your code to the public. Some projects use Freshmeat and/or SourceForge, while others prefer having their own private sites. Whichever you choose, check that all your files get included and are working properly, before distribution.

Collaboration – sharing your vision
When the files have been released to the public and more people know about your ideas,
you should think about how to make sure the project stays alive more than just a couple of days. Try to find developers who are interested in joining open source projects. Tell them about your vision and show them your plan so that they know what kind of project it is, what the needs are, and the required developer skill you’re look for.
Let everyone involved look at the plan and comment it. If needed, change it to fit everyone’s needs better. Setup a repository using a concurrent versioning system like CVS or any of its variants, where all of you can exchange and modify files to be able to get things progressing and growing steadily. Ask the people involved in your project if they are especially good at something particular that they wish to work on. If they are, you can divide tasks among the developers more effectively, and the motivation
will most likely be higher as well.

Public relations – making the users stay interested
To keep the project fresh in the easy of its public, post news about how things are progressing and what you are doing in terms of code changes and design — basically anything to draw users’ attention, pique their curiosity, and create a demand for the next release of the project files. You can also create a forum where people can discuss things with the developers, suggest changes and improvements, and give feedback with
comments on good and bad experiences.

Staying with the plan
How far have you come? How much progress have you made since your initial release? What was the date of the previous release? Don’t wait too long for the next release or people will wonder how things are progressing, but don’t release too often, either,
as that will just create a lot of irritation. What you need is balance and, as always, good planning. In the end, it all comes down to that.

Hints and tips

In closing, here are a few points worth remembering:

A really good overall planning raises the potential for the project to gain wide interest and acceptance from users.

Prepare your file distributions carefully. Ideally, let a small group of people try out your updated code before every official release.

Usually it is a good idea to include either your name or your online nickname along with an email address in the README file, in case users wants to get in touch with you with comments, issues, feedback, or discovered bugs.

Set up a Web site where you promote your project. Offer a weekly poll for your users, a forum, and anything else that you see fit.

Don’t forget that, if your project gets successful and widely accepted, you might have a chance to get it included in a Linux distribution. According to Linux.org, there are more than 300 Linux distributions available today, so there’s a pretty good chance of getting the project accepted by at least one of them.

Tony Granberg is a 21-year-old student from Sweden with six years’ experience using Linux software. He has been a full-time Linux user since 2001.