Home · About · A-Z Index · Search · Contacts · Press · Register · Login

CIO Corner


CIO Corner Articles

Boundaryless Information Flow is Real and Relevant
Boundaryless Information Flow to Manage Our Safety
EA, Business Agility, and Boundaryless Information Flow
Enterprise Architecture: Return on Investment
Deciding on Open Source
Managing the Flow
Certification - A Part of a Virtuous Circle
Directories - If There Were No Directories I Couldn't Find IT
Boundaryless Information Flow & Enterprise Architecture
Thinking Strategically about Certified Products
Architecture: Make IT Work for You
Open Source and Standards
Architecture: An Essential Tool for the CIO
What Keeps CIO Awake
You are here:  The Open Group > CIO

CIO Corner with Terry Blevins

Deciding on Open Source

I have been in this industry for 24 years, 21 of those years with NCR. Though I’m now with a smaller organization, I share some of the same decisions that large organizations face when it comes to things like deciding to use Open Source. I believe that the CIO community has a great stake in Open Source, just as it has in off-shore development, outsourcing, etc.

Open Source has great potential. We are confronted every day with the option of considering new Open Source technologies, but we need to progress with our eyes wide open. In this column I hope to provide some pointers that you may find useful, and help you understand how your strategy can incorporate Open Source.

The first thing to do is examine what Open Source is and examine its current and future states.

Open Source is not just Linux, it is about a lot of other software spanning the entire spectrum of architecture. Open Source is really about two things: software that adheres to certain rules for distribution, and a development model. In The Open Group we think of the development model as a “boundaryless” development model, where you could have programmers from many organizations working to develop a common code base. This model brings a freedom to users as they can become part of the development model, thereby breaking the dependency they might have on a single software supplier.

The Open Source Initiative has the official description of Open Source software. The essence is manifested in the license agreements. The key attributes being that the code is readable, redistributable, modifiable, and freely usable.

Some enthusiasts say that Open Source is a movement that cannot be stopped. But it can be slowed if issues aren’t addressed. It hasn’t been stopped because it has run under the radar for many years, but attention is now focused on Open Source. It will be scrutinized from various points of view including legal, technical, business, and social-ethical.

When people start to look at and listen to the Open Source debates it is easy to develop a perception that the community is driven by many different battles between engineers and everyone else. If it is or becomes reality it will ultimately result in isolation that will do more harm than good. Then Open Source will not be a tool in tomorrow’s toolbox.

However, other voices that represent the opposite point of view present a rather different perception, one of cooperation, one of added value. This more positive view demonstrates that the community wishes to cooperate rather than battle. If this perception becomes reality then Open Source can contribute to our businesses tomorrow. I believe this is the more likely outcome.

So what other issues have to be considered?

From a technical perspective - Standardization and application interoperability.
We have all experienced the benefits of standards, RJ11, RJ45, TCP/IP, http, UNIX®, SQL. Standards are important, but we must consider how standards and Open Source play together. Standards impact us all when we decide on using a software package. We must understand that just because we have selected Open Source it doesn’t necessarily mean we have chosen a standard.


Business issues - Uncertainty of business model.
I’m sure I don’t have to remind anyone we must not be distracted by the statement that Open Source is free. Even if all source code was free there are costs elsewhere, which leads to the uncertainty of the business model for Open Source. There is a positive business case for using Open Source in specific places. And we know that business models are being developed and adopted. But nothing is free! Exploiting Open Source will cost people, time and money. As in any other business decision, total cost of ownership (TCO) and measures such as return on investment should be the guide.

Business issues - Requirements management.
Requirements for interoperation at the application level is still an issue. There is more work to be done to ensure that requirements for information exchange and document format standards get addressed. Requirements management in the Open Source development model must evolve to ensure that real customer issues are addressed.

Legal issues - WYDSIWGY (What You Don’t See Is What Gets You).
Now what about “What You Don’t See Is What Gets You?” This issue is about understanding the fine print. There are now over 50 approved Open Source licenses, and the number is rising. All licenses do one thing: they guarantee anyone, anywhere, for any purpose whatsoever, the right to use the software, copy it, modify it, and distribute those modifications free, or for a fee and the right to have the source code that makes those things possible. However each has its own emphasis, each says something about IPR and you need to understand it. Those who intend to distribute software have to exercise due diligence regarding the terms of the license.

Social-ethical issues - Accountability for failures, supportability and manageability.
Some distributors are taking up the other issues of accountability for failures, supportability and manageability, so there is hope in those arenas. There is likely to be more positive change in these areas as distributors evolve and mature.

So how can you effectively deal with Open Source? The following are a few pointers.

First, develop your policy and business case. To determine how Open Source should be used and where Open Source would be most useful to your organization you have to do some homework. Don’t just assume that anything “Open Source” would be useful. Assess the size of the development community as you would assess the capabilities of a vendor company, examine the market for multiple providers, compare the long-term costs, and from this develop and execute a strategy that supports a sound business case.

Your next tool is active involvement, and it is essential to making Open Source what you need it to become. Your involvement comes in many ways, starting with how you express your requirements. Your desire for Open Source to support open standards. Your involvement with other buyers in coming together and creating a concerted voice on what is needed. Internally, developing and executing your Open Source strategy is essential. Finally, you need to assess how you will ensure that the Open Source products are what they say they are and conform to open standards; the best way is to demand certified product.

Defend yourself proactively. It is best to work out business goals before choosing an Open Source license so that it’s clear to what extent the company is obligated to share. It might take some time, but if you are seriously considering Open Source, make sure to seek legal counsel.

In conclusion:
Open Source does not make software free. We know that license fees are a small part of software TCO.

Open Source does not obviate the need for open standards. We need to get involved to ensure that Open Source is responsibly addressing real needs. We still need an open environment and an open consensus process for standards setting.

Open Source can make business sense for you, not necessarily everywhere, but definitely in specific places. Email t.blevins

http://www.opengroup.org/cio