đź“• Node [[the bystander effect in open source]]
đź“„ The-Bystander-Effect-in-Open-Source.md by @enki

The Bystander Effect in Open Source

Big projects with thriving communities are how non-developers (and surprisingly many developers) picture open source, but it’s hard to…


The Bystander Effect in Open Source

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 knowledge that maintainer X is a jerk or caustic or that maintainer Y is generally OK but has a hangup about licenses or maintainer Z will reject any patch that has an enum in it due to early life trauma. Actually fixing the bug means learning all these things or dealing with a waste of time & effort on both sides as the results of not learning them get negotiated. So the drive-by developer submits a bug report.

But wait! It gets worse! Because some bugs are really features. One must have an even deeper understanding of the code base and the community around it in order to determine whether some apparent bug is actually an intentional behavior, or an obscure joke kept for lore reasons, or bug-for-bug compatibility with something else, or the best of several bad possibilities necessitated by structural or dependency decisions made early in the project’s development. Or, it may be a perverse manifestation of some author or maintainer’s personal philosophy. So maybe even reporting the bug is a waste of everybody’s time. Checking would involve trying to find similar reported bugs & reading the discussion around them, and the drive-by developer has better things to do than to read thirty pages of semi-related bug reports on the off chance that it’s been filed before and marked not-a-bug.

Reporting the bug might be a waste of time for other reasons as well. If I installed the application from my distribution’s package manager rather than building from source, [it might have been fixed upstream years ago](https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping- xscreensaver/), or it might have actually been introduced by a distro maintainer. Checking would require building from source, which would require getting the right versions of dev packages for all dependencies & maybe building other things from source too, and the drive-by developer would do that as part of constructing a bug fix but is not willing to do that for a bug report.

The worst case scenario here looks like an apache project — the bane of all drive-by bug-fixes. Apache projects are typically former internal corporate projects that were at some point dumped on the apache foundation. Apache projects are big and tangled and have complex interdependencies. They often have decades of mailing list & bug tracker discussion, involving the same approximately one hundred core developers whose tangled interpersonal history is preserved in bureaucratic amber. Apache projects are highly actively maintained, but not by anyone you know, and you have a hard time imagining the mind of a being who can fully understand the class hierarchy of some of these projects. The tangled weeds of apache projects are full of strange counterproductive decisions — slow code, counterintuitive behavior — protected by a dense web of complicated dependencies and tight coupling between seemingly unrelated classes. No mortal drive-by developer can contribute to an apache project and live — or at least, that’s the impression any drive-by developer gets upon investigating whether or not to fix (or even report) a bug for about ten minutes.

It’s possible to have a full-featured and complex project that is inviting to drive-by developers, though.

A project that looks unmaintained will encourage forks (which can be selectively merged — you don’t need to wait for a push request, and can simply grab good-looking diffs). Seemingly-unmaintained projects also are poison to corporate users (who are looking for somebody to do free labor & who generally won’t contribute back changes made in-house), so while your code may get fewer users in total, those users it does get are more likely to be meaningful contributors.

A project that’s highly modular, and where the modules are simple and very loosely coupled, will be inviting to drive-by developers. Not only is identifying bugs easier, but the fact that identifying bugs will be easier is obvious before one even starts. There are fewer opportunities for complications like bugs-that-are-really-features, and those cases can be more easily explained.

If maintainers must be visible, a casual structure for talking to all the maintainers helps. Formalized bug tracking mechanisms lower the labor on maintainers to deal with large numbers of bugs by putting the onus on those filing the bugs to obey complex and often opaque rules. Such systems are absolutely necessary when you have hundreds or thousands of bug reports a day, but they make it impossible to say “hey, I noticed this weird behavior — do you guys already know about it?” in a way that doesn’t look like an atomized task on somebody’s plate.

A project that handles this quite well is my favorite linux distro, Lunar. Despite being a full-featured linux distribution, Lunar is really just a handful of fairly-readable short shell scripts; the maintainers & developers number less than ten and hang out on IRC. I do not use Lunar as my primary distribution (only because it lacks multilib support, which I very occasionally need for running binaries), but the environment and the community always feels like home, in part because I know that with only a little bit of effort I could not only have a complete understanding of the entire distro’s code & its policies, but get to know everybody involved on a first name basis too. This kind of situation is only really possible because Lunar is fringe and its user base small, but I’ve seen plenty of projects with substantially smaller user bases that have substantially larger barriers to entry for casual contributors.

By John Ohno on January 10, 2020.

[Canonical link](https://medium.com/@enkiv2/the-bystander-effect-in-open- source-598430de16a7)

Exported from Medium on September 18, 2020.

Loading pushes...

Rendering context...