> support contracts aren't zero margin software products, and nobody buys software anymore
There have been other models for open-source software companies, such as the "sell some defaults to advertisers or sponsors".
If someone could manage to work out the details, I think the open-source ecosystem would respond favorably to a bitcoin approach to revenue share (which would make it explicitly not "open source", but I think people are willing to forgive this violation). The hard part is figuring out how to negotiate with thousands of separate tiny "open-source" components, without project leaders making demands too ridiculous.
At the same time, we don't really want a race-to-the-bottom of poorly-maintained software projects just because someone figured reimplementation could net him a bunch of revenue if he prices everything lower... presumably this cuts into long-term software maintenance, which is something that a good system would ideally incentivize both from the perspective of library authors but also from the perspective of software purchasers, who don't want to suffer from bitrot.
(Another approach could be "performance targets" where bonds are created by library authors, but funded by company purchasers, who would be buying up some amount of technical debt in exchange for rights to deploy and use the software in their production environments. These bonds would then pay out to the library author team based on milestones, like long-term maintenance, or fixing scaling bugs, or something... But similar problems remain regarding how to handle the negotiation between thousands of tiny library authors vs companies that don't have 1000s of hours to waste on software negotiation..... Also lots of questions about "rebundling"- we can't have negotiations with all 100k library authors between themselves and some company just to strike a deal for the company to use an Ubuntu-like software system. Answer is probably something like "have an array of default ready-to-go contracts that any new business can use, and then have terms for renegotiation after a certain period of time or certain amount of revenue accumulation by the downstream company"..)
we can't have negotiations with all 100k library authors between themselves
Yeah, it's the "nobody is ever going to pay for bash, vim, top, netcat, ..." problem.
Apple has found a good middle ground though. Pay developers millions of dollars internally (infinitely growing stock) then they release what they work on as open source code. It solves the (reasonable) compensation problem for individuals while letting new software spread purposefully throughout the world.
We're just missing a middle ground where you can write open source software while not being owned by the most valuable company in the world.
> Pay developers millions of dollars internally then they release what they work on as open source code.
What do they release as open source code, apart from TextEdit? I am really surprised by your comparison since it seems to me that the two (bash, vim, top, netcat… and Apple's open source code) do not compare at all.
Apple "owns" LLVM which has changed our computing landscape from the bottom up in more ways than I can count. GCC was happy being stagnant until LLVM came along and GCC could finally see how awful and behind the times they had become. Now there's at least some competition again.
(competition-free platforms are never a good thing, no matter how many times you pray to your zero-to-one god)
There have been other models for open-source software companies, such as the "sell some defaults to advertisers or sponsors".
If someone could manage to work out the details, I think the open-source ecosystem would respond favorably to a bitcoin approach to revenue share (which would make it explicitly not "open source", but I think people are willing to forgive this violation). The hard part is figuring out how to negotiate with thousands of separate tiny "open-source" components, without project leaders making demands too ridiculous.
At the same time, we don't really want a race-to-the-bottom of poorly-maintained software projects just because someone figured reimplementation could net him a bunch of revenue if he prices everything lower... presumably this cuts into long-term software maintenance, which is something that a good system would ideally incentivize both from the perspective of library authors but also from the perspective of software purchasers, who don't want to suffer from bitrot.
(Another approach could be "performance targets" where bonds are created by library authors, but funded by company purchasers, who would be buying up some amount of technical debt in exchange for rights to deploy and use the software in their production environments. These bonds would then pay out to the library author team based on milestones, like long-term maintenance, or fixing scaling bugs, or something... But similar problems remain regarding how to handle the negotiation between thousands of tiny library authors vs companies that don't have 1000s of hours to waste on software negotiation..... Also lots of questions about "rebundling"- we can't have negotiations with all 100k library authors between themselves and some company just to strike a deal for the company to use an Ubuntu-like software system. Answer is probably something like "have an array of default ready-to-go contracts that any new business can use, and then have terms for renegotiation after a certain period of time or certain amount of revenue accumulation by the downstream company"..)