Platform lock-in

From Baron Schwartz speaking at the O’Reilly Media MySQL Conference:

We talk about proprietary vendor lock-in, but in many cases the reality is that anyone who uses any platform, even an open source one, ends up being locked-in to some extent. Switching is something you just can’t contemplate after a while.

3 thoughts on “Platform lock-in

  1. Dirk Eddelbuettel

    I disagree. This may be true if and when you are tied to a close-to-hardware or OS optimization or lower-level work. But what concerns analysts like us is almost always higher-level. Platform independence is a free (or cheap) option: you can choose to throw it away, or you can try make use of the value (even if you have to pay a little premium for keeping your code portable).

    I for one try to stay away from ‘one-vendor-only’ languages or applications. Tools I use (e.g. R and C++ as languages, Emacs as an editor, bash as a shell) are valuable to me not only because their are as good or better as competing approaches (others may swear by Matlab or Python over R, and similarly for Java or C# over C++, but either works well for me) but also easily portable and deployable on other OSs. But as the saying goes, “your mileage may vary”.

  2. Analysts are an unusual case. They are actively involved with the software they write, not developing a system they would release into production. The software is an extension of the author. Much of the intelligence in the programmer/software system remains with the programmer.

    Contrast that with a typical business application. A handful of programmers write software for a large number complete strangers to use. Nothing can be left to the programmer’s intelligence once the software is released. This kind of software depends in detail on peculiarities of its platform.

    In context, Schwarz was talking about databases. In theory you can swap out databases because they have a quasi-standard interface. In practice, this is much harder, especially once a project is mature. I’ve seen numerous projects say “We can always change the database later if we want to” but I’ve never seen a project actually do it.

  3. Truth!

    RDBMS-wise (professionally), I’ve only lived with the proprietary DB2 (two huge shops) and Open Source MySQL (one small shop). In both cases, the shops were dead locked-in. Even suggesting an alternative would have gotten “ugly looks.” I love DB2 and tolerate MySQL (merely consider the difference in the EXPLAIN verb, when trying to tune performance, to glean the basis of my preference). The lock-in in all cases came from the OS platform choice – IBM mainframe vs. CentOS server. I can live with MySQL ‘cuz it’s free and dead-easy to configure…PostgreSQL might be a superior solution, but it ain’t the default (easy) solution for most Linux-based OSs (the acronym “LAMP” exists for a reason). Once the developers elect a platform and thereby its concomitant “preferred solutions,” the customers’ choices are reduced to approximately zero.

    The more general issue of OS choice is also pretty much outside of the users’ decision demesne. Users get locked-in with little voice.

    Once the developers (or shop) elect a platform, the “weight of code” takes control. The more specifically unique the platform, along with its subsumed particles, and the “heavier the code,” the more swiftly lock-in occurs. Not all RDBMSs or dialects of SQL are created equal.

    P.S. Geeks, in their private lives, really don’t count. I swap OSs (not so much tools) frequently.

Comments are closed.