Quality Culture

Last year, upon an unintentional nerd snipe from a friend, I spent a weekend writing a pretty performant XML library in Jai. In order to make sure it handled things correctly I used the XML 1.1 test suite as conformance tests, even though realistically it consists to a very large degree of tests of weird encodings and bizarre edge cases. I got most of it done, but for the last year I’ve had this weirdly deep sense of guilt over not having finished adding support for UTF-16.

I think this guilt illustrates a mentality that I wish I had adopted a lot earlier. I was in my late teens when I was indoctrinated into the “done is better than perfect” mindset, where “perfect is the enemy of good.” I learned the “three virtues” promoted to perl programmers, of laziness, impatience and hubris - the notion being that the lazy programmer finds the simplest solution that requires the least work, the impatient programmer won’t wait for somebody else to solve it, and the programmer exhibiting hubris will want to share his creation with others, potentially saving them the same work.

These mindset elements are incredibly common in the free software/open source world, to the point where people are actively encouraged to share code that is far from complete, unfit for purpose, untested, and just plain bad.

Recently I’ve seen some programmers I highly respect taking shots at open source software on these grounds, some going so far as to argue that all open source software is junk for this reason: that it’s slow, buggy, and generally quite shit.

I disliked this take, as somebody whose entire ability to learn to write code at all was a direct result of free and open source software: peasant children from small remote islands didn’t get to play with technology in that way without open source. But, as much as I disliked it, I knew it was at least in part true.

Yet the truth of it is very thin. Reality is, we have open source projects like the Linux kernel and SQLite that both run on billions of devices. There are projects like nginx, PostgreSQL, and gcc which are, for all their faults, the go to software of their type - first in their class. There are hundreds or even thousands of open source dependencies people rely on every day which, yes, have some shortcomings, but are fundamentally good.

And of course there are absolute pieces of shit that should be thrown into the sun. (No, I will not provide examples.)

But let me posit that the problem is not open source, but rather a motivation-alignment problem, which weirdly has its roots in Eternal September.

For those who are unfamiliar, Eternal September refers to the point in time (arguably September 1994) when so many people flooded onto the internet for the first time that they collectively overwhelmed the capacity to impart certain shared ideas of etiquette - netiquette, as it was called - that were common among the earlier denizens of the net.

Three of the many rules of netiquette (in at least one codification) were to “Respect other people’s time and bandwidth”, “Make yourself look good online” and “Share expert knowledge”. In the context of software development, these could be recast as:

• Don’t release crappy software that will cause people problems
• Build your reputation as a purveyor of the highest quality code
• Release well made code with the world so that others might benefit

The free and open source software world very much emphasized the last of those, without saying anything about the former.

And that kind of makes sense. The philosophy of free software was created at a time long before Eternal September started, where the context of netiquette was implicit. The early advocates of free software weren’t focused on software quality because the notion of only making quality things was a preexisting axiom in the culture it was built on.

The introduction to The Wonderful Wizard of Oz captures this in a different context: “Modern education includes morality; therefore the modern child seeks only entertainment in its wonder tales and gladly dispenses with all disagreeable incident.” In L. Frank Baum’s view, morality tales were obsolete, because they were handled in education. But as we know, morality is at best handled piss-poorly in education today. It may have been true, or may not have, but either way it was at best true temporarily, and shouldn’t be ignored.

Similarly, in his book The Cathedral and the Bazaar, Eric S. Raymond coined Linus’s Law, the assertion that “given enough eyeballs, all bugs are shallow”. But this was coined in the context of there being a highly motivated and detail-oriented cadre maintaining the Linux kernel. At that time and with that context, it might have been true to a large enough extent that it was worth observing.

So when Robert Glass challenged Linus’s Law in Facts and Fallacies about Software Engineering, he did so from the context of it being implausible: the underlying cultural tenet was either long gone, or never existed in any meaningful way in the first place. The publication of these two books was only separated by 4 years, but while Glass was trying to discuss software engineering broadly from a software engineering standpoint, Raymond was attempting to capture an anthropological observation of a specific and quite narrow slice of reality.

Either way, when he was framing the values of the Free Software Foundation, Richard Stallman focused on the thing that he considered the important value; what later became the four freedoms (use, study, share, improve). To him there was probably no reason to provide obligations for each freedom. Never was there a directive to use inquisitively, study deeply, share carefully, and improve constantly.

If anything, the liberty to improve might have been taken too freely as license to leave things in a state where improvements were sorely needed.

Whether it be morality, or a culture of quality, to consider an important value so obvious as to not need stating is to invite that value to be disregarded or forgotten.

At any rate: I think the issue is not that open source has a quality problem. I think the issue is that our entire culture has a quality problem, and open source software just happens to be more prone to exhibit the pitfalls of such a cultural falling by sheer virtue of how open it is.

Of course, closed source things can be shitty just as much as open source things. Or more! But free and open source software is intentionally open (like, it’s in the name), inclusive, participatory, and it actively encourages learning, experimentation, and contributions from people regardless of their skill level.

This is good. But it must be balanced against quality concerns, and one way to achieve that is to promote a culture of quality, where it is considered acceptable to ask people to do better, where robustness and efficiency are not permitted to be afterthoughts, and bad practices are actively, but politely, called out.

There’s a balance that needs to be struck here. It’s very easy, when people are volunteering their time, to seem disrespectful of that effort when criticizing. Here again, netiquette has something valuable to say: Remember the human, respect other people’s time and bandwidth, and be forgiving of people’s mistakes. Set high standards, but also try to help people achieve those standards.

There are many levels to this: it isn’t just about bugginess, performance, or architecture, it’s also about documentation, clarity, usability, accessibility, and many other things. And while it’s probably not helpful to say “never release unless it’s perfect”, you should feel uncomfortable when you release something you know is sub-par. It might still be worth releasing it, but mark it clearly as such, demonstrate that you are aware of the shortcomings, limitations and quality issues, and improve when you can. The ethos isn’t just one of freedoms, but also of responsibilities.

All in all, open source does not have to be bad quality. There is no law that says it must. But it won’t become good quality without everybody putting in the effort. And until then, I should feel guilty about the lack of UTF-16 support, and all my many other failings.

(Many thanks to James Tomasino, Helgi Hrafn Gunnarsson and rysiek for reviewing drafts of this essay. Any errors or omissions are my fault of course.)