Unintended consequences and open source
Posted by Ian Holsman
Recently I have been looking back over some of the major turning points in CNET’s IT development history as I prepare for a presentation I plan on giving in May.
What struck me was some of the unintended consequences that moving to open source(ish) products has given CNET and what it did to ROI calculations later on.
The first major OSS ‘win’ in CNET was the weblogic to resin switch, where the case was made that a $500/server licence was better than $10k/CPU licence. (I think those were the numbers it was several years ago). we were all happy with that, but what we didn’t realize at the time was that by doing this we were setting ourselves up for the next OSS win. by switching to a OSS application with a much cheaper licenseing scheme we could now:
a) switch to a different operating system easier.
b) remove the need for those big-ass CPU’s, allowing us to move to slower and cheaper machines.
These two things were not taken into account when we did the cost benefit analysis, but these two things lowered the cost of getting new features/service s up and running (and in turn allowed developers to implement ‘riskier’ features)
we were changing the rules of the game without even realizing it.
It also set in motion the next change (solaris to linux), and others following it, which in turn brought unintended (positive) consequences.
I wish I could articulate better what I am seeing here.. I’m sure this sounds like rambling. but in a nutshell every time we switched to a lower cost basis, we discovered new doors opening up we never thought of, and by going through those doors more appeared.
right now we are removing the last vesitages of the large single database, and moving to multiple replicated smaller ones.. I wonder where this will lead us in times to come.
I think what you are describing is related to something I’ve observed which is that OpenSource software gives you freeer range in creating software systems because you are no longer bound by “market engineering” considerations.
Market engineering is the term I used to describe how companies limit the capabilities of their software in order to fit their business model.
Open Source software removes many of these considerations, so you no longer need to worry about partitioning your applications a certain way because database feature X doubles the per-CPU licensing.
Even better, developers no longer have to contend with the need to understand a given vendors licensing model in order to make this sort of decision. They just have to worry about whether a given feature saves them dev time and delivers an acceptable level of reliability or performance. This allows them to get on with implementing functionality, rather than dealing with the delay as someone figures out what, exactly, has already been licensed from Oracle or MS and how badly they’ll rape you if you want to add something you haven’t already negotiated.