After spending a considerable amount of time releasing your Free Software project to the public, you will probably want to make sure that it reaches as many of the people it could be useful to as possible. Here are a few tips to get you started.

Homepage: Is this software for me?

The first thing you will probably think about is to create a homepage promoting your project. There are a lot of good tips on how to create an effective homepage, but I will focus here on the contents that you should include.

Screenshots are one of the most important elements you can include on your homepage. First-time visitors will only spend a few seconds on your site before deciding whether or not the information is relevant to them. You need to be able to summarize in a few pictures what your project is all about.

Would you be willing to read long white papers or to go through long build instructions just to find out that this software isn't going to be useful to you after all? Probably not. Make sure you can help users figure this out in a few seconds, even if your software lacks a graphical user interface.

Of course you will also want to describe the project in a few words and provide links to the source code and other services you may have available.

Hosting Choices

Where to put your contents is somewhat of a personal choice but there are a few things to keep in mind.

First of all, depending on the size of your project and its related data, the hosting site should may need a significant amount of storage and bandwidth. Furthermore, you should check whether download statistics are collected by your hosting provider. While not strictly necessary, it can be very motivating to watch these numbers go up!

Free Software hosting sites like Google Code, Source Forge and LaunchPad also provide different services like bug trackers and source control repositories.

Some people prefer a distributed approach to source control and issue tracking to avoid trusting their master copy of the data to a third party. Setting up a separate code repository on sites like Github or Gitorious is an option to consider.

All of these hosting providers promote the software they host to varying degrees. Have a look around before deciding where you should park your project.

Announcing your Release

Finally, what would a website be without other sites linking to it? The obvious place to start would be the main search engines, but that in itself is unlikely to bring much traffic in the early days of your project.

Sites dedicated to Free Software are more likely to bring visitors to your shiny new project. The most famous place for Free Software release news is Freshmeat. Whether or not you visit this site regularly, you should know that its contents is widely read and syndicated and you should not pass on this great opportunity to let people know about your software.

Other directories that may be of interest include the Free Software Foundation Directory and Ohloh (especially if you offer a publicly available source code repository).

Now that the word is getting out, it's time to start thinking about supporting these new users!

Once your new Free Software project has had some traction and is gaining users, you will probably want to supplement its initial homepage with a few extra services. However, the most important aspects of managing a Free Software community have more to do with relating to human beings.

Social Interactions in Small Projects

In the early days of your project, support requests usually only come in through personal emails to the lead developer. In order to build your community, make sure new users feel welcome:

• Be friendly and informal in your responses. Feel free to use the person's first name at the beginning of your emails.

• Be responsive to feedback and request for help. Most Free Software developers are quite busy so this is about letting user know that you'll get back to them or thanking them for their suggestions/feedback. Very few people take the time to contact authors to let them know about the problems they run into. It's important to be supportive of the ones who do.

• Be calm when responding to negative feedback. It helps to take a full day to cool off before sending a reply. Thank users for writing to you, but remind them that you are not getting paid to work on this project and that you are doing this for fun in your spare time. Some users seem to forget this.

But of course, remember that the main job of a developer/maintainer is to make the software better. Keep this in mind when replying to support requests and allocate your (limited) time accordingly.

More Tools for Growing Projects

As your project grows and handling user-reported issues start becoming more of a burden, consider two things: documentation and distributed support.

The obvious place to start documentation-wise is to start collecting responses that you send to users who get in touch with you. This is the original meaning of a FAQ: answers to actual questions sent in by actual users. Fill your FAQ with irrelevant questions and users won't bother reading it and will email you instead.

In addition to providing good documentation, you should also think about creating a mailing list or a forum where users can post their questions (Google Groups provides a nice blend of the two technologies). There are two main advantages to this service:

• the support load is distributed across other users of the software
• questions and answers are archived by search engines

As your project grows even bigger, you will probably also want to look into getting a bug tracker and a wiki.

Have a look at this excellent online book for more ideas.

After releasing a new Free Software project to the world, you may be interested to see it included by the main Linux or Free Software distributions. After all this is the easiest way for end-users to download and install your software.

Here are a couple of technical details that will increase the chances that your project will be picked up by a distribution.

Can I distribute this software?

The first question that a distribution maintainer will need to answer is this one: can my distribution legally distribute this piece of software?

There are two ways you can help here:

• Make your chosen license clearly visible (normally in a file called COPYING or LICENSE).

• Include a clear copyright statement in your documentation (inside README for example).

Once your software has past this check, the next question will be of course: does it actually work?

Will it work on my distro?

To answer this question, the maintainer will have to install the software and figure out all of the external dependencies that need to be installed at the same time.

Therefore, your tarball should include:

• all of the steps (and exact commands) that are necessary to install your software on a standard Free Software distribution

• a list of the external libraries and tools that your software requires to run

What's changed?

Another element that can make life easier for the maintainers of your software in downstream distributions is to include indications of what changes from one release to the next.

One important detail is to use a sane versioning system. In a nutshell, this means:

• Version numbers should always be increasing (e.g. in normal ASCII sorting, 1.0pre1 comes after 1.0).

• Any change to the contents of the tarball should trigger a version bump.

• The difference in version numbers from one version to the next should give an indication of the magnitude (minor v. major) of the change.

Another thing that you should include is a changelog (normally in a file called Changes or ChangeLog). This document will be used by maintainers to decide when to upgrade to a new version and to figure out which bugs may be fixed by the new version. It should contain:

• release date
• version number
• summary of the changes since the last version

Finally, to make sure that distro maintainers don't miss new releases of your software, make sure you sign your project up on Freshmeat and announce new releases there.

Proposing your Package to Distros

On Debian, the main way that users and upstream developers can suggest packages for inclusion in the archive is through the Debian Bug Tracking system. Bugs are filled against the special wnpp (Work-needed and Prospective Packages) pseudo-package and are titled something like RFP: superfoo -- bringing more foo to the desktop where RFP stands for "Request For Package".

Alternatively, if you are a Debian/Ubuntu user, you may also want to build and maintain the package yourself. In which case, you will need to find a sponsor.

Other distributions have different procedures. Feel free to leave a comment explaining what these may be.

More detailed information on getting packaged for Debian is available on the Debian wiki.

Getting started with a Free Software project and making it available to the community can be confusing for first-time software authors. However there are a couple of things worth knowing that will help you attract more users and increase the likelihood that your software will be part of a Free Software distribution like Debian.

Idea, Name and License

At the core, a Free Software project starts with an idea. It's the reason why you wrote the software in the first place. Where this becomes interesting is when your think that your software could be useful to others. That's when you should think about sharing your code.

Of course, one of the very first decisions you'll need to make is to name your project. This is of course a very personal decision, but if you're struggling to find something exciting and trendy, consider choosing something that:

• is not already used,
• is easy to remember and
• gives an idea of what the project is about.

Another choice you will need to make before your first release is the license. While that topic may not be familiar or interesting to you, I highly recommend that you carefully consider your options since your license choice can influence the type of community that will form around your project.

Public Release

Making your project publicly available can be as simple as dropping a tarball on a mailing list. However, if you want your project to reach all of the users for which it could be useful, there are a few other things you might want to do.

One of these things is to provide a digital home for your project. That homepage should provide access to all of the services related to your project. Such services usually include source control, bug tracking, mailing list and file areas. I've got some ideas about what that homepage should contain later but first things first, let's look at what that tarball should contain.

Tarball Contents

Most people downloading your source code will either be end-users or
distribution maintainers. Here's what they will be looking for:

• Complete source code along with the data files (if any) necessary to use your software.

• Installation instructions explaining how to compile and install your project on one of the supported platforms. This file is usually called INSTALL.

• Quick instructions on how to get started. This is usually contained in the README and it should provide new users all of the commands or instructions they need to get going within a minute or two.

• Full copy of the licensing terms, usually in a file named COPYING.

• Contact information for help or contributions. Small projects will often share the email address of the main author and a link to the project homepage if available. This is traditionally located in a file called AUTHORS or in the README directly.

This is pretty much the minimum that you need to provide in order for your code release to be useful to others and to be legally distributed by others. There are a few more things that you should think about if you would like to increase the likelihood that your software will be included in a Free Software distribution.

After putting all of this together, you should be ready for the initial public release of your project and will now be moving to the next phase: supporting your growing community.