> Once the project already exists, is largely feature-completeThat may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative.
> mostly in the "fixing bugs and small annoyances" phase
I don't know of any UI framework that has had the luxury of ever reaching that phase.
> then Linus's Law [1] takes over.
If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/
This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone.
> if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done".
Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.