The Ties That Bind
The other day, I was reading a web page, and something strange happened. Without warning, a woman in a red uniform appeared, and started pushing things about. “This is it,” I thought, “I’ve cracked. The walls of reality are coming tumbling down.” However, it turned out that I wasn’t, in fact, going mad, but was instead experiencing something I’d been deprived of for quite a few years now; animated banner advertising.
The reason for this brief psychodrama was that I was trying out Google Chrome. My general impressions of it are almost universally positive, but I switched back to Firefox because of something I didn’t expect: lock-in, where the way a piece of software works makes it difficult or impossible to move to an alternative. Usually, lock-in is something associated with proprietary software and formats, MS Word being a typical example. Firefox and Chrome are both open source, and deal in the open standards that make up the web, so what’s going on? Firstly, being open source does not prevent lock-in. The issue at hand isn’t the program - in fact, quite the opposite. The less relevant the program is, the better. What’s important is your data, and hence the thing that makes the difference is the format in which the data is kept. In the case of a web browser, the data that it deals with day-to-day is in open, standard formats - HTML, CSS, PNG - so that shouldn’t be a problem. The lock-in comes instead from the configuration. This used to mean bookmarks, but that’s now an all-but-solved problem - pretty much every browser worth considering will happily import your bookmarks from all of the others.
The thing that eventually drove me back to Firefox, and was behind my unexpected visit from the cabin crew, was the lack of extensions. For example, I’m so used to AdBlock and NoScript that I forget that they’re there, until they suddenly aren’t. Hence, as Chrome doesn’t (yet) have either, migrating from Firefox becomes a lot less tempting, regardless of how well the young pretender does everything else (very well, for the record).
Extensions, at first sight, look like an issue of lock-in, as I can’t take the extensions I use in Firefox and run them in Chrome. However, it isn’t - it’s merely a functionality issue. For example, another extension I use a lot is Firebug, a web page development tool. As with the others, this only works in Firefox. However, in this case I don’t really care, as Chrome has pretty good development tools built in. The functionality is what I’m interested in; as long as I can migrate between tools, I can use whichever meets my needs.
So, the main thing that prevented me switching wasn’t really lock-in, but rather that Chrome doesn’t yet meet my needs. However, there is a lock-in issue lurking. GreaseMonkey allows me to write user scripts that tweak web-pages in pretty much any way I like. These scripts are subject to lock-in; however long I wait, Google aren’t going to add a switch to Chrome to shuffle around Bugzilla pages to reflect my personal whim. This sort of thing blurs the line between functionality and data, but in lock-in terms is definitely on the side of data. User scripts are essentially a data format, and in fact are not exclusive to GreaseMonkey; Opera also supports them, and Chrome is working on it. When the support is there, I’ll be giving Chrome another look.
There’s a similar situation where things don’t work out quite so neatly. There’s an application that I spend most of screen-staring time in even more than a web browser; the Emacs editor. This has the problems of extensions and user scripts writ large - I’ve not only collected a vast array of extension and customised the behaviour of the editor to behave the way I like it, but have produced reams of my own elisp (Emacs Lisp) code to add substantial chunks of functionality that is unlikely to turn up in other applications any time soon. Unlike user scripts, elisp isn’t really an independent format - it’s inextricably bound up with Emacs and the way it works, which in turn consists of more than thirty years of innovation, refinement and cruft.
In theory, you could implement an elisp interpreter in another editor, but if you did one good enough to be useful, then you wouldn’t have a distinct editor any more - you’d just have another version of Emacs. If I ever move to truly different editor, I’ll have to rewrite my custom extensions from scratch, which would be a significant amount of effort. It’s usually easier to extend Emacs to include whatever features I want from the competitor, using yet more elisp. Now that’s lock-in.