Imagine for a moment you’re the CIO of a Global 2000. You’re responsible for your company’s IT services and infrastructure, as well as how well technology investments support the overall mission of the business and its employees. Your company has tens or hundreds of thousands of external customer relationships that depend on your systems, with thousands of employees whose productivity depends on them. Your development team has been building software for years, taking advantage of the abundance of free and open source software available on the Internet – not just the big packages in the LAMP stack (Linux, Apache MySQL, PHP), but hundreds if not thousands of useful components and software “parts” and snippets in code or binary form (JARs, etc.). And many of the recent college graduates your team has hired pride themselves on their knowledge and use of open source.
Is this a problem? How could using freely available code that your dev. team doesn’t have to re-invent be a bad thing? It’s not. But if your developers have had free reign to choose and use whatever code they want without governance — oversight, guidelines and controls — it can become a huge problem. But not for them, necessarily.
Often these developers are heroes in their own department silos, coding less and delivering more. The problem is for the CIO and the company is that, if you don’t have visibility or control over what’s been downloaded and deployed in your IT infrastructure, the quality and maintainability of your systems may be in question causing operational, technical and security risks. Financial institutions, for example, are known for keeping their software applications tightly locked down, but it’s not practical without a system that tracks open source.
In fact Gartner predicts that, “By 2014, 50 percent of Global 2000 organizations will experience technology, cost and security challenges through lack of open source governance.” At Black Duck, we’ve experienced is time and time again when we’re called in to work with an IT group, even in companies that purport not to use open source and have policies against it, and we invariably find it, and lots more than was known.
So what is open source governance? It is a closed-loop process to control the use of open source within an organization’s IT systems and supply chains. It covers the development lifecycle from acquiring software through building, deploying and maintaining it. And it’s directly related to the broader category of IT governance, which helps ensure that IT supports business goals and appropriately manages IT-related assets, risks and opportunities. A governance solution must include an open source policy, with guidelines for:
- Open source use for developers, managers, security, auditors, and legal
- Implementation of the processes for reviewing and controlling the flow of open source through the lifecycle
- A technology platform to automate manual governance processes that may have been patch-worked into place, as well as new processes that are required to fill gaps (e.g., the acquisition, review and approval workflow for using external software from the Internet)
As the use of open source software grows rapidly, the need for open source governance is becoming an integral part of mainstream IT development. Adoption of open source governance is also driven by related compliance initiatives. Sarbanes-Oxley requires certification that a company has proper financial procedures and controls in place and can verify ownership of material assets including software. In Europe Basel III regulates how much capital banks need to put aside to guard against the types of financial and operational risks banks face, including operational risk from deployed software.
Governance and compliance go hand in hand. Hopefully I’ve made a decent argument of the need for open source governance. I’ll tackle open source compliance in my next post.
Please share your thoughts in the comment section – I look forward to discussing why IT needs open source governance.
