What you are describing is a change in behavior needed in order for consumers of a new technology to adopt it. This pretty much describes the source of Geoffrey Moore's famous 'Chasm'. If open source is 'not necessarily better or worse' it will have a hard time crossing this chasm. In order for open source to be adopted it will have to be 'necessarily better' otherwise the effort needed to change behavior will not be worth it.

The commercial open source situation is that you can modify the software and support yourself if you want but you don't have to (if you have paid for a subscription). The organic open source situation is that you can and might have to modify the software (by paying for development time). Either way you have to pay and this is why open source is 'free as in speech' not 'as in beer'. At least open source gives you the choice of how you want to pay.

My experience in the last few ISVs that I worked for was that open source was downloaded and used because it was quick and easy. There was no procurement cycle, budget approval, or any other process needed to get Apache Tomcat, for example. It was partly the lack of governance that made open source attractive. When we hit problems it sometimes took significant time and effort to resolve them. This effort was 'silently' absorbed. Overall it was still cheaper and quicker to get the job done using open source. Essentially this was an IT department/developer-level issue and not a 'company' one. It was smooth and without friction but also without any auditing or control. This is where it gets awkward. If you want to manage the adoption of open source in a company you need apply some standards or governance procedures but the very act of doing this could make open source less attractive to IT developers. A careful balance needs to be set.

First let me say that there are many ways enterprises need to deal with open source. Bringing it in for strictly internal use is probably one of the simplest, if you can guarantee that is the only way it will be employed.

Other things you might do with it include

• incorporating into a software product which may or may not be open source
• customizing it and then using it in service engagements
• embedding it in hardware products, though users may never know that the contained software is open source
• making changes to it and then sharing those changes with the community.

What is needed, in my opinion, is enterprise governance of all these potential uses of open source.

Key participants are business leaders with responsibility over the products, services, and internal applications, and one or more intellectual property lawyers.

There needs to be a clearly defined delegation model so that it is clear who can and cannot make decisions about the use of open source.

There needs to be a documented and well defined escalation path, possibly all the way to the CEO, on how to make decisions on new or potentially risky situations.

Users need to be educated on the enterprise's policy around use of open source, along with regular reminders and updates.

Sounds kind of like regular business, doesn't it?

I think fear of governance can lead some enterprises to simply say "no open source" for simplicity, even though I suspect it is still being used in the trenches.

Over time more and more decisions can be delegated to local business units as experience is gained and precedents are established. Sixty to seventy percentage delegation to local management and legal staff is not an unreasonable goal after two or three years of experience.

In my mind, one of the worst answers a business leader can give about his or her enterprise's use of open source is "I don't know." It doesn't need to be scary, but just like other uses of software (e.g., only have a fixed number of licenses to proprietary software), it needs to be monitored and governed

I recommend at least annual reviews of the policies to ensure that your enterprise is making maximal good use of open source, is not being unnecessarily bureaucratic, and takes into account the latest software and legal understanding.

At Alfresco we tend to advise customers to carefully plan and consider any changes to the software. Through the Alfresco Community we encourage innovation and contribution and manage how these contributions are carried or not as the case may be into the project core.

We advise enterprise IT teams on those areas that can be customized and should not be customized to ensure future compatibility and upgrades. We also strongly believe in basing the foundation of our architecture, APIs and storage mechanisms on industry standards to give customers maximum flexibility for future-proofing their solutions.

John Powell
CEO, Alfresco Software
http://www.alfresco.com

Just to echo Bob Sutor's recommendation: it's critical to put governance in place, because you're already using open source and will use more open source in the future. Governance moves open source use from invisible to transparent.

Governance allows you to ensure that your open source choices are appropriate, with the right functionality, strong community, and necessary resources like documentation and professional services.

Failing to move to an overt method of governance only means that open source will remain a covert presence in your infrastructure, which is the most dangerous situation of all -- because if it's there, you're responsible for SLAs in the systems it resides in.

What Does Open-Source Adoption Change? Well the easy answer is nothing because most companies are already using open source software! However for the most part we are talking about IT infrastructure tools; cross-industry commodities like operating systems, application servers, databases, browsers etc.. This is software that gets in under the business radar for the convenience of IT - the sort of use that James described earlier.

The answer would be different if we were talking about industry specific solutions - tools for the business users. Here clearly the primary concern is making certain the software suits the needs of the business, so from that perspective the change is no different from using commercial solutions.

Advantages may include the ability to contribute to the code, influencing the evolution of the software (using your own developers) in more direct manner than you can with commercial software (via user groups). This really depends on whether a business has its own IT department or not, if they do then open source may offer an opportunity to use their development team skills more effectively by contributing to, and receiving from, the open source community. If you are a business without an IT department, then the main change may simply be in the way (and how much) you decide to pay for support and the cost of entry.

The impact open source will have will be different depending on the type of business using it, an insurance broker will use software as a tool, a multimedia set-top box manufacturer may use it as an integral part of the product they make and sell. Small companies will utilize software in different ways to large companies. In some cases licensing may be a major factor, in others cost of ownership may be. The number of different scenarios out there is huge, and so the number of different possible answers to the question "What Does Open-Source Adoption Change?" is also huge!

Esther says "If you don't like the way a feature works, you can't blame a vendor and tacitly decide to wait for the next version.", but in reality a lot of companies are not large enough to have this luxury, and with the big IT players like SUN and IBM pushing the adoption of open source to business, surely they (not alone!) also have a responsibility to make certain open source delivers. There is a saying in business that "You can't get fired for buying IBM", a saying I'm sure IBM is quite happy to encourage! Now wouldn't it be nice if businesses started saying "You can't get fired for embracing open source" - hopefully Bobs' work is helping educate business so they really do understand what open source commitment involves and rewards that can be gained, then perhaps one day they will really be saying "You can't get fired for embracing open source" ;-)

Matthew Tomlinson

Founding Member: OpenQuote
Director: Applied Industrial Logic
Sponsor: OpenSourceInsurance.org