Reading a Wired article about Ubuntu’s latest attempt to do things its own way, by developing a display server of it’s own, there’s a hilarious quote in there:
“This isn’t the first time the Ubuntu team has decided to go its own way. They’ve been catching flak ever since the company created the distribution by forking the Debian distribution. But the most significant example is Unity, a user-interface shell that runs on top of GNOME in place of the traditional GNOME shell. Unity was met with mixed reactions from users.
Unity may make more sense to users now that Ubuntu Touch has been unveiled. The trouble is Ubuntu is venturing further and further from the Linux tools used by the greater community.
What’s the problem with this? Isn’t freedom of choice a part of the spirit of open source development? Yes, but duplication of effort also flies in the face of the open source ethos. (emphasis mine) One phrase regarding the creation of Mir that came up over and over again in comment threads and discussion boards is “not invented here syndrome,” a term for “reinventing the wheel” when there is no compelling technical reason to do so. Rather than improve an existing project that does what Canonical wants, the company is investing resources in its own pet project.”
I call shenanigans on that.
It’s actually, unfortunately, a truth that petty factionalism is one of the underpinnings of the open source ethos and has been since the beginning. It’s why there’s KDE (“Experience Freedom!”) and GNOME (“Freedom for Everybody”), and why there were at some point a half dozen different audio daemons, two different audio driver architectures (OSS vs ALSA), and why there’s glibc and eglibc. It’s why a binary compiled for glibc won’t “just run” on any Linux system you throw it at. It’s why binary incompatibilities exist, even though the source code is exactly the same. It’s why I don’t, generally speaking, run Linux on a desktop anymore. Because “it just works” usually isn’t the first thing I think of when I reach for a Linux desktop anymore, I worry more about the cases where it doesn’t, and I end up blowing a weekend googling to find out why. Of course, the server stuff runs pretty well and serves its niche incredibly well, and if your favorite time is spent in emacs, or coding to a webserver, it’s fine.
But that quote is just awesome, because it’s just not true. Even in the early days, actually probably even now, Richard Stallman was always bitching and moaning (mostly, it seemed, out of jealousy) about the uptake of the Linus Torvalds’ Linux kernel versus his vaporware (but “free” as in freedom) Hurd microkernel. It’s the reason Debian switched from glibc, when the maintainer of glibc continuously and persistently refused to allow / derided superior open-source code contributions to that library or even allow people to really participate in the process. Another example is the LLVM compiler ecosystem versus the GNU Compiler Collection, showing that after years of stalling, and the fact that actually extending the GCC Objective-C compiler was made technically more difficult by GCC’s poor software architecture, Apple finally got fed up with the direction of GCC and decided to fund a clean-room implementation that now runs faster and produces more efficient compilation on common hardware.
Ultimately, the argument over freedom in open source development is misplaced, what developers (me) really want is stable, well-tested Application Programming Interfaces (APIs) and the three-clause BSD license. We don’t necessarily (nor do our employers, usually) want (L)GPL libraries or the baggage that comes with them, when that baggage doesn’t guarantee API stability, or the fact that those libraries have no support guarantees or unit tests, and could turn their users into alpha testers. We don’t want to use or write autoconf/automake scripts, or read caveats about building something for our systems.
At this point, duplication of effort is actually what I think open source is all about. It’s why there are countless web frameworks, without clear winners that actually do have batteries included (I’m looking at you, Django). It’s why there are so many libraries that only have subsets of a complete functionality that I’d actually like to have. It’s why these two guides are still so hilarious. So I’m not a true believer, but it doesn’t matter, because with all the infighting, nobody’s side is winning.
The only solution to this mess is more cooperation. If open source wants to win, the number of code libraries it produces needs to stop bifurcating, and instead shift into reverse, consolidate, and stabilize, with more effort being focused on fewer projects and clear winners. But that probably won’t ever happen (with one exception that I’m aware of), because although code is ultimately rational, egos are not.