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.

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.