Related link: http://conferences.oreillynet.com/pub/w/38/osbr.html
Every year at OSCON, Tim O’Reilly gives a speech about his latest views on technology, publishing, and whatever else is on his mind. At every speech that I’ve seen, at some point he stops to explain that one thing he wishes more people would understand is that what the company does, how it creates value, is not primarily by publishing books, but rather by helping communities come together and communicate with each other. Publishing is one way that that happens, so are conferences, so are web sites, creating developer communities, and FOO camps. The point that I have always taken away from Tim’s observation is that it is important to look deeper into organizations to understand what really makes them tick. The essential processes may be obscured by the visible evidence.
So it is, in my opinion, with open source when applied by Information Technology departments. The visible evidence that is typically the focus of discussion is the “free as in beer” lack of license fees, the ability to thumb one’s nose at vendors, and the innovative uses to which many companies have put open source. What is less visible, but I believe the main event, is the surrounding skills and processes that IT departments have had to acquire and manage in order to make open source successful.
What makes open source a nightmare at one company and a victory at another? It’s not the software. What interests me about open source is the way that it forces IT departments to address the issues that are central to making the essential processes of IT work better. Here are a few examples:
Using open source forces conscious management of the skills of an IT department. With most commercial software an ecosystem of support and consultants exist to deliver expertise for a fee. This allows an IT department to effectively ignore the question of determining the right level of skills and learning how to institutionalize them so they are not focused in one person. With open source, the ecosystems for support and consulting are usually weak or non-existent, although a host of new startups is attempting to change this for certain types of open source. Using open source requires an increase in skill levels for most IT departments. The point is to use open source an IT department must consciously decide what skills such as expertise in certain languages, infrastructure, or applications that it is going to develop and leverage to the greatest extent possible.
Open source forces attention on designing a hybrid architecture. With most commercial software, the architecture at many levels comes with the products. That is, the way everything fits together and the qualities that are created, such as an emphasis on flexibility or performance or ease of use is all determined by a product designer. With open source, the IT department must create a hybrid architecture to make things work, and in doing so must examine the question of what is the right architecture for the company’s specific needs. This is a question that is not asked enough in most IT departments. In creating an hybrid architecture, an IT department generally improves its architectural skills and its ability to understand how to integrate all of the components in its infrastructure together.
Governance is another issue that must be managed carefully by IT departments adopting open source. Governance can mean many things, but in this context, I mean the rules by which management exerts control over the department. For most IT departments that use commercial software, governance happens through the purchasing process. You have to pay money for commercial software, so to get access to that money, a strong case for the software must be made. There always is a limited amount of money, so only so much commercial software can come in the door. Open source makes governance more challenging. Anyone can download open source and install most programs quite quickly, which distributes the power to consider which software to use. Because there are no license fees, the purchasing process cannot be used as an effective governance mechanism. The lack of license fees means that the size of the budget is not a constraint on how much open source can be used. Adopting open source forces companies to think about how to extend their governance mechanisms to encompass a larger group of people and address a broader set of issues.
Open source forces companies to improve their game when it comes to evaluating how well software meets its requirements. With commercial software, a vendor usually has all sorts of mechanisms such as case studies, white papers, customer references to explain what a piece of software does. Too often, an IT department must rely on these mechanisms or is not able to install the commercial software and determine its capabilities and how well they meet the requirements. With open source software generally the software is all there is. To determine what it does and how well it works and how well it meets requirements, an IT department must install it and perform experiments. While this is a burden in one sense, it usually prevents any surprising requirements mismatches later on.
With commercial software, support is a monopoly, only one vendor provides support for each product. While for open source, a market is forming. A variety of companies are competing to offer various kinds of support services. Adopting open source means that an IT department has to go beyond taking comfort in that there is one throat to choke, and must decide what support tasks it will take on and which will be outsourced. This generally means the issue is given more consideration.
Using open source forces an IT department to understand its relationship to intellectual property. Intellectual property with commercial software is pretty straightforward. The vendor usually warrants that it owns the intellectual property in the software that it is selling and the buyer is protected. With open source, an IT department must determine how it is going to manage the risk that the intellectual property in an open source project is not going to create liability. This is especially complicated when building software using open source.
With all of these issues, adopting open source in a thorough and responsible manner raises consciousness and forces an IT department to address fundamental issues in a more complete manner than is common practice. The higher skill an organization has, the more likely it is to be a heavy user of open source. What makes such organizations effective, though, is not just technical skill, but the better management processes that must be put in place to manage the use of open source. This is the essential underlying gift behind the visible manifestations of open source.
Of course, there is no reason that any of the sort of consciousness raising that is described here couldn’t happen without adopting open source. And using open source is no guarantee that all these things will happen. But for an IT department that is really paying attention, adopting open source where it makes sense can be like a management fitness program that results on the sort of empowerment that Doc Searles envisions in is prescription for Do It Your Self IT.
If you like thinking about these sorts of issues and you think that you might like to talk with others who find them interesting, I hope you take the time to check out the program for the Open Source Business Review, a new premium conference that is part of this year’s Open Source Conference. The conference program is aimed straight at teaching IT departments how to address the issues raised above.
I look forward to hearing from fellow travelers who have experience addressing these issues in IT departments.