I am old enough to remember what happened to GCC. It was also developed by a closed group of maintainers, because "it couldn't work" as a bazaar-style development. Then EGCS fork happened and became more successful.
I think closing contributions (due) to AI will be looked at in a similar way. Forks open to AI will appear, and take over. And people will return to the open model. I think it needs more proliferation of AI coding and reviewing tools, so that AI contributions can be automatically independently reviewed for quality.
EGCS was created because Cygnus, a company whose business was based on GCC, wasn't getting their patches to GCC, maintained by non-company FSF.
Cygnus outcompeted FSF by so much that FSF folded and made EGCS maintainers new maintainers of GCC.
I just don't see average open source project being forked and improved by so much that it eliminates the original.
This requires 3 rare things to happen:
- the project is important enough
- the project is half-dead
- someone is willing to out-compete the original project
That won't happen to e.g. Laydbird. Yes, it's important but it's making rapid progress and they also use ai, so you can't outcompete them just using ai. It's a full-time project for at least one person (Andreas Kling) so unless you manage to find a band of great, unemployed programmers I don't see how you would compete.
I’m not sure this is generally true, and you’re ignoring a lot of context around the specific situation of GCC.
Just to make a point: I could throw out SQLite as a project that bans open contributions and is wildly successful.
Also, as others pointed out, Linux is technically open contribution bazaar style by 2000s standards. But if you look at how to actually get involved, there’s way more friction compared to the average GitHub project.
I actually think GCC falls into the same category. Even though it’s technically open contribution these days, it’s not exactly a free for all where any AI agent can open a GitHub pull request and get it reviewed.
You have to mail patches to a mailing list and follow a bunch of super specific and arcane rules set by the grey beards.
The rust conversion was a byte-for-byte replica of the original's bytecode, was it not? Thereby it was easily possible to validate the quality of the AI-based work. The same would obviously not be possible for patches. I don't believe you can use the rust conversion as a valid, if implied, argument that you can take AI-patches in good faith.
My implied argument is not so much that "because llm was used, then llm must be used."
The original argument proposed by the author is essentially distilled into, "because llm could be used, we must no longer accept public contributions."
Which is, in my opinion, a disproportional and misguided overreaction. The llm was apparently good enough to do the byte for byte replica, so we know that it can be used (within the context of ladybird) in a way that's apparently acceptable to the maintainers.
To attempt to get more precise, argument is that "closing the gates" is moving in the wrong direction against progress, and a signals a potentially net negative impact to the ladybird project.
I don't have a fully formed thesis, it's a lot of vibes. It just feels wrong. I'm willing to acknowledge that, much like the overreaction that I'm calling out, I could be experiencing a similar kind of conservative gut reaction to the changing of the open source community that unsettles me.
Well see how it all shakes out. Right now the topic is so charged and we don't have a good suite of tools and heuristics for the new world, that were bound to see the gamut of reactions.
From my fairly quick reading, their premise seems to be "we can no longer trust /unknown/ developers who use AI to understand and maintain the code they submit", rather than a simple attack on those who use AI.
This seems fair to me: numerous developers would love to put "contributed to the Ladybird project" on their curriculum vitaes, and AI tools can now make this within the reach of a huge number of people.
But the Ladybird project needs more than just working-code, something that AI can easily produce: they need code that is understood and maintainable by the person who submitted it.
Not only does AI-generated code fail to guarantee this understanding and maintenance (to a greater degree than before), but the developers increasingly need to get through an avalanche of AI-generated pull requests rather than, say, code new features.
I would prefer projects to be developed in the open: but when developing in the open makes the code checking exponentially harder, and the chance of the submitters sticking around becomes significantly lower, then I can at least understand.
When the dam starts to overflow, then something needs to be done.
I see where you're coming from, but I think it's less the fact that they _can_ use an LLM to do this and more that they can't guarantee anybody else has exercised equal diligence with their code or equal experience with browser engines.
It's not unreasonable to feel conflicted about this, but at the same time, I wonder if they're starting to burn out on code review.
I think closing contributions (due) to AI will be looked at in a similar way. Forks open to AI will appear, and take over. And people will return to the open model. I think it needs more proliferation of AI coding and reviewing tools, so that AI contributions can be automatically independently reviewed for quality.