We’re approaching (in a few months) the 24th anniversary of the famous email that Linus Torvalds (then an anonymous college student) sent to the world announcing his ‘hobby’ operating system (Linux). A lot has changed since that email, and while Linus still maintains ultimate veto power over what goes into the Linux Kernel, the fundamental tenet of letting go of a portion of the control over his project to gain the advantages of mass collaboration remains.
This is at the core of all open source projects, and even in 2015 it seems to be a lesson that some people in Corporate America still haven’t fully grasped. The good news is that pretty much every industry has recognized the huge value of consuming open source, whether it be for internal use in their enterprise infrastructure, or as the basis for successful product lines. However, there is still widespread corporate reluctance to consider open sourcing any internally-written code that is not part of an existing open source project. Additionally, even the idea of working in an open source fashion inside and outside of the corporate firewall has struggled to find acceptance.
There have been entire industries created around assisting companies with open source compliance, yet there are only a handful of companies offering advice and assistance on how to help your enterprise effectively participate in open source and migrate proprietary or internal code to these large, collaborative communities. This post will focus on a few tangible steps your organization can take to transition internal code from your organization to open source and when it makes sense to do so.
Identify Your Commodity Code
This may seem like the most obvious first step in the process of open sourcing your code – and it is. There is no magic bullet to accomplish this, but you must have a cross-domain set of experts to help with this task. It should include both engineering and legal representation at a minimum, but it’s also helpful to have senior-level management and architects as part of the group that assesses your internal code. Some things to consider as criteria during these discussions include, but are not limited to:
- Is this code reused in multiple places in your infrastructure?
- Does the code provide a competitive advantage to your organization?
- Does the code provide functionality similar to an existing open source project?
A major thing to keep in mind at this stage is that there may be code identified as ‘commodity’ which is so domain-specific that it can’t reasonably be used in the wider open source community. Make sure you resist the temptation to ‘code dump’ these kinds of projects to the open source world in hopes of scoring public relations points. The open source community is very adept at spotting this and you’ll quickly develop a bad reputation by doing this.
Understand The Value of Open Sourcing
Once you’ve identified potential candidate projects in your organization for open sourcing, you’ll need to make sure you have a solid business case that answers the ‘What’s In It For Us?’ question for all of your stakeholders. A big portion of this is determining the value of the code and what can be saved by re-allocating some of the internal resources used for maintaining it to other projects that provide more value to your company.
While you will be able to save some of the cost of maintaining the project completely on your own, keep in mind that successfully open sourcing a project requires significant up-front effort in compliance, licensing, etc., and some ongoing work to help manage and govern the community you’ll be creating to help drive the project going forward. Also note that it may be difficult to quantify the value brought to the project by fresh perspectives from outside your organization, but this will, in fact, be a considerable benefit if you build a successful community.
The value proposition you come up with after looking at all of these factors should help alleviate some of the cultural fears of ‘losing control’, especially if you can articulate how this process both solves a business need and increases innovation potential.
Create Small Pilot Projects
It’s important to remember that you don’t have to open the floodgates to all of your internal code to get started and derive value from contributing to open source. If you are a company who has traditionally only consumed open source, pick one or two small to medium sized projects that look like a good fit for you to open source.
Make sure you do your research to determine if there are potential contributors you can work with as you release the code. In some cases, it may make sense to have your project contribute its code to an existing open source project where there is already a base of developers working on similar code.
Even if your organization has already started to open source some code, it can be helpful to create an actual team (or a virtual one) to help guide the process of contributing and helping to shape the community.
Iterate on Success
The open source cliché of ‘release early, release often’ is a cliché for a reason – it works. It’s important to understand that successfully open sourcing your internal code is not a one-time effort. What separates ‘code dumps’ from communities is the time and effort you make in sustaining the development, and helping the community be successful.
This process of open sourcing is not easy for all companies. There are significant hurdles, be they cultural, regulatory, or financial. But, the reality is that the companies who have put in the effort to cede some of their control (Twitter, Facebook, Red Hat, and even Samsung) have reaped huge benefits in productivity, innovation, and yes, profits.
Losing (control) to win is a strategy that helps define the success of open source, and it’s crucial to understand this strategy if your organization wants to be successful in leveraging the power of open source communities.