A key nuance is that open source has largely only devalued software that any competent software engineer could write. In this sense, open source replaces software that was essentially selling labor rather than expertise. A developer always has the option to write this software themselves if they don't want to pay for it. The price of a product of undifferentiated labor will converge on the cost of that labor in a well-functioning market, which in the case of open source is effectively zero.

On the other hand, software that requires rare and difficult to acquire expertise -- software development where competence is insufficient -- faces little threat from open source in practice. This creates two-tier markets that differentiate on the replicability of capability. Products that are replicable by any software developer eventually will be in open source. But there are still large gaps in capabilities between closed and open source in some markets because the average software developer has no obvious way to replicate those capabilities on a purely technical level.

In essence, you can only make money if you are doing hardcore R&D. This strongly incentivizes the creation of new capabilities but also disincentivizes publication of CS research.

You see this in markets like databases, where open source has captured almost the entire market for undifferentiated capabilities, and there is a lucrative high-end market with unique product capabilities that don't exist in open source or CS literature. The trend toward treating CS research as trade secrets, originally started because algorithm patents were impractical to enforce, turned out to be effective at maintaining profitability in high-end software products if open source can't replicate capability.

> A key nuance is that open source has largely only devalued software that any competent software engineer could write

I don't think so. Take GCC or Clang, for example. While I have taken a lot of compiler courses at university, I couldn't build a production compiler for a real language, without dedicating a decade of my life or so to it.

What Open Source projects really bring to the table is massive manpower over decades. Those projects that become popular, at least. And then no smaller dev shop (or single developer except Fabrice Bellard and a handful others) can possibly compete.

There are legitimate exceptions (and as I was writing that LLVM was the one that popped into my mind) but they are quite rare in practice if you look at open source as a whole. And Intel's compiler is still significantly better at optimization, as of a couple years ago at least.

Open source sometimes has a manpower advantage, usually when companies are paying for the development, but manpower per se doesn't address the significant expertise advantage of closed source in many areas. Quantity is not a good substitute for quality.

> significant expertise advantage of closed source in many areas

Citation very much needed here! The average closed source product has zilch expertise advantage compared to FLOSS. And the expertise that is embedded in FLOSS is actually verifiable (as well as, crucially, being resilient over time - sometimes enduring for decades in a "load-bearing" role with no long-term maintenance issues whatsoever), in a way that closed source could never be.

Most closed source applications contain no differentiating technical expertise, this is true. By "expertise", I am referring to deep expertise in computer science domains where the state-of-the-art is rarely published. The areas where you see large gaps in capability are domains that are intrinsically computer science limited e.g. most things involving high-scale/high-performance data infrastructure, real-time sensor processing, database kernels, etc. There is a surprising amount of highly evolved algorithms and designs that are not in literature but nonetheless show up in a multiple closed source systems.

Customers pay for the capabilities and performance that expertise affords. Most of it just manifests as "speeds and feeds" i.e. orders of magnitude more throughput, scalability, etc. In much rarer cases, there are manifest capabilities that don't have an obvious solution in published computer science, never mind open source (e.g. large scale semantic models of physical reality).

This is better described as "niche" expertise than anything significantly 'deep' or 'high-end'. Basically, stuff that (1) is not truly business-critical, at least compared to the closest FLOSS equivalent, and (2) is so inherently niche that it would not derive any benefit from the typical network effects that drive people to standardize on open source solutions. ESR himself discusses this case in his book The Magic Cauldron; one example he provides of something where FLOSS is probably not called for, is software for calculating cutting patterns for sawmills. A different one, is the business-management "secret sauce" that's embedded in many ERP packages. Note that the "not truly business-critical" proviso is quite relevant; for something that is critical to your business, however "niche" it might be, not having access to the source code would be an unacceptable risk!

1. libsodium is opensource and better than any closed source replacement

2. no single expert can ever recreate linux or clang or the hotspot jvm or many other things, just because of their size.

> I do feel social systems / economies work best when there's a mutual exchange of value

That’s too broad of a claim to possibly be true. Many things are required for smoothly running economies, and sometimes a ledger is the problem and sometimes it’s the solution.

> sometimes a ledger is the problem and sometimes it’s the solution.

And sometimes it's the solution in search of a problem cough cough blockchain cough cough

If everyone you need to send money to is legally accessible through the international banking system, I’m happy for you.

But don’t throw the others under the bus. Some people have family in places you can’t easily send money to, it’s not a joke.

The value of everything approaching zero is a signal of a post-scarcity world, which seems like a good thing, even if it requires some adjustment.

I think it's more because there's a lot of software that's too cheap to charge for, but has too many edge cases for the average programmer to get right.

Logging is a perfect example, server-side logs are all handled by free frameworks (too cheap to charge for, but everyone needs it), but client-side is often handled by companies (just complex enough to make money on).

The former is often handled by LBIPs like Eric, where-as the latter is either written in house (usually badly) or you get something like Sentry.

If the useful open source software development work was not scarce these maintainers would certainly not be under immense pressure.

To boot, the entire idea of post scarcity is preposterous. Until the theorized heat death of the universe, there will always be uneven distribution of resources and some things that are better than others.