Open Source Governance Framework

By Subraya Mallya - October 2009 | Topics - Compliance, Open Source

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

Thoughts shared by readers (2)

  1. Jonathan Strong Says:

    Subraya – timely article. I agree with your points, and also feel that you’ve only surfaced the tip of the iceberg. It seems that many of the newer companies who embrace open source have spent quite a bit of time working on a model to help them monetize the offering, and in turn that translates to expense for us, the corporate users of the software.

    I can’t blame them. Few companies are in the position of a Sun or IBM and are able to allow complete unfettered use of their software the way developers are free to use Java without paying a license fee. As I’ve led teams using various open source tools over the last couple of years, we’ve seen how many of the newer monetization models work, and it definitely takes a bit of the allure away from the idea of “open source”.

    For a current example, we can look at something like Pentaho, an ostensibly open source business intelligence suite. At first glance, it’s pretty compelling. It appears that most of the pieces are “there” to let you construct your own BI system with “free” software. But when you actually start working with it, you keep bumping into the differences between the open source version, and the commercially supported version. You discover that debugged builds for open source are never at the same version as the commercial version. Documentation that’s readily available if you pay a $30,000 license fee simply doesn’t exist for the open source version.

    If you start to dig your way through the online forums, you find that most users are with companies who paid for the commercial version and they depend, constantly, on the support from the vendor that the license fee affords them. This is not available for open source users.

    I could continue, but I imagine that you’re getting the picture. Essentially, using the open source version is very similar to making use of the open source router firmware that Linksys makes available to the world. Typically, it’s only hackers, and folks like the authors of Sveasoft (3rd party firmware for the Linksys boxes) who can make use of this open source code.

    Infobright is a great column-oriented DBMS, and it also comes in an open source version (ICE – inforbright community edition) and a commercial version. In this case, the company is a bit better about providing support for the open source version, but this version is limited and is missing some critical features that are only available in the licensed version (such as multi-threaded data loaders, and the allowable use of DML). You can manipulate ICE to get around some of the limitations, but only if your budget allows your team R&D time, and only if your team is up to the challenge. Otherwise you will once again find that the product may only be practical for you if you buy the licensed version.

    So – in addition to the other points you make in your blog post, there may be significant hidden costs that only become apparent if you dig deep, or spend several weeks or months working with the products.

    And this all happens before you have to even think about governance issues… Great potential, and very powerful in the right hands. But, as in all things, caveat emptor.

  2. Subraya Mallya Says:

    Thanks Jon. I agree with you completely. While the attraction to Open Source is pretty clear, the challenges companies inherit (unknowingly or willingly) is enormous.

    Subraya Mallya

Trackbacks For This Post (4)

  1. Subraya Mallya Says:

    Open Source Governance Framework – http://tinyurl.com/yfxpfxg (via @prudentcloud)

  2. Open Source Governance Framework | Strategies for Software-as-a … | Open Hacking Says:

    […] here to read the rest: Open Source Governance Framework | Strategies for Software-as-a … This entry was posted on Monday, October 12th, 2009 at 1:22 pm and is filed under Linux, News, […]

  3. hovo Says:

    Open Source Governance Framework | Strategies for Software-as-a …: A well-defined open source governance proc.. http://bit.ly/UR420

  4. hovo Says:

    Open Source Governance Framework | Strategies for Software-as-a …: A well-defined open source governance proc.. http://bit.ly/UR420

We would love to hear your thoughts. Please leave a comment

Note: Please review our Comment Policy

You must be logged in to post a comment.

Back to Top

Discover more from PrudentCloud

Subscribe now to keep reading and get access to the full archive.

Continue reading