Member-only story
Big projects with thriving communities are how non-developers (and surprisingly many developers) picture open source, but it’s hard to square these kinds of projects with ESR’s idea that source visibility & the ability to submit patches results in a substantially greater number of fixed bugs. Certainly, these kinds of projects benefit core maintainers socially, and certainly, source visibility helps with organized audits & makes it easier for individuals to fix bugs, on top of making drive-by fixes possible, but this conventionalized structure does not optimize for drive-by fixes.
When a project is large — especially when it is non-modular or when modules have complex interrelations — it takes a lot of effort just to understand things like project structure, dependency graphs, and control flow. These things need to be understood to a certain extent in order to produce a bug fix. If a project is visibly maintained — when it has a named maintainer & a high commit rate, and especially if it has a community of active developers around it — there is the sense that fixing a bug is somebody else’s job. After all, the drive-by developer doesn’t already have deep knowledge of the codebase, while all these active contributors do.
On top of that, the drive-by developer isn’t necessarily aware of or comfortable with the social structure built around especially large projects: complex norms around code style and best practices (rarely shared between unrelated projects), formal and informal social hierarchies among developers, tacit…
