When should you open source your software?

An overview of what to bear in mind when open sourcing a software project.

It’s 20 years since the term ‘Open Source’ was coined. In that time the movement for free and open software has gone from a niche to a common method of distribution and a normal way of operating for businesses.

Major technology shifts are now driven by open source technologies: Big Data (Hadoop, Spark), AI (TensorFlow, Caffe), and Containers (Docker, Kubernetes) are all open projects. Massive companies including Google, Facebook, and even Lyft regularly release Open Source tools for the world to use. Microsoft – whose former CEO once described Linux as a cancer – now embraces the concept. 

According to the latest developer survey by Stack Overflow, nearly 45% of developers contribute to open source projects. But when should an organization go from merely contributing to other projects to creating its own open source projects?


What to know before you open source a project

When and why:

The specifics of when to open source a project depend on the project you have in mind and the company’s goals. Perhaps it’s a new project that’s useful but not part of your core commercial strategy, perhaps it’s an internal tool that other may find useful. Maybe it’s a piece of software that’s come to the end of its useful lifecycle and legacy customers might find it useful. Maybe you want to speed development of a product and build your business on top of that. Or maybe you want to adopt a commercial open source business model based on services or Community & Enterprise editions of your software.



You can host your open code on your own site, or use public repositories such as GitHub, GitLab, Coding, or BitBucket. Hosting open source/public repositories are usually free and make community contributions easy to do and manage.



Releasing a project as open source requires an open source license. But picking a license can be overwhelming. There are many different licenses, all containing different terms about how the code can be used, modified, and contributed to. The type of license your project is released under can be changed, but it’s better to do your homework first to save disruption down the line.



If you want people to use and contribute to your project, it’s good to give the community as much information as possible. Documentation is important – the more the better – and there are various tools including Gitbook, Docusaurus, and Corilla to help you properly document your code. 


Ongoing management:

How much work goes into maintaining a project after you open it is up to you.  You can maintain it like you would any propriety code you own, or just leave it for the community. To keep a community engaged, however, it’s best to dedicate at least some time and resources to stewarding your project.



A community might spontaneously appear around your project, but if you want to drive adoption of your open software, you need to keep the community active. Communicate with them often, be clear about the direction of the project, and work with them if they make feature suggestions. Tools such as Gitter, Slack, Riot.im offer ways to manage and engage with your community.


Below is a Q&A with Mike McQuaid, Senior Engineer at GitHub and lead maintainer of the Homebrew project, an open source packet manager for MacOS; and Sid Sijbrandij, CEO & co-founder of GitLab.


What projects/products make good candidates for being made a standalone Open Source project, rather than commercialized?

McQuaid: Any project that does not provide a clear commercial advantage over your competitors is a good candidate for being an open source project. The software industry is increasingly using only open source development and infrastructure tools, so collaborating with other parts of the industry on these allows a rising tide which makes the work for all companies easier.

Sijbrandij: Projects that are used by many verticals because more users increase the number of contributions that a project receives. In addition, projects that are used by developers will have an easier time attracting contributors.

Who should that decision sit with – the team who developed it, the CIO etc.? How much involvement should there be from people beyond the development team, and who owns it going forward?

McQuaid: The decision has to be a collaboration between all involved parties: the CIO, the team who developed it, and any other stakeholders in the organization.

It’s likely the day-to-day work of running the project will fall to the development team. Therefore, it’s important that they are empowered to make successful maintenance of the project part of their performance criteria.

Sijbrandij: It depends on the size of the company. For startups, the decision traditionally lies with the CEO and board members. However, it should be noted that it’s easier to transition before raising investment because after the fact, investors might be reluctant to open source their IP. While the development relations team should be responsible for the success of the open source community around the project, they are most successful when the entire company participates.


How important is it to choose the right OS license, and how do you go about deciding which is the right one?

McQuaid: As long as you choose a widely used OSI approved license you are safe. In general though, you’re best to pick one of the most common licenses recommended on https://choosealicense.com.

Sijbrandij: Open source licenses should never be an afterthought – they dictate how developers can use and develop code for each open source project.

Before choosing what open source license is most fitting, research each offer and consult an expert. What is appropriate for one company, may not be for another. Three common open source licenses include General Public License (GPL), Affero General Public License (AGPL) and the MIT license.

GPL is used less because it’s difficult for companies to adopt. AGPL is a license used by open-core software providers to entice payment for their proprietary version. And MIT, the most popular, allows organizations to work with projects without restriction. In particular, MIT can be leveraged in tandem with the Developer Certificate of Origin (DCO) instead of Contributor License Agreements (CLA).


How involved should a company’s legal team be in this decision?

McQuaid: The legal team should only need to provide a final sign-off; open source licenses are standard and widely used at this point. Under no circumstance should the company’s legal team create their own open source license; this will dramatically stifle usage.

Sijbrandij: Adopting open source essentially means you’re giving up your IP. To avoid any negative repercussions, your legal team should be heavily involved in the selection process. If they’re unfamiliar, it’s worth outsourcing to someone knowledgeable.


How important is creating the community around a project, and how do you do that?

McQuaid: Creating a community is not essential if you’re happy running the project yourself. That said, if you want to do so we explore this in our Open Source Guide on Building Welcoming Communities.

Sijbrandij: Open source was born by harnessing the power of the crowd. Without a community mentality, it’s impossible to reap the benefits of open source. For enterprises considering open source, they can take advantage of its power by approaching open source with the following  steps:

Welcoming contributors: To foster a vibrant community, it’s essential for enterprises to make their contributors feel welcome and valued. Empowerment leads to greater collaboration.

Measuring contributions: At GitLab, we have a merge request coach, whose role is to push merge requests from the community into GitLab. We created this title to welcome added contributors to the platform and get their efforts across the finish line. It’s also crucial from a measurement perspective. Quantifying involvement, pushes others to come aboard.

Being transparent: The philosophy on open source is built on transparency. At GitLab, everything we do is public. By making information readily available, we effectively reduce the threshold to contribute and make collaboration easier.

Finding a balance between core and proprietary: For example, GitLab is open core. We have to strike a balance between the open core and proprietary. What’s important is to state the rules of engagement - what will be in open core and in open source - and stick to it. Never promise to open source something and then make it closed source.

Engaging with the community: In order to successfully foster a community, an organization must be actively engaging. At GitLab, I maintain a constant presence, and whenever a concern arises, you’ll see me commenting on that issue.


How important is good documentation when Open Sourcing a project?

McQuaid: Good documentation helps an open source project grow and be used but it doesn’t have to be amazing or perfect on day one. It’s worth noting that even the worst documented open source projects are often still better documented than many internal company projects!

Sijbrandij: Documentation is essential for making a open source project popular. First and foremost, a project’s documentation must clearly outline why you should use a feature and then how you can use it. As part of documentation, it should include multiple formats for a variety of different styles of learning including text, graphics, videos and the opportunity for Q&A’s.

At GitLab, we hired three full-time employees, whose responsibility is to constantly refactor and redefine documentation for our community edition. They work off documentation originally created by developers and this ensures developers have everything in one place to be able to contribute their thoughts and ideas without interference.


How much ongoing effort/maintenance/resources does a project require from the host company once it is released?

McQuaid: The host company doesn’t necessarily need to provide any ongoing efforts or resources; some organizations just “dump” their open source code for others to use if they choose. That said, if you wish to have your project be a recruiting tool or grow much beyond what you’ve already done, it’s important to invest time into the community and attract new users, contributors and maintainers.

Sijbrandij: Maintaining open source projects is a full-time job – they require constant upkeep. Responsibilities associated include: dependency upgrades, security vulnerability reports, performance fixes, release management, application consistency, refactoring the code base, UX testing, design guides, and Quality Assurance on end results.


What is your view on Open Sourcing old products after their commercial viability is coming towards their end?

McQuaid: Open sourced code is always more useful to the community than proprietary code they cannot see. In general, therefore, it’s always worth open sourcing old products.

Sijbrandij: From an educational standpoint, open sourcing old products after their commercial viability has expired can be of tremendous value. Granting developers access to these types of projects allows them to study and learn from codebases. This is especially true for computer games, as they can be played in a simulator. However, old products are unlikely to become viable open source projects.


Key things to know, key things to avoid doing?

McQuaid: Our Open Source Guides document many more of the best practices in running and growing open source projects. Check them out!

Sijbrandij: When you begin creating an open source project, consider starting with small steps and iterate from there. Secondly, err on the side of being too open and transparent. Lastly, when you make improvements to a open source project it is better to contribute them back. Not only does it feel great to give back to the larger community, but it also ensures you’re not maintaining the changes by yourself – this can be a costly endeavor.


Also read:
Alfresco Founder: Commercial Open Source is more than Old Stuff for Free
DataBricks: From Berkeley Labs to democratising AI with APIs
Free vs. open source software – what’s the difference?
Jim Jagielski: Open source pendulum will swing back towards community
Linux Foundation exec on why Open Source is now everywhere
What will Linux and open source look like in 2041?


Enterprise GitHub projects of the week: Google special
Enterprise GitHub projects of the week: Microsoft special
Enterprise GitHub projects of the week: Facebook special
Enterprise GitHub projects of the week: Blockchain special
Enterprise GitHub projects of the week: Intelligence agency special
Enterprise GitHub projects of the week: VR Data Center Experience, Jasper, and CodeSV
Enterprise GitHub projects of the week: Confidant, UI for UWP, & Ansible
Enterprise GitHub projects of the week: UFO, CloudFoundry, Brakeman
Enterprise GitHub projects of the week: Atlas, Unit, and prplHypervisor
Enterprise GitHub projects of the week: Envoy, NativeScript, & OpenShift