The Selfish Contributor Explained
James Bottomley
jejb@linux.ibm.com
Twitter: jejb_
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 IBM, 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 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
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
Aside about the Benevolent Dictator
Extremely common in Open Source
Mirrors Industry technical leadership
CTO = Benevolent dictators
Architects = Maintainers/Cabal
Architects = Maintainers/Cabal
Model is well understood and tested
Python will show us if you can have only a cabal and no dictator
Other models are possible, but none are as widely adopted
The Quid Pro Quo Trap
All projects which become popular run into scaling issues
In Linux this happened in 2002
Linus inspected and integrated every patch
"Linus Doesn't Scale" problem
We blamed Linus and he fixed it with tooling
Bitkeeper in 2002 and git in 2005
Fixing in the acceptance layer avoids the quid pro quo trap
Temptation is to push the problem back on contributors
do two reviews or I won't accept your patch, etc.
OpenStack did this for feature contributors
Prove to us you'll stick around to maintain this feature
Conditioning contribution on mandatory unrelated actions makes people feel used
Scaling problems must be solved in the acceptance layer not the contribution layer
The Origin Problem
Open Source is Pragmatic
Contributions should be considered on their merit
Regardless of where they came from
Inquiring into why someone submitted a patch leads to the origin problem
Not considering motivation allows diverse and differently motivated people to collaborate
Which keeps the contributor base broad
Dealing with Corporations
Corporations only act in their own best interests
All their engagements are transactional
If the business goal changes, so will their contribution targets
So they're the archetypal selfish contributor
But they generated some of the biggest problem in Linux
Selfishness doesn't always produce the best course of action
even for the selfish contributor
So you have to work out what is in the best interest of the selfish contributor
And persuade them to adopt it
Wanted to treat Linux exactly like UNIX
Demanded stable ABI and worked with Distributions to get their code in
By the end of the 2.4 kernel cycle, distributions carried additional patches equalling the full kernel in size
Finally realised we had to explain to corporations why working upstream is in their best interest
Need to understand their selfish motivations to do this
Managing Communities
A key goal is to enable selfish contributions
And make selfish contributors feel welcome
While making the contribution acceptable to the project
Understanding selfish motivations is vital for this
As can be controlling them
And finding better motivations for corporations
Clear documentation about how to send in contributions really helps
Both in getting better patches and setting expectations
Sometimes contributions need modifications to be acceptable to upstream
Explaining to the contributor why this is useful to both you and them really helps
Conclusions
Harnessing Selfishnes is essential to maximum engineer productivity
Understanding selfish motivations is vital for helping contributors
And also vital for managing corporate contributions
Web Developer!
Thank You!
Questions?