Open Standards are not enough to prevent lock in

Many people claim that open standards are the answer to lock in problems of software. Even our government can be heard to claim open standards are the answer:

There can sometimes be a danger of lock-in with some proprietary providers, and we must avoid developing an over-reliance on individual suppliers. The Government, via the Office of Government Commerce, work hard to avoid that by using open standards to ensure that different suppliers’ software can be used interchangeably. (Angela Eagle, The Exchequer Secretary to the Treasury during a parliamentary debate)

However, there is much more to the lock in problem than the format the data is stored in. We also have to consider how this data is stored and processed in any given business process.

Until recently I’ve been reading about peoples concerns over the closed nature of Microsofts Sharepoint with a pinch of salt. I have to admit I just didn’t get the problem. If the data was in an open format you could just take your data and run, right?

Well no, that is not the case. Thanks to my old boss Randy Metcalfe, I now realise the lock in comes in the form of business processes tied to the repository. Matt Asay explains in an interview with lwn.net:

Let’s assume you store data in ODF in a Sharepoint repository. It doesn’t matter that ODF is an open format. The repository holding it is proprietary, and that proprietary lock-in is doubled by the fact that the enterprise will build (proprietary, non-standard) workflows to manage that content which keeps content a prisoner to Microsoft.

This may be true, but the fact is that Sharepoint makes it possible to build these workflows. I’m aware of no other single tool, open or closed, that is as complete. Almost certainly this is why many of the people I speak to in the education sector report an interest in Sharepoint.

What worries me is not that these people are considering Sharepoint, it’s that they think that a move to Sharepoint, coupled with an adoption of open standards will prevent a lock-in to a single vendor. This does not appear to be the case.

So, if you are concerned about vendor lock-in what can you do?

Firstly, you should recognise that no software tool can be rolled out across an organisation without significant configuration and optimisation for the (often fluid) local business practices of that organisations. Buying any off the shelf product will always result in the need to also buy consultancy and/or staff training to provide ongoing support . As a representative of a major UK university recently told me “we thought we could buy the licences and pay some consultants and that would be it. Unfortunately it’s not as simple as that.”
Secondly, we must recognise that it is possible to create a software stack using mature and successful open source software that will do everything Sharepoint will do, and more. Sure, it takes effort to do this, but it can be done.

Finally, we must ensure that we evaluate any closed source solutions against any open source alternatives, taking into account all strategic, technical and resource objectives.

Why must we consider open source? There are many reasons, the most relevant to this post is that open source, coupled with open standards prevent lock-in.

4 thoughts on “Open Standards are not enough to prevent lock in

  1. Simon Wardley

    I absolutely agree with you.

    This is especially true in the XaaS (X as a Service) world where open standards are not enough to ensure portability, you also need multiple providers of the same standard. The only way to ensure this is through open source as no provider will hand over strategic control of their business to another. I covered this in my OSCON 07, Web 2.0 SF and Berlin talks.

    Anyway, open standards is not enough.

  2. Kjetil Kjernsmo

    This has been a topic of my interest for some time. Facebook and Google has been hailed for building on open standards in many of their APIs and formats, using e.g. class attributes of HTML or Atom, JavaScript, etc, but this is not enough to prevent lock-in either. One reason is that the legal conditions that these APIs are under makes it pretty clear that they are not at all open standards, even though they are built on such. That’s actually pretty easy to fix, these things are so simple, it could easily be reproduced by a community.

    More importantly, I think, is that the data is under locks, and so, any alternative use and implementation will be a second-class citizen, thus ensuring lock-in even though there are simple, open formats and APIs.

  3. Ross Gardler

    Kjetil,

    I agree and have posted on many occasions on the topic of data lock-in with web2.0 services. However, in this instance I’m concerned about a different issue. In this scenario the data is in a truly open standard and is held on servers owned and managed by the data owner, yet there is still a potential for lock-in.

  4. Pingback: Nodalities » Blog Archive » This Week’s Semantic Web

Comments are closed.