Thoughts on Software Imprisonment
What is "vendor lock-in" anyway, and how concerned should we be of it? A few experiences recently have me thinking more deeply about this.
In discussing a web project with a prospective client recently, they were very excited to build their website using open source tools to avoid vendor lock-in. "This way, we can use anyone who knows the code to support our site," they told me. I used to nod reflexively at this comment, but instead I replied, "Well, you will have the keys, but they can be hard to use."
Under appreciated as a data analyst, philosopher Jean Jacques Rousseau wrote "Man is born free, and everywhere he is in shackles." What does it mean to be locked in to your vendor, to your software or hardware? I just replaced my dead laptop with a shiny new Macbook Pro with a full Apple warranty - I feel so much more free to toss around my laptop, while knowing that if I have anyone else try to repair it, I void my warranty. Did I just drink the Apple lock-in Kool-Aid or did I make a smart investment?
As reported by David Meyer, Microsoft has just filed a patent for "metered computing" - you get a heavily subsidized computer and pay for how much you use of it. DaaS - Desktops as a Service? Its appealing to have your hardware all taken care of - we enjoy this service with our web hosts, email providers, database service providers. Would I want to pay per hour of computer use in return for hardware and desktop software support? Will I be more upset if Microsoft tells me I can't monkey with my computer configuration, or if my system breaks down after the warrenty expires?
Each of our lock-in scenarios differ. While the open source Drupal website content management system may indeed have hundreds of thousands of users with all kinds of special Drupal administrative skills, that does not automatically mean I will be able to find one that will support my software implementation. It can and often does take work to open that lock with a new support provider. I may feel less locked into a proprietary database vendor if I have ready access to export all my data along with consistant support and predicable costs. Sure, my database vendor may simply disappear, and I need to get a new database. However, frequently we see open source consultants disappearing, and new ones declaring the system unfit to continue. In both cases, the vendor lock-in problem manifests into being locked-out.
Vendor lock-in sometimes takes an oversized role in discussions around best fit software solutions. We all want to easily use as much of our software as is useful to us, for as long as possible. Affordability, usability, access, support, licensing all play a role in determining this best fit solution.
In discussing a web project with a prospective client recently, they were very excited to build their website using open source tools to avoid vendor lock-in. "This way, we can use anyone who knows the code to support our site," they told me. I used to nod reflexively at this comment, but instead I replied, "Well, you will have the keys, but they can be hard to use."
Under appreciated as a data analyst, philosopher Jean Jacques Rousseau wrote "Man is born free, and everywhere he is in shackles." What does it mean to be locked in to your vendor, to your software or hardware? I just replaced my dead laptop with a shiny new Macbook Pro with a full Apple warranty - I feel so much more free to toss around my laptop, while knowing that if I have anyone else try to repair it, I void my warranty. Did I just drink the Apple lock-in Kool-Aid or did I make a smart investment?
As reported by David Meyer, Microsoft has just filed a patent for "metered computing" - you get a heavily subsidized computer and pay for how much you use of it. DaaS - Desktops as a Service? Its appealing to have your hardware all taken care of - we enjoy this service with our web hosts, email providers, database service providers. Would I want to pay per hour of computer use in return for hardware and desktop software support? Will I be more upset if Microsoft tells me I can't monkey with my computer configuration, or if my system breaks down after the warrenty expires?
Each of our lock-in scenarios differ. While the open source Drupal website content management system may indeed have hundreds of thousands of users with all kinds of special Drupal administrative skills, that does not automatically mean I will be able to find one that will support my software implementation. It can and often does take work to open that lock with a new support provider. I may feel less locked into a proprietary database vendor if I have ready access to export all my data along with consistant support and predicable costs. Sure, my database vendor may simply disappear, and I need to get a new database. However, frequently we see open source consultants disappearing, and new ones declaring the system unfit to continue. In both cases, the vendor lock-in problem manifests into being locked-out.
Vendor lock-in sometimes takes an oversized role in discussions around best fit software solutions. We all want to easily use as much of our software as is useful to us, for as long as possible. Affordability, usability, access, support, licensing all play a role in determining this best fit solution.
Labels: lock-in, opensource, software
Subscribe through Feedburner
4 Comments:
I've been thinking about this too. The ease of moving to a new system is an important consideration, but it isn't easily boiled down to something as cut and dry as "open source means less lock-in."
Consider content management systems, for instance (which Michelle and I have been doing at length for our upcoming Open Source Content Management Systems report!). It's a pain to move from almost any CMS to another, but there's features that can help - for instance, the ability to easily find and download your documents and images from some logical place on your server, or that ability to export the whole site into a standard format like XML.
Many open source systems don't have these features. And likely some proprietary ones do. So lock-in is certainly dependent on more than business model.
I agree that it isn't boiled down easily to "open source means less lock-in" because, as you mention, moving from almost any CMS to another is a pain, and there is no guarantee that you can find someone to do it.
However, I think you can say that "open source decreases the probability of lock-in, and decreases the likely cost of migration" given the broad user and developer bases, and reliance on open standards. But you are right, there are plenty of open source software that doesn't include features that make migration easier. Something that should be worked on, for sure.
Good points. Software lock-in as it relates to data migration is another area that tends to be oversimplified in terms of whether you can mechanically get the data out of, and into, another system. While it is true that many software packages offer dramatically different capacities for moving data, its generally the amount of data clean up and transformation that really determines the difficulty of getting out of a software.
I see lock-in to any software as constantly shifting, not static, and thus requires ongoing management. Software as an investment (rather than a product) prepares us better to look for the gains it brings us, and to mitigate increasing lock-in as both our context and that of our vendors change.
Data migration is almost always the most annoying frustration part of deploying a system, open source or proprietary, it seems to me. I don't really use proprietary systems for much, but I can't imagine that they've managed to "crack" the problem in a meaningful way.
The issue, for all systems around data migration is that "customized" data, is shaped in non-regularized ways. So if you're, say, using a lot of custom content types in Drupal, the range of software that you can export it to, is somewhat limited. In the next, ten years (and this is me just theorizing) eventually document driven databases (like CouchDB) will make this sort of thing a bit easier, but it'll be a while. Wordpress, for example, is able to provide really good imports and exports because it's data only really has one shape, and it only accepts data from sources that provide the possibility of quick one-to-one conversions. What we gain from drupal in terms of flexible content types, we loose in terms of being able to take advantage of standard tools for getting data into and out of the system. It's a tradeoff, and I think it's probably worth it, but knowing about these challenges can help lead to even smarter site design early on.
Post a Comment
<< Home