The selfish contributor revisited

Open source is often described as a "gift economy"—an ecosystem where contributors are motivated by a desire to make the world a better place. That is, sometimes, true. However, James Bottomley used his main track slot at FOSDEM 2025, on February 1, to make the case that it is better to bank on the selfish motivations of individuals to drive community success than to rely on their altruism.

His talk was titled "The Selfish Contributor Revisited". It was something of a follow-up to "The Selfish Contributor Explained", a presentation that Bottomley gave at FOSDEM in the "Community and Ethics" devroom in 2020. That talk focused on the selfish interests of corporations that contribute to open source. This time, he came to discuss the motivations of individual contributors instead.

Bottomley began with the disclaimer that, while Microsoft is his employer, the opinions expressed in his talk were his and his only. That said, his day job of managing engineers provides a certain insight into their motivations and how to persuade them to do what the corporation considers "productive work". Productive work, in this case, being defined by what VPs and CEOs want done.

Hunting truffles and herding cats

If asked, he said, engineers will claim that anything they're doing—including staring out the window while thinking—is productive work. Engineers work best on things they like doing. Trying to make them do other things is like herding cats. Companies, of course, want those cats herded. He opined that open source manages to move more rapidly than industry because its contributors are motivated, and that industry has been "jealous of what we were doing". Every engineer has a slightly different motivation. Some engineers, he joked, "even work on Rust".

He then turned to the topic of truffles. Bottomley enjoys cooking with truffles, and when he lived in the Pacific Northwest he observed a small industry based on finding and selling truffles to farmer's markets. People would seek them out with truffle-sniffing dogs, because they are good at finding them, and then sell the truffles to the markets and such.

In Europe, though, he said that truffle hunting was done with pigs. There are arguments about which are better, pigs or dogs, but Bottomley noted that pigs were more motivated than dogs because the pigs' motives were selfish. Dogs hunt truffles, he said, because they want to please their humans. Pigs hunt truffles because they want the truffles, and if they find a patch they have to be controlled to ensure they don't grub up the ground and eat the truffles. Harnessing selfishness, he said, could lead to better yield but has to be done correctly. And the same is true for open source.

People participating in open source typically do so, as the saying goes, to scratch their own itch. They form communities of volunteers that want to see something done for their own reasons. "Open source wins because contributors self-select for their interests." If that is so, then do open-source projects still need a cat herder? "Sometimes no, but mostly yes", he said.

When Linus Torvalds sent out the email saying he was working on Linux, he did not ask for contributions. Bottomley said that Torvalds thought he was going to write all the code, but was asking for suggestions and users. Within a year, contributions were flooding in and Linux was a self-hosting operating system. Not yet a good one, but on its way, and Torvalds was now an open-source cat herder. He still tries to write patches, Bottomley said, "because they certify you as dead" if a maintainer ceases to write code—but he is now primarily an open-source cat herder (or benevolent dictator, if one prefers that term).

Common goals, competing interests

Linux shows the power of natural community formation. It is a human thing, Bottomley said, not unique to open source—but it is a great strength of open source that it harnesses this tendency. Communities are formed when common goals emerge from competing interests. The competing interests stimulate ideas, but getting things done relies on negotiation and compromise between participants. "If everybody has a fixed view and is clashing, nothing gets done." There has to be a willingness to work together.

An equitable power balance is important for the ability to work together, Bottomley said. While human societies are naturally hierarchical, successful communities don't work that way. "It's a key requirement for people to be empowered, and if everybody is empowered, nobody is at the top."

Communities also need a diversity of viewpoints. Bottomley said that there is often a strong link between having people of different backgrounds and having diversity of thought in a community. And the more diverse the inputs, the more thoroughly a problem space is explored, which can lead to the best and most durable solutions.

However, having diverse inputs is not sufficient in and of itself. "Community must also reconcile them into code". That means having to reconcile viewpoints, or "you'll just disagree and have a schism". The process of bringing those viewpoints together is assisted by some kind of leader who can help people see how to combine their inputs into the best solution.

Doing all this correctly, Bottomley said, "results in enormous synergy" and can double or triple the efficiency of proprietary industry. Things move much faster in open source than traditional programming, which is "why industry is so keen to embrace the model". The key to that is to understand the motivations of contributors, he said.

People are a problem

Bringing a community together does not ensure success. Bottomley said that there are many things that can drag down a community and make it less successful. For example, there is the problem of "fixed idea dominance" where the community leader "has a fixed idea of what you do to solve whatever you're trying to do". That shackles the community to the view of a single person. Often the participants in a project don't notice this until a project becomes big enough for it to be a problem—or it fails to attract enough contributors and dies naturally.

Another problem is the inability to reconcile inputs, he said. Negotiation between contributors doesn't produce results, it simply goes round and round without success. Bottomley said that this was often caused by ineffective leadership.

Having a diverse community with diverse views is important, but won't lead to success if those participants have entrenched views they are unwilling to budge from. Bottomley said that a community must be able to come to agreement, and that means participants need to be willing to embrace other ideas. That is difficult if participants have a win/lose mentality. Some people define problems in terms of opposites. "If my opponent wins anything, I have lost." People have to be able to make accommodations for the views of others.

The problem, really, is people. Working with others, that is to say negotiating, is a learned behavior. But many people don't learn to negotiate, they learn to manipulate. This is not all bad, he said, politics is "the art of manipulation by incentive". Community politicians see achievable compromises. A leader, Bottomley said, can see and drive compromises that others can't see. "Manipulation by incentive is a quality a leader has".

Passive aggression

But, some people try to manipulate by other means—through express or implied threats. "Look at a bad community, you'll often find passive aggression as the basis". Codes of conduct, he said, don't help much with passive aggression. They are effective against direct threats. "If you push this patch, I'll break your kneecaps", is something a code of conduct can deal with. But they don't help much with passive aggressive behavior.

He illustrated this with an example that may be familiar to many who have participated in open-source communities. A contributor says, "a number of us have reviewed this patch, and as a group urge you to withdraw it or there would be fracture and dissent" because it's not very good or some other reason. Typically the technical reasons are not well defined. This contains subtle threats and tactics to negatively manipulate another contributor.

First, Bottomley noted, it implies that there is a group behind the speaker. "[They] always imply they're on behalf of a group". Everybody is ganging up on the person trying to push the patch, or so the contributor is supposed to think. The implication that the patch does not meet the expectations of a group also is an attempt to lower the contributor's self-esteem—to make them more likely to be manipulated. Finally, if the contributor persists, there is the implied threat that "the rest of the community is going to take umbrage". It doesn't say what the community might do, but the threat is out there.

Put together, this works as a passive-aggressive tactic to try to stop a patch, and Bottomley noted "nothing that a code of conduct says will help me combat this".

Insiders versus outsiders

Another problem communities may suffer from is the divide between insiders and outsiders, which implicitly discriminates against drive-by contributors. Bottomley said that he is a "fairly prolific" drive-by contributor because he uses open source for almost everything he does, and submits patches to other projects often. The drive-by contributors are often users with "a valid point" and patches that are not that bad. And, he noted, outsiders may become insiders if contributing is easy. "Originally they only wanted to get one thing done, but it was so easy they stick around". But, even if they don't, it's not a bad thing.

He cautioned against the "origin trap"—that is, the trap of inquiring into a patch's origins as a basis for acceptance rather than the quality of the patch itself, because it is a slippery slope. Using an extreme example, he said that it might seem fine to not accept patches from people convicted of crimes. But then, what about those who are merely indicted, or just suspected? Then, he said, the community will soon be refusing patches from people "who disagree with a key goal". Or have the wrong political affiliation. Don't do this, he said, but if a community must discriminate in some way "use an objective, externally-vetted standard". Otherwise, "when you get to the bottom [of this slippery slope] you'll see your community destroyed".

Persuading the pig

It is possible to become a good leader. That is a process, Bottomley said, that involves learning to see all sides of an argument. The problem is that most people think they already can do this, but actually very few do. There are, however, exercises that he recommended to develop this skill.

One thing to do is to learn to debate the contrary position. He recommended, "in an argument with a good friend", to stop and try to argue for the other side. Reverse the viewpoints to become an advocate for the opposite position. This only works, he cautioned, with good friends, though. It is important to learn how to argue well for a cause you do not support, and develop the ability to see all angles of a problem. This is most difficult when arguing against yourself, Bottomley said. "Try to think of reasons not to accept your own patch, helping you to see other sides of the argument."

Good leaders can learn this ability to see the motivations of others, and to promote negotiation and compromise in the community. They make suggestions to give others effective negotiating positions, rather than making decisions. "A community that comes to its own conclusions is healthier". It is even, he said, possible to learn incentive-based manipulation. "It's now what I get paid for".

Leaders also have to learn to deal with passive-aggressive people in email. He reminded the audience that leaders in open-source communities have no real power, "you have to persuade the pig". Bottomley suggested that people should respond only to the technical content in that kind of email and ignore the passive aggression. People employing passive aggression seek responses to their aggression and he said the victim should "never, ever" respond to the passive-aggressive part of the message. Nothing is going to nudge them toward more effective engagement. It is, of course, easier to say that people should not respond to passive aggression than it is to avoid doing so. "There will be times when you don't achieve this advice, but that shouldn't stop you from trying the next time".

Bottomley coached the audience to pay attention to the economics of engaging with the passive-aggressive types. If the cost balance is positive, he said, "accept it". But if the cost of engaging is more than the patch is worth, think about ways to ease the person out of the community. He also suggested that leaders in a community could help to deflect passive-aggressive tactics by intervening. "I pipe up and say 'actually, I think it's pretty good'".

Finally, he said, "be willing to be wrong and admit when you are."

With the session nearly at an end, and no time for questions, he noted that he had created the slides with Impress.js, which in turn "makes me a web developer" too. The slides will eventually be published on his site, hansenpartnership.com, but he said the site was currently down due to the wildfires in Los Angeles. The video of the talk is not yet available on the FOSDEM site, but should appear within a few days or weeks.

[I was unable to attend FOSDEM in person, but watched the talk as it live-streamed on Saturday. Many thanks to the video team for their work in live-streaming all FOSDEM sessions.]