"...that experience - of a CIO not knowing how ubiquitous and valuable free software has become to their organization - isn't atypical. In fact, it's the norm, and a divide we're gently trying to bridge. Opportunity's everywhere. So is free and open software. They might even travel in pairs."
Jonathan Schwartz, CEO of Sun
The case for the effective operation of Free/Libre and Open Source Software (F/LOSS) in the enterprise has never been stronger. Yet in some quarters, the chasm between senior management's perception of the penetration of F/LOSS within their organization, and the reality, has never been wider. And when you consider that Gartner predicts that "by 2012 more than 90% of enterprises will use open source in direct or embedded form", this suggests that the development of an effective F/LOSS policy will become increasingly necessary for business operations.
Many enterprises, for now, are sourcing the majority of their F/LOSS solutions via a vendor. This does not remove the need for governance. Even with commercial arrangements in place, it is crucial that business have an understanding of F/LOSS communities: what drives them, how to interact with them, and what obligations they may have to them. The game has changed and innovation is no longer the reserve of software vendors with large development budgets. Software development is now enabled by open licenses that afford great freedoms and, in doing so, facilitate widespread collaboration. With this unprecedented pace of innovation, comes new obligations. We argue that the need for education around F/LOSS communities and licensing is clear.
Governance + Education + Tools = Operations
The management of F/LOSS in the enterprise starts with governance and the creation of a policy and process to support the effective and appropriate adoption of associated technology and principles. This will, at the very least, amount to a general policy on the usage of F/LOSS, but will also likely require developer and procurement specific policies. If the standard desktop software policy is relatively strict in terms of what can and cannot be downloaded and installed, the developer policy will need to account for this while still enabling innovation and ensuring continued network integrity. The procurement policy and supply contracts can require that suppliers disclose use of F/LOSS in integrated solutions as well as provide all the materials that are required to meet licensing obligations.
Once the new policy and process is in place, it is important to provide a widespread awareness and common understanding not only amongst developers, but across development managers, product managers, research, procurement and anyone else who may come into contact with F/LOSS. Without this, the business may be exposed to risks that vary from lost opportunities to innovate, up-skill, and reduce costs, to the potential for litigation. Education is a key enabler for the effective enterprise adoption of F/LOSS and its value cannot be overemphasized.
Language
In naming the mandated organizational unit, F/LOSS Operations or Open Source "Operations" is preferable to F/LOSS or Open Source "Governance". This supports the wider role of being an enabler, rather than simply being responsible for policing and restricting the use of F/LOSS.
It is easy to adopt the negative language of F/LOSS detractors and those looking to sell associated tools and services, and this should be avoided. For example "licensing issues" and "risks" may be used in connection with license obligations and support arrangements. Here, F/LOSS is just like any other software in that you must: i) have a license to use it; and ii) either be able to support it yourself or have a support contract with a third party. These are not new considerations. But since F/LOSS enables new possibilities in both areas, it is likely that enterprises will need to bring their understanding up to date in order to build confidence in F/LOSS adoption.
Reuse
When new needs have been identified, organizations should look to reuse existing tools and capabilities where appropriate. Functions engaged in the management of F/LOSS--for instance, in an operations or governance capacity--should not seek to replace, subvert or undermine existing agencies but to instead work in concert with them. F/LOSS should largely be treated just like any other software that has the same considerations around architectural conformance, security, support and the right to use. Mutually beneficial relationships can be formed with the organization's IT architects, procurement, security officers, and legal counsel. In fact, this is critical in effecting outcomes that are in the best interests of the business and internal stakeholders, while meeting or exceeding any obligations to external communities.
Obligations
Meeting licensing obligations to external development communities is of the utmost importance, as F/LOSS is no different to proprietary software in that you must have the right to use it. If you do not abide by the terms in the license, you have no right to use the software. If you disagree with those terms, it follows that you'll either have to look elsewhere or speak to the developer(s) and see if they are willing to provide the software on different terms via a paid-for license. Here, governance is required in support of projects looking to work with F/LOSS.
More often than not it is likely that, given a license and your intended use case, your obligations will be clear. However, there will be instances where license compatibility needs to be examined, such as when combining software from multiple sources for redistribution. In such cases, legal guidance may be needed. The role of an operations/governance unit could be considered as triage to your legal counsel. However, where there is any doubt, no matter how small, consult your lawyers.
Increasingly, companies are beginning to appreciate that the maximum value from F/LOSS can only be realized through a symbiotic relationship with the community. In many cases, keeping modifications made to F/LOSS closed, rather than protecting investment, can lead to increased support costs, reduced ability to innovate, and missed opportunities. As such, a developer policy may need to cater for employees contributing to existing F/LOSS projects and starting new projects. Here there is an obligation to the business to ensure that all the relevant stakeholders have provided sign-off and accept the licensing model proposed for a given development.
Where a company has a patent portfolio, additional checks may be required to ensure that furnishing code via a F/LOSS license will not compromise an existing patent. It is also possible that standard employment contracts may state that the company owns all work done by an employee. Therefore, personnel may need to be involved in the review of the relevant company policy.
Tools
When considering new tools required by the enterprise, it should be noted that F/LOSS equivalents may be tricky to find, select, and implement. Vendors will offer their own solutions, and these should be considered alongside solutions produced by the F/LOSS community. For example, the source code analysis tool FOSSology is freely available from the FOSSbazaar initiative, a working group of the Linux Foundation. For some, FOSSology will suffice as a tool for identifying license types in enterprise code bases, thus enabling them to ascertain obligations. Where the supply chain is more complex and there is concern that fragments of unattributed F/LOSS code may have been integrated along the way, the more fully featured capabilities of a proprietary alternative may be more appropriate.
Community
When evaluating commercial services, consider that, in some cases, a great deal more value may be had from an investment in education and community engagement. Much can be gained from a symbiotic relationship with a F/LOSS community, some of which may be unforeseen. A direct relationship with the community provides access to core developers, opportunities to up-skill in-house staff, and possible opportunities to steer development of the project. Such access to core development functions and an opportunity to influence was previously, with proprietary software, largely the reserve of Fortune 500 companies.
Contributing back to a project may actually reduce costs. As an example, contributing patches or enhancements avoids the costs of operating a self-supported forked code base. Contributions also win favour with the community and visibly demonstrate to a global community your organization's capabilities. With a vendor sandwiched in-between, however, a great many of these opportunities are lost, as they exploit the relationships in each direction purely to their benefit.
Conclusion
Even if you think you don't use F/LOSS, chances are that you will consume it indirectly as part of integrated and hybrid solutions. At its most basic, F/LOSS governance will be required in the form of a clear policy and simple lightweight supporting process. You may additionally need to build new capabilities to support effective governance. Tools from the F/LOSS community should be considered alongside those from proprietary vendors. In the management of F/LOSS--consumption, contribution and creation--consideration should be given to both internal and external stakeholders, and, wherever doubt exists, support sought from domain experts such as your legal counsel. As an enabler of unprecedented flexibility in terms of innovation, licensing and support, education will be required to build enterprise wide confidence and to avoid confusion whilst addressing misunderstanding.
To realise the maximum potential from F/LOSS, you need to understand that it enables you to do what was previously not possible with proprietary software. It is likely that a direct relationship with the F/LOSS community will play a key part. Lastly, it is important to remember that in many respects F/LOSS is no different to proprietary software, and simply affords new optional freedoms.
Recommended Resources