In this document, we’ll cover the steps to open sourcing a project. These steps are drawn from the experience of managing multiple projects on GitHub. Although every situation is different and might require additional steps, these guidelines will help you launch well.
In this article I’ll explain how to open source your project, you will learn how to properly setup a GitHub repository, how to add awesome contributors and much more.
Create your own open source project
Every project should start with an identified need. If you feel that existing projects on GitHub or Bitbucket don’t offer the functionality you would like to build, then create your own open source solution. Besides an initial project draft, you should consider the following set of questions:
- What skills do you need for your project?
- How much time are you willing to spend on your project?
- What problem(s) does your software solve?
- How many potential users are there for your product?
Determine the goals
Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.
One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.
The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.
Create open source alternatives to commercial software
Today’s commercial projects actively engage open source solutions. Many companies base their projects on free tools. When there’s a huge selection of software, you don’t need to reinvent the wheel. This is why it’s useful to play around with free software that can replace similar proprietary software, or that fixes an issue you’ve recently faced.
Another reason for replacing commercial solutions with open source software is eagerness for real innovation and growth. Commercial software claims to be innovative, but its final goal is turning a profit. Open source software unites best practices, great quality of code and passionate developers willing to code just because they like to.
The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.
Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.
I use pivotal tracker. The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.
Contribute to existing open source projects
You can find many projects you are free to participate in on GitHub – a developer-oriented platform with a simple but essential set of functionality. GitHub attracts developers with public APIs, a sleek and frequently updated UI, gists (Git repositories) that allow you to share pieces of code or even whole applications, and much more. You can contribute to free software in many ways. Developers can fork projects, make changes to code, and send pull requests. And quality assurance is always appreciated. Sometimes developers are too busy or too lazy to check the quality of their code. So go ahead and report a bug or try to fix it – your help is appreciated.
You can reach the hottest GitHub projects by following the “Trending” link. And in order to make your search more relevant, use advanced search: select the language you would like to code in and choose “best match” criteria. Best match ranks projects according to relevance, taking into account the number of forks (which represents how actively the project is updated) and stars (“likes”, in the language of Facebook). Most projects have known issues (however, some don’t) with labels like “bug”, “discussion”, “security”, or “refactor”, or other labels according to the level of difficulty: “easy”, “medium”, “hard.”
Every open source project should contain these things:
- Open Source license
- Contributing guidelines
The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template.
The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service.
The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.
Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.
To track important changes for users and contributors, there is a semantic version. The version number contains numbers and adheres to the following pattern X.Y.Z.
- X major release
- Y minor release
- Z patch release
Why create an open source project?
There are plenty of reasons for your company to start an open source project. You might aim to innovate faster, achieve quicker time to market, collect new ideas, enable interoperability or de facto standards, recruit talented developers, and gather diverse viewpoints and contributions to produce better code and better products.
These benefits can all be realized by using and contributing to open source projects created and managed outside your company. But a comprehensive open source strategy often includes creating and launching your own open source projects as well.
Initiating projects or releasing existing projects as open source to the community strengthens the sense of give and take, which can further build a company’s reputation in open source, and make the company even more attractive to open source developers and more influential in the open source projects where it contributes. Having your codebase as a starting point for discussion can bring other advantages as you look to engage an external ecosystem of partners, vendors, and users.
By opening up your own code and development practices to outside use and contribution, you are truly embracing open innovation and using open source to its best effect for your business. Code released under an open source license allows anyone to contribute, inspect, modify, and improve it. This collaborative approach to development is now the de facto way of building software and a proven engine of technological innovation.
This is true whether your primary mission is financial services, providing health care, operating fleets of trucks, selling retail goods in stores or online, providing transportation to commuters and airline passengers, building roads and bridges, or thousands of other specialties. While these enterprises certainly want to keep the applications and technologies that are core to the value they provide to their customers, there exists a myriad of code and software that are dependencies and which are not a high-value differentiator to the organization. Opening these technologies up as a project to outside contributions can create new possibilities and opportunities for growing and strengthening this code.
This is a short guide which will help you to prepare your project to be Open Sourced. This document will also help you and your contributors to work together as an efficient team.