You are writing your software and everything works well. Now you want to release the first beta version to the public. Where should you put the files online? Where would people read about your project?

As mentioned in the article “The project needs a home – where to host your project” you might want to host everything on sourceforge, github or whatever hosting site you select. They often provide the option to put various information about your project online and the possibility to publish news. That’s a good start, but don’t forget to keep the information up to date. Nothing is more confusing than wrong information about the project, features, links to other sources of information regarding the project. That point is valid for self hosted websites as well as external hosting providers. A solution to ease the pain of maintaining the information are wikis. You can set them to read-only for anonymous readers, so only your team can change the pages.

When you are hosting the website yourself, please be aware that your server is constantly a target for hackers and when you host your source code there, it’s an even a more attractive target. Keep the software on the server up to date, be selective who gets access to the server itself. Keep more than one backup of the server to be able to restore everything in case something bad happened.

Documentation, the voluntary exercise?

People who would like to use your software will most likely need some form of guidance. Provide as much documentation as possible. Information on deployment/installation, usage of the software, developer info (if you are providing an API), etc.

But with a lot of documentation you’ll get a lot of responsibility. Don’t let the documentation be outdated or at least state somewhere where everyone can see it, which version you are referring to. Sometimes you are lucky and users from the community offer to help you with the user documentation. This happens frequently, but not on all projects! Take that chance and add these users to your team. They need to be informed about the current developments, so don’t just give them access to the wiki and let them do their work. There is a high chance that this won’t work out in the long run. They are valuable members of your team, so treat them as such.

Which additional information might be valuable for the users?

So you have a location to put information online (wiki, blog, cms,…), what should you put there? The answer is again pretty simple: as much as possible!

As a user it might be valuable to read how you can join the team or in which areas you  desperately need help. Not everyone is brave enough and asks you directly. many people are shy and don’t want to bother the team, because they may have something better to do or the user just fears to be ignored. Be very clear in your communication and people will listen.

Another very neat kind of documentation are screenshots, webcasts and online demos. It doesn’t matter if your software can be installed in seconds on the users computer. When you provide screenshots, people will more often give your software a try. In the last 2-4 years projects started to put webcasts about their software online. This has several advantages, you have some kind of “moving screenshot”, so people get a quick impression how your software feels and you have nice looking “interactive” documentation, if you do them in right way. Give it a try!

When you have a team of several developers and the projects progresses, it may happen that no one has time left to write some nice articles about the progress the team has made. The developers know that there is progress in the project, but users normally don’t follow SVN commit mails, so they may just think that the silence is the sign of a dying project. Maybe someone in the community is willing to perform these actions on a regular basis.

Single point of failure

So, now you have your domains, maybe even a dedicated webserver and a paypal account for donations. Imagine now, the people that opened the accounts want to leave the project. You have a lot of work transferring the accounts, domains, … Sometimes people don’t go, they are kicked out of the project, that’s even more bad if they had a central role in the project before. You can imagine that getting the domain from a kicked project member might be tricky.

When your project reaches a certain size you should consider to start for example a non-profit foundation (“gemeinnütziger Verein” in Germany) that holds the rights on the accounts, domains etc. This way you are safe in case someone leaves the project and you might be able to get some funding from companies that like your project. But we’ll come back to that topic in another blog post.

Conclusion

So, organizing the (one-way) communication with your users can be done by providing a homepage with the necessary information. Put as much information up there as you can handle. It will be worth it, because many users just go to the next site when the project doesn’t provide the answers they are looking for. Also be careful to distribute the ownership of assets like server, domains, admin rights etc, so the project can continue when an important person is suddenly gone. In the next article we’ll have a look at two way communication with your users.

I am really glad that oracle has decided in this way!

Just use your shared hosting account…

When you’re starting a new project, the decision to host it on your own webspace, which is usually a shared webhosting account. This may not be the best solution. When your project grows, then you might get help and you probably want other people to help you with maintaining the homepage. Do you want to give them your credentials which also has access to your private homepage?

When your project does a new release and get’s slashdotted, then your hoster might get angry or force you into a bigger webspace contract. With more users you might need more bandwidth, more memory and maintaining the software that runs the homepage might lead to a bigger workload too when you switch from a static homepage with a webforum to a full blown CMS.

You’ll also need a version control system for your sourcecode and a bugtracker to keep track of the bugreports. Maintaining these for yourself maybe pretty painful if you don’t have much time or experience with this kind of administration.

Long story short: When you’re not an administrator, decide if you are really capable of maintaining the site in the long run.

Free project hosting – but where?

There are plenty of hosting sites out there. I just want to point out two sites that are outstanding in my point of view. Of course the other sites like berlios etc. are fine as well. The hosting sites offer unlimited bandwith, preinstalled software for most tasks (version control system, bugtracker, tasktracker, …), backups and a fine grained permission system to be able to split the work among the team.

The big old man in project hosting is sourceforge. Everybody will have downloaded software from there before. They offer easy project creation, bug-/task tracker, very (very) simple forums, simple news, downloads, limited shell access, cron jobs, Mailinglists etc. It’s the all you can eat buffet in project hosting. Not the best solutions, but a big selection of services.

[UPDATE: Kenai has been suspended. Looks like Oracle has not seen it's potential :-(]

A relatively new project hosting site that has been published during the JavaOne from sun in 2008 is Project Kenai. The concept is very nice. They use standard software and provide a homogeneous web-interface. They offer Mercurial/Subversion/Git for version control, Bugzilla/Jira for Bug-/Tasktracking, mailinglists, Wiki, forums, … And you can access them vie their regular API, which is especially with jira neat, because the Mylyn integration is great. The project are not limited to java projects, it can be every technology. Have a look, it’s really nice.

In short: If you don’t want to do everything on your own, consider free project hosting, especially in distributed projects.

Dedicated server for the project

When cthe project grows you might have special needs. Then a dedicated server might be the best solution. You are not bound to the memory/cpu constraints of shared webhosting and you have free choice of the installed software. But you need to have good administration skills (in your project). Backups and security of the installation are important things to keep in mind. It’s one of the publicity nightmares for projects when the sourcecode or the downloadable files are compromised by hackers. Take this seriously or your efforts of building a great product are wasted. As a summary: Dedicated servers are risky, but they offer the most freedom. Take your choice.

Conclusion

There are many choices for project hosting. Every option has some advantages or disadvantages. Most projects will be served best by choosing free project hosting, but the other two options also have their charme.