...seeing as I'm in London and awake and online before everyone else.

You are right that most CIOs are not going to lurk for a week on mailing lists, but they probably have developers and engineers in their teams doing just that every day who already have some decent ideas about potential open source alternatives.

Of course you don't want developers downloading anything and everything and wasting company time and resources, but with some simple policies in place open source adoption is an opportunity to empower the IT department to engage more in the software selection process.

That selection process is completely different from the traditional software selection model, and tips the balance of power much more in favour of the customer in that they are able to download the software and ensure it fits their needs before engaging in a commercial conversation with the vendor.

CIOs need to retain the processes they have in place for the adoption of traditionally-licensed software, but they should also create processes that enable them to identify and compare potential open source products, as well as identify existing use of open source software within the company.

In a recent report (sorry for the plug, but it is relevant) we wrote that "IT organizations should... be working to address the differing attitude toward open source in the developer/administrator and executive/procurement communities." This can help them to understand the existing level of open source use within their organizations and the value it provides in order to properly weigh up the potential benefits of open source or proprietary products.

Of course, this is best accomplished via broader projects that improve communication across technical, line-of-business and executive management, and is easier said than done, but open source adoption should be considered an opportunity in this regard.

The route into an organisation will be different depending upon what the software is offering, typically open source software is infrastructure related (os, database, web and application servers etc.) and the route here is via IT departments. Very often the business is not even aware of what software is being used - they are just told if you want your IT to work, you need licences X, Y and Z. Some will be commercial, others will be open source, one thing is certain though, any good IT department will be aware of the open source possibilities.

Where the software is delivering business functionality (industry specific systems - ie insurance software) or business user experience (desktop, word processing, spreadsheets), then it is the business that will be in the driving seat, and typically they will not be aware of open source solutions, they may not even know what open source is. For open source this is a major challenge, you are competing with long established specialised software developed by commercial companies, and whilst a lot of the software may well be old and creaking at the foundations, these software companies spend large amounts of money developing and maintaining a market presence. The more specialised the market then more often than not, the smaller the open source visibility. Quite how open source visibility is raised is a problem my company is just beginning to explore, but word of mouth - business user to business user is currently looking like one of the more powerful tools available.

I'm looking forward to the "Tap Tap Tap -- Is This Thing On?" discussion later where I will definitely be raising this issue!

Matthew Tomlinson

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

Businesses are gaining key knowledge about the open source software space by employing the next generation of IT professionals who have gained insight, awareness and experience about open source because they are the Generation Y. The Generation Y young IT professionals grew up understand the future of open source software. They are used to using open source software like Linux, PHP, PostgreSQL or maybe MySQL. They probably have experience with Drupal and many other high profile open source solutions. With this type of experience under their belt while in high school and college, they end up educating and informing their inexperienced IT professionals who may have no clue about open source. As time goes on, they showcase to their directors and vps how using open source can help their company save time and money along with increased productivity with high quality and robust solutions that come from open source offerings.

Another primary way open source is promoted is thru an internal IT organizations showing proof of concepts using an open source solution. They back these POCs with case studies about other companies gaining success with open source solutions. In addition, it could be one of their very own competitors who are gaining traction thru the use of open source software. Case studies are key in providing IT organizations with education on how others are successful using open source.

Bob Zurek
EnterpriseDB

Based on quite a lot of recent research, including some conducted by CIO Magazine (http://www.cio.com/article/375916), we know that enterprises are using and evaluating open source software (for a wide variety of uses) in increasing percentages. We also know, based on this research, that their top two obstacles to adopting open source are product support concerns and awareness/knowledge of available solutions. So, to answer Esther's question, an enterprise should use 3 simple, evaluative steps to finding the best software for its purposes:

1. Consider all sources for the software, proprietary and open source products
The key criteria for choosing software should be based on both the needed capability and functionality as well as the costs to acquire, learn, use, and implement the software. Well-known proprietary products are easy to research (mostly through reputation), but so are well-established open source alternatives. Forgetting to do some basic research (i.e., Google) to evaluate the open source products is probably a costly mistake in many cases.
2. If an open source product possesses the needed capability and functionality, then evaluate it based on some additional criteria:
a. Ensure it is available from a commercial open source company that has the resources and licensing mechanism to ensure your success (including customer
support).
b. Check the size and vibrancy of its community (which, even better than annual revenue, helps to determine the likely success possible with its products).
c. Try to learn how many production deployments are in use (by other commercial enterprises), which is a strong indicator of the product's (and the
vendor's) ability to really deliver.
d. Then, use all the standard evaluation techniques used with proprietary vendors (quality of the product roadmap, strength of the company's personnel,
availability of training and professional consulting services, etc.).
3. Build and use a comparative Total Cost of Ownership schedule for the leading vendors (both proprietary and open source). There are many TCO tools available from leading industry analyst firms and even vendors themselves. These TCO tools can shed real light on the complete costs to acquire, learn, use, and implement. Again, if the enterprise has a leading open source vendor on its short list (at this point), I'd be very surprised if it didn't deliver the leading TCO (perhaps by a wide margin).

Three simple steps - starting with the right basic research to ensure the landscape of possibilities is clear . . . could provide a great windfall of functionality and lower costs for the well-run enterprise.