Why some software project websites suck and others don't

written on Saturday, September 04, 2010 by

Today I gave some thoughts to what distinguishes a good software project website from a bad software project website (especially for open source projects).

I came up with a few must-have criteria for a good software project website:

On the very first page, state what the software does, and what the goal of the project is.

More than once, I've seen project websites about a software, that provide downloads and how-tos and everything else, but don't even explain what the software does. If I hear about a software and open the website, the first thing I want to know is what the software can be used for. If I can't find that information quickly, I lose interest.

Provide Screenshots in the main navigation

Whether you like it or not, what many users care for are screenshots. Feature lists are great, but when you see some screenshots of the program in action, you get the general Idea how it works and how user-friendly it has been designed. Great features are useless if the UI sucks.

Put the download section in the main navigation

The second most important thing on a project website is the link to the download section. It should be visible on every page, and it should provide quick, easy download possibilities. Also, redirected downloads suck. Direct (and therefore wget-able) downloadlinks are better.

Provide documentation

What users want and developers hate, is documentation. Great documentation can contribute to great success. A good example of this is the area of software frameworks. A lot of frameworks (like CodeIgniter, Django and jQuery) are highly successful - not least because of the great and easy-to-understand documentation. Provide good documentation (e.g. on ReadTheDocs) and don't forget to share it with others.

Provide a way for feedback

Many open source projects grew over time because of user feedback. User feedback is important. And it needs to be quick and easy. A registration for an issue tracker is a no-go for me. If I have to register, I don't report. Allow anonymous bugreports and feature requests, and a lot more feedback will come in.

For OSS projects: Provide easy possibilities to participate and share code

Among software users, there are many great and capable programmers. Many of them have great ideas for contributions they could make. Most of them don't have the time and motivation to track down the owner of the source repository and to ask for the permission to contribute. And patches that can't be shared aren't fun. Provide an e-mail address to send in patches. Or even better, use a distributed source code management system like Git. And then host it on a platform like Github, so that users can easily contribute their changes to the main branch, without you having to manage tedious permissions.

Stay in touch with the users

Communicate. And provide information on how to reach you on all available communication channels, like e-mail, IRC, twitter, facebook, forums etc. The more there are, the better. Inform the users about updates, but don't spam them (use newsfeeds or social networks). And answer all not-totally-stupid questions. If you communicate, and if your software rocks, users will turn into fans.

A majority of the mentioned issues should be known to most people releasing software, but apparently aren't. The project website is the first contact with the "outer world" and in most cases best way to promote your software. Use it, don't waste this potential.

There are probably several other important things to remember when creating a project website. The listed ones are just some important issues that came to my mind, the list is by no means complete. You are free to contribute your experiences in the comment box.

This entry was tagged internet and open_source