When Mischa Spiegelmock takes interest in something about the history of software, it’s best to just get out of his way. This was the case, yesterday, when he published a little blog he’d written about POSIX. The results of his experiment basically proves that the old ways of building democratized, community-driven software are completely ridiculous when compared to modern workflows.

This is a tale of Spiegelmock’s attempt to make an innocuous change to POSIX, and how he ended up running into multiple technological hurdles from the 1990s. It’s also the story of how none of those hurdles have anything to do with the actual POSIX code.

This all began with Ken Thompson. The original Unix geek, Thompson was once asked if he he’d change anything about Unix if he had to do it over again. His response was that he’d spell the flag “O_CREAT” “O_CREATE”. This admission inspired Spiegelmock, and he began a lengthy journey into the heart of Unix.

POSIX is the standard Unix-y stuff that all the Unix-like operating systems include. Mac OS X, Linux, BSD and even Windows adhere to this standard. While POSIX is ratified by the IEEE, its real master as a standard is the Austin Common Standards Revision Group.

And this is where Spiegelmock encountered the silliness that is now the POSIX standards process. First, he was stymied by ridiculously invasive registration processes built with extremely old software. Then he was rebuked by the utterly fragile PHP website behind it. Finally, he washed ashore on a semi-functioning page that gave him some of the names of the folks associated with the POSIX standard and the Austin Common Standards Revision Group.

This is the point where Spiegelmock finally gets someone to talk about how to propose a patch for POSIX. Spiegelmock, mind you, is not advocating for changing O_CREAT; he simply wants to add a synonym so that typing O_CREATE also works. Thus, in theory, this would make for a fairly innocuous patch and shouldn’t break anything, right? It’s just a synonym.

Evidently, that’s not the type of thing the POSIX people are into. Spiegelmock was driven off by what he called a relatively unfriendly encounter with someone from the working group. But rather than give up there, he said, he kept pushing forward in the hopes of being able to at least submit a bug report.

That didn’t go well either, as the e-mail system for the bug reporting list appeared to be from 1996, and behaved about as reliably as a 1996 version of Sendmail.

All of this is indicative of the fact that there are a great many dusty corners in computing that need to be cleaned out a bit. We’ve seen how the world used GnuPG to encrypt its e-mails, all while the project itself was propped up by a single developer working for free. We’ve seen OpenSSL get ripped apart this past nine months, possibly because the project was not receiving much developer attention, but was also being used by millions of sites.

These standards are the lifeblood of our industry. If they sit for too long, they go sour like milk. It’s certainly a majorly big deal to change POSIX, and such a change can potentially break thousands—if not millions—of implementations.

But that’s also indicative of the fact that the POSIX standard is expected to be static, and the developers implementing it are not expecting it to change. In truth, it doesn’t need to change much. But it most certainly needs to be able to change when something goes wrong. And that’s what’s so infuriating about Spiegelmock’s experience: We’ve seen how horribly bad things can be when the whole Internet relies on one small group of underfunded, under-motivated developers.

This is no way to run a standards body—at least, not in this day and age. This might have worked fine in the 1990s, but I think we all know there are much better ways to do this in the modern era.