Open-source project release checklist

Releasing an open-source project requires a few more things than just putting the code up on the internet. Well, that is if you want people to see it.

The interest in open-source has grown a lot over the past ten years. Linux has been deployed on washing machines and combat drones, and most programmers today could hardly imagine doing their work without the vast array of free and open-source tools at their disposal.

With all this attention, more and more code is being developed out in the open by both companies and individuals alike. The downside of this amazing trend, however, is that when releasing a brand new project, you’re against some pretty stiff competition.

How can you help your open source project get noticed?

The checklist

These are the steps I take when making any of my code open source. They come in five sections in no particular order. You can use some, you can use all. The goal is to make it as easy as possible for others to find out about your project, learn how to use it and contribute back. Here it goes:

Licensing

• Does your project include a licence?

  Without a licence, your project isn’t open source. Learn more.

• Is the licence approved by OSI/FSF?

  Some licences may look like they are open-source but they really aren’t. See the list of OSI-approved or FSF-approved licences.

• Is your licence compatible with the rest of the ecosystem?

  Check whether your licence is compatible with the popular choices for other projects in your area. Learn more.

Landing page

• Does your project have a landing page?

  A README on GitHub, profile on SourceForge or dedicated website. Your project needs a place on the internet.

• Does it say what it is and where to get it?

• And how to make it work?

• Can you include any visual elements?

  Screenshots or diagrams are great to grab people’s attention.

• Does it say how to contact you?

  You don’t want to miss out on ideas from people who are interested in your project!

Accessibility

• Do you provide a language-level package?

  An npm package, gem or crate. If your language has a package manager, your project should be on it.

• Can you provide distro-level packages?

  Installing software from your trusted distribution sources is the pinnacle of user comfort. If you have time, make sure to package your project up for Fedora, Debian/Ubuntu or Homebrew.

• Would it make sense to write an automated installer?

  Automated installer can make getting your project up and running as easy as a package. If packaging doesn’t make sense for you project, write and easy installer (like this or this one).

Documentation

• Does your documentation start with a quick guide?

  The easier to get up and running with your project, the more likely it is that somebody will give it a go.

• Does it include an interface/API reference?

  Beyond just giving it a go, an interface/API reference is essential if someone decides to really make use of your project.

• Is it searchable?

  Search functionality will make your docs much more useful. Even if it’s all on one page with CTRL+s in the browser.

• Should it explain how to setup the dev environment?

  You might want to mention how to build and debug your project for people who decide to contribute.

Bug tracker

• Is it NOT empty?

  Even if you haven’t found any bugs yet, put down a few tickets for things that you’d like to improve or do next. You never know who might pick it up.

• Does it include a few issues for beginners?

  Keep a few really simple tickets to onboard first time contributors. Splitting a function in two or exporting an extra CLI option? These are great tasks for people who are unfamiliar with the codebase. Learn more.

• Are all the tickets well explained?

  Make sure the tasks are well defined so other people can work on them if interested.

Tools

• Does your project have with automated tests?

  A test suite makes it easier for contributors to validate their changes without being aware of the rest of the codebase.

Ready, set, release!

With all these boxes ticked your project is well set to sail the high seas of open source. Don’t worry if you can’t do all of them - every little helps.

And when you finally get the first contributor, don’t forget to celebrate:

Do you do anything else that isn’t on that list? Let me know in the comments section below or tweet at @radekpazdera.