Snowdrift? Toboggan hill!

Paul Chiusano, in the course of reinventing the world, writes:

One of my personal pet causes is developing a better alternative to HTML/CSS. This is a case where the metaphorical snowdrift is R&D on new platforms (which could at least initially compile to HTML/CSS).

The problem with the ‘snowdrift’ here, to abuse the metaphor, has nothing to do with IP law, and nothing to do with lack of innovation. It has everything to do with the size of the drift. You don’t have any choice but to wait for someone else to come along to help shovel. But the author is trying to say, If everyone doesn’t shovel, nobody gets out. And that’s not always true.

A quick reminder: When HTML first came out, the very first thing virtually every proprietary software vendor of note did was create their own, better alternative. Web design tools were so common, it became difficult to market oneself as someone who actually knew how to create HTML by hand. And each of those tools used proprietary extensions and/or unique behaviour in an attempt to provide a ‘better alternative’ to consumers – and of course to corner the market on web development, and therefore on the web itself.

But the ‘snowdrift’ in this case was all the other companies. Because no single one of them was capable of establishing and holding overwhelming dominance, the ‘drift’ was doomed to remain more manageable by groups than by any single entity. (Microsoft came closest to achieving dominance, but ultimately their failure was such that they have in fact been weakened by the effort.)

Say what you like about the W3C, and draw what conclusions you will from the recent schism-and-reunification with WHATWG. The plain fact is that stodgy, not-too-volatile standards actually work in everybody’s favour. To be clear: they provide the greatest benefit to the group, not to the enfant terrible programmer who thinks he knows better than multiple generations of his predecessors.

Past a certain point, the ‘snowdrift’ becomes a geographical feature relative to the individual developer. And at that point, I personally prefer a toboggan to a shovel.

Yes, FOSS projects face institutional weaknesses, including a lack of funding. Especially on funding for R&D. But funded projects face significant weaknesses as well. Just look at the recent Node.JS / io.js fork, all because Joyent went overboard in its egalitarian zeal. Consider also that recent widely publicised bugs such as Shellshock and Heartbleed, despite the alarm they’ve caused, haven’t really done much to materially affect the relative level of quality in funded vs proprietary vs unfunded code bases. They all have gaping holes, alas, but the extent of their suckage seems to be dependent on factors other than funding. If not, Microsoft would be the ne plus ultra of software.

Weighed in the balance, therefore, FOSS’s existential problems are real, and significant, but they’re not as significant as those faced by all the other methods we’ve tried. So to those who have a better idea about how to balance community benefits and obligations, I can only reply as the Empress famously did when revolutionaries arrived to remove her from the palace: ‘I wish them well.’