I think the SQLite model of contribution "Open-Source, not Open-Contribution" is a good middle ground to keep maintainer's sanity while having the code open [1]:

"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."

[1]: https://sqlite.org/copyright.html

▲

derdi 2 days ago | parent [-]

The text you quoted is purely about copyright/licensing, not about the maintainers' sanity.

The more relevant quote is: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches from random people on the internet. There is a process to get a patch accepted, but that process is involved and for smaller changes is not normally worth the effort." Though this is still about copyright, not about being swamped with PRs.

▲

UnlockedSecrets 2 days ago | parent [-]

The issue of the maintainers sanity is the onslaught of random people or LLM's submitting packages, So how is not both quotes equally valid for the intended outcome of describing the restrictions required as to collaborate???

	▲	derdi 2 days ago \| parent [-]
		You're right that the outcome may be similar, in that trivial contributions are discouraged. But the reasoning to getting there is completely different. Sqlite's copyright.html talks about copyright, not about maintainer overload. An otherwise overloaded maintainer of another project may probably be willing to accept individual brilliant contributions from brilliant contributors. Sqlite will not, no matter how brilliant, if the contributor doesn't sign an affidavit. Independent of Sqlite maintainer load. A known Sqlite contributor who has signed an affidavit, and has a history of good, accepted contributions, may also start spamming trivial contributions that may lead to maintainer overload, and nothing in copyright.html will prevent that.