Commentary

Serdar Yegulalp
 

Evidence-Based Open Source Adoption

I mentioned to a friend of mine the other day how I was replacing Word with OpenOffice in the long run. He replied that they use OO exclusively at his place of work (mostly as a security measure, as it turns out). That provoked a question from another, skeptical friend: How do you know this is really going to help?

I mentioned to a friend of mine the other day how I was replacing Word with OpenOffice in the long run. He replied that they use OO exclusively at his place of work (mostly as a security measure, as it turns out). That provoked a question from another, skeptical friend: How do you know this is really going to help?


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

By "this", he meant my own incremental adoption of OO. And questions like this deserve a good answer, because they are likely to be asked again and again by people who aren't advocates for or against anything -- just people trying to get a job done. They have good reason to be skeptical if they feel they're being asked to trade the devil they know (Microsoft) with the devil they don't know (OpenOffice / Sun / open source in general).

The argument obviously isn't limited to Microsoft/OO, but can be applied to any situation where you're trying to ditch something proprietary. I'm also trying to look at this issue outside of the question of cost: if people have money to spend, they're going to buy what works best for them. To that end, an open solution has to be better regardless of what you're paying for it.

The bad news is that right now, the only way to guarantee something like that is not through the software itself, but through its support structure. That means -- you guessed it -- a paid support contract of some kind.

There are a couple of ways, I think, to help people break up the glacier of skepticism preventing them from using open source that much more vigorously. The first is to create as many circumstances as possible where the software can be used and also abandoned without regret. No-install editions, software appliances, VMs, install-and-go-stacks, that sort of thing. A lot of this already is being done, but there always is room for more and better versions of the same, and for more automation for both the use of the product and the data it generates and manipulates.

Another way to do this is to provide people with tools that allow them to calculate costs for using specific applications -- not just licensing or support, but training, possible downtime, or lost productivity, and so on. Granted, a lot of these things are tough to pin down, but the sooner people start to do them in a systematic way the easier it will become to quantify those costs, both for them and others.

Both of these things require people to do more than simply give away copies of the software or to stump for it. They take at least as much work as developing, testing, debugging, and promoting it by itself. They are thankless and un-sexy jobs, and I imagine few people are drawn to doing them.

But they're worth doing, because they help answer the question up top there: How do you know this is going to help? Answer: I have evidence. The more ways we can help people get the evidence they need that open source will be worth it, the better.


InformationWeek Analytics has published an independent analysis of IT governance models and metrics. Download the report here (registration required).


Follow me and the rest of InformationWeek on Twitter.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links