So, your developers (hopefully using company-provided guidance) have found some FOSS that seems to fit the bill. But, does it? You’ll need to ask yourself the following questions:
- What are your criteria for good FOSS?
- How does it get downloaded and reviewed?
- How does my organization evaluate and approve FOSS components before they are included in our products or our business applications?
- Do you have mature processes in this area to manage FOSS, or are you exposed to operational and legal risks due to lack of governance?
FOSS approval processes have been around for a while. Of the eight management disciplines in the Olliance FOSS Maturity Model, I would say this one is the most mature. When companies start to put process around FOSS management, the review and approval process is generally the first one created. Companies create review and approval processes to suit their risk tolerance levels, decision making cultures, and organizational structures. Sometimes, they are centralized, sometimes decentralized and sometimes a hybrid. Some create special teams for the purpose of approving FOSS (like Open Source Review Boards) and some leverage existing groups (like architecture teams, legal teams, and security teams).
Some companies have multiple processes. There might be one process governed by IT for downloading the FOSS, running it on the desktop or other internal uses and another process owned by an Open Source Management Board to manage use of FOSS incorporated into your company’s products.
The types of approvals vary across companies, as well. I’ve seen approvals to download, approvals to evaluate, approvals to use on the desktop, as a development tool, in an internal application, in a customer facing hosted offering, in a professional service offering, and (of course) embedded and distributed with products. It does not end there. There are also approvals to reuse, approval extensions, approvals to modify and approvals to upgrade. And, then there are all the organizational approvals; legal approvals, OSRB approvals, architecture approvals, security approvals, manager approvals and senior management exception approvals. I could go on, but it is starting to feel like Bubba talking to Forest Gump about all the ways you can prepare shrimp.
So, how would you classify your company?
Exposed to Risk: If your company allows developers to make their own decisions regarding which components should be used and how they evaluate that software without any guidance or methodology, your company may be unnecessarily exposed to the legal and operation risks of uncontrolled FOSS. The lack of a process may allow the incorporation of FOSS that is not appropriate for your intended use or legal compliance requirements.
Measured Risk Reduction: Do you provide some review and selection guidelines to your developers or does each product development organization have its own guidelines that they developed? At this point, you have accomplished some measured risk reduction. FOSS will be evaluated to some standard, but this will not be consistently applied across the organization. Also, different standards in different groups can hamper or even prevent code sharing across groups. So, at this point, you have not fully leveraged the value of FOSS and you are using it in a way that can increase costs.
Effectively Managing FOSS: Does your company have a written FOSS policy that describes acceptable sources and desired attributes of FOSS? Does this policy also extend to any dependent FOSS that is included with the primary FOSS package? Do you have a FOSS evaluation framework where you have developed the management infrastructure, including a model and criteria, to evaluate open source options effectively and consistently across your organization? And finally, does your company have people with defined roles or review boards that provide oversight and decide on any FOSS usage requests that are out of compliance with existing policy requirements? If you have all this, then congratulations, you are effectively managing FOSS in your organization, at least to the point of risk reduction. Having a written policy criteria and an evaluation methodology means that consistent evaluations of FOSS will occur, and this means code reuse can be encouraged. A formal approval process will provide the necessary oversight to review the evaluation and select open source consistent with company goals.
Excelling with FOSS: Just because you are effectively managing FOSS, does not mean you are fully leveraging the benefit of FOSS. In fact, I’ve seen formal approval processes that actually discourage using FOSS, and when your procurement acquisition processes are much simpler and more efficient than your FOSS acquisition processes, you have a problem. Ask yourself the following: Does your company have an automated process supported by applications to handle FOSS requests, approvals and record keeping? Can the system automatically grant approvals without people intervention if requests are consistent with policy? Do you have visibility and transparency during the FOSS approval process for those requests that must be considered? Is the process monitored to ensure no bottlenecks are created? Is this approval system tracking FOSS at the release level and integrated with your FOSS compliance process? And finally, has this system and process been accepted by your engineers? If so, then you are getting the full benefit of FOSS at your company.
Driving with FOSS: If your company is involved in efforts to evaluate and select FOSS as part of a community effort, then you are actually using FOSS communities to drive your business objectives. Not many companies get to, or desire to get to, this level. The example I gave during my previous blog about searching is the GENIVI Alliance for the automotive industry. Google with Android is doing the same. Both Google and GENIVI Alliance members are evaluating FOSS components and putting them into a platform so you don’t have to select and evaluate those particular components. You are simply reusing their work. And by reusing their code and participating in community efforts with them, you are likely helping them to accomplish their business goals. If you or your company is involved in those efforts or similar efforts, then my hat is off to you.
Note: This blog entry is part of a series regarding effective management of OSS. It is based upon the Olliance Open Source Maturity Model which covers eight key management disciplines ranging from “Open Source Discovery” to “Executive Oversight.”
