Open-source project release checklist

Things to remember when open-sourcing your code
23 November 2015
~
3 min read

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

  • Without a licence, your project isn't open source. Learn more.
  • Some licences may look like they are open-source but they really aren't. See the list of OSI-approved or FSF-approved licences.
  • Check whether your licence is compatible with the popular choices for other projects in your area. Learn more.

Landing page

  • A README on GitHub, profile on SourceForge or dedicated website. Your project needs a place on the internet.
  • Screenshots or diagrams are great to grab people's attention.
  • You don't want to miss out on ideas from people who are interested in your project!

Accessibility

  • An npm package, gem or crate. If your language has a package manager, your project should be on it.
  • 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.
  • 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

  • The easier to get up and running with your project, the more likely it is that somebody will give it a go.
  • Beyond just giving it a go, an interface/API reference is essential if someone decides to really make use of your project.
  • Search functionality will make your docs much more useful. Even if it's all on one page with CTRL+s in the browser.
  • You might want to mention how to build and debug your project for people who decide to contribute.

Bug tracker

  • 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.
  • 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.
  • Make sure the tasks are well defined so other people can work on them if interested.

Tools

  • 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:

The Dude from Big Lebowski
Just got home from Illinois...

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