What you need to do before you post open source code

Posting an open source project is more than posting code on the Internet.

Interest in open source software has been growing for the past 10 years. Linux stands in washing machines and battle drones. Most programmers cannot imagine their life without a wide range of free and open source tools at their disposal.

The flip side of this remarkable trend is that when you release a new open source project, you are in a zone of fierce competition.

How can you help your project to be noticed?



Before you open any code, I answer the questions that are outlined in this article. But not necessarily in the same order.

You can follow every point of the checklist, but you can only parts of it. Remember the goal - to help others learn about your project, quickly figure out how to use it, and take part in it.

License

• Does your project have a license?

Without a license, your project is not open source software. Read more about this here .

• Is this license approved by OSI / FSF?

Some licenses may look like they are suitable for licensing open source software. But they do not have that right. Check the list of licenses approved by OSI and FSF .

• Is your license compatible with others in the ecosystem?

Check what licensing projects with similar topics. Read more about license compatibility here .

Website

• Does your project have a page on the Internet?

Readme on Gihub, profile on SourgeForce or specialized sites . Your project needs to have its place on the Internet.

• The visitor of the page will immediately understand what is it?

• And how does it work?

• Did you use visual elements?

Screenshots and diagrams are an easy way to capture the reader’s attention.

• Have you left your contacts?

Surely you will want to hear the thoughts of people who are interested in your project.

Availability

• Do you provide a way to distribute native to a programming language?

It can be npm , gem or crate . If your language has a package management system, your project must be registered in it.

• Can you suggest a distribution method for the * nix distribution?

The ability to install software from familiar sources is at the top of your user's comfort. If you have time, make sure to host your project for Fedora , Debian / Ubuntu, or Homebrew .

• Does it make sense to write an automatic installer?

With the help of an automatic installer, your project can be launched and installed as easily as installing a package using regular tools. If creating a package does not make sense for your project, write an easy installer / installer (like this one or this one )

Documentation

• Does your documentation begin with a quick installation guide?

The easier it is to install and run your project, the more likely it is that someone will try it.

• Is the interface / API links enabled?

In addition, to give the opportunity to "try" your project, the interface / API links are extremely important if someone really wants to use your product.

• Can your documentation be found?

Search functionality will make your documentation more useful. Even if this is only one page with ctrl-f in the browser.

• Should she explain how to create an environment for the developer?

Perhaps you want to mention how to build and debug your project for those who want to take part in its development.

Bugtracker

• Is he not empty?

Even if you haven’t found any bugs right now, make a few tickets for the things you want to improve or do next time. You will never guess who can find them.

• Does it include several tasks for beginners?

Do some really simple tasks to engage those who are just starting to program for open source projects. Dividing a function into two or deriving an additional command line argument are great tasks for those who are unfamiliar with the project code.

• Are all tasks well explained?

Make sure that all tasks are well described, and other programmers can easily work with them if they are interested.

Instruments

• Does your project have autotests?

A set of tests will facilitate checking changes for compatibility with the remaining project code for programmers who participate in your project.

To the start, attention, release!

If you answer all the questions in the affirmative, your project will become very successful among other open source projects. Do not worry if you can’t do everything - even small steps work for you.

And when the first developer comes and writes something in the code, don’t forget to mention it, like a dude from the Big Lebowski:


Just from Illinois.

If you know what else you can add to this list, write in the comments on this article or on Twitter to the author of the article: @radekpazdera.