On Vendor Lock-in

I was listening to the latest episode of LugRadio the other day, and they had a discussion on vendor lock-in by open source distribution companies. I think they missed the point about vendor lock-in: that it locks users into a particular vendor, usually through some means that makes it hard to switch to a better solution later. So I wrote up a reply to send to them that I'm posting below, slightly edited. There is also an ongoing conversation about the topic at the LugRadio forum, and I see several posters are making the same points that I do here.

---

Open source business is the antithesis of vendor lock-in. Vendor Lock-in is when a vendor uses some sneaky, underhanded, unadvertised method to make it impossible to recover any of your original investment if you ever decide to go with a different system. Vendor lock-in is accomplished by using all the dirty tactics the proprietary software world has used for ages--closed systems that lock away your data, hidden undocumented features, patents, and sneaky licenses.

What you described on the show was not vendor lock-in. It's called healthy competition, and it's how open source software innovates. How is optimizing your client OS to work with your server OS vendor lock-in, if anybody else can see what you're doing and do the same thing? Furthermore, how is it different than competition between KDE and Gnome, or vi and emacs, or any other of the many long-term competitions in the open source world?

Any distribution that is not looking for ways to improve their users' experience is on the fast track to irrelevance. Take a look at some recent examples you should've used in your discussion:

* Xgl vs Aiglx: Novell went off and created Xgl, while Red Hat essentially recruited a bunch of other projects to do the same thing in a different way. Different distributions became real-life test beds for real innovation, and the better technology won.

* Xen. Novell and Red Hat have a great lead over Ubuntu on management tools for Xen. You could've accused either of those companies of trying to provide better experiences for their users, but that's just good business, not vendor lock-in. Ubuntu may be behind, but they're able to pick and choose their approach to managing Xen--nothing Red Hat or Novell has done is keeping their technology out of Ubuntu or any other distribution looking for enterprise customers. Neither Red Hat or Novell has achieved any kind of lock-in with enterprise customers--what they've achieved is leadership.

* Upstart. Here's an area Ubuntu pioneered, and others are adopting.

* LTSP, K12LTSP vs Edubuntu.

I could go on and on. So I will. Distributions are always trying to shine at some particular set of features. Users decide which ones are appropriate for their needs. This is a fantastic thing. If Ubuntu weren't trying to make their servers work particularly well with their desktops, they open an opportunity for another distribution who would. As long as a distribution can stay ahead of the competition technically, they deserve all the success they get--they're pioneering the way, and the whole open source community benefits.

Okay. Now here is what would be vendor lock-in. If Canonical created some tricky way of making their servers talk to their clients, and then patented it so they could sue anybody else who tried to do the same thing, THAT would be vendor lock-in. If Red Hat embedded some private key on their commercial server that unlocked some turbo-samba supercharger, and encrypted their algorithm so nobody else could see it, and then put the key to unlock that speed in their desktop, THAT would be vendor lock-in.

But any open source company that tried such a tactic would be instantly cut off from the rest of the community--and they would probably have to violate a bunch of GPLd software to do so...

The competition between distributions make all of them better. While we're all racing each other to see who can innovate faster, we still get the benefits of each other's code, and Microsoft and Apple are starting to disappear in the dust in our rear view mirrors.

One other point I'd like to make: the earlier an open source project tries some new tactic to improve computing, and commits code to a repository the whole world can see, the better. Prior art is the key to defeating all the frivolous patents companies are taking out. If somebody tries something really inventive to eke out a bit more performance, I want that in a public Subversion revision associated with a date and a free license--it's the best insurance we've got against a broken patent system.