Hi, so we are going to start with the next session, so we have our presentation and James
Bottomley, who is going to cover the Selfie's Contributor, so we can start.
Okay, well, everybody, thank you very much for coming, so one of the things I really like about
Phos Dam is that it's a conference that actually has a lot of excitement about it, but mostly
they're willing to take talks that I give that are about weird and wonderful sort of parts of my
brain that grew up in the prehistory of open source that no other conference will, and so this talk
is pretty much that. So this is exploring the really weird parts of my brain from what has
observed in the 20 odd, 25 years I've been involved with the Linux kernel project. I suppose I should
not to sell Vestray, who is the last speaker, and say that by the time you rewrite my brain in Rust,
it won't have any of these dark corners where these talks come from, but until that happens I'm
perfectly happy to give these sort of talks. So a bit about me, where I came from and giving this talk,
I started out life as I said, as a kernel maintainer, a kernel developer, and I've been doing
the kernel for many years. I was actually been an open source advocate for a long time. I was
on the legal panel earlier on advocating for the DCO, which is the legal mechanism whereby you
make contributions to the Linux kernel. Part of my job, when we first engage SNOSDL and later
the Linux Foundation, was to evangelize for the DCO, because we knew if we made it, industry standard,
nobody would be able to question it, which is the position we're pretty much in today, 20 years later.
I also led the effort to create the Linux Foundation Technical Advisory Board, and I did do a
few things with containers that have been forgotten about long in the depths of time. But what I want
to talk to you today is about the sort of deeper darker motivations that come with open source
and why people actually do it, and how based on this you can manage communities to do it.
I should also say that I gave a talk similar to this five years ago at FOSDAM before, just before
COVID here to actually, and it was also entitled the selfish contributor, but it was mostly focused
on the aspects of selfishness that help drive open source engagement with business. So I was really
trying to explain to you how you can use selfish motivations to drive engagement with open source
in businesses. This talk is actually going to be trying to explain how you can use the selfish
motivations of individuals, people to actually help accret and drive your community.
So with that we'll get on with it. I do have to give you a disclaimer. This talk is mostly my opinion.
The reason it's so controversial is not everybody shares my opinion about how open source
works, what you should be doing and everything. So this is all on me. I do work for Microsoft now,
and you may attribute anything in this talk to me personally. My employer is nothing to do with
any of the opinions that I'm going to be telling you, so you may not attribute them to them. This is
the legal disclaimer. This is why they allow me to come and do these sort of talks. If I make clear
that I'm talking on my behalf, not on their behalf, and with that we'll get into all of the problems
of managing engineers, which are many shall we say. So this is a great cartoon. Managing engineers
has been often said, everybody has heard this is like herding cats. This is one of Sarah Anderson's
pictures of a cat hearder, but basically all engineers like to go their own way, they like to do their
own thing in exactly the same way as cats do. And a cat hearder really just doesn't work.
The basic problem that has plagued industry for a long time is that getting engineers to do
productive work and by productive work, industry means work that the VPs and the CEO of your corporation
once done. All engineers would claim whatever they were doing, including looking out of the window,
they were doing productive work, obviously because we're thinking, but companies have very fixed
ideas of what productive work actually is. So engineers tend to work best and work most
productively on things they like doing, which is a very important thing to observe. And usually
every engineer has a slightly different motivation. Everyone likes doing slightly different things,
or sometimes even radically different things. I mean, some people even work on rust from what I've
heard, whereas obviously people like me working in the Linux kernel would work mostly on C. So
there's obviously a diversity of motivation among sort of everybody. Industry as in industry that
higher traditional engineers to produce proprietary software has been struggling with productivity
issues in software teams for a long time. Primarily because it's very difficult to motivate
engineers to work on the same problem. And industry's idea was, we'll produce a project plan and we'll
sit you through meetings and we'll get you in there and we'll get HR and give you motivational
talk. And eventually you'll figure out what we want producing and you'll do it. And this always
worked somewhat slowly. It worked. So it perhaps slowly towards its goal. But when open source
came along, it was a real revelation because open source managed to move much more rapidly than
industry did. And if you know in this anything about industry, you know the watch word is always
agility. And so industry became very jealous of the way open source actually ran. So let's do some
analogies from truffle hunting. I actually, although I work for Microsoft, I now live in Virginia,
but I used to live actually a mile away from Microsoft campus in Bellevue. And one of the things
I really liked about living in the Pacific Northwest for eight years is that the Pacific Northwest
actually has a truffle industry. So I could, as a sort of in my spare time, I enjoy cooking and I
really enjoyed cooking with black and white truffles that I could just go and pick up in the local
farmers market. Because the Pacific Northwest actually has a native truffle called the Chiba
Melonosporum that grew up in the Pacific Northwest and has found nowhere else in the world. It tastes
very similar to the Paragode truffles you get here. But obviously the French think it's not as good.
I actually, as a gourmet, I don't, I do disagree with that statement. I think you can get
truffles from the Pacific Northwest as good as you can get here. But the point is, if you live
in the Pacific Northwest, you pick them up in the farmers market and they're cheap. I mean,
there are a lot cheaper than the Paragode truffles, which means I can cook with them an awful lot,
which means I have excellent experience in truffle-based recipes. But I'm not here to talk about
the recipes, I'm here to give you the truffle-hunting analogy. So the people who gather the truffles
in the Pacific Northwest always use dogs to actually go hunting for truffles. Dogs are not unreasonable
animals to do this with because you find truffles through the smell. They're very deep in
the ground, but they always emit a slight smell that an animal with a good sense of smell can
find, and dogs have a good sense of smell. So there's a massive industry in the Pacific Northwest
roaming through the woods with dogs that are trained to hunt truffles, picking up truffles and
selling them at farmers market. But in Europe or in France, this is not what happens. Europeans
always hunt truffles with pigs. And there are many arguments between American truffle hunters and
European truffle hunters about what is the best animal. The pigs hunt truffles are really well
because they haven't a selfish interest in the truffle. A pig loves truffles. The reason a pig
hunts truffles is because the pig wants the truffles. The reason a dog hunts truffles is because
the dog loves you, and you've told it, you like the truffles, so the dog will get the truffles for you.
But it doesn't have the selfish motivation to get the truffle. It has an altruistic motivation.
It's only grabbing around and the dirt for the truffles because you told it to. As soon as you tell
it's something else, it'll forget about the truffles and do whatever else you do. Pigs usually,
if they found a good truffle patch, have to be dragged away, kicking and screaming. They do not want
to give up the truffles. It is their selfish motivation to get the truffles. And the upshot of this
is that, at least according to Europeans, because obviously I'm speaking from the American side of the
continent, pigs do find more truffles because of the selfish motivation. The downside,
corollary is that dogs actually do less damage. If the pig slipped its leash or got its
muzzle off, it would actually grab up the truffle orchid. It would damage all the trees and
create a massive scar on the forest. So pig using pigs to truffle hunt is dangerous because you
have to control them. Whereas dogs, as soon as you whistle and call them off, they'll be gone.
They're not interested in the truffles at all. But the key point here is that by harnessing the
selfish motivation of pigs, Europeans can actually find masses and masses of truffles and the
woods around here. So what does this have to do with open source, which is basically the
meat of the talk I'm going to give you? You've all heard of the selfish motivation and open
source because it's a very famous phrase. People who work in open source, it's all about scratching
your own edge. Scratching your own edge is satisfying your own selfish motivation to get whatever
is itching you done. And this is a key point about almost all open source. It's actually made
up usually of communities of volunteers who have a selfish interest. The selfish interest is they
want to see something change, something happens, something you're done. Harnessing the selfish
motivation is actually what can make communities move together. And open source wins in this regard,
often because contributors self-select for being interested in the community. So this is a
big difference from the way the way engineering in companies works is you hire a load of engineers.
You don't really ask them what they're interested in. You put them on a task and you tell them to do it.
In open source, you sort of flag you might be interested in doing this project and you sort of
announce it on some broad mailing list and chances are that the only people who turn up and are
interested in it come to you are people who are already interested in this project. So open source
already has the first advantage in that it is self-selected for people who are actually interested
in the problem you're trying to solve. Whatever it is you're trying to do. So this is Strike
want to open source. An interesting question in that regard if everybody's just going to join
and self-interest is enough is actually do we even need a catheter? Do we need somebody to
lead the project? It's an interesting theoretical question and the answer in some communities is
no but in most communities is yes. And what I'm going to do to illustrate this is give you lessons
from Linux. So you probably can't read this but this is the email Linus Turvals originally sent out
and answering that he was actually going to start working on Linux 25th August 1991. The first line
is good because it sounds nicely ironic now. I'm doing a free and open source operating system.
It's just a hobby and it won't be big and professional like new and obviously we know Linux
nowadays is definitely not big and professional. However in this email there are no mention of open
source. There's no mention of any request for contributions. I'm starting this project that's it.
What he says at the bottom is any suggestions are welcome but I won't promise I will implement them.
What this means is Linus actually thinks he's going to write all the code for Linux. So this was his
idea when Linux first started. I'm writing all the code. You're going to tell me what you want and I'll
do it. That's going to scale really well as we all found out. He's asking for suggestions. All these
doing is asking for suggestions and users. Nothing else. I produce the project you consume it.
And obviously all these contributions in the shape of patches came flooding in. It was only
sort of 10 patches in by the time. Linus realized that he wasn't going to be the one.
The only contributed to this project they were going to be loads. Linus for bless his heart.
He liked things like memory management. He does not care about things like networking,
things like storage, things that are really essential for a modern computer actually to run.
So he realized very early on that a lot of these patches were in areas he didn't care about
but they were done by people who knew what they were doing and they would really help his project
and indeed they did because within a year of that first email the Linux kernel had got to the
point where it could self host the GNU operating system. So that's going from zero to a fully
self-hosting operating system. I'm not going to say it's a good fully self-hosting operating system
but it was fully self-hosting within a year. And obviously as far as Linus Torvals was concerned I mean
his initial thought was I'm going to be the technical guy the one writing all the code.
Now all he is is an open source catheter. He's the one hurting the patches. So just from this first
email within the first few years I mean Linus still tried to keep his hand in. He's still tried
to write patches. He's still nowadays even in the Linux kernel tries to write his own patches.
If you look at the number of patches authored by Linus there are still a few in the Linux kernel.
All of us try to do this. All of us who claim to be kernel developers don't write patches.
You're virtually equivalent of not breathing in the kernel community. They certify you as dead.
But pretty much Linus's day job is managing the patches. He's become organically an open source
catheter. Or actually as we now call him the benevolent taketer.
But the key point that I want to make to you the audience is that this community just formed
naturally. We didn't need a foundation, we didn't need funding, we didn't need anything else.
All we used was the communication tools at the university's disposal. Remember 1991,
this almost predates the main internet. So most people at home weren't connected.
So any students at universities were. So it's no coincidence that the initial
contributors to Linus were all very young students who just joined university or all very
young people who just got a computer and were getting online.
And the other point is that the Linux community formed, even though everybody had slightly
different interests. So I became a storage maintainer because storage was my interest.
They've mellow became the network maintainer because networking was his interest.
Lots of people are interested, lots of file systems, we have lots of file systems,
other pieces of Linux, memory management, all that. They were all done by people who had an
interest in that area. And so the combination of all of these interests is what got the
kernel to be self-hosting. I mean Linus likes to think that he could have done it on his own,
but if you can't write a disk driver, you're not really going to have anywhere to store
your kernel code that you're actually writing once your system is self-hosting. Oh dear.
And the greatest power of open source I think is this power of natural community formation.
It's not a thing that's unique to open source. It's a fairly human quality.
If you look at what happens day-to-day in human society, we naturally create communities.
So natural community creation is a human quality, but it's a great strength of open source
that we harness this human quality and make it actually work for us.
So what I'd like to do next is talk a bit about community-found information.
Since this is the heart of how open source actually works,
I'd like to discuss how it actually facilitates things.
So as I said, open source participants self-select for interest in the project.
So you already start with a body of people who are interested in your project.
And the 99.99999999% of the world who doesn't care about it is off doing something else
and not bothering you, which is always good.
Communities are formed when common goals emerge often from competing interests.
Now, the last phrase from competing interests is somewhat, it's not entirely controversial,
but I can tell you there are lots of people who manage communities who tell you
it's much easier if everybody thinks the same way because it's not as much work for a community manager
but the true secret to forming communities is actually forming them from competing interests.
It's the competition of interest that actually stimulates the ideas that drive the community.
This is a really important point when you get on to trying to do something like outperforming
the entire world in terms of producing an operating system.
If you can't move faster than everybody else who tried this before, you're going to be left in the dust.
And obviously common goals emerging from competing interest relies on negotiation and compromise
between participants. If everybody has a completely fixed, clashing view of what should be done,
nothing gets done because you spend all your time arguing about it.
So it's this natural ability of human beings to negotiate and compromise and accommodate
that actually facilitates the emergence of common viewpoints for what would be a sea of clashing interest.
And obviously it needs a willingness to work together, but this is another thing that opens
force has. Interested people already came to your project. They already come with some form of
willingness to actually help you do this. So this willingness is provided naturally. It's not like
in the industry where you go, oh you've put me on project X. Why am I in project X? Can I
can I be in project Y? Please let me go in project Y and when the management eventually goes
unless you could help us on project X you're going to be on report and eventually you're
going to be resigning. So it's the stick not the carrot, right? So in open source we don't have
any of those projects because of the self selection for interest, any of those problems.
Now here's another thing in that equitable power balance is important for this. What do I mean by this?
Everybody who comes to a project has some sort of power to affect change within that project
do things within the project. Now human societies if you look at them naturally form hierarchically.
Usually there's a leader at the top say King Donald or somebody else like that and then there are
people beneath them who actually do what they want to do. So even I think in the early days of
Linux, Linux Toolviles was thinking he'd be the guy at the top, the King and he'd be telling
everybody else what to do. And in reality, successful communities don't work that way. They work
by actually having a load of empowered people do what they want to do. So empowering people to do
what they want to do actually to bring out their naturally selfish motivation is a key requirement.
And in order to get this to work, it means that everybody has to be empowered and if everybody's
empowered, nobody has the controlling power at the top. So nobody is King, everybody is effectively
acting like climate potentials. As to get all of this to work is the diversity of viewpoints.
If you don't have a diversity of viewpoints, you don't have the competing interests that you're going
to make all this tick. Now obviously diversity thanks to what's been going on in America is a
dirty word nowadays. So what I want to do if Donald Trump happens to be listening is to emphasize
that when I say diversity, I mean diversity of thought. People who think differently. This is not
not DEI. So hopefully he's not listening now. And the point here is that people who are different
from you often think differently. So diversity of thought is often found in diversity of
appearance and everything else. So although I can claim when the Republicans are listening that
this has nothing to do with DEI, there is actually a strong link. If you're recruiting from
diverse communities, communities who are diverse and different backgrounds from you,
you're obviously recruiting diversity of thought as well. So it actually becomes a very important
characteristic of the project. But the point is that project seek out diversity for a rational
reason. They need diversity of thought. And it accidentally comes with diversity of community and
you know, being different, being different colors, different races, different orientations. They all
come to it naturally. And obviously the more diverse the inputs are to the project,
the more thoroughly the community is capable of exploring the project space. Because people who think
differently from you explore in different areas than you're actually looking in to find your solutions.
This is very similar when I was kid, my PhD was in computational physics. So we had this problem
of finding the global maximum, not the local maximum of the wave equations. And the point is that
if you look at a photography of a mountain escape, you can get a U-shaped valley. And if I only walk
a small way into the valley, I think, oh, this must be the global minimum because I walk up the
outside. I don't see that if I walked outside the mountain and along the plane, I'd come to a cliff
and there's the sea because I haven't explored far enough. This business of exploring far enough is
key to finding the optimal solutions to whatever problem you have. And it's actually also what goes
into artificial intelligence. Most of what artificial intelligence is doing is an optimization
for theory trying to find a global maximum in a space of millions of dimensions. So this is my
link to AI. So now I've ticked all the boxes. And robust exploration leads to the best and most
durable solutions. This is why you want to recruit a community of diverse interests because
if a solution does emerge, it will be the robot and most robust and the best one you can
actually have. However, simply obtaining diverse inputs is often not enough to form a community.
The community must also reconcile diverse inputs into code. If all a community does,
it's turn up and say, well, I think this and I think that and you think the other and nobody
ever agrees what the best way is to proceed forwards, nothing will ever get done. So reconciliation
of viewpoints is also key. You need to go off and explore the diverse spaces but it needs to be pulled
back together in the end because if you don't do this, you'll just disagree and have a schism.
And we've had many famous disagreements and schisms and open source based on high diversity of
input. So reconciliation also has to happen. And if it doesn't happen, you won't get the good code
that you're expecting. And this reconciliation is often facilitated by a leader. Effectively,
the cat heard of the project or in the case of Linux, the benevolent dictator. But the job of the
leader is not to tell you what to do. The job of the leader is to help everybody who has the diverse
inputs see how they could actually combine these inputs from this problem exploration into building
the best solution based on what everybody is found. Because everybody goes off and finds different
things. And they all think that the different things they find are the most important for solving
the project, the problem. But the leader is the one who comes along and says, okay, you three different
people have found three different things, but they're three different aspects of the same problem.
Here's what it is. And if you all worked together on it, you'd actually find that you could
reconcile all of these inputs and produce the code that's going to solve the problem.
Doing this correctly is what results in enormous synergy. Synergy is the process of taking a group
of individuals and actually getting them to work more efficiently than the individuals would have
done when working on the project. And if you look, compare open source efficiency to industrial
efficiency, what you actually see is most even productive engineers in industry are usually working
at about half their potential capacity. Right? In open source, we can easily double this,
sometimes we can triple this. And it's the reason the velocity of open source project is
so much greater than the velocity of projects in proprietary industries. And it's why open source
is moves a lot faster than traditional programming and why industry is really keen to embrace
the model. They're not interested in you. They're not interested in the community. They're
interested in the productivity. And naturally so, because industry has a profit and therefore
productivity-based motive. And again, understanding motivations is key to getting people to
working together with people. And obviously one of the problems is if you do this wrongly it produces
dysfunction. So if the leader is unable to reconcile the viewpoints, chances are you'll actually
get a skism in the community. This would be a dysfunctional community. And I mean, I don't necessarily
disagree that having two completely separate desktops for Linux was a bad idea, because I know
some people passionately like gnome and some people passionately like KDE, but it indicates there was a
failure to work on a single thing somewhere in the project. So let's talk a bit about community
dysfunction. So often community dysfunction results from the failure of exploration. So if you don't
have enough diverse inputs to begin with, you haven't explored the project problem space.
The problem you've actually solved isn't the problem you have because you found that little
local minimum, you didn't go all the way to the sea and see the great horizons. So this is a lack
of diverse input, often leads to failure of failure of exploration. Fixed idea dominance is another one.
If you elect a leader first before working out what the problem is, often the person you've
elected has a very fixed idea of what you're supposed to do to solve whatever it is you're trying
to do. And this can be a huge problem because if all the leader is doing is measuring everything
that comes to them based on the one fixed idea they have, you're going to get a project that
basically reflects everything they think of and nothing the community thinks of. So effectively
you're shackling yourselves that the views of single person and it works for a while. It can work
for a while for a lot of communities. Often you don't notice the dysfunction. But eventually if the
project gets big enough, you'll notice the dysfunction. I mean the good thing about dysfunctional
projects that look like this is often they just don't get big enough. They fail to attract
a sufficient community and they die naturally and nobody ever actually sees what's going on.
Inability to reconcile inputs is also a significant problem. So let's say you don't have
you have a diversity of input and you don't have a leader with a fixed idea and so they're trying
to help the project negotiate to find the best solution to the problem and the negotiation just
doesn't produce results. So you go round and round and circles but you never agree. This is a failure
of negotiation. It's often caused by ineffective leadership. One of the objectives of a good leader is
actually to help communities resolve their negotiation problems. So a good leader, if you have
a negotiation failure, often the leader is being ineffective. Sometimes it's just because all of the
people who have the diverse views also have those in direct diverse views very entrenched. Because
remember negotiation is not good enough. Negotiation doesn't mean getting everybody to see my
point of view. It means getting the entire community to agree on what the best point of view was
and that's not necessarily mine. So if I have entrenched views and I'm trying even as a participant
to force them on everybody else, I'm going to drag everybody away from the compromise. So even
as a participant in the community, you must be willing to embrace the ideas of others,
potentially because they can be better than you. And the final one that I didn't really think
about, this didn't really come into Linux, but it is starting to be a significant problem in the
modern world is what's called a wind-lews mentality. What this means is you define a problem
in terms of opposites. It's what you see going on in the United States today. If you're not with
me, you're against me. If my opponent wins, anything, I have lost. And this actually produces
a failure of negotiation. In the American Congress, it's a failure of bipartisanship. A lot of the
bills that actually went through in Joe Biden's last year got killed, not because Republicans
Democrats didn't support them. A lot of Republicans Democrats did. The bills were negotiated
so that they had considerable bipartisans support. It was a right-wing fringe of Republicans who
came along and said, you can't give the Democrats all that. That means they've won and therefore
we've lost. So a lot of bills in Congress were killed because of this, but the wind-lews mentality
will also kill negotiation within your project. So you need people who are able to accommodate
them to see what accommodations they can get and to actually accommodate themselves to the views of others.
Okay, so a lot of this is actually people problems. People are a problem. Working with others,
negotiation is actually a learned behavior. It's what a lot of people learn on the school playground.
And this is a good thing because that's why human beings actually form communities. Because as
toddlers, we all learn to negotiate with other toddlers, you know, if I kick this football through
the window, will you take the blame for it, something like that, but we all learn this behavior.
Now here's the problem. A lot of people who work in open source are clever people.
Unfortunately, in the playground, clever people don't learn to negotiate. They often learn to manipulate,
right? So I can remember as a kid, you know, if I give you the my suites, will you go and
take the blame for this football, I've kicked you the window. That's not a negotiation, that's
a manipulation. The other thing I might say is, ooh, you know, I saw you do X yesterday, which is
way worse than me kicking the football through the window. If you don't take the blame for this,
I'm going to tell a headmaster you did X yesterday. Are you going to take the blame for this? That's
threat-based manipulation. A lot of us learned to do this. Now obviously, manipulation is not all bad.
Politics itself is the art of manipulation by incentive. So the guy offered sweets to take the blame
for the football, that's an incentive-based negotiation. He gets something out of it, I get something out of it.
Nobody entirely loses in this thing. The one where I did threat-based negotiation, you know, I'll
tell on you if you don't take the blame for this. That's actually a manipulation by express or
implied threats. But the point is that politicians see achievable compromises, often before the
parties who are going to be the subject of the compromise do this. So you're offering them something
that perhaps they're willing to take, but they didn't think themselves that actually I am willing
to take this. Perhaps that is a negotiation I should have offered. So this is often what a leader can do
is to achieve the compromises that other people don't see. So manipulation by incentive is often
a quality that a leader has. And obviously if you can see the potential for compromise,
you can persuade others to adopt these compromises. Now manipulation by express or implied threat
is actually very corrosive. This is the one that is picked up by a lot of people. Passive aggression
is one of the most inimical things to community formation. But it's unfortunately one of the ways
that a lot of people learn to get their own way in the playground and later on in life. And if you
want to be a community leader, you have to know how to cope with this. Passive aggression often
tends to fracture a community. If you look at a bad community or a community with a bad leader,
you often find passive aggression sitting somewhere at the basis of this. So often what you see
is in terms of bad behavior and a community, you should have a code of conduct. The big problem
is that codes of conduct don't help with passive aggression. So codes of conduct regulate behavior,
you think passive aggression is a type of behavior. They don't give negotiating positions,
so they don't really help you with the tasks you have to do as community formation.
They don't help you to see another person's viewpoint, which is one of the key things for community
formation. But they are effective against direct threats. If you find anybody issuing direct threats
in your community, you can use the code of conduct to regulate it. The main problem is that passive
aggressive people do not issue direct threats. The threats they issue are always indirect.
So codes of conduct are often ineffective against implied threats. So let's give an example.
If I have a patch that somebody else in the community doesn't like because it competes with their
patch, and they come to me directly or write an email saying, if you push this patch, I'll break
your kneecaps. That's a direct threat. I can go, I'm calling the code of conduct people on you,
you've succeeded direct threat against me and I can have you expelled from the community. But a clever
passive aggressive person wouldn't do that. What they'd say is something like, a number of
us in this community have reviewed this patch. We think your patch would, in the long run,
act decrease the consensus in the community, and therefore is a bad thing. And therefore, as a group,
we urge you to withdraw it, and obviously there would be fracture and dissent in the community if you
didn't. It doesn't sound like there's a threat anywhere in that statement. But in fact, it's
loaded with threats. First threat is, everybody is ganging up on you. A number of us in the
community, usually passive aggressive people always imply they're talking on behalf of majority.
Right, this is number one. Number two, we've reviewed your patch and we don't think it's very good.
So what I'm trying to do is they're trying to lower my self esteem, my confidence, my own patch.
People whose confidence can be lowered will often not push the patch as hard as they should.
This is what passive aggressive people are doing. We haven't even got to the threat yet,
which is, okay, so if you keep pushing it, the rest of the community is really going to take
unbridge against this. Again, haven't said what the community's going to do,
they're not, are they going to come around and fire upon my house? They're just going to write
nasty letters, doesn't say. It's an implied threat. It's not a direct threat. But the whole combination
of that sentence is to do a passive aggressive attack on me and on my patch, to get me to
doubt my ability to push my patch and to get me to withdraw it. And nothing that a code of conduct
says about regulating behavior would help me combat this. Another problem with communities
is they often divide themselves into insiders versus outsiders. An outsider is a drive-by
contributors. An open source, we get a huge number of drive-by contributors. Basically,
because lots of people turn up with just one bug in this project. If you fix this one bug,
I'm fine. I'll go away and I'll just happily use your project and never contribute again.
This is a drive-by contribution. I actually have done a lot of talks about drive-by
contributions because I'm a fairly prolific drive-by contributor because I use open source
for pretty much everything I do. When you use something often, you find things that are wrong with it
and being obviously a good open source programmer, you want to fix it. And once you fix it,
you want to get it upstream, makes me a drive-by contributor. Dividing a community into
insiders and outsiders implicitly discriminates against drive-by contributors and this is always
bad. Partly because drive-by contributors, in my case, are often your users, they often have a
valid point and the patches are often not that bad. And secondly, because communities always need to
grow. And the only way you're going to grow organically as a community is as outsiders become
insiders. They become your core contributors. They're originally, they want to just get this one
thing done. But because you are so welcoming, kind to them, they're quite like the community and
they stuck around and eventually became core contributors, community leaders, and so on. So encouraging
drive-outsideers to become insiders is key, but just because an outside of declines to become an
insider is not a reason to discriminate against them. So let's go briefly over the origin trap
because it's also becoming a key thing in open source. In acquiring into the origins of a patch instead
of its contents is a slippery slope. So this is the question of who produced the patch rather than
technically what does the patch do and is it good enough to go in? Not accepting patches for people
convicted of crimes seems like a not unreasonable thing to do, right? Looks good. So we could do this.
What about they're just indicted? Federal government has accused them of a crime. They say they're
innocent, but they could not be. We could possibly not accept their patch because of that. What about
millisusfected? Let's see Joe blogs down the road to specs this person of doing that. Let's not
accept patches from them. And then after that it will be people who disagree with the key goal.
So I'm a leader of the project. You disagree with goal number five on my manifesto I just published
therefore we're not going to accept patches with you because obviously all patches you submitted
would be subverting the goals of the project. You're a bad person to do business with. And then finally
we get into not accepting patches because you have the wrong political affiliation. I'm a liberal
project. You're a conservative right winger. We're not accepting your patches. So alternatively
this is a conservative project. You're too liberal. We're not accepting your patches. And what you see
here is we got from something that was ostensibly easily justifiable down to something which is
basically destructive behavior. This is the slippery slope, the origin trap of patches.
So the key for a community leader is don't do this. Never ever discriminate on origin if you can.
If you must and sometimes you must because a community insists on it. Sometimes people have done
something so bad. Damage the community so much. The community wants them ousted and you have to do
this. But always use an objective and externally vetted standard if you have to do this. If you
don't do that you will find yourself on the slippery slope again and eventually when you get to the
bottom you'll see your community destroyed. Community leadership is really important.
In all communities it's often called maintainers, cause, committers, whatever. But it's often seen
as a powerful position within the project. But remember what I said about distribution of
power within a project. Good projects distribute power. Therefore good leaders also distribute and
dissipate their own power. If you get into community leadership for the power of it you're
so facto going to be a bad leader. Don't bother. And actually tell the truth. Often good leaders
are incentive based manipulators. So they're people who instead of going the passive aggressive
route actually went the incentive based manipulation route. Clever people, as I said. They do
often seek diversity by listening to all sides. They don't rely on their own view solely. They talk
to other people. They facilitate negotiation by suggesting compromises. This is an aspect of incentive
based manipulation. And they base the compromises they get on what they understand to be the
selfish motivations of all the others. So understanding everybody else's self-if motivation
is also a very key requirement for a leader of an open source community. They encourage others
to share the leadership burden. So if you see somebody encouraging another person through a
view patch or encouraging another person to change a patch or even make them a sort of subcommitter
allow them to build a tree, help you get things in, do the testing. This is the way good leaders
function in the project. They're easy to work with because they reduce the friction and going
from producing the patch to getting the code committed. That's the job of a good community leader.
Good leadership reduces the work and burn out within a community. So it's not necessarily an
absolute truth, but it's a reasonable truth that a good community doesn't really suffer from
burnout, even though you hear a lot about it. Bad leaders do the opposite. They act to increase
their own power. They make themselves the bottleneck and a lot of the projects. They become a
single point of inspection commit-off and they believe they have to do all the work. This
seizing all the work to themselves is equivalent to seizing the power, but it effectively results
in micromanagement and all sorts of other projects. They often have fixed an immutable
visions of where the project is going. They can delay contributions because it conflicts with
the patch that they've not even produced yet. It just sits in their mind. So we won't accept
these five patches because I want to work on that area. They belittle other contributors who
might have become good community leaders because if their goal is to increase their power,
they often sense the threat other people may become and they move to eliminate that threat
before it presents itself. Good community leaders actually sense when others also might be
good leaders and act to encourage them. And obviously they often create a passive aggressive echo
chamber. So usually the project becomes populated by people who think the same as the bad
leader and echo their views. And the corollary of this is that because they take so much of the
power to themselves because they take so much of the commanding, the trolls of themselves, they're
often overworked and burned out. So if you see people complaining about burn out in their jobs,
it's not an absolute indication their bad leaders, but it's definitely a signal that may be a
leadership problem somewhere in the project. So how to become a good leader? This is basically
the wrap up of my talk. Obviously you've got to learn to see all sides of an argument. Leaders
who only see one view are single-minded and useless as community leaders. It's a fact that most
people think they can already do it. So everybody in this room probably thinks this and it's a truth
that very few of you actually have this ability. So this is a learned ability you need to practice
and you need to practice very hard. So how do you do it? When I was a kid debating was a thing
that we did in school. So you used to get these debate societies where the teacher would sort of get
to pick out two pupils and give them a topic to debate and being the teacher, it was often a topic
you didn't agree with. So everybody in this debating club got to debate topics they didn't like
and it was always seen as a really annoying thing because if I only had the topic I liked I could
have argued so much better for it but being a competitive lot we debated and discussed among ourselves
and we actually found some good arguments even if we didn't like the topic. So this learning
to debate on popular topics is key and if you're arguing with a friend you can actually do this simply
by if you know the friend well enough, stop, reverse the viewpoints so you both become advocates
for the others view and then try and have the argument over again. This is a very effective way
of allowing you to see other people's point of view and very effective way of doing devil's advocacy.
It only really works with good friends but try at some time and see how you get along it's actually
a good exercise to do. If you learn to argue well for a cause you don't necessarily support what
you're actually doing is developing the ability to see all sides of a problem. This is how you
actually get the ability to see all sides of a problem as a good community leader so it's something
that everybody should practice and obviously it's most difficult to do most people have the most
problem with this when they're arguing against their own positions. So one of the things you can
actually do as a committer is try and argue against your own patch. Always look at your own patches
and think you know if I were looking at this and it didn't come from me what would I find that
was wrong with it because this is also helping you to see the other side of the argument.
So learn to use this ability to see the motivations of others and also because you can see potentially
what the compromises are now. You can actually offer a person who has a different motivation,
the compromise that they didn't see but you as the project leader actually did.
You promote negotiation and compromise this way in your community and you make suggestions that give
others effective negotiating positions. So your object is not to tell everybody what the conclusion
is going to be. It's to give everybody the ability to reach this conclusion on their own because
a community that actually comes to its own conclusion without being told to is a community that's
developing effectively and well. And you possibly even learn to be an incentive based manipulator
although if you've understood everything I've said about manipulators you may not want to admit this.
So most people who are incentive based manipulators don't admit this. I'm sort of I wouldn't say
a recovering incentive based manipulator but it took me a long time to admit that actually the
politics of how communities and companies work what I'm really good at and it's now actually what
I get paid for. So it can work for you in the end and obviously you need to deal with passive
aggressive people and often in email. If you're a good community leader don't have you've already given
away your power you don't have the power to muzzle the pig you actually have to persuade the
pig which is a lot more difficult than it sounds. If somebody is being passive aggressive in email
only respond to the technical content. Obviously if they're being directly aggressive and
vote the code of conduct is a no-brainer. Ignore any passive aggression direct towards yourself.
This is vitally important. Passive aggressive people seek responses to their aggression so if they're
seeking a response to their aggression and you don't do anything they usually move on to a different
target. But eventually this signals to them if you respond it signals to them which passive
aggressive what button they've pushed that's actually likely to motivate you and they'll do it again
in future. So never ever respond as an individual to passive aggressive overchairs in an email
always only respond to the technical content otherwise you're going to find yourself manipulated.
Providing no signal on a passive aggressive person can actually eventually encourage them just to
engage normally because if they think they're standard negotiating technique doesn't work they're
going to eventually and this can take a long time with some people try something else.
Sometimes ignoring passive aggression can be really hard. Everybody has a button which once
pushed really lights a fire under you. I do you do everybody does. So there'll always be times
when however hard you try you don't achieve this advice that I've said but it doesn't it shouldn't
stop you from trying the next time. Also you need to pay attention to the economics of engaging
with passive aggressive people. So what do I mean by this? A passive aggressive person has an
object to get something done and as a as a good or round a person you might be able to see the value
of that something if it were done to the project. This is the value of actually getting that
patch up stream. You set against that the cost to you of actually engaging and trying to make
this passive aggressive person part of the community because it is a cost to most people who
have to engage with them. If the cost balance turns out to be positive the patch will be worth
more than the aggro of actually persuading them to engage properly with the community. Probably
accept it but if it's costing you way more than the patch is worth let's say it's just a spelling
mistake fix. Chances are you want to think about easing this person out of your community
towards another let's say less well uh first community. Now if you see passive aggression
directed towards others the best thing is to do nothing as long as nothing gets done there's no
signal that's fine. If the person it's directed to responds you can think about intervening.
So in the example I gave where you say the community thought that this patch you produced was
really bad and that the approach you're on is wrong. If as a leader I pipe up and say actually
I read that patch and I thought it was pretty good. You are deflecting the passive aggression towards
somebody else. This can often be good and then always be willing to be wrong and always admit being
wrong when you are and so we get the conclusions which are harnessing selfishness is essential to
maximum engineering productivity. You have to do this. Understanding selfish motivations is vital
for helping contributions and also vital for becoming community leaders. So I hope you enjoyed the
talk. It was actually produced with impress that makes me a web developer because I wrote a tool
in HTML 5 and CSS. Unfortunately my handsome partnership system is down at the moment
owing to a data center failure in Los Angeles. When I get it back up which will be a couple of weeks
the slides will be at this path and I'll say thank you and cool for questions.
We have a limited amount of time so just raise your hand if you have any questions I will go back
to your seats. Any questions at all?
Okay then let's wrap it up. Thank you very much.