Setting the traps of Vendor Lock-in

Posted 18 Sep 2002 at 13:43 UTC by garym Share This

Following on the theme of the Long and Short Term Techniques mantra, an oft-touted advantage of Linux is freedom from vendor lock-in. But is this really true? ...

I was reading the latest DH Brown Associates report on migrating to Linux servers, an excellent paper that deserves space in every advocate's arsenal, when I encountered this statement among the selling points of Linux:

...choice of technical support and service provider, avoiding vendor lock-in, ...

Flashback to yesterday, while doing some evals of small and portable mini-squidlike web proxies to use with my Intranet Amplification project, I was knee-deep in performance problems with otherwise promising SmartCache when I discovered their online docs were deleted save one page; no problem, I thought, the source archive includes the SGML sources!

Except for one small detail:

<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">

DebianDoc? DebianDoc?! I thought the Debian people were smarter than that! What is this other than vendor lock-in, even if it is accidental? I don't mean to blame anyone here, with free software you take what you get or do it yourself, but I just wanted to put out an alert: LSB is not the only way to ensure we retain the Freedom of Choice in what we do.

You have a funny definition of vendor lock-in, posted 18 Sep 2002 at 14:23 UTC by movement » (Master)

Given that you can download the Debian DTD regardless of what system you're using.

If you're going to choose an example, a better one would be training all your sysadmins to use the non-free YaST2 or something.

Transparent format, posted 18 Sep 2002 at 14:39 UTC by tk » (Observer)

Besides, DebianDoc is almost certainly a transparent format, which means you can force your way through and view it as a plain text file, if you so wish. So where's the problem?

It's not a problem, it's a danger, posted 18 Sep 2002 at 15:21 UTC by garym » (Master)

I probably wasn't totally clear and yes, those examples were just what prompted my posting, not held out as paragons of illustration. My only real point here is that, instead of developing parallel methods (like DebianDoc when LinuxDoc or even DocBook-lite are perfectly sufficient) we should make a conscious effort to work together more, to make the LSB guidelines happen. You can download the DTD, but if you run sgml2html, it fails (that util only works on the obsolete LinuxDoc) so the person is faced with a hunt, and it's needless; the problem is avoided by checking for standards first.

Sometimes it backfires: Yesterday I discovered by accident that the strange date format used by the SportsNetwork newswire is in fact RFC822's date format, whereas Java is not prepared (by default) for this format. You not only should pick a standard, but pick a winning standard ;)

DebianDoc is ancient and doesn't lock, posted 18 Sep 2002 at 19:40 UTC by liw » (Observer)

DebianDoc is pretty old, actually.

If I remember correctly, DebianDoc was created by Ian Jackson at a time when Debian needed a reasonably good markup language, with working tools to convert it to on-line and hardcopy formats. The need was pressing, there was not time to wait for others to develop formats and tools. It was much quicker to do it yourself.

Of the available options you mentioned, LinuxDoc was pretty messy (might have improved since) and DocBook was unknown and badly supported by tools (still is, alas). Texinfo didn't have a reasonable converter for HTML, I think.

(I've been part of both LDP, who developed LinuxDoc, and Debian, and now use DocBook much of my markup, having converted my book to use it. I'd guess I'm pretty impartial on the issue.)

That, however, only challenges your example. I'm not particularly happy with your point, either. I don't think writing your own tools to do things is vendor lock-in, as long as your tools are freely available. (Nor do I think it is bad to do things yourself, even if there are existing options, assuming you can do a better job.)

I freely admit that sticking to standard tools often makes things simpler. Using some non-standard tools doesn't raise the barrier for switching to something else high enough, I claim, that it warrants being called lock-in.

lock-in for non-techies, posted 18 Sep 2002 at 23:29 UTC by gregorrothfuss » (Journeyer)

there is indeed some lock-in in open source, namely when it takes a non- trivial effort to get data out of one system and import it into another. for all practical purposes this is a form of lock-in, whether intended or not. witness the paucity of interop between open source projects due to "choice" for the end user. "everything MUST be configurable". yeah right.

i would love to see more standardized configuration formats and more interop in open source land.

It's not vendor lock-in., posted 30 Sep 2002 at 06:49 UTC by Mysidia » (Journeyer)

DebianDoc? DebianDoc?! I thought the Debian people were smarter than that! What is this other than vendor lock-in, even if it is accidental?

Linux can have custom file formats without creating vendor-lock in.

Vendor lock-in means by using the system your data is stored or dependant upon a proprietary format, preventing you from getting it out.

In the case of the SGML source file, well, you didn't write that, so it isn't your data (just like it wouldn't be vendor lock-in if they chose to write their man pages using pure nroff or postscript instead of using SGML) -- they conciously chose to put it in that format, there are publicly available tools you can use to get their data out of that format (though that isn't important).

Vendor lockin isn't when the documentation to software is in a format that's coupled with it's distribution, it's when a vendor erects a strong barrier against you switching to a competing product without starting all over.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page