As far as I can tell, he makes a weak argument by analogy

> This lesser-known fact is masked by the isolated points fallacy. The isolated points fallacy consists in taking the high scoring points on a graph and plotting your line on the basis of them. Hence open source champions wheel out the standard examples of success - Open Office, Wordpress and Red Hat Linux (we'll look at why some of these have succeeded later) - ignoring the vast sea of floating half submerged buggy and abandoned projects (over 120,000) that litter Github. It is the sort of technique Mugabe would have used for TV. If you're accused of starving the country, wheel out a handful of well nourished kids for people to see. 'Look, our country is fine; see how healthy these kids are'. Out in the slums the less fortunate die of cholera.

I don't buy his argument and I think he's confused. Lots of people have released code on github (as have I) so that other people can use it. Lots of it isn't used, so it looks abandoned. Maybe it is. So what? Why is that considered a failure of Open Source?

I think he's applying closed source's rules. A closed source project is a failure if no one uses (ie, buys) it, since it represents a development cost that wasn't compensated. Not so with open source. I don't suffer if no one uses my project, and the existence of my repositories doesn't detract from anyone else's work.

> A closed source project is a failure if no one uses (ie, buys) it,

I don't think this is true. The vast majority of closed source programs are created in house for in house use. No one is ever offered it publicly so no one buys it either.

It's hard for people to see the scale though because there is usually no central repository.

I agree. When I first started programming I put a program close to hello world on Github. I suppose that's counted as abandoned?

Also, I'm sure everyone's seen a closed source project that went nowhere?

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.

A closed source project that went nowhere is less likely to be seen, as it often isn't released somewhere, I think.

I agree completely. I meant I expect many people have watched closed source projects die before they're released or be abandoned after release, but that is harder to measure in aggregate because it's much less likely to be seen.

So the author is wrong to compare all software on Github to closed source software he's heard about. Those "measurements" are completely different.