> most open source code is poor or unusable

Is there any special reason to believe that closed source is any better? If we can count the sea of abandonware on Github, then we get to count the mountain of "interesting" code that remains internal to large companies, or worse, the stuff that actually got released on unsuspecting customers.

> Is there any special reason to believe that closed source is any better?

As many (most?) of us on HN are in some sense or another professional programmers I would think that would be an easy question to answer.

In my opinion the vast bulk of closed source code suffers from exactly the same constraints.

And most definitely there are vast quantities of quite execrable code in closed source programs. I've seen plenty and written some.

Closed-source crap is better because it's not available to the world, so millions of developers don't waste time exploring it and finding out that it's unusable.

Generally, a business pays developers to write software that it expects to be put to immediate use, which means that most of the time it functions, at least minimally. I'm sure exceptions exist, of course.

FLOSS abandonware has no such constraint.

Generally, expectations do not define reality.

I'm not just being contrary, I've worked on a project for a year or two that got scrapped, and I think it happens a lot.

Another way to look at it, is that if you have programmers that are regular employees and not temps or something, you might as well have them work on something that's not very important, or that's risky, when you don't have something better for them to do, because you're paying them anyway.

I’m convinced if they stopped paying us all to rewrite things that work the market would fall out from under us.

Every job I’ve ever been involved with has always had some code base that was in framework X and now needs to be in framework Y, or on in house hardware and needs to move to the cloud, etc etc.

And having just interviewed every place has a project like that. “We were using PHP for the mvp but are moving to RoR”, “We were using class based react but now we’re using hooks”, etc etc.

I feel half of it is valuable migrations and half of it is to always have something on our plates.

And it always has to get done yesterday. What a world.

Most software engineers I know love to build software for the sake of itself. They are not all that interested in the business. Most businesses for which software is being produced is not personally relatable or interesting to most software engineers.

To keep engineers motivated, the work has to have sufficient amount technical accomplishments and not just churning out business features.

Luckily, due to continuous growth in market and scale of users, and improvements in hardware, there is opportunity for serious amount of technical work in any project.

Also, faster time to market is of real business value. Compromises are done in ideal perfect designs to meet timelines (or resource constraints) – hence, tech debt occurs and it is real and just as useful as financial debt to help scale a business in a competing marketplace.

And speculative/iterative market feedback based development is also real. All these things add up to one thing – things that were right for yesterday isn't right for tomorrow.

So we have to rewrite or refactor software continuously. And that's perfectly normal. It is actually one of the biggest strengths of software based solutions – that we can change things live - while it is already in use - change the engines of the rocket while it is flying - so to speak. We have to embrace this and leverage it disruptively.

Those who pine for perfect software are denying realities of the larger real-world.

My first six months of employment at my current job consisted of going from one project to another that the C-levels listed as "a top priority for the company"--like, called all-hands meetings and told everyone about this great thing and how important the people working on it were--and then decided to cancel.

Two years later, that still happens from time to time.

So, from my point of view, it looks much more like businesses pay developers to write software to be thrown away. Which I guess is fine with me, as long as my paycheck keeps coming....

Honestly, isn't it bothering you that they are wasting your time ?

Yes. But they give me a regular paycheck and extremely generous vacation and sick days, and nobody else I've interviewed with or been contacted by recruiters for can match those benefits... so I stay. At least until my RSUs vest.

Sounds like you work at a startup that was very young when you first joined.

If this is the case, did any of those projects contribute to you guys still being around now, two years later?

Nope. I work for a major corporation that owns its own entire office building for headquarters and operates in over 30 states.

None of those projects contributed to still being around 2 years later, but one of them (if simulations based on prior years' data are assumed to be reasonably accurate) would've improved revenue on one of our sales channels by approximately 30% if it had actually been put into production....

The author is wrong on innovation as well usability. One of his arguments is summarized as follows:

> [Open source] did not reward innovation. The most successful products of open source are knockoffs of old ideas; Linux included.

So what about Spark? What about Python numpy, pandas, and scikit-learn? Most people don't just use them because they are open source. They are innovative solutions to difficult problems.

Ironically, he anticipated this objection, which many people beyond the parent poster are making, and answered it in the paragraph that contains:

"... Open source users will admit that a lot of open source is buggy abandonware. However they argue that this really does not matter since some small significant fraction is really quite good and that's the stuff we should use. ..."

Finding and dissecting the paragraph that contains the above sentence is left as an exercise to the reader.

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.

> The fact that I wrote a toy renderer in Rust five years ago and haven't touched it since then doesn't change this.

I ask you in good faith...if you pushed this to a public github repo that was your reasoning? If it was something I found to be of value and you'd LICENSE'd it under a promiscuous license and I took that code and made a few million dollars from your idea (and kept all the money), would you be happy with that?

Was this just a thing to show potential employers you can code and use git, how does an employer even know actually you wrote that code?

> they're referring to serious projects like the Linux kernel, Apache, PostreSQL, Firefox, etc.

I feel you're missing the point here, not all the contributors to these projects are getting paid for their efforts. See his point about Linux Torvalds comment about:

This model of using people was acknowledged right from the beginning with a sly wink to Linus Torvalds from Eric S. Raymond in The Cathedral and the Bazaar.

Eric S. Raymond: "In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: “I’m basically a very lazy person who likes to get credit for things other people actually do."

Those things I agree with it. The good open-source programs mostly are better than other programs in these ways.

Yes there will be many badly written programs (I think someone said that 90% of anything will be not very good), but there is good stuff too. I think it may be the case even with the closed sources, but in that case they are unavailable so we will not have any statistics about it.

> 90% of anything will be not very good),

Theodore Sturgeon is usually credited with it but he was a little less polite and rather more definite, see: https://en.wikipedia.org/wiki/Sturgeon%27s_law