One of the advantages of having helped found the open-source movement that I cherish most is that nobody can criticize me when I criticize it. I’m a gadfly by nature, disgusted by cant even (actually, especially!) when it’s my own insights being reflected back at me as dogma. Anyone who actually does that is likely to flip me into full Discordian rascal-guru mode.
So I was actually pleased to learn of the existence of Linux-Hater’s Blog. I rather looked forward to winnowing through it for nuggets with which I could shock the more fanboyish members of my community by agreeing. Alas: when I finally went there with intent to read, I discovered that the never-actually-identified author of the blog had ended the project. I read the entire archives anway.
A lot of it is just off-target flamage. The very first substantive entry, for example, is a flame about copy-paste behavior that applies to all Unixes running X, not just Linux and not just open-source systems. Linux-Hating Blogger’s bile is further undercut when the discussion of standards he links to includes a reasoned (and, I think. correct) decision to make Linux implementations behave more like the way Macs and Windows do it.
I’m also going to just ignore entries at the lameness level of Linux won’t get you hot chicks (which is to my certain knowledge untrue) and Linux sucks.. for watching Porn. That knocks out, oh, at least 60% of the content. But then there’s this, in Use Linux to lower your customer’s expectations:
You know, cuz it’s totally acceptable to ship a busted battery meter,
or something that you have to type some crazy hexadecimal key in every
time you want to get on the interweb. It ships Linux, so we can
forgive it, right? Fuck no.
Fuck no, indeed. The point of open source is supposed to be better software quality; LHB is quite right that we ought to given vendors who ship slovenly builds a sound kicking.
And then there’s this: You don’t pay me, so I don’t care what you want. LHB is right; a lot of open source is developed by developers for developers and underweights – or completely fails to connect with – the needs of actual users. In fact, the situation is actually worse than LHB describes; his belief that “When you’re small, you’ll do a bunch of stuff to try to get more users.” is, generally, false. Small open-source projects aren’t normally focused on getting more users at all; usually, they happen because some hacker thought a particular program would be fun or useful to write, and whatever number of users show up in his in-box is fine with him.
It’s no bad thing to have LHB remind us that inattention to end-users’ needs is a serious problem; it’s a point I’ve made in public more than once myself. Nor is he wrong to point out that formal project management can’t actually solve this; the developers themselves have to care. I actually like his last line: “And besides, open source projects already have product management. It’s called a bug tracker.” Spoken in jest or snarkiness, perhaps, but they really do function that way.
So, is there a solution? Interestingly, LHB is too smart to actually commit himself to the position that monetary incentives can make developers care; one suspects he’s been a programmer at a closed-source shop, and knows exactly how often the whole self-congratulatory apparat of paid managers and marketing departments produces botches just as awful, if not worse, than development-by-geeks-for-geeks.
In Release cycles are for lusers, LHB actually manages to say something useful and constructive and even admit to good reasons for respecting Mark Shuttleworth. Zounds! You could almost think LHB were a secret Linux fan!
I got remarkably far into the archives before I found something that I disagreed with at a more fundamental level than “Dude, you’re just flaming.” It was here: Good Software isn’t really free. LHB writes:
Projects like the kernel and firefox are exceptions in a sea full of
shitty projects. They are how open source projects should be
run. They’ve figured out how to create value that people will pay
for. They have paid people working on them, producing valuable code,
solving real problems, and are usually shipped in usable, tested ways.
Rarely, and I mean rarely (i.e. hard enough to find that it’s not
worth trying out 3000 different apt-get installs for programs that do
the same thing), you find a project that has a really good developer
writing really good code, but it’s not backed by a sustainable
But LHB is wrong. Bearing in mind Sturgeon’s Law (“90% of everything is crap”) finding projects that produce quality code without what LHB thinks of as a “sustainable model” isn’t actually hard. One effective way to filter out the real crap is to ignore projects that aren’t packaged by a major distro. There are an awful lot of projects good enough for (say) Ubuntu to feel it can package and ship without jeopardizing its reputation; of these, only a vanishingly small percentage have paid developers.
Within that set, there will as usual be a power-law distribution of quality. There are ways to make sure you’re at the good end. One I find pretty reliable is to look at the number of people in the credits or authors file; more is better, and I don’t think I’ve ever encountered a real dog with more than a half-dozen names on it. What you’re doing here is evaluating a proxy for the number of people who found the code sound enough to invest time in improving it.
You can actually apply more filters than this: does it have a website that has recently been updated? Is there documentation that looks useful at first glance? The point is that however many of these you apply, however high you set the quality bar, you’re still not going to get to where any but a tiny fraction of what’s left has what LHB thinks is a “sustainable model”.
And…oops…LHB says: “The vast majority of the rest is crap. Not too unlike commercial softare you say? No shit.” That’s right; he actually knows, when he thinks about it, that “sustainable model” doesn’t really do sweet fuck-all for your error statistics, and the power-law quality distribution applies to all software, on and off Linux and whether it’s open or closed.
Beneath the profanity and the flamage, LHB actually has a clue. When he allows himself one, that is — something the blog’s stated mission often prevents.
Occasionally he’s dead on target. As in The Registry is dead…long live…the registry!? Tell it, brother! This old Unix hand thinks gconf is indeed a botch, a frightening piece of overengineering. Give me a $HOME full of old-school dotfiles any day; they’re far easier to read and modify without fearing that a change to one thing will break everyting.
How to Write a KDE Application is both funny and seems disturbingly true. To be fair, so does How to write a Gnome Application. Well, except for the cloning part; there are plenty of original apps using both toolkits. But otherwise…I laughed. I winced. Then I laughed again.
How to Create a Linux distro is not quite as good, though the last item (“Write tons of documentation on complicated procedures to make things work, instead of making things work.”) has a bit of sting in it. These three satires probably represent the high point of LHB’s oeuvre; any Linux fan who doesn’t wince and take at least one lesson from them definitely needs to get out more.
Catastraphont is kind of interesting. You have to ignore the first paragraph, which was easy for me since LHB’s pages don’t in fact render in Deja Vu Sans on my Linux box. His description of the layers of historical cruft around X fonts is pretty accurate. It’s also shared with almost every modern Unix, including the closed-source ones. (Yes, MacOS X is an exception because Apple obsesses about these things.)
Perhaps this should have been Unix-Hater’s Blog; LHB admits at one point that he’s emulating the style of the Unix-Hater’s Handbook. But then he wouldn’t get to throw around cute epithets like “freetard”. Like the Handbook, too much of LHB reads like bile looking for an excuse.
That affects LHB’s prose style, too. There is a certain entertainment value in phrasings like “more tangled than Paris Hilton’s semen-encrusted hair after her cameo in a Brazilian vomit porn tape”, but if that’s the only note you hit in your writing…you could be more effective. And LHB is in fact much more effective when he forgets to cop his attitude and writes something like this:
Y’all seem to not realize that most people don’t google for answers to computer issues in the first place. To these people, it either works or it doesn’t. If nothing happens when they plug their camera into their computer, they assume their computer just doesn’t work with their camera. Or they call up their lame-ass grandson who installed some weird thing called youbuntube on their computer. They don’t give a flying fuck if some forum user gph0t04ever on gphoto-rulez.org has a 10-step procedure that will make it work.
Besides, to actually use google effectively, you already have to 1) kinda know what you’re talking about, 2) know what keywords to use, and 3) know how to use the results to fix your problem. When’s the last time that someone typed “my screen looks big” into google, and got to your newbie-proof instructions of how to replace the “nv” in your xorg.conf with “nvidia”? Oh, that’s right. Never.
This is a worthwhile reality check. Or, as I sometimes put it, “Documentation is an admission of UI design failure.” For most users, procedures that need to be documented might as well not exist.
But he continues to be really uneven. His Stupidity Formula, for example; even if you buy the notion that stupidity increases with number of developers, agency and communication problems certainly mean it doesn’t decrease reliably with the amount of money thrown at the problem. There needs to be a multiplier proportionate to the square of the funding organization’s size in there.
Then there’s Feel the Source, where LHB, apparently seriously, proposes that upstream Linux projects should ship production binaries. That is, rather than shipping tarballs and letting packagers and distro builders make the binaries.
If I were writing in LHB’s style, I’d be sputtering scornful profanity right about now. Yeah, like every open-source project can have a build farm in its basement, with servers for every possible arcane combination of hardware, distro, and release level. The concept is just nuts. We’ve evolved a three-tier system (upstream projects to packagers to distro repositories) for excellent reasons; it’s the minimal-complexity adaptation to our deployment issues. This is probably the most foolish thing LHB wrote, if we’re leaving out the pure Beavis-and-Butthead flamage.
Sometimes LHB just seems confused. In my experience, when a Linux user or advocate says “Linux gives me choices”, it actually means “My choices aren’t dictated by a single-vendor monopoly or a locked proprietary data format.” But, in The fallacy of choice LHB argues as though Linux advocates actually relish having lots of competing choices for each applications niche as a virtue in itself.
This is an odd position that seems not to actually match observed behavior; we don’t normally see people building competitors to an established program unless there are specific reasons to do it. So, for example, nobody seems to be trying to build direct competitors to the GIMP, but we do have Scribus and Inkscape that work from different imaging models.
It’s too bad LHB goes down this garden path, because he might have had some properly trenchant things to say about (for example) the GNOME/KDE split. That had a reason, but a case could be made that it was a bogus one.
And after that post, LHB gradually runs out of momentum. There’s one last and mildly good rant at Pulse my audio; sound has never been broken for me, but the plethora of Linux sound APIs and servers is undoubtedly a mess for people with more complex requirements. Once again, though, it seems a little off to blame this on “freetard” attitudes; really, it sounds to me like the mess was more due to design problems that were intrinsically difficult to get right without a couple of (software) generations of experience.
This is how it ends:
So in true open source fashion, as the maintainer of this project, I am going to arbitrarily drop off the face off the of this earth for purely selfish reasons, and leave the entire cause in limbo. That is how open source projects truly die. But hey, all the material is out there for y’all to see (it’s “open source” in it’s own way), so maybe someone else will take up the cause. Carry on, lusers!
That kind of embodies all of LHB’s contradictions right there – trashing open source in one breath, expressing a sort of stifled backhand respect for it in the next. As though even he, the Linux hater, can’t stand aside from what Linux has taught him.