The selfish contributor revisited [LWN.net]

Benefits for LWN subscribers
The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Joe Brockmeier
February 6, 2025

FOSDEM

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.]

Index entries for this article
Conference	FOSDEM/2025

to post comments

Negociation/manipulation

Posted Feb 6, 2025 15:45 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

A coach put it a lot more bluntly to us, manipulation is when you want others to do something and do not care if there is something in there for them (zero-sum win/lose mentality), leadership is when you care enough to make sure everyone wins something in the end (even if others may find the solution unbalanced).

Manipulation by incentive is just manipulation if the incentive does not materialize, it only works once, engineers have better memories than pigs.

Negociation/manipulation

Posted Feb 6, 2025 17:20 UTC (Thu) by Wol (subscriber, #4433) [Link]

A leader looks for the "win win". If you can be honest about what you want, and think clearly about what the other person wants (it's far too easy to project *your* motivation on *them* and reward them with something *you* find valuable), then negotiation should be easy.

If you can't see clearly, amd offer them something they find worthless, then you're not going to get very far.

Cheers,
Wol

A single leader isn't the only way

Posted Feb 6, 2025 16:54 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> 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.

Having a single leader is definitely one way of doing it, but not the only one. It is said the best form of governance is a benevolent dictatorship, but it's also unstable because succession is an issue long term. Though this isn't really an issue for most opensource projects.

You don't need a 'leader' so much as 'leadership'.

The alternative is leadership by a group or council. Much harder to setup and get going , but more stable in the long run. It does require careful nurturing and training, because each of the members of the council needs to have all the skills to negotiate and work with others. This takes effort and will, but leads to better results in the long run.

But yeah, people like 'strong men' and its simplicity does explain why it's so popular in opensource projects (and elsewhere).

programming as theory building

Posted Feb 6, 2025 19:22 UTC (Thu) by hecanjog (subscriber, #114889) [Link]

> If asked, he said, engineers will claim that anything they're doing—including staring out the window while thinking—is productive work.

This really reads like a misunderstanding of what programming is to me -- a human process. Characterizing "productive work" this way makes sense for a large corporation I suppose. It doesn't make any sense to me unless you ignore the human component, though.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 6, 2025 20:32 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (21 responses)

> 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".

This is necessary, but not good enough. It is also important for established members of the community (who are not the victim) to explicitly call out passive aggression when they see it. I don't necessarily advocate for doing this in every case, since there will always be gray areas and the project does not benefit from bickering over them. But we must not tolerate clear instances of incivility or unkindness, no matter how many good patches the perpetrator wrote in the past.

Addressing the obvious reply: You do not have to be mean to get your point across. If you have a technical argument, you can state it dispassionately. If you cannot control your emotions, you can step away from the computer and take a walk.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 6, 2025 21:48 UTC (Thu) by jzb (editor, #7867) [Link] (20 responses)

He did suggest that people should and could intervene by deflecting the PA attempts, but I think Bottomley sees calling it out as just feeding into what the person wants in the first place.

What I've observed in other communities is that if you call out an entrenched PA'er, you give them the fight that they were itching for but didn't want to be seen obviously starting. If they are 1) ignored and/or 2) people stand up for the "victim" with support, it tends to defuse things much more handily.

Of course, no tactic is going to work in all situations. And I fully agree with your last point. I try to think about how I will feel about a reply when I calm down, or try to imagine how Fred Rogers would respond in my shoes. So far that has worked out pretty well.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 4:46 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (19 responses)

> He did suggest that people should and could intervene by deflecting the PA attempts, but I think Bottomley sees calling it out as just feeding into what the person wants in the first place.

In other words, we're talking about people who are deliberately trolling for reactions, not just having a bad day or whatever. My attitude is that you ban trolls and move on without them. But for some reason, many online communities have a hard time actually doing that when the perpetrator is an established member. The Wikipedia folks have written an essay[1] on this problem (in the context of their community), but there do not appear to be any easy answers.

"Gray rocking," the general behavior of ignoring abusive behavior, can be effective under the right circumstances, but it is not part of a healthy relationship, and most people cannot keep it up indefinitely in response to a regular or sustained pattern of abuse. We should not be asking newcomers to put up with abuse in the first place, let alone dictate the specific coping strategies they employ in response. Our ultimate goal should be the removal of problematic individuals from the community, difficult as that may be, and that starts with identifying bad behavior.

[1]: https://en.wikipedia.org/wiki/Wikipedia:Unblockables

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 5:19 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (18 responses)

People spend too much time arguing about what to do about passive aggressive behaviour because the natural response - yell and chew them out when someone is being over the top - is banned. There is no direct response, and that's the problem. CoCs created this problem when they started enforcing culture in a way that was entirely superficial.

If you want an example, we had one just the other day with Christoph trying to stop Rust work in its tracks.

The answer is to stop all the hand wringing and put some actual thought into what professionalism is.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 7:47 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

As I said, you don't have to yell and chew people out to get your point across. It is enough to credibly and sincerely tell them that their behavior is unacceptable and repeat incidents will result in removal from the community. Then follow through, if necessary.

The problem is not that people are forced to use civil language, nor that CoCs are superficial. The problem is that we do not have the practical ability to make credible threats of this nature (shouting is at best a poor substitute, because they'll just do it again in a few months). If the perpetrator has enough "social credit," then half the community will bend over backwards to excuse almost any misbehavior whatsoever, so you can't ban these people. I would cite examples, but then my replies would be filled with people arguing that so-and-so did nothing wrong, for every value of "so-and-so" that I might care to bring up. I'm sure that gives you a sense of the general category of person I'm suggesting ought to be banned.

For all the superficiality of CoCs, at least they have established the de facto ability to remove people who misbehave (in some communities, anyway). Now we just have to get them better at identifying misbehavior, and worse at starting petty squabbles over nonsense.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 7:50 UTC (Fri) by kleptog (subscriber, #1183) [Link] (14 responses)

> because the natural response - yell and chew them out when someone is being over the top

Really? I don't see how that could be a natural response, nor can I think of a situation where it would actually help. Yelling is never a productive approach.

I guess IRL where you have non-verbal cues to clarify the situation it might work, but over the internet I just don't see how it could ever work as intended.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 9:56 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> Really? I don't see how that could be a natural response, nor can I think of a situation where it would actually help. Yelling is never a productive approach.

If it's not the natural response, why do so many people do it?

As you say, it's never (or rarely) productive, but it usually gives the yeller a short term win, and we are biologically programmed to prefer immediate wins - in life-or-death situations the immediate win is all that matters! But people who can break that tend to win in the end.

The classic psychological experiment is to take a class of kids and give them all a sweet at the start of a lesson. Tell them they can eat that sweet whenever they want, but if they can show you that sweet, untouched, at the end of the lesson you'll give them another sweet. That will very rapidly identify the kids that will do well both later in school, and later in life.

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 10:17 UTC (Fri) by randomguy3 (subscriber, #71063) [Link] (1 responses)

more recent attempts to replicate the marshmallow experiment (the classic psychological experiment you are referring to) have suggested its abililty to predict success as an adult is either much less than originally thought, or even negligible

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 13:56 UTC (Fri) by fishface60 (subscriber, #88700) [Link]

I remember hearing about that. The original study showed a correlation but completely neglected the context that the kids who ate the marshmallow immediately came from disproportionately poorer households which won't have sweets as often so sweets would be more immediately alluring, and may have experienced food precarity and seen promises of food later not materialise.

Success later in life tracks much more strongly with family wealth growing up, much quicker to look at that than wasting time with an experiment with sweets and the wealth disparity suggests a remedial action that could be taken there there were political will to do so.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 13:28 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (10 responses)

> I guess IRL where you have non-verbal cues to clarify the situation it might work, but over the internet I just don't see how it could ever work as intended.

Precisely, IRL you notice when someone is getting annoyed and about to snap at you and you back off.

When it escalates into full blown yelling, no that's never ideal or productive, but generally the breakdown in communication happened well before that point [0]; and the solution to avoiding those breakdowns in communication is to be more direct, not less.

If someone's being an idiot and trying to do something dangerous, you tell them they're an idiot, simple and short, and you move on.

(If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).

Unfortunately, because CoC enforcement is heavy handed, everyone now walks around on eggshells, taking the politeness to absurd levels and avoiding _anything_ that might lead to a blowup or confrontation because if you're smart you don't want to be in the vicinity when that gun goes off. Not a healthy situation.

[0] or you have someone who's seriously stressed out and needs a break, or just an asshole, but that's a different problem.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 15:26 UTC (Fri) by pizza (subscriber, #46) [Link]

> When it escalates into full blown yelling, no that's never ideal or productive,

Unless the person doing the yelling is in charge; in which case they're rewarded for "strong leadership" and "getting results".

Our society is replete with countless examples of this sort of behavior, and how it is explicitly *rewarded*.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 16:07 UTC (Fri) by stijn (subscriber, #570) [Link] (8 responses)

> If someone's being an idiot and trying to do something dangerous, you tell them they're an idiot, simple and short, and you move on.

Why not just point out the first part (trying to do something dangerous)? What is gained by the insult? I do know what is lost - this fosters a shouty atmosphere that drives people away. This (kitchen, heat) is sometimes mistaken for a meritocracy, but the absence of a very basic level of (workplace-type) civility puzzles me. I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.

> (If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).

For me it really does not amount to the same thing. I may not be the only one.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 16:27 UTC (Fri) by marcH (subscriber, #57642) [Link]

> For me it really does not amount to the same thing. I may not be the only one.

Of course the choice of words affects perceptions, emotions and form matters.

It's as far from an "exact science" as it can be though; maybe why it's tempting to dismiss it?

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 16:42 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (6 responses)

> Why not just point out the first part (trying to do something dangerous)? What is gained by the insult? I do know what is lost - this fosters a shouty atmosphere that drives people away. This (kitchen, heat) is sometimes mistaken for a meritocracy, but the absence of a very basic level of (workplace-type) civility puzzles me.

We were talking about the situation where someone is being passive aggressive and dismissive, i.e. you've already tried the first option. In that case, making an issue out of it rather than letting it slide or simmer is absolutely the right call.

> I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.

Well, the thing you have to keep in mind is: the kernel is safety critical, high stakes code. Most of the world's infrastructure runs on Linux - the stuff that doesn't is a rounding error, and whatever additional testing and validation there might be before it's put into mission critical applications can only provide an additional safety margin, not real assurances.

We have to take responsibility for our work and own our mistakes, that has to come first.

In other safety critical environments (i.e. anything blue collar; imagine working on heavy machinery, or even installing brake lines in a shop), if you screw up in a way that's dangerous for someone else you can expect to get chewed out. That's just life. Take it on the chin, learn from your mistake, and move on; if you try to flip the script and say "CoC violation!" in that kind of environment you won't be working there long.

In my career I've had to deal with and chase down quite a few silent data corruption bugs, often introduced by other people into code I wrote who were being sloppy with process. That's always a really, really stressful event, and you have to think about what's at risk; people's entire lives are on their computers these days, think about the photo albums that might not be backed up.

If we want the kernel to be a less stressful place to work, the way to do that is:
- slow down a bit, take care with the code you write
- listen well, have empathy for the people you work with and the people who will be running and relying on your code
- own your mistakes, and make sure mistakes are addressed with a minimum of drama: seeing conflict addressed /well/ instead of being swept under the rug is a big builder of trust
- and embrace tools that make it easier to ship code we can rely on: better testing, Rust

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 17:43 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> In my career I've had to deal with and chase down quite a few silent data corruption bugs, often introduced by other people into code I wrote who were being sloppy with process. That's always a really, really stressful event, and you have to think about what's at risk; people's entire lives are on their computers these days, think about the photo albums that might not be backed up.

Been there, done that :-)

Writing a critical path analysis program.

The code said:

1) Find a segment with no predecessors and process it.
2) If the successor segment only has the current segment as a predecessor, go back to (1) and process it.
Comment : If there's any other predecessors DO NOT process the next segment because that's the way you find temporal loops.
3) Forget the next segment, search for a different segment with no predecessors and go back to (1) ...

Of course, a colleague of mine looked at the code that abandoned the next segment, said "what's that for" and deleted it (leaving the comment there, of course), and then couldn't understand why the code assumed the user had a time machine handy ... (ie would happily process temporal loops without realising there was a problem).

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 17:50 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (2 responses)

So you're processing a digraph and he hadn't learned anything past linked lists? Hah...

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 21:14 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

The killer though was he ignored the comment spelling out exactly why that code was needed! And then wondered why the predicted consequences happened!

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

Posted Feb 7, 2025 21:46 UTC (Fri) by koverstreet (subscriber, #4296) [Link]

I'll one up you.

So before I started working on the kernel, splitting bios (block layer IOs) was an unholy mess. There was no reasonable way to do it if the bio was more than a single segment, so upper layers would query lower layers "can I add another page to this bio?" as they were building it up. Oof...

This was all stuff that predated the more modern stacking block drivers (dm, bcache); it kind of worked for md where the restrictions were static, but quickly fell over if they were dynamic. And it was a whole pile of fragile, brittle slow code.

So I got rid of that and made efficient bio splitting possible by introducing a novel concept - the iterator. That made the biovec immutable, meaning it could be shared by splits. Novel stuff. It also meant that you could take a bio you were processing (in the middle of the io stack), stash a copy of the iterator somewhere, submit it, and then on completion restore the iterator to its previous state and walk precisely the same segments you saw when it was originally submitted to you (say for bouncing, decryption, what have you).

Deleted a ton of code from the block layer and device mapper, and bcache was pretty heavily reliant on all this stuff. Worked great, but..

It seems the maintainers never got the memo on things you can and cannot do with bio iterators. Saving and restoring iterators works great, because then it doesn't matter what the lower layer does with the bio (and it can advance the iterator, truncate it, or both, or neither). But an iterator was too big for them, they wanted to be able to restore the bio to its previous state by just rewinding it (by some number of bytes they pulled out of the ether).

So they merged an entire standard normal looking API to do this completely broken "bio_rewind()" thing, and then drivers started using it in predictably broken ways. And I didn't find out about it by getting CC'd on any patches - no, I found out about it through reports of bcache corrupting data; much shouting was required to get it reverted. And then they tried to merge it again...

Fighting passive aggression should not entirely fall on the victim

Posted Feb 8, 2025 6:29 UTC (Sat) by interalia (subscriber, #26615) [Link] (1 responses)

> In other safety critical environments (i.e. anything blue collar; imagine working on heavy machinery, or even installing brake lines in a shop), if you screw up in a way that's dangerous for someone else you can expect to get chewed out. That's just life. Take it on the chin, learn from your mistake, and move on; if you try to flip the script and say "CoC violation!" in that kind of environment you won't be working there long.

But are those environments really similar to OSS work though? Strangers don't turn up at the shop doing an unprompted change to your heavy machinery or to the vehicle. In the blue collar manual labour work you're talking about, the person is a team member that got explicitly hired by you. Or they're a team member and you're their more senior peer/mentor. And the justification for occasionally shouting in this context is that it can convey urgency and gravity where necessary. If they do something wrong like they're about to screw in the wrong bolt, you might have to urgently prevent or fix their action before the machine goes haywire and explodes.

This isn't the case in an OSS setting, someone just turns up and supplies a patch or an idea. The team is all ad-hoc and made up of self-selecting interested parties. But patches don't get auto-applied to the code, so often nothing bad has actually happened yet or is imminently happening. The machine doesn't have the wrong bolt applied and it isn't about to explode. There's no urgency at all. Or sometimes maybe it has been already applied, and you see a problem, but it still takes quite a while for code to work its way to production deployments. The yelling doesn't actually achieve anything now.

If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 8, 2025 7:07 UTC (Sat) by koverstreet (subscriber, #4296) [Link]

> But are those environments really similar to OSS work though? Strangers don't turn up at the shop doing an unprompted change to your heavy machinery or to the vehicle. In the blue collar manual labour work you're talking about, the person is a team member that got explicitly hired by you. Or they're a team member and you're their more senior peer/mentor. And the justification for occasionally shouting in this context is that it can convey urgency and gravity where necessary. If they do something wrong like they're about to screw in the wrong bolt, you might have to urgently prevent or fix their action before the machine goes haywire and explodes.

OSS didn't invent non professional collaboration, though. In the blue collar world, sharing your shop with a buddy or acquaintance based on trust, a demonstrated level of competence and some sort of quid pro quo is absolutely the norm.

And in the OSS world, we're not forced to take patches from random strangers; people demonstrate their competence and trustworthiness over time and we choose who we want to work with based on that.

It's different in the OSS world because there is indeed a higher _expectation_ that we'll try to collaborate and make it work, but fundamentally it's all about trust, and if you can't demonstrate that your work is trustworthy you can't expect to get it in - and the way to become competent, to develop that trust, is to work well with others; listen, learn, own your mistakes and all that. That part's the same anywhere.

> If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.

Yup, and that part works well when there's a clear line of competent authority.

Where you see the real problems and drama occurring is where there isn't a clear line of authority; either the authority figure has too much to do, or you've got a maintainer who's screwing up and unwilling to admit it (lose face) and listen or back down. And since there's never enough true experts, and everyone's human and makes mistakes, those situations happen quite a lot.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 8, 2025 6:03 UTC (Sat) by interalia (subscriber, #26615) [Link] (1 responses)

It seems obvious to me that the existence of passive aggressiveness by people in mailing lists etc. predates codes of conduct, so I can only take it that what you actually mean is that CoCs have increased the amount of it rather than causing its invention.

If someone is unable to give their critical analysis of a contribution without being either directly aggressive or passive aggressive, then they need to either learn that skill or learn to take a breath and refrain from posting when they recognise their tone would be bad.

Fighting passive aggression should not entirely fall on the victim

Posted Feb 8, 2025 8:09 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> It seems obvious to me that the existence of passive aggressiveness by people in mailing lists etc. predates codes of conduct, so I can only take it that what you actually mean is that CoCs have increased the amount of it rather than causing its invention.

I can try to probably explain what was meant.

Due to the fact that all too often, the codified conduct is superficial (tending to favor form over substance, aka "are we using nice words" over "is everyone respectfully working in furtherance of common goals") and enforcement is one-sided (tending to favor those who already were in positions of power and authority), it becomes very effective in punishing reactive abuse (when someone has enough and snaps) and very ineffective in punishing those who express hostility, sabotage and stonewall while making sure to only use nice words.

Thus, passive aggressiveness becomes the tool of choice to express unsubstantiated hostility and still "get out of jail free".

Relevance to Recent Contributions

Posted Feb 7, 2025 0:37 UTC (Fri) by robbawebba (subscriber, #134224) [Link]

I agree with many of the points made by Bottomley. Progress becomes easier when we empathize with others, understand each other's motivations, and have calm discussions in good faith. Ideally these steps make it easier to find a solution in which everyone wins.

I see examples of many of Bottomley's observations in the recent patchset and mailing list discussion about Rust abstractions for DMA allocation (Covered by LWN on Jan 30, 2025, titled "Resistance to Rust abstractions for DMA mapping"). In the ML discussion, you'll find competing motivations, attempts for negotiation, passive aggression, requests for leadership involvement, and little progress towards a compromise. Some aggression and conflict in the thread have been squashed and called out as unproductive, and I hope that the contributor and maintainers can re-ignite the discussion based on the technical merits of the patch.

Seen from the other side

Posted Feb 7, 2025 6:03 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (8 responses)

I really agree with many of James' observations and points. Sometimes you're yourself on the side of the one having to accept changes that you don't like much, and you know by being used to that, that your comments might give you a label of PA or manipulator. This often happens when you disagree with something for various reasons but try to to hurt the submitter, so you keep your dissatisfaction for you and take the patch, but the problem is that it creates a precedent, with something imperfect that serves as an example of how to properly contribute. It can be small issues like coding style etc for example, or an approach that you're not certain how it will evolve over the long term.

What I found in this case is to address yourself the small unimportant stuff (e.g. fix typos or indent), mentioning it when taking the change and presenting it as something normal, so that the person is not surprised to see their contribution modified, and if there's nothing to fix but you're not much happy with the change, but have no technical argument against it (often we're driven by feeling itself driven by experience), just openly mention it: "I sense something might go wrong by proceeding like this, but I can't tell what; since I have no technical argument, let's merge it, and if later we figure it really causes a problem, we can revert it". It generally makes the contributor more careful in the future about the goals of the project, and if the suspected problem finally happens and something needs to be changed, the person doesn't perceive it as something bad since it was already envisioned. Usually that makes that contributor feel trusted and come back with more contributions. And even the problems you envisioned are often related to a slight change of direction that was clashing with your approach, but the contributor can continue that change and finally replace an older approach with something much better in the end.

This is a good example of long-term win/win driven by trust. It's difficult though because as a project leader you're also the one responsible for the project not to steer in directions that don't match the community's expectations, but by making public statements like this, you bring the community with you, or the community will contest your decision and you can roll it back if there are good reasons.

Seen from the other side

Posted Feb 8, 2025 0:16 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (7 responses)

> What I found in this case is to address yourself the small unimportant stuff (e.g. fix typos or indent), mentioning it when taking the change and presenting it as something normal, so that the person is not surprised to see their contribution modified

Why not have this done in an automated way? It relieves the reviewer from having to consider it and the contributor can work with CI before looping a human into the loop.

Seen from the other side

Posted Feb 8, 2025 1:36 UTC (Sat) by neilbrown (subscriber, #359) [Link] (6 responses)

> Why not have this done in an automated way?

Because small-talk is important. It can help build connection and trust.
"I took your patch seriously and here are some comments" says something quite different to "nobody bothered to look at your patch because you misspelled 'colour'."

Seen from the other side

Posted Feb 8, 2025 12:03 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (5 responses)

> Because small-talk is important. It can help build connection and trust.
Exactly! It's super important IMHO to build trust with the community.

Everyone prefers being explained by a human why their work was sub-perfect and was fixed rather than having a bot reject it for obscure reasons.

Also when you see the same shocking patterns happen often in submissions, you can start to think about documenting them or even relax your coding style if that's not dramatic.

Seen from the other side

Posted Feb 9, 2025 1:37 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (4 responses)

> Everyone prefers being explained by a human why their work was sub-perfect and was fixed rather than having a bot reject it for obscure reasons.

In my case, the robot can also *do* the formatting fixes (I also don't like the "CI says formatting is wrong" that doesn't offer a fix or at least a diff I can apply), so there's no real "rejection" here nevermind for "obscure" reasons.

My experience is that it allows me more time as a reviewer to focus on the actual technical content of the patch rather than nitpicking over minutae (which is attention-consuming and a great way to make very-chatty PR threads…GitLab at least allows collapsing things usefully though; I don't know how Github-based reviews deal with its behaviors there).

Even as a contributor, I like using CI to improve my patches before roping a human into the loop.

Seen from the other side

Posted Feb 9, 2025 15:16 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

> In my case, the robot can also *do* the formatting fixes (I also don't like the "CI says formatting is wrong" that doesn't offer a fix or at least a diff I can apply), so there's no real "rejection" here nevermind for "obscure" reasons.

Those people who don't like the project's default format (and I would definitely enforce one) should simply define their own formatter to run on checkout. Then everybody wins - code in the repository is consistently formatted to the repository's rules, and contributors work with code formatted to their rules.

Cheers,
Wol

Seen from the other side

Posted Feb 9, 2025 16:15 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

I do wish that editors had a "make it look nice" view, but that requires reliable formatting tools (which don't exist for every language). It's not something I think should be project-specific.

In any case, I have kind of inured myself to many objectionable formatting quirks in projects I drive-by contribute to (e.g., GNU-style indentation or inter-line alignment in tab-based projects) and other times I'm just not familiar enough with the language to know how some idiom should be formatted (e.g., comment placement/wrapping or Ruby's closures). No, the issue is that I have better things to focus on when coding than whitespace tweezing or line wrapping rules; these are things we *can* reliably outsource to automation. I hope that reviewers do too.

Seen from the other side

Posted Feb 9, 2025 22:19 UTC (Sun) by wtarreau (subscriber, #51152) [Link] (1 responses)

The problem with automated tools is that it molests patches, and you end up with 1000 lines of changes instead of 3, which completely ruins your review, and that you definitely cannot commit without manually fixing to look like the original file. I agree that spaces/tabs are most of a semantic stuff than anything else that could theoretically be handled fine on the client, except that no two clients are equally configurable and you end up having to accept variations. That's where automatic reformatting of code produced in another editor makes things worse.

Seen from the other side

Posted Feb 10, 2025 7:38 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Yes, if you do not do a sweeping change to make the formatter happy with the entire codebase, you'll end up reformatting whole files when it gets touched the first time. We have the entire repository formatted en masse to make sure this doesn't happen. These commits are authored by our automation user and can be ignored for blaming purposes via `blame.ignoreRevsFile`[1]. We used to have the (IMO, awful) Whitesmith brace style and at some point decided to use something that editors can actually help with (Allman) to avoid having to think about it anymore.

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-blameignoreRevsFile

Gift economies

Posted Feb 10, 2025 10:12 UTC (Mon) by Phantom_Hoover (subscriber, #167627) [Link]

> 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 not what a gift economy is. A gift economy is one where property is gifted without expectation of immediate compensation, serving to maintain complex social norms around reciprocal gifting. People in gift economies are still motivated by self-interest, not altruism.

https://en.m.wikipedia.org/wiki/Gift_economy