The Selfish Contributor Revisited
James Bottomley
jejb@kernel.org
@jejb@mastodon.online
About Me
Container evangelist
Open Source Advocate
- Converting Business to Open Source
- Lead effort to create LF TAB
Kernel Developer
- SCSI Subsystem Maintainer
- PA-RISC architecture Maintainer
Disclaimer: Talk based on Personal Opinion and Observation
May attribute to me, not to Microsoft, anything I say in this talk
Managing Engineers
Getting Engineers to do productive work is difficult
They work best on things they like doing
Usually every engineer has a slightly different motivation
Industry has been struggling with this for decades
Analogies from Truffle Hunting
Pacific Northwest has a small truffle industry
Americans prefer dogs for hunting truffles
Whereas Europeans prefer pigs
Pigs have a selfish interest
but dogs are altruistic
but dogs are altruistic
Pigs find more truffles
Dogs do less damage
Selfishness and Open Source
Scratching your own itch provides a selfish motivation
Harnessing the selfish motivations makes the cats move together.
Open Source wins because contributors self select for interest.
But does an open source project still need a cat-herder?
Lessons from Linux
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Date: 25 Aug 91 20:57:08 GMT
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
No mention of open source or request for contributions
"Any suggestions are welcome, but I won't promise I'll implement them :-)"
Linus actually thinks he's writing all the code
And all he's asking for is suggestions and users
And contributions, in the shape of patches, (eventually) came flooding in
An Open Source cat-herder is organically created
Or as we now say: Benevolent Dictator
But a key point is the community formed naturally
Even though everyone had slightly different agendas
The great power of Open Source is natural Community Formation
Although this is a Human thing not uniquely Open Source
Community Formation
Open Source participants self select for interest in project
Communities are formed when common goals emerge from competing interests
Relies on negotiation and compromise between participants
Needs willingness to work together
Equitable power balance is important for this
As is a diversity of view points
Diversity here means diversity of thought
But people who are different from you often think differently
The more diverse the inputs the
more thoroughly the problem space is explored
Similar to Computational Physics and Artificial Intelligence
Robust problem exploration leads to the best and most durable solutions
However simply obtaining diverse inputs isn't enough
Community must also reconcile them into code
Process usually assisted by some type of leader
Doing this correctly results in enormous synergy
It's why Open Source moves faster than traditional programming
And why Industry is keen to embrace the model
But ... doing this wrongly produces disfunction
Community Disfunction
Failure of Problem Exploration
- Lack of diversity in input
- Fixed idea dominance
Inability to reconcile inputs (Negotiation failure)
- Ineffective Leadership
- entrenched views
- win/lose mentality
People Problems
Working with others (negotiation) is a learned behaviour
Clever people learn to manipulate instead of negotiate
Not all bad: Politics is the art of manipulation by incentive
Community politicians see achievable compromises
and persuade others to adopt them
Manipulation by express or implied threat is corrosive
Done by passive aggressive people
Tends to fracture the community
Codes of conduct don't help much
Codes of conduct regulate behaviour
They don't give negotiating positions
don't help one person see another's viewpoint
Effective against direct threats
Often ineffective against implied threats
Insiders vs Outsiders (Drive by contributions)
Origin Trap
Inquiring into patch origins is a slippery slope
Not accepting patches from people convicted of crimes seems fine
But what about merely indicted
Or just suspected
Soon it will be people who disagree with a key goal
or have the wrong political affiliation
Best advice is don't do this
But if you have to (community insists) use an objective and externally vetted standard
Community Leadership
Often called Maintainers, cores, committers
Powerful position within project
Good leaders dissipate and distribute that power
Seek diversity by listening to all sides
Facilitate negotiation by suggesting compromises based on individual needs
(selfish motivations)
Encourage others to share the leadership burden
Easy to work with (reduce friction going from code to commit)
Good leadership reduces work and burnout
Bad leaders act to increase their power
Make themselves the bottleneck
Single point of inspection and commit
Process micromanagement
Fixed and immutable vision of where the project is going
Delay contribution because it conflicts with their unpushed work
Belittle other contributors who might become leaders
Create a passive aggressive echo chamber
Often overworked and burned out
How to Become a Good Leader
Learn to see all sides of an argument
Most people think they already can
But actually very few do (naturally)
Some exercises you can try:
Debate the contrary position (Devil's Advocate)
In an argument with a good friend stop and each try to argue for the other's side
Learn to argue well for a cause you don't necessarily support
helps develop the ability to see all sides of a problem
This is most difficult to do when arguing against yourself
Try thinking of reasons not to accept your own patch
Learn and use this ability to see the motivations of others
and promote negotiation and compromise in the community
Make suggestions that give others effective negotiating positions
Possibly even learn incentive based manipulation
Need to deal with passive aggressive people in email
No power (except code of conduct) to muzzle the pig, must persuade
In email only respond to technical content
Ignore any passive aggression towards you
Passive aggressive people seek responses to their agression
Signals their strategy is likely to be effective
Providing no signal can nudge them towards more effective engagement
Sometimes ignoring passive aggression can be really hard
Also pay attention to the economics of engaging with them
Think about deflecting aggression towards others
Always be willing to be wrong
Always admit being wrong and move on when you are
Conclusions
Harnessing Selfishnes is essential to maximum engineer productivity
Understanding selfish motivations is vital for helping contributors
And also vital for becoming a community leader
Web Developer!
Thank You!
Questions?