How to Open Source Your Side Project and make it rock!


Starting your side project but not being able to complete it is nothing you should boast about. As you are making that cool app or developing an awesome web software, you might like to get a helping hand. In situations such as this, open-sourcing your side project can be a pivotal difference between the success and failure of your project.

Not only will you be engaged with other like-minded people, but also learn from them.

Side projects are a great way to learn and have fun at the same time. Many successful programmers always work on side projects as it keeps them engaged. They also get the chance to try new technologies. Content creators such as Fumanchu, Alexbooker, Kornerr, and Aashish work on their side projects and livestream at the same time. You can check their channels and follow them!


Fumanchu Weaving The Magic of OpenSource

However, there is a time when you need to open source your side project. Open-sourcing your side projects can bring a lot of benefits and ensure that it moves in the right direction.

Arik Fraimovich, a past member of EverythingMe, worked on his side-project re:dash during his work tenure. Later, when the business closed, he open sourced the tool which in turn enabled him to start an Open Source company.

A great journey, indeed!

The same story can also be seen on LiveEdu, where many content creators are streaming their projects to the audience.

Fumanchu, a great content creator on, loves the idea of open source. He adds, “As a programmer, investing your time in open source, raises your pricing power as a seller of labor. Businesses using open source (yours or not) will pay for the expertise you have, not the licensing.”

Let’s take a look at the benefits of open-sourcing your side project.

Benefits of open-sourcing side-project

  1. There will be a significant improvement in code-quality as more and more people will work on the code.
  2. After open-sourcing your side-project, you will see an improvement in documentation quality.
  3. Those contributing to the project will feel more valued and satisfied. Open-sourcing the project can be a good way to engage the brilliant minds to work on your idea.
  4. The security aspect of your side project will improve as more bugs will be panned out with time.
  5. People will start learning how your software works and that’s a good thing, as it will enable more people to adapt to the new software.

How to open source your Side Project

0. Project Summary Paragraph

The first step is to create a clear project summary paragraph for your project. The summary should be precise and meaningful, and should give a glimpse of what the project is about. It should not use complex words or jargons to avoid confusion. The project summary paragraph is a high-level information.

Below is an example of a fictional project:

Gladiator is a simple debugging tool for web developers. It is different from the available debugging tools in the market. It works with all the modern browsers and operating systems.

The above example is simple and easy to understand. It also conveys the general idea behind the tool and the target audience including the usability case.

1. Hosting your project

The next step is to host your project. You can get started using GitHub (paid or free). If you are using a paid account, you need to make sure the repository is set to public.

You can also choose other hosting sites such as BitBucketGoogle Code, and SourceForge. However, it is recommended to go with GitHub as it is the number one hosting site when it comes to open source projects. GitHub offers good issue tracker and other solid features.

Before you choose your project hosting site, you need to keep two things in mind (as you are going to manage the project as project leader):

  • Integrated Wiki
  • Issue Tracker

If you are worried about leading the project, then you should choose a hosting site that offers excellent issue tracking system. Other things such as integrated wiki, the ability to publish a site, and release new changes can help you manage your project easily.

After making the final choice, you need to import your code to the site.


2. Issue Tracker

The next step is to create an issue tracker after the code is deployed in your chosen hosting site. Issue tracker enables contributors to understand the project in a structured way. To make the most out of the issue tracker, you need to list the bugs in your code. You can also list the future tasks as it can help contributors to work on features along with bug fixes.

The bugs and feature-set are closely related and hence listing the future tasks can help anyone who is willing to contribute in the project.

So, how to get started? The first step is to create high-quality tickets. The tickets should be clear and should list the tasks explicitly. This will help volunteers to be clear on the deliverables.

Bad example: Responsive design is not working properly. Need to bootstrap the frontend.

Good example: Fix responsive design to display correctly on mobile resolution.

3. Change log

A change log is a place where all the project changes are listed. You need to keep the change log file into your source repository for accessibility purposes. Change log should only be accessible by the project leader. As a project leader, you should update the change log regularly as the project progresses.

Strictly speaking, there is no defined structure for the change log. However, it is a good idea to add the following information under different subheadings:

  • New Features
  • Compatibility issues with the previous version
  • Bug Fixes

You should also note that the change log should not use any fancy English terms and should be easy to read and understand.

Pro Tip: Don’t forget to mention the name of the contributors.

4. Mailing List

A mailing list will help you grow your community further. It is not possible to improve the project without a mailing list. Also, having a common place where both the contributors and users can suggest changes or make feature requests can further accelerate contributions.

You can use FreeLists or Google Groups to create a mailing list. It is also recommended to create two mailing lists, one for the users and the other for the contributors. This will help you take control of different threads easily.

5. ReadMe

One of the most important files of your project is the README file. It contains all the information related to the project and is the first thing a contributor will notice.

README is a simple, plain text file written using  markdown. You can add any information that you think will help the users or contributors to understand the project or how to use it. To get started, you can add the following information in the README file:

  • Summary paragraph
  • Email and author’s address
  • Official Project website URL
  • Project Hosting URL
  • Issue/Bug Tracker link
  • Project mailing list URL.

A good example of how a ReadMe should be.

6. Release your project

Not everyone is tech savvy and will not like to install your software/app by downloading the project GitHub repository. To ensure a proper user installation experience, you should include a proper tarball file (.tar.gz). This will enable anyone to download and install it easily.

You must also ensure that every new release comes with proper information. Don’t go overboard and try to assume that the user already knows about your project. Anyone who visits your project page for the first time should know what it is about and how they are benefitted by using it. That’s why the Project Summary Paragraph should be at the top of the release notes.

Every release should also mention the list of contributors. Mentioning your contributor’s name shouldn’t take much time and it will motivate them to contribute further and as such they will feel appreciated and valued.

7. Proper Documentation

Writing documentation can be a hard challenge. Among the community, documentation is considered the single most hated part of software development. Thus documenting open source projects is a huge challenge.

For open source projects, initial documentation can be written in the form of FAQ. However, it is a good idea to develop a proper documentation later on and improve it with every release. Many contributors like to write documentation, which in turn, will help your project documentation. However, the initial documentation work should be done by you.

8. Website creation

To make users interested in your software, you need to create a proper home page for it.

The homepage should be designed keeping non-tech users in mind. For example, if your project is a simple To-Do app, you may want to create a proper website to ensure that users download and use it without the need to go to the code-hosting website (such as GitHub).




Phaser Website

9. Licensing

There are different types of licenses you can choose for your open source project. For example, you can choose the MIT license if you want your project to be simple and permissive. Another popular choice is the Apache License 2.0 which provides an express grant of patent rights, from contributors to users.

There are many different licenses for open source, and it is hard to list all of them here. You can check ChooseALicense, a website dedicated to open source license, and decide yourself which license fits your project.

10. Stream the whole process on

After you are done with all the steps mentioned above, it is now time for you to make a grand announcement to the audience. Keep in mind that users only value projects that offer valuable information from the onset. They don’t want to invest time in projects if these lack basic information such as project summary, mailing list or bug tracker.

So, only announce when everything has been done correctly and comprehensively. The announcement should be made through livestream as it will easily grab contributors attention. You should choose to  host a livestream on and host a Q&A session with the audience. It is also a good idea to announce your livestream on social media platforms such as Facebook, Twitter, and Google. If you run a blog, don’t forget to write a proper blog post and then share it.

You made it!

Congratulations! You have successfully open sourced your side project. Now, it is time for you to monitor the growth and keep iterating. You should also host a livestream, once in a while, to address the contributors about the critical changes made to the project since the last release. This will motivate contributors to stay involved in the project. A clear planning can easily make side projects flourish and capture the attention of the best developers around the world.

So, which side-project you are deciding to open source? Comment below and let us know.

  • Arnold Crowley

    Open-sourcing a side-project is no small feat. However, I really liked how the article put up all the steps. It will really help those who are stuck with their side-project and would like to make it open-source. Thanks for the article!

  • I think you need to arrive at a more realistic perspective regarding releasing an existing proprietary project under a libre license.

    First, most developers in the libre software world are busy with their own projects and don’t join other projects randomly. Also, it’s always easier to start your own, new project than to learn about existing code. So be warned: after release under a libre license, nothing may happen (at first).

    Second, I don’t find the project description easy to understand. Please tell the interested audience how your debugging tool is different from what’s on the market.

    Third, GitHub makes forking and contributing changes very, very easy, and I guess they were the first to provide such functionality. While other project hosters might offer git hosting, GitHub is the favourite for historical reasons.

    Fourth, you don’t necessarily need to manage the project as the project leader. You can also leave it alone or somebody else picks up the project lead.

    Fifth, an issue tracker does not necessarily help others to understand the project in a structured way, it keeps track of what needs to be done. You could very well find yourself in a situation where people file previously unknown bugs and new feature requests in the tracker and expect YOU (or somebody else) to fix them instead the other way around. But it’s always a good idea to dump all of the known issues and potential extensions into the tracker, so novice and veteran developers learn where/how they can get involved in your project.

    Sixth, the version control and issue tracker of your project hosting could be considered the change log. The names of the contributors are logged there as part of the commit.

    Seventh, it is possible to improve the project without mailing list (why shouldn’t it?). Ideally, users should suggest changes and feature requests in the issue tracker, but if they don’t have an account, somebody should accept them per e-mail or web form and then insert them into the project hosting issue tracker. Keep things together and centralized, you should not expect people to read months and years of mailing list discussion.

    Eighth, the README file must include the license of the software. If not provided elsewhere in the project files, information is needed how to build the code.

    Ninth, the best place for documentation is right next to the code. Use something like Javadoc to automatically generate the low-level documentation from source, while keeping it up to date with relatively little effort. The overall architecture then can easily be explained in a few sketches, referencing the concrete methods/classes/functions from the Javadoc documentation. Make sure that there’s a way for everybody to change the documentation, be it as part of the version controlled source code or a Wiki, so there is no friction for others to update/improve/correct it.

    Tenth, licensing. Choosing a license won’t make your project any simpler or more complicated. If you should pick the MIT/X11 license, notice that people are not required to contribute extensions or bug fixes back to you (no copyleft). If your software is supposed to be accessed via a network, you should consider the GNU AGPL version 3 + any later version in order to avoid the Software-as-a-Service loophole. You really should learn about the GNU AGPLv3+later, because legal problems can render all of your technical works useless.

    While releasing a project under a libre license is a honorable thing to do and a contribution to the community and the libre software world, you should not do it for the wrong reasons (except you don’t mind to be disappointed). The free/libre software movement cares about the rights of the user, and as we are all users ourselves, we deserve something like essential, universal digital human rights. They include: run the software for any purpose, reading and changing the code, distribute the software (incuding the code) independently and distribute modified versions of the software (including the code). With software that meets those requirements, one can do his computing independently and in freedom. That’s the main purpose of “open sourcing” something. For your project, this means that libre software developers will only consider contributing to your project if you contributed the project to the community because otherwise it would be a waste of time and energy. If you just want to crowdsource people to do work for you while you retain the rights or control, such a project release could even be considered as some kind of attack.

    For entertainment purposes, I recommend the documentary “Project Code Rush”. It’s about Netscape releasing their browser code under a free license which became the Mozilla project.

Show Buttons
Hide Buttons
Read previous post:
Обзор и голосование за лучшие IDE для веб разработки 2017

Некоторые IDE являются бесплатными, другие - платными. Некоторые из них довольно простые, в то время как другие делают практически все,...