Why do we need governance for Open Source Software (OSS)
In nutshell, OSS is quite different from commercial software products therefore existing governance proccesses have to be adjusted to accomodate new model that OSS brings. It is not really a separate process: it needs to be part of existing enterprise IT govenance.
What is OSS?
It is more than just *free* software. It comes in many forms and shapes and brings along new development process, distribution and service models and several software licenses. In addition, a very important part of OSS is governance and community. Therefore, in order to deal with OSS efficiently, enterprise has to clarify what OSS is from the company’s perspective, what is its scope and decide what type of OSS is the best aligned with the company strategic goals.
In what way OSS is different?
Licensing model is different.
OSS introduces new software licenses to the enterprise and to make things even more complicated there are hundreds of OSS licenses. A special effort is required to get through this legal maze unscarred.
Service model is different.
Whether there is a vendor behind OSS or not it is based on a new service and support model. Enterprise policies around service contracts have to be re-evaluated and adjusted even if OSS comes as a part of vendor solution with the signed SLA. Things to consider:
- how to report defects
- scheduling fixes and patches
- what about contributing patches or enhancements?
Distribution model is different.
Unlike commercial software all it takes to start using OSS is download distribution files and install it. Therefore, a policy is required that defines:
- how to get OSS, where to store it
- do we get only binaries or source as well
- what version, what about upgrades and patches
Risk management is different.
First, OSS introduces new legal risks. The primary legal risks are contamination, derived works and indemnification. Indemnification risk can be reasonably easy mitigated through license agreements. To address contamination (i.e. using company proprietary code in the OSS contributions) a policy is required about contributing to the Open Source project. The trickiest one is derived works risk when use of OSS in the enterprise solution may make it subject to the General Public License (GPL). In some cases indemnification protection may not cover derived works risk.
In addition to legal risks there are other risks associated with use of OSS. Among those are software commoditization, lack of standardization in OSS, misalignment with emerging application superplatforms, integration risks, changing business models, project stability, challenges in assessing OSS. Things to consider:
- define policies to deal with each risk
- define alignment with strategic direction
- define alignment with application superplatform vs best of bread strategic direction
- how to assess OSS
- what is preferred OSS license
- get legal department involved in assessing OSS risks
Cost structure is different
Traditional commercial software cost consists of multiple components such as license fees, customization cost, service and support fees. Though there are number of hidden costs and it is not as transparent as software vendors want them to look enterprises as a rule are well prepared to deal with it. On the other hand, OSS costs are uncharted territory and figuring out total cost of ownership (TCO) for OSS maybe quite challenging. Things to consider:
- how to assess TCO for OSS
- how to compare commercial and OSS software price
- how to budget for OSS projects.
Dependency management is much more complex.
OSS projects are very liberal at introducing dependencies on other open source components. That may easily lead to spaghetti of dependencies and seriously limit the ability to manage and integrate applications using OSS. Anyone who had to troubleshoot notorious java.lang.LinkageError problem knows exactly what I’m talking about. Things to consider:
- OSS repository
- tools to manage OSS dependencies
- OSS dependency analysis is part of the early risk assessment for all projects.
Human factor.
There is a lot of passion around OSS. OSS brings strong sense of community and spirit of participation. Architects and developers using OSS or participating in OSS development tend to develop attachment to specific products or projects. Therefore, policies are processes are especially important to make technical decisions that are balanced and based on business needs and organization strategic goals and not on emotions or affiliation with specific OSS products.
Areas of OSS Governance
What exactly needs to be governed? You may be suprised to what degree OSS is used at any particular enterprise even those that do not allow use of OSS at all. Here are some of the areas OSS governance may need to focus on.
- OSS that is currently used in enterprise applications. What is enterprise strategy on using OSS? What OSS needs to be grandfathered and what needs to be replaced or get rid of?
- Application development team wants to use OSS because commercial alternative is not available, too expensive or doesn’t meet business or technical requirements
- OSS introduced as a part of vendor solution or platform
- OSS introduced by integration vendor
- Buy vs build decision. IS OSS based solution considered at all?
- Vendor evaluation. Should OSS that vendor uses be part of the evaluation criteria. How about OSS experience/participation?
- Use of OSS development tools.
- Use of OSS for proof-of-concept projects.
- OSS software development practices. Is there something company can learn from?
- Skill set: is experience with OSS required or considered a plus?