Once an IT department has used open source software successfully on a small scale to fill a gap in a data center’s infrastructure, to reduce the cost for commodity functionality, or to provide the organization with an application of value, the appetite for open source can grow dangerously fast. Using one open source application or infrastructure is frequently a simple task, with modest implications. However, as each new instance of open source is added, modest implications can multiply into major headaches.
For example, if a company introduces Linux to replace a proprietary Unix implementation, it has now taken responsibility for maintaining the skills needed to support Linux. If a content management system such as Drupal is added, skills to understand and maintain that application are required, along with the ability to code in PHP, the language Drupal is written in. Of course, Drupal requires a database—usually MySQL—and a variety of other PHP components, as well as knowledge of Apache.
Let’s say TWiki, a flexible, IT-oriented Wiki implementation, is installed. Now someone must understand how to support the TWiki application and the Perl language that TWiki is written in. In short order, an IT department can rapidly expand the pool of skills it needs to acquire.
It is easy for this pattern—the uncontrolled introduction of open source software with its accompanying demands on skills—to occur because the control processes associated with commercial software (the need to spend money to acquire and implement software) do not apply in the open source world. Download it, install it, and you’re off.
In Chapter 5, we discussed a few different approaches to solving organizational problems faced when managing open source adoption. This appendix will shift focus to the technology itself and will use the concept of the platform to provide some guidance as to how to assemble the right portfolio of open source software.
The central idea is that each IT department should seek to minimize the number of skills required to support the open source portfolio it assembles. At the same time, IT departments should seek to leverage those skills repeatedly so that the investment in acquiring and maintaining them produces maximum value.
The idea of a platform has gained great currency in technology strategy in the past few years. Most of the time, the term applies to a foundation layer on which other technology can be constructed. Intel’s chip set is a platform. Microsoft Windows is a platform. Java is a platform. Much has been written about the rules for constructing and marketing a platform to gain the most control and to squeeze the most profit from its use.
Our perspective on platforms is much more modest. We use the idea of a platform to refer to the collection of software used for development, infrastructure, or applications. The goal is to assemble the smallest, least expensive, easiest-to-maintain infrastructure that meets all your needs.
The challenge in assembling a platform based on open source is that for the most part, no one is designing open source to be a platform. Some open source projects are used together so often that they are treated as a platform: the combination of Linux, Apache, and MySQL with Perl, Python, or PHP is referred to as the LAMP platform. But that doesn’t mean it’s easy to get a particular version of PHP working well with Apache or with MySQL. In short, the evolution of open source platforms, like open source itself, has left significant holes in the platform that IT departments should be aware of as they decide which open source to adopt.