For the next generation of OSS, it would be wise to stand together and introduce a new licensing model: if a company builds a product using an open-source library and reaches a specific revenue threshold (e.g., $XX million), they must compensate the authors proportional to the library's footprint in their codebase and/or its execution during daily operations.
The only model I've seen work in reality is open core (aside from the very few projects that have been successful with patronage)
The MIT license and other "pushover" licenses was built in the pre-LLM era.
I don't think it is fit for purpose anymore since now maintainers are getting burnt out and most code is now being generated from OSS.
A new OSS license for the AI age must be made for newer libraries, projects and existing projects that want to change licenses.
a) volunteers
b) brief windows in which corporate decision makers are driven by ideology and good intentions, where those decisions carry momentum or license obligations (see Android, and how Google tries to claw it back)
c) corporations attempting to shape the larger landscape or commoditize their complement, see Facebook's work on React, or contributions to the Linux kernel
Of the above, only (a) or rarely and temporarily (b) are interested in collective wellbeing. Most of the labor and resources go into making moats and doing the bare minimum to keep the shared infrastructure alive.
Now companies selling LLM coding agents enter the scene, promising to eliminate their customers' dependence on the commons, and whatever minimal obligations they had to support it. Why use a standard solution when what used to be a library can now be generated on the fly and be part of your moat? Spot a security bug? Have an agent diagnose and fix it. No need to contribute to any upstream. Hell, no upstream would even accept whatever the LLM made without a bunch of cleanup and massaging to get it to conform the their style guides and standards.
Open source, free software, they're fundamentally about code. The intended audience for such code is machine and human. They're not compatible with a development cycle where craft is not a consideration and code is not meant to be read and understood. That is all to say: yes, it is unrealistic to expect companies to donate anything to the commons if they can find any other avenue. They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
This is misguided. Maintenance of LLM code has a far greater cost than generating it.
> They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
I don't think that's even a thought. The thought is that "no one can tell me no".
In corporate reality they don't care. They have their product, requirement. As it starts to rot it's easier to rebuild than to maintain.
If you can ask for an LLM with a skeleton crew team now they can do it all again in five years time with the next level of LLMs.
> 60% of maintainers are still unpaid.
That's actually not as bad as I would have guessed.
Is my best guess. The GP is perhaps referring to ghostty repo adding helper files for Llm agents to operate as a cursory look at issues to placate issue submitters.