Effectively Governing the Internal Use of Open Source Software

  

 Email Article  

Tweet  

  

Without an effective internal OSS governance strategy, enterprises both large and small are susceptible to problems and risks that can surface quickly when there is a lack of understanding and acceptance of open source software issues.

Poor governance strategies can:

• Threaten timely delivery of software
• Cause you to duplicate your efforts by reengineering products when an open source component creates licensing conflicts
• Incur unexpected costs for training and development
• Put an employee’s job at risk when their seemingly helpful actions conflict with management’s acceptance of open source solutions.

Understanding that enterprise organizations use open source software for a variety of reasons. Cost benefit, flexibility to choose solutions that fit your specific needs, access to source code to make changes, and the ability to contribute to the community and participate in innovative technologies, just to name a few.  In today’s blog post, we’ll look at a few real-world examples of problems that could have been avoided had the companies involved, executed, or kept up with an open source governance process. 

The first example comes from a company that had actually defined an acceptable list of open source packages and had instituted a license review board.  However, the governance process was focused on the final products and there were no tools or processes in place to track open source projects as they were introduced during development.  This meant that several libraries were included in the products that were not sanctioned by the governance group.  When it came time to move forward into production, a final review revealed an incompatibility in licensing for one of the components.  At the last minute, the Enterprise Architecture team had to submit requests for exceptions to the internal policy for the offending component, but unfortunately, the license conflicts meant that the legal team could not make an exception.  The project was delayed while the development team located a replacement technology, which created even further delays because the only fitting alternative was in a programming language that was unfamiliar to them.  In a mad rush to deliver their product, they were forced to learn a new programming language on the fly and risk launching a product built with sub-optimal expertise.

A very different scenario occurred at company B.  This company had always been very risk averse and from early on had taken the standpoint that open source software presented too many risks.  The discussion of the merits of open source and governance strategies could never be broached because executives just said “no”.  They assumed this was enough to ensure open source would not be brought into their environment, and no audits were ever conducted to discover whether any open source was in use.  As part of the company’s security policy, all outgoing communications were closely monitored.  One day an email was sent from a corporate address to an open source community containing a bug fix.  This email set off a chain reaction of confusion and panic.  Unbeknownst to the management, the development teams had been quietly using (and improving upon) open source projects.  One of the developers wrote a fix and wanted to share it with the community, but when he did so, using his corporate email account, it was flagged and brought to the attention of management.  Security and legal teams were outraged and the employee was suddenly at risk of being fired.  His manager, not wanting to lose this team member, and realizing that this could be a much bigger problem if not addressed, had to go on the defensive and carefully broach the topic with the executives. It has taken some time and patience to get everyone to look at the issue realistically, but this company is now beginning to come to terms with how much open source is actually being used and developing a governance strategy to ensure these surprises don’t disrupt operations in the future.

How could these troublesome situations have been avoided in the first place?  In the first scenario, even though the company had a pre-approved list of open source software and a policy permissive of using open source, new projects being introduced into the development environment were not being reviewed until the final product was about to be released.  A provisioning process would have helped here.  The company could have encouraged the development team to submit a request for any open source components as they were being evaluated.  The governance board would then have had a chance to research the license and understand how the usage model might trigger a conflict in the final product, well before they were going into production.

In the second scenario, an employee nearly got terminated for not following a policy that didn’t reflect the reality of the development practices. Acceptance about the adoption of open source that was already happening would have been a good first step.  The company could then conduct an audit and identify exactly how much open source was being used and start to understand their risk profile.  Ignoring the problem does not make it go away and only leads to unpleasant surprises. 

You can read more articles on OSS Scanning, Compliance, and Governance here.