In the world of large enterprise, technology infrastructure “procurement” usually includes a lengthy process of evaluating and selecting new goods or services, funding approvals, contract negotiation, and finally purchasing something. Three of these four procurement processes should not relate to enterprises using free and open source software (OSS), correct? So why even consider creating a strategy for procuring open source?
Because, open source is just as valuable, if not more valuable, than commercial off-the-shelf software (COTS).
The fact that open source is easily accessible, and organizations may not be paying attention to this value, could simultaneously create security risks and license compliance exposures. The rest of this article draws a few basic parallels between an enterprise buying some kind of new asset, and an enterprise acquiring new open source software.
Stage 1: Evaluation and selection
In many situations, large enterprises perform extensive evaluation of software and technology products before developing a short list of products for a final selection. There are commercial software products that help companies improve business processes, increase efficiency, reduce overhead, and boost sales for just about any organization. Open source software assets are no different, and the options available in the world of OSS may seem to border on infinity. By establishing some minimum evaluation and selection criteria that an open source software community must meet to even be considered, the infinite amount of options can be reduced to a shorter list of the safest, and most sustainable, open source products available.
Stage 2: Initial approval (funding approval)
With commercial software, after evaluation and selection of potential new assets are completed, someone has to ask for money to acquire the assets. This is where the comparison takes a very different road in the procurement of new OSS assets. If open source software is not associated with a paper trail of who approved it, where it came from, why it is being used, and (in the case of distribution) who else is going to use the asset, this strategy becomes even more critical to a successful and sustainable open source environment. The fact that open source software can, and does, bypass the traditional procurement model of funding approval is probably the number one reason to have a system like this in place; just replace the initial (funding) approval with an approval from a team member on the first or second level of the open source software review board.
Stage 3: Contracts and licensing (legal approval)
Software license agreements, and associated compliance with terms and conditions of the software product, are equally applicable to COTS usage and OSS usage. A commercial software license for an enterprise is likely to be vetted through a procurement office, a process that usually involves a contract attorney.
An open source software license can essentially be accepted by anyone with a network connection and the wherewithal to explore the world of free and open source software. If the download, usage, and potential distribution of open source software goes undocumented, and is never vetted by legal, there is the chance of exposing the organization to a license violation. Naturally, enterprises that have adopted a mature open source procurement strategy will have a legal review requirement at some stage of the request, and an approval process for using open source. This may occur even earlier in the process than just described, or there may even be license approval conditions that guide developers in selecting licenses legal has already vetted for specific usage models. Pre-approving specific licenses will save an attorney untold hours by not having to answer the same questions again and again for developers.
Stage 4: Buying and acquiring (final approval and deployment)
Once the sustainability of an open source community is vetted, a project is selected, legal approves the license and usage, the open source review board has analyzed and approved the request, and a developer or system administrator brings the new OSS into the organization, the process is completed. This all may sound like a lot of unnecessary work just to download some new code. Initially it does take some time to set up this strategy, but once the foundation for an open source policy and procurement strategy is in place, this entire process of acquiring new open source will easily and safely outpace the traditional procurement of COTS. On the other hand, knowing that you are not allowed to acquire a specific OSS library or license could mean the difference between a nasty license violation complaint, and a safe usage and distribution strategy.
The open source horse is out of the gate and has been for over a decade. Have you read the iOS or OSX license agreement recently? Companies that safely leverage other peoples’ software products are growing leaps and bounds beyond competitors who have yet to realize the value of these strategies.
We would love to hear from our readers on this subject!
Does your organization have a similar OSS procurement strategy? Do you have a different approach than what is outlined above?