As Open Source software continues to penetrate every facet of software business (vendor and consumer) companies now face a challenge in getting a handle on the various open source software that they might be using. In the course of the last three years of my working with many startups or their leaders, I have found that startups have taken a special liking to open source more than their larger corporate peers for obvious reasons.
In the last decade or so, Open Source software (besides SaaS) has caused a major upheaval in the world of software, both consumer and enterprise. The main attraction of open source software has been the fact that it provides a choice for organizations free themselves from the clasp of the proprietary software vendors and the control they exert in terms of expensive support contracts. Community based and third party support from organizations has also played a major part in the wider adoption of open source software.
Although the essence of Open Source was to make software available for FREE, each software offering does come with a license. As with any free, open standards process, the flavors of Open Source software licenses are aplenty. Before adoption a Open Source offering and benefit from the value delivered to their organization, it is critical that companies pay close attention and rationalize the nuances of the type of license that governs it. Pay special attention to the fact that each open source technology might itself be an amalgamation of other open source technologies that come with their own licenses.
Given that they are easily available and free and not requiring you to go through a corporate procurement/budget process does not mean companies can start using them willy-nilly. A well-defined governance process is essential for companies to effectively manage the legal and operational risks they could run into down the road.
As part of working with a startup that built software heavily based on open source, I came up with process (which is still being refined). Depending on what stage you are as a company, a brand new startup or a large global organization, you might want to start with different activity in this process, to quickly get a handle on the process.
Inventory
If you are an organization, that is already using some (or many) open source software in your company, and until now, have not had a defined process, the first thing to do is to get a exhaustive inventory of all the open source technologies that are being used.
As part of compiling the inventory, make it specific to the version of the software. There have been many instances where open source license terms have changed between versions of the software. So it is important to capture that.
Once you have a comprehensive inventory created, classify or tag them with the following factors
- license type (Mozilla, BSD, Apache, GPL2…etc)
- License Agreement language (link or downloaded format)
- # usage - number of projects/products using them in the company
- Form of usage (reference or derivations made)
- packaging & distribution - bundled into the product or referenced as a separate pre-requisite
- platforms - (J2EE, PHP, Ruby-on-Rails, .NET)
- Internal Sponsor/lead (identify one, if the decision was made-by-committee or the lead is no longer with the organization)
Approval Policies
Implement an approval process at the outset for approving the decision to adopt any new open source software. In fact, as part of instituting the process, I would strongly recommend, conducting an quick approval process for software already being used as a means to vet the effectiveness of the policy. This gives you a good understanding of what, if any, corrective actions need to be taken to mitigate risks, for software already in use.
An effective approval policy must include roles for all the constituents that will be impacted by adoption of the open source technology. Legal, IT operations, support, engineering, marketing should all have varying degrees of involvement in the approval.
The approval processes should include approvals from
- Legal - for the specific language in the license agreement. This should take into consideration the pattern of usage - reference v creating derivative work, bundling vs soft pre-requisite. If you are selling your product that includes Open Source software, then reviewing your liability clauses to ensure you are covered might also be required.
- IT Operations - in terms of certification for interoperability with remaining technology infrastructure, scalability, security.
- Support - in terms of capability to support your customers while your product, including the open source software being used. This might also mean that you have upgrade to a enterprise support license from your hitherto used community license of the open source software.
- Intellectual Property - clearance in terms of keeping ownership of your intellectual property. Remember, in the event of any M&A your IP will come under scrutiny so a stitch-in-time saves nine. (Startups need to pay special attention to this).
Provisioning
Once the adoption of a open source technology has been approved (legally and operationally), it is important that provisioning is done through proper channels. Much as people hate going through IT for technology provisioning, this one might come back to bite. Provisioning should involve
- IT certifying the product you plan to use is certified with your current IT infrastructure
- Certification should also be done in other areas like support for security holes, performance/scalability.
- Clear definition of download/uptake process for patches and software. Better yet, have a internal download site for approved patches that are also certified.
Tracking and Governance
In addition to the pre-approval and provisioning, a continuous oversight is necessary in terms of usage of the technology. During the time of usage of the open source technology any of the following could happen
- With the changing technology landscape, companies getting acquired or going bankrupt, you might have inherited risks that you thought you were clear off.
- A motivated developer, seeing new features in the newer version might have upgraded the open source version and built that fancy feature you are planning for the next release.
- Since it is already an approved product, a new project inside the company might start using it and you might not know about it.
- A project using open source technology gets shelved resulting in non-usage of the open source software you
Managing the inventory of the Open Source software being used through some form of Asset Tracking is critical. This will provide a good platform for period audits against the Terms of Use of each of those software products along with approved projects/users.
Some companies do a great job of managing their Open Source usage. AppDynamics goes a step further and publishes the list of products they use on their site for public to see.
Bruce Cleveland of InterWest Partners wrote a excellent post on the issues a company ran into as part of M&A due diligence due to lack of a good governance process around open source. Check it out here

Pingback: Subraya Mallya
Pingback: Open Source Governance Framework | Strategies for Software-as-a … | Open Hacking
Pingback: hovo
Pingback: hovo