Commentary

Serdar Yegulalp
 

Choices vs. Consequences

A big buzzword with open source is that you have that many more choices available to you, and Choice, as we all know, is a Good Thing.  The problem is that too much choice is as bad as no choice at all -- especially when it's not clear what the consequences of those choices are.

A big buzzword with open source is that you have that many more choices available to you, and Choice, as we all know, is a Good Thing.  The problem is that too much choice is as bad as no choice at all -- especially when it's not clear what the consequences of those choices are.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

It's not surprising that open source vendors don't seem to do much educating of users about the consequences of adopting this or that solution.  But wait -- isn't "Consequences" one of those ugly, negative words that reeks of doom and despair?  The last thing we want to do is scare people away, right?  Well, no.  But you do want them to get an idea of what they're getting into, and where they might end up, based on what other people have been doing.  And because so much of open source is so new, it's that much harder to determine consequences.

Right now we're seeing a bit of a push toward adopting open source database solutions that has been broad, but not very deep.  In other words, these solutions aren't really being used to displace existing legacy systems (although that does happen) -- they're being used mainly for more easy work, like reporting.

Obviously this will change in time, but the folks who have an established proprietary database solution have good reason to be hesitant.  You don't scrap everything you've built up over the years -- even if it's been costing you a lot of money -- and replace it with something that you have no direct experience with, and especially something where you have no experience with the long-term consequences of its adoption.  The human factor alone is a big stickler: What kind of people will you have to hire to get it running well, to replace the legacy programming, to write new and creative applications for it?

Consequences are something that you only understand with time, and pain, so you do your best to keep the pain to a minimum.  I ran into this myself while hunting for a CMS to replace the old "edit everything by Notepad" methodology on my Web sites.  I eventually settled on Movable Type and was very happy with it, but only because a friend of mine had been running his site -- far more elaborate than mine! -- with the same software, and had been able to brief me on what to expect.  And even then there was a lot of pain, as I found that my original pages were so woefully inconsistent that there was no practical way to slurp them up into the database and use regular expressions to normalize them.  I had to punch everything back in by hand.  (On the plus side, it meant I could go back over my own work with that much more scrutiny, so I guess it's not all downside.)

Even for a product that has been around as long as, say, MySQL or PostgreSQL, the consequences of adopting it in your environment are not going to be clear unless you're actually doing it.  Small wonder the adoptions tend to be tentative at first: you want to find out not just what you're getting into but where you might end up in a couple of years.

So if open source adoption is shallower than people want it to be, that may just be a sign that, like all newly available choices, the consequences have to play themselves out.  This doesn't happen overnight, and it shouldn't.


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