6
Spread the word – communicating with your users Part 1
No comments · Posted by patrick.c in Talk posts
For us developers, it’s easy to write the code, but that is not all a good project needs to do. You have to provide information on your project, the releases, the schedules and how to use your software. That’s a bunch of work, how can you fulfill the user expectations?
The website, a first step
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.
early-phase · hosting · introduction · talk
