> I want to hear maintainers of complex, actively developed, and widely used open-source projects (e.g. ffmpeg, curl, openssh, sqlite) start touting a massive uptick in positive contributions

That's obviously not going to happen, because AI tools can't solve for taste. Just because a developer can churn out working code with an LLM doesn't mean they have the skills to figure out what the right working code to contribute to a project is, and how to do so in a way that makes the maintainers lives easier and not harder.

That skill will remain rare.

(Also SQLite famously refuses to accept external contributions, but that's a different issue.)

▲ SQLite 3 hours ago | parent [-]

No, Simon, we don't "refuse". We are just very selective and there is a lot of paperwork involved to confirm the contribution is in the public domain and does not contaminate the SQLite core with licensed code. Please put the false narrative that "SQLite refuses outside contributions" to rest. The bar is high to get there, but the SQLite code base does contain contributed code.

▲ mtlynch 2 hours ago | parent | next [-]

Dr. Hipp, I love SQLite but also had simonw's misapprehension that the project did not accept contributions. The SQLite copyright page says:

> Contributed Code

> In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to suggest a change and you include a patch as a proof-of-concept, that would be great. However, please do not be offended if we rewrite your patch from scratch.

I realize that the section, "Open-Source, not Open-Contribution" says that the project accepts contributions, but I'm having trouble understanding how that section and the "Contributed Code" section can both be accurate. Is there a distinction between accepting a "patch" vs. accepting a "contribution?"

If you're planning to update this page to reduce confusion of the contribution policy, I humbly suggest a rewrite of this sentence to eliminate the single and double negatives, which make it harder to understand:

> 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.

Could be rewritten as:

> In order to keep SQLite in the public domain and prevent contamination of the code from proprietary or licensed content, the project only accepts patches from people who have submitted an affidavit dedicating their contribution into the public domain.

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

	▲	simonw 2 hours ago \| parent [-]
		Yes, that "does not accept patches" line must have been where I picked up my incorrect mental model.

▲ simonw 3 hours ago | parent | prev [-]

Thanks for the correction, and sorry for getting that wrong. I genuinely didn't know that.

Found that paperwork here: https://www.sqlite.org/copyright-release.html

I will make sure not to spread that misinformation further in the future!

Update: I had a look in fossil and counted 38 contributors:

  brew install fossil
  fossil clone https://www.sqlite.org/src sqlite.fossil
  fossil sql -R sqlite.fossil "
    SELECT user, COUNT(*) as commits
    FROM event WHERE type='ci'
    GROUP BY user ORDER BY commits DESC
  "

Blogged about this (since it feels important to help spread the correction about this): https://simonwillison.net/2025/Dec/29/copyright-release/