Top five tips for releasing software

By Steve Crouch.

You've put in the hard work, developed your software masterpiece and it's finally ready. How should you go about releasing it into the wild? In the rush to release your software it's easy to forget a few things. A few very important things! Let's take a look at five things you should consider prior to release...

1. Always release software with a licence

Your hard work in developing your software is just that: it's yours. Without specifying the rights you want to convey to your users, and under what conditions, they could do whatever they want with it - including making a tidy sum by selling it! And without being clear on liability, users could pursue you for damages if something goes wrong when they use it. The onus is on you to protect your interests and the rights to your software.

For an introduction to copyright and licencing, see our guide on adopting an open-source licence.

2. Don't wait until the software is perfect before releasing

Whilst it's important to make sure your software is ready for release, it's easy to get caught up in making the software perfect, which can unnecessarily delay the release.

It's a harsh truth to accept, but your software will never be perfect. There will always be parts of it that need a little tweaking or lack the ability to do that extra something. The key here is in expectation management: be clear about what the software can and cannot do, and what still needs to be done. The clear advantage to this approach is that you can get early feedback on your software. You may even find that the extra something isn't that important after all, or perhaps is better implemented in a different way.

In general, the reasons to publish your code are plentiful. There is a very good article in Nature by Nick Barnes, the director of the Climate Code Foundation, which gives a host of reasons to overcome the resistance to release.

3. Software releases should be versioned

You can run into problems with user expectations and make it difficult to track issues if you release your software without versioning information.

If you aren't clear that a release is a beta, then users may assume the software is ready for proper use and end up upset when it doesn't work. And things get very complicated if a user encounters an issue but - due to your multiple, unversioned releases - it's not clear which release is affected.

You can manage expectations for the scale of changes by adopting a consistent (and publicised!) use of major and minor release version numbers, e.g. going from 2.0 to 3.0 should convey the software has changed substantially, whilst changing from 2.0 to 2.0.1 shows that only small fixes and enhancements have been made.

4. Provide contact information

Users may want to get in contact with you for any number of reasons. Perhaps they've encountered a problem, want to report a bug or need further information. It's not all bad - they might want to collaborate with you, provide code enhancements, or congratulate you on creating such wonderful software. Of course, they need to know how to contact you, so providing a website address and an email address in your software, on your website, and in your documentation is strongly recommended.

5. Download and test your release yourself

In the rush to release it's easy to miss a key step and - just like that - the release doesn't work. This is a frustration that can be easily avoided by downloading the new release and going through the process of building, installing and testing it. This way, you make sure that the download links work and the software is usable. Even if you could have a great piece of software to show the world, no one will ever find out about it if your software cannot be installed due to an avoidable mistake.

If you want to know more about releasing software, take a look at our handy guide on releasing software.