Problems in FLOSS Projects #3 - The Development Bystander Problem

Welcome

Welcome to part three of my “Problems in FLOSS Projects” series. Better late than never. In this entry, we talk about a paradoxical problem that I’ve observed within Jellyfin and several other large projects. I hope you enjoy.

The Paradox

There is a seeming paradox in FLOSS projects when it comes to developer engagement versus user count. It can be summed up pretty simply:

The larger a FLOSS project gets, in terms of user base, the less likely it is that new developers come onboard, causing the project to stagnate.

I call this a paradox because this is not what most new projects think will happen.

The conventional wisdom is that more users is always a good thing, because more users will bring a larger community which will in turn bring on more developers to aid the project.

But in my experience, this does not hold, and in fact, the opposite happens. The more users the project gets, the fewer new developers the project takes on.

Why? I have some ideas.

The Bystander Effect and the Tragedy of the Commons

These are two somewhat related but distinct sociological phenomena that have been well described and documented by sociologists.

The Bystander Effect is, to quote Wikipedia:

a social psychological theory that states that individuals are less likely to offer help to a victim when there are other people present

The Bystander Effect is most commonly described in terms of victim situations, for instance, a robbery. If many people see a person being robbed, the more people there are witnessing the crime, the less likely any single one is to take action and help the victim.

In short, the more people that there are around, the less likely any single person is to render assistance. The thinking is, in its simplest form, “someone else will help”.

The Tragedy of the Commons is a similar idea, to quote Wikipedia:

a situation in which individual users, who have open access to a resource unhampered by shared social structures or formal rules that govern access and use, act independently according to their own self-interest and, contrary to the common good of all users, cause depletion of the resource through their uncoordinated action in case there are too many users related to the available resources

While the Bystander Effect is usually used for social situations, the Tragedy of the Commons is most often described in terms of environmental situations. A canonical example is that of a number of woodcutters: each woodcutter has an individual incentive to cut down as many trees as they possibly can to increase their individual wealth. However taken together, all woodcutters are likely to completely exhaust the forest. Despite this being something that negatively affects all woodcutters, because of the incentives involved, each woodcutter is incentivized to hurt everyone - including themselves - in the long-term to benefit themselves short-term, because the long-term consequences are abstracted among “the commons” of all woodcutters.

I posit that both effects are at play as FLOSS projects grow, to the detriment of the project at large and individual contributors and users over time.

A Disclaimer

I had some backlash to the last post for my generalizations, so I want to make a quick disclaimer here.

Despite anything I say below, I am not saying that projects shouldn’t grow, or that “users are bad”, or anything of that sort. I am simply describing a problem I observe that I believe project managers, contributors, and users should be aware of.

I also don’t have an easy solution. Like many sociological phenomena, these are complex, and there is no one-size-fits-all solution or magic bullet that will solve them. I simply hope that by bringing attention to this, that it can help projects understand what is happening and work to develop their own solutions that suit their project.

How the Bystander Effect affects projects

The Bystander Effect is the easier of the two to map onto FLOSS projects.

As a project grows, and more users join, there is a much higher likelihood of any individual user being a developer who is capable, and even willing, to contribute to the project. This does of course depends on the nature of the project, as projects that focus primarily on end-users are likely to have a lower “developer pool” than those that target developers (i.e. libraries and such), but there are still likely many capable developers in the userbase of every project.

The Bystander Effect comes in because of the size of the userbase. Each individual developer is more likely to see both the size of the project, the number of other developers (active or not), and the number of users, and conclude that “someone else is working on that”. In contrast, when a project is still new and small, a developer is much less likely to conclude this, and is thus more likely to make a contribution to fix a bug or implement a feature that they want.

We have seen this happen with Jellyfin in near real-time. Earlier on in the project, when issues came up, we were very likely to get a quick implementation of a fix by a new contributor; many of these contributors ended up joining the project team and helping long-term. However as time has gone on and the userbase has grown exponentially, this has become rarer and rarer. I’m certain these developers are out there, but that for some reason they are not making the jump from user to contributor, and I believe that this “FLOSS Bystander Effect” is the major reason why.

How the Tragedy of the Commons affects projects

The Tragedy of the Commons has a slightly more tenuous connection to FLOSS projects, but I think it is still relevant here, though causing a slightly different result than the Bystander Effect.

This issue is more on the side of users who are also developers. Each individual user-developer has their own ideas about what the project should do. This is especially pronounced in very large, sprawling projects with many features, like Jellyfin. For each feature the developer may want, they have an incentive to implement it. And the user-developer does move past the Bystander Effect and start working on a feature or bugfix. They might even finish it. The tragedy of the commons comes into play when said feature is shared with the project at large.

Depending on the “cost” of the feature, in many terms - developer effort, review effort, migration paths, etc. - the project as a whole might not be interested in the feature. Either in general, or in specific implementation. This results in a major discouragement to the user-developer-turned-new-contributor, as their pull request languishes in the purgatory of “waiting on review”, with no one being willing to dismiss it nor to actively accept it.

Now this may seem like a stretch, but there is one specific area where I think this particular phenomenon is decidedly at play: that of code quality.

In the Jellyfin project, we have a relatively small number of core “server” developers, the “server” being the backend API/database that the various clients (including the main “web” client) interface with. These developers have spent many years “cleaning up” the codebase, trying to bring in good development practices and clear, maintainable code.

In this situation, “the commons” is the codebase as a whole.

The tragedy comes because there is a conflicting incentive for the user-developer-turned-new-contributor. Without saying anything about their actual skill level, it is a lot of work for them to (a) get up to speed on the codebase, and (b) learn the rules and processes of the project, and (c) ensure that their code follows the often-institutionalized-and-undocumented knowledge practices that the current contributors have developed, all on top of the work of actually implementing the feature. However, there is incentive for the user-developer to implement the feature they want quickly, so they can use it, without too much concern for how it fits into the larger codebase (the “commons” of the project).

This can have two effects, both of which are alienating: first, if the project “doesn’t care” about “the commons”, you can end up with a situation where cleanup work is discarded, the codebase becomes messy as new contributions add code-paths that do not align with the structure, and this alienates those developers doing the cleanup; or, second, if the project does “care” about “the commons”, this can alienate the new user-developer, who sees the constant requests for rewrites as “nitpicking” their contributions, alienating them and making them at best less likely to see their contribution through, and at worse cause them to fork and implement things their way.

Hopefully the analogy to the original “environmental” version of the Tragedy of the Commons makes more sense with that example.

Another example is that of feature creep. Here “the commons” is the conciseness and focus of the project, the few features that the (current) core contributors see as the most important. The tragedy comes about as users request more and more features and, potentially, new user-developers attempt to implement them, resulting in either a sprawling codebase that becomes harder and harder to maintain, or further alienation vis-a-vis “this feature isn’t wanted”.

I’m sure there are plenty more as well that maintainers of large, long-lived projects can think of, but these are the two major ones that I have observed, and neither is limited to Jellyfin specifically, but to many other large FLOSS projects.

What is a project to do?

As mentioned in the disclaimer, I unfortunately do not have a good solution here. The problem of “new blood” in the project is one we’ve been struggling with in Jellyfin for over a year now. We’ve thrown around some ideas, but ultimately none have been particularly satisfactory.

Ultimately, I think the best solution to both is simply education. Knowing, from both sides, that these are potential pitfalls can go a long way to a shared understanding between users (and especially, developer-users) and core contributors/maintainers about how best to approach things like work-sharing, reviews, new features, and code quality. Once there is shared understanding, this hopefully makes finding solutions tailored to each specific project easier on everyone.