The Cathedral and the Bizarre

Not all open source software is produced by a "herd"; many are written by one person.

My own projects I write by myself; often there are no other contributors at all (although I do accept bug reports and sometimes accept contributed code too, I am the only maintainer).

SQLite is a good open source software project (there are some proprietary extensions, but the core system is open source, and there are also open source extensions which are as good as the proprietary ones if you do not need the warranties and professional support they provide), and is written by only three people. Still, the commit history is public and I often look to see what changes they will have in the next version (and in one case, even found a bug and reported it, and they quickly corrected it).

I have heard Bourbaki before but didn't know much about that, but now I look it up and I can see what it is. I did not know that Bourbaki is actually a group of mathematicians, but I looked and now I know. I also did not know that the "dangerous bend" sign used by Knuth was invented by Bourbaki.

I’m going to play devil’s advocate and suggest this essay is worth an open-minded read to anyone working in the software industry. The vast majority of comments that take issue with it in this thread thus far are nitpicks about minor points, and almost none address the essential thrusts of Tarver’s argument, all of which are actually quite cogent.

As he notes, it’s still the case today that the vast majority of successful open source projects are only those coming out of mega corporations that actually pay tons of smart engineers to spend time on them (fb, google, uber, et al). It happens every now and then, but it’s quite rare that some solitary programmer or duo whip up an os library or product that snags as much of the market as an os project managed by one of the big dogs.

Burnout on the part of solitary maintainers of non-corporate backed os projects is also quite a real and problematic issue.

The adoption of the MIT license, I’d wager, borders on a cultic practice these days and is rarely the outcome of long deliberation on the appropriate license selection on the part of a project maintainer (excluding of course the big companies, whom are incredibly savy and smart about this because they have lawyers).

Os projects also have, generally speaking, horrible support. If an os library isn’t small enough or written in such a way that I can read the source and understand it in about a day and a half, maximum, I won’t use it. The adoption of certain libraries also trends toward tribal practice and ritualistic behavior. People select librires based on their popularity or a personal incentive (these two motivations merge, since a thing’s being popular stirs a personal incentive to learn it in order to be more valuable on the market, see react et al.) more oft than they do based on a thorough technical assessment.

All in all, os has benefited massive corporations much more than it has benefited solo programmers or users. Tbh, I would not be surprised if a world w/o open source actually would have given us more diversity in the tech market—spawning several boutiques of software houses churning out small-scale bespoke, but closed source, tech instead of massive corps who not only use os as a “good grace” but also as a tool to create yet another relation of dependency between themselves and users or other companies—i.e. gain more power.

OS’s one invoiable benefit is that it has significantly liberated the auto-didact—its a huge boon for those that can’t learn through other channels...but even this benefit comes with wrinkles. One can’t know which of the practices one sees in os code are instances of good or bad technique without having external knowledge about programming techniques, which cannot come from code reading alone (unless you think a pattern’s frequency equates to it being a good practice, arguably a mistake in most cases).

His point remains reasonable, though: If all you did was dump the resulting artifacts of a learning or self-edification exercise online, you didn't make a product like a Firefox or MySQL. And to the extent that people use your code, it's most likely as part of a similar journey to yours, and studying that code is not hugely different from studying books and whitepapers, even if the code is easier to leverage. But people were doing this before "open source" became a thing, and in a manner more befitting the role of such code: as part of a text file documenting the core concepts and posted on a BBS or Usenet, so that you could program the same thing. It's the kind of thing that would be a blogpost now. The actual code? Usually only the really deep, underlying algorithms need that spelled out.

It's only when you make a full system that the end user can get value out of that you get into the scenario he outlines. Somewhere in the middle in between the simple code dump and Firefox, open source tends to sink into a quagmire where it looks like a product but it's not supported like a product. And the only good answers then seem to be "go small" (impose LOC limits and hard constraints on features you ship so that maintenance drifts towards stability) or "commoditize" (become part of someone's product in a way that gets you paid).

Except he's arguing the fact that there's a bunch of useless code on Github means open source is bad. I argue that for the purpose of comparing the results of open and closed source development it's reasonable to restrict to software with a real user base.

No personal attacks on HN, please.

https://news.ycombinator.com/newsguidelines.html