Evolve Or Perish! Improving Communities The Apache Way

Thank you for that great introduction, !
«Think: This American Life (delivery style)»
From San Marcos, Texas, it’s This Apache Way, I’m Joan Touzet. Today in our program:
“Evolve or Perish,” stories in which communities are facing something difficult, something
that threatens their very existence, and they choose to change themselves rather than
wither under the challenge. I have three intertwined stories for you today, including later in
our program, how a community theatre production nearly collapsed in on itself because of
the experience of just one of the cast members…stay with us!
But before we get to that, a show of hands:
* How many people here today are contributors to open source projects? Whatever
contribution means to you, if you think you contribute, raise your hand please.
* How many people contribute to the Linux kernel itself (and are on the LKML)?
* Is anyone here an Apache project committer, PMC or Foundation member?
So why should you listen to me?
1
2015-08-22
Evolve Or Perish - Joan Touzet

View Slide

Well, if you ask Microsoft Office who I am, apparently either I swear a lot, or I’m a
bathroom fixture.
2
2015-08-22

View Slide

But here’s some of the open projects I’ve worked on.
For the record, 1995 is when the first Apache httpd server was released, built by 8 people
working together on abandoned NCSA httpd code (because NCSA fired their developer).
And in 1999, the Apache Software Foundation was formed as a non-profit organization in
the US, with the first ApacheCons being held in 2000.
In 2008, CouchDB was still an Apache incubator project – meaning it was still working to
prove itself capable of upholding the Apache standards. More about this later.
3
2015-08-22

View Slide

…But I also have other passions. I am involved in the leadership of a gaming "outfit" - like a
clan
- We play any number of games, but I really like PlanetSide 2 (PS2)
- I run FEAR, our PS2 air and tank division
- Twice a week we strap on our headsets, kit out our vehicles and go nuts
- Part of a coordinated group of 100+ people who apply strategy and force to win on alien
battlefields
- We play as part of a faction called the Vanu Sovereignty, decked out in purple and blue
They have been called "Religious nut jobs", "Techno-evangelist", and a "Trans-humanist
Cult." The Vanu Sovereignty would find those terms to be dismissive and born of ignorance.
They are what we would call true believers. The V.S. firmly believes that technology and
knowledge hold the answers to all of mankind's problems. It has been said that "The
Ancients" (the ones that actually created the tech that the V.S. use) have shown them the
way. They believe that they have been "blessed" with the gift of technology and power to
"smite those that stand against the pursuit of knowledge and power". The V.S. also believes
that everyone should have the freedom to believe in the ancients just as they do.
The VS motto is “Technology equals Might” – you can see why techno-advocates (like I’ve
been for years) are attracted to playing as VS!
4
2015-08-22

View Slide

In university years I ran a charitable drive organization that solicited donations from alumni
and local businesses, and worked to bring the community and the university together in
different ways. I also worked directly with city youth and transient populations to transform
their lives on a daily basis.
In this picture you can see the DEMOS group, a group we funded, using equipment and
supplies from the university to demonstrate various scientific principles to elementary
school students.
While I won’t be going into my experiences running a non-profit during this talk, if you have
questions about running a 501(c)3 later, feel free to ask me after the talk.
5
2015-08-22

View Slide

Over the years I’ve also been involved in the performing arts, primarily theatre and music,
both on stage and behind the scenes. There’s nothing like creative endeavour to bring out
people’s opinions about anything and everything…significantly more so than in software
development, I’ll add. I’ll get back to this.
Oh, and that’s not me in the picture. But I wish it was! :D
So what has been the common theme across all of these communities that I’ve built and
participated in?
6
2015-08-22

View Slide

But actually…that’s overstating it a bit.
7
2015-08-22

View Slide

Patience turned out to be the key element in all of these efforts.
Today I have stories for you about patience, and how it can best be used to evolve
communities of practice – like open source development, but also video gaming
communities, theatre communities, and non-profits – from their current status quo into
something objectively better, something more closely calibrated to
And for those of you who have already made up your minds about my talk – that you are
convinced you’re not going to be swayed – I encourage you not to give into the backfire
effect. Do your best to not “dig in” and honestly consider the options I’m presenting. If I
had to guess, every single one of you who raised your hand as having been on a project
have experienced conflict, stonewalling, unfair decision making, contrarianism, trolling, and
yes, even sexism. Hopefully during the course of today’s talk you’ll learn some techniques
that may help you move past these problems…but it’s going to take your patience now,
listening to the options, and your patience later, when you actually try them in your
projects.
8
2015-08-22

View Slide

In which we look at all the ways in which good intentions get torpedoed right out of the
gate.
9
2015-08-22

View Slide

…the founder of your project completely slams your work ethic, approach and direction.
And that the needs of the few (one business, one person) are more important than the
needs of the many (i.e., the community, the project, etc.)
10
2015-08-22

View Slide

You’re just sitting there, minding your own business, and then someone comes along and
knifes you in the back of the head.
You’re cursing yourself because you’re caught off guard, you wonder if you should have
seen it coming, and you have to collect yourself before you make your next move.
11
2015-08-22

View Slide

You start off feeling….like you didn’t deserve that kind of treatment, and it’s a wistful sad
first moment. But it rapidly shifts into:
12
2015-08-22

View Slide

Bitterness. Those of you who know the five stages of grief shouldn’t be surprised by this.
But hoo boy does bitterness have the ability to crush any spirit of cooperation you may
have. And lest Catherine winnow away forever in Wuthering Heights, she might do well to
review her sense of who merits her affections, if not young Mr. Heathcliff…and we would
do well to review just what the word Merit means.
13
2015-08-22

View Slide

So when it gets personal, you have to get personal back.
How many of you are aware of the Prisoner’s Dilemma game?
Two members of a criminal-gang are arrested and imprisoned. Each prisoner is in solitary
confinement with no means of communicating with the other. The prosecutors lack
sufficient evidence to convict the pair on the principal charge. They hope to get both
sentenced to a year in prison on a lesser charge. Simultaneously, the prosecutors offer each
prisoner a bargain. Each prisoner is given the opportunity either to: betray the other by
testifying that the other committed the crime, or to cooperate with the other by remaining
silent. The offer is:
If A and B each betray the other, each of them serves 2 years in prison
If A betrays B but B remains silent, A will be set free and B will serve 3 years in prison (and
vice versa)
If A and B both remain silent, both of them will only serve 1 year in prison (on the lesser
charge)
In the iterative version of Prisoner’s Dilemma, where you are repeating the choice to vote
for or against the other player(s), one of the best strategies is known as “Tit for Tat.” You
start off by cooperating, but then copy your opponent’s last move every time after that. So
if your opponent doesn’t cooperate the first round, you defect the second time. If they
return to cooperation, you return to cooperation. It turns out to be one of the best
strategies for PD, and is often how we tend to act in open source: we generally avoid
14
2015-08-22

View Slide

escalation unless someone else escalates first, which can lead to “cold wars” at times.
There’s a whole lot more I had prepared on the Prisoner’s Dilemma, but I cut it from this talk.
If you’re interested in that topic I may resurrect it for another talk in the future.
Evolve Or Perish - Joan Touzet 2015-08-22
14

View Slide

So it’s time to talk about one of the key aspects of The Apache Way, and that’s the concept
of merit.
I found this description in one of the earliest talks about The Apache Way, from Ted Husted
in 2007.
When you read codebase here, think all assets of a project.
So in other words…
15
2015-08-22

View Slide

Merit is perceived value to the community.
Individuals, not corporations, accrue merit at Apache.
Merit is not transitive to your coworkers. emphasize this when it comes to the
corporate-OSS conversation
Merit is not transferable between communities.
Merit does not expire.
Merit can be lost, through harmful actions within the community.
Merit does not buy you authority! The community must still agree.
Merit is not just for code. Documentation, website, infrastructure, mailing list help, IRC,
community management, marketing, outreach…
And as it turns out, our founder hadn’t committed any assets to the project in a couple of
years, hadn’t been active on the mailing lists, and was basically doing what he did as a way
to promote his company over the interests of a community. Censure was the best option.
He ended up being asked to leave the PMC. Which he did.
16
2015-08-22

View Slide

So with this definition of merit, I’d like to try and redefine one of the most problematic terms
in our culture today:
16

View Slide

So even if you’re used to a different definition of meritocracy – such as those who are best
get to lead – this is very different. Take a moment to think about it: if you do the work, you
get to be part of the organization. If the organization recognizes you as having done a lot
more of the work, you get to step up and be part of the PMC, whose additional role is
primarily limited to conflict resolution and rudder-like guidance, a small influence on the
overall project goals.
And by the way, this definition and use of the word at Apache still has issues, ones that
we’re working through as an organization to get a better handle on, to further level the
playing field. This topic is bigger than I have time to get into, so I’ll just say: keeping the
amount of power gained through merit to “just enough” and ensuring that even that
amount of power is not some sort of “special club” to which one gets admitted is a real
challenge. We work hard to avoid class stratification in Apache CouchDB, but ultimately
there remains an imbalance. The best we can do is make it easy to gain status, and that’s a
topic I’ll cover in the next Act.
17
2015-08-22

View Slide

18
2015-08-22

View Slide

So we’ve evolved our notion of meritocracy, and we’ve moved past an attempt by – let’s
not beat around the bush here – a corporate interest intent on sabotaging a good faith
open source project simply to build their own business case. And we’ve identified a list of
action items we can pursue to further evolve the culture.
19
2015-08-22

View Slide

So if you’ve spent any time in the performing or visual arts, you will have encountered this
phrase, “The Creative Process.” Usually it’s preceded by “Don’t interfere with…” or “Come
be a part of…,” or if you’re an outsider, “You don’t understand….” Today I want to talk about
not the process itself, which manifests differently for everyone, but more about what it
takes to enable the best creative process possible, as someone involved directly or even in
a limited peripheral way.
20
2015-08-22

View Slide

So after the meeting, a few of us got together because we felt things were still unresolved.
What were the barriers to entry to our project? How could we try and lower those barriers
even further? Reeling from that black eye, growth seemed the only reasonable alternative
to dying completely.
21
2015-08-22

View Slide

And so the first one came up, the one that dogged us for years. CouchDB is written in
Erlang, and people complained that it was too hard to learn, compared to Ruby, Python,
JavaScript, or other languages.
As it turned out, this one solved itself. Erlang became cool, possibly in part because of what
CouchDB did with Erlang. We started finding more and more Erlang developers willing to
lend a hand. And new developers were helped further on by Fred’s great book, LYSE.
In short, we got lucky.
22
2015-08-22

View Slide

Another one was knowing where to start. Often people would run into design limitations
that they wanted to conquer, only to find out that dealing with that particular problem
required knowing the majority of the code base, or needing to touch a very large number
of subsystems.
So a pass was done on our issue database, adding a new field for skill level. Now it became
clear what problems were easily approachable by new committers, and which weren’t.
We also held a few Google Hangouts to discuss system architecture, especially that of our
new dashboard frontend, Fauxton (explain the joke). Unfortunately these weren’t as
successful as we would have liked, primarily due to time zone issues. So we continued to
hold our IRC meetings approximately once-a-week; these remain a solid source of
discussion and inspiration for the project.
23
2015-08-22

View Slide

So back to the gaming community, and a little bit of an origin story. Our video gaming group
started out 13 years ago – making us one of the oldest surviving video gaming groups out
there – playing PlanetSide 1, or as it was known then, just “PlanetSide.” This is an MMO
video game so old, it was designed to work well over dial-up connections, and holds up
surprisingly well – the servers are still running, and you can download the client and play it
today if you want. (There’s not that many people on the servers anymore, though).
This video shows one of our Sunday Fun Raids, where we all suited up in these mech suits
with jump jets, and rushed across the map as a single group assaulting bases. It was fun
because of the element of surprise, and the fact that seeing 40-80 coordinated people in a
single rush was pretty rare in those days. Our strength came from our coordinatedness,
along with our knowledge of the intricacies of how the game played, the mechanics of
dodging, and our mastery of these mech suits and their larger partners, the vehicles and
vehicle-sized robots.
Overall, it was a niche title, and as a coordinated outfit of 40-80 people, we were definitely
one of the heavyweights playing the game.
It was a blast…and then PlanetSide 2 came along in 2013.
24
2015-08-22

View Slide

And here’s PlanetSide 2, during one of our Thursday Main Raids. We’re following our PEST
group here, a small focused tactical team handling just one of our side battles, not the
main front. You can see the graphics are a lot richer and the action is a lot faster, enabled
by new video card technology and the advent of high-speed, low-latency connections. It’s a
real adrenaline rush, requiring quick wits and even faster reflexes.
Here’s a shot of the drop pod, dropping you directly into the action…very, very fast action.
Our old techniques were going to need changing, and it was obvious that with PS2 out, PS1
was going to fade into obscurity quite quickly.
So we needed to evolve, but how? The outfit’s strength was always in coordinating a large
number of people who were good at their craft independently. "Survival of the fittest" is
not an answer!
- We had a choice: could become an "elite outfit" and only keep the best, people who
could slot into any role and were truly masters of everything, quick-twitch players who play
11+ hours of the game a week
- Or we could open the door to more and keep the interest level high. Accept all kinds of
contributors. And that’s what we did. Out of that experience came:
25
2015-08-22

View Slide

Talking about the outfit facing a huge shift in change – PS1 to PS2.
Just like the fast-paced action of this game, we're born understanding "heroics in the face
of an immediate threat". Long-term systemic seeing and thinking takes a different set of
tools.
How did we manage it? What are some examples?
26
2015-08-22

View Slide

It was a great bridge for some of our older players, who weren’t as much into the high-
speed FPS action introduced with PlanetSide 2, and allowed them to continue to contribute
in a meaningful fashion.
In fact, to this day, I have still not seen another PS2 outfit that has a dedicated forward
operations base for its tankers or aircraft.
27
2015-08-22

View Slide

And in CouchDB, we decided that to level the playing field, encouraging support from all
corners was equally valuable. We explicitly stated that UI Designers, Documentation
editors, translators, marketing support, project management support, and community
advocates were all officially recognized as being of value by giving them merit – making
them official contributors to the project.
For those of you involved in open source projects – have you ever taken the time to
officially recognize the contributions of all of these kinds of people? What might it do for
those people? Probably a big ego boost, yeah? And how much effort might it take you to
recognize them? Probably not very much, am I right?
The days of the “commit bit” being the sole arbiter of who is “allowed” to participate
should be long behind us. Being a coder isn’t all it takes.
28
2015-08-22

View Slide

Now this lead us to another one of the crucial Apache Way rules: openness.
We realized that some decisions were possibly being reached in other venues – like our
CouchDB conference, though for that one we had nearly all of the committers present in
one room.
As a result we decided to enforce the Apache mantra that decisions get made on the
mailing lists, and nowhere else.
And who gets to participate in those mailing lists? And how are the discussions held?
29
2015-08-22

View Slide

So we enacted our official Bylaws. We had to codify the ways in which we worked formally,
to make it clearer for people how they can (and should) interact with the project. By writing
down what we expect of people, we set them up for success – the rules can’t magically
change between the time you start work on something, and by the time you finish it and
are ready to merge it with everyone else’s work in progress.
* Uncontroversial or small changes: JFDI
* Controversial / irreversible / large changes get a proposal, then
* 72 hours of waiting
* Conflict that goes unresolved may result in a vote
* Votes are actually a failure to resolve conflict!
One word on vetoes. We’re actually considering removing the veto from our bylaws.
Presently the only veto allowed is on code changes being made that directly affect our
master branch. We’re not sure we want committers to be able to have this power – it can
and has lead to so-called “commit wars” in the repository to block specific changes from
occurring. We haven’t made the call yet, though.
30
2015-08-22

View Slide

We also formalised our rules around voting, which were by and large the same as those in
the Apache foundation: depending on the vote type, you need +1s to pass something, any
number of 0s, and no -1s. Any -1s submitted must include an alternative proposal. And so
far, we haven’t been deadlocked on any decisions. Well, almost never. I’ll get back to that.
In our gaming community, we have a similar structure that we call the Eidolon Council. In
the words of our outfit leader, “it’d be just so much easier to be dictatorial and just force
changes on everyone. Putting things up to a vote of the community’s elected leaders makes
change slower, but ultimately gives better accountability and ensures more fairness.”
31
2015-08-22

View Slide

Or, for those of you who have never been to a rave: Peace, Love, Unity, Respect. It’s
amazing, having attended at least a few of these, how closely knit a random group of
people can be when they are pursuing fun, they can find ways to bond. Sitting down once
to catch my breath after dancing my butt off in my younger years, I had no less than 3
people passing by ask me if I was OK, if I needed some water, and ask if I wanted to join
them in dancing / chilling / having fun. And no, it wasn’t the drugs – as far as I could tell,
these people were sober, as I was too. It gives you a warm squishy feeling inside, and the
music only enhances the good vibes.
So as we continued on our introspection about things our project could be doing better,
one thing started standing out above all other problems: this persistent impression by new
members that CouchDB was a hostile community.
In Act 3, we explore what lead to that perception, and what we’ve done about it to try and
change the game.
So we did know that some people considered our little project a “hostile community.”
When we reached out to some of those people, here’s what they said.
32
2015-08-22

View Slide

A really challenging one for us was that people would suggest new ideas, new ways of
working with CouchDB, and would say “My contributions to the ecosystem went
unnoticed.”
33
2015-08-22

View Slide

As a new Erlanger myself, I spoke up saying that I couldn’t get the mentoring I needed from
more advanced people on the project, to explain how some of the more complex parts of
the system worked. For me specifically, people took the time out to explain things to me,
but I had to complain first – it was a painful process for me, not just because I was stepping
out of my comfort zone, but because it wasn’t clear where to turn, or who to talk to, to
increase my abilities beyond “Well, here’s the source, good luck!”
34
2015-08-22

View Slide

But after I spoke up, others started coming out of the woodwork, and this complaint got
voiced a couple of times, on public mailing lists. I was left slack-jawed: not only was it hard
to climb up the hill of learning the code base in place, once you finished, were you just
going to have the door slammed in your face by a -1 vote?
As it turns out, we found there were at least two reasons why this happened.
35
2015-08-22

View Slide

The first is so-called cookie licking. Have you heard of this? It’s a way of saying “I want to
work on X, you can’t touch X, because I’ve already started working on it.” It’s a power play,
and can be used by people who don’t want you to do it any way but theirs…but is also a
problem that can be started by people who have only the best of intentions.
In fact, this became a huge problem with the merge of the bigcouch branch, a branch
created by a number of our core committers to add clustering functionality to the product.
Between the time the branch was announced to be merged, until it was actually merged,
took 2.5 years. That’s far too long – but how can you criticise people who work on this sort
of thing as volunteers? Where are they supposed to find the time to do that work alongside
their paid jobs?
In the end, we weren’t able to identify situations where cookie licking was actually
malicious, and so the resolution for this problem was basically the same as that to grow the
community: let more people in. Get a pull request out there. Do the work, and then the
work can be reviewed and changed if necessary.
Like any real project, we still have challenges – I feel like there’s more to do here that we
haven’t yet hammered out.
36
2015-08-22

View Slide

But the complaints lodged went beyond just cookie licking, and suggested that the
community had some bad actors.
In open source projects, you run into these bad actors, people with whom it is difficult if
not impossible to work. And they wreak their havoc on the community pretty visibly, by
rejecting people’s viewpoints out of hand, taking the smallest amount of criticism and
turning it into a huge explosion, and more.
But once again science has an answer. “In several social psychology experiments, people
chosen at random to receive messages of social exclusion become more aggressive,
more willing to cheat, less willing to help others, and more likely to pursue short-term
over long-term goals. Rejection appears to lead very rapidly to self-defeating and
antisocial behavior.”
In other words, the longer we left the problem in our community unchecked, the worse
the problem got.
Sure, some people have bad days, but some people seem to have a lot of bad days. Like,
every day.
We knew that we couldn’t allow this rampant rejection to continue, and that it would only
give birth to similar behaviour across the entire project community.
37
2015-08-22

View Slide

Now we turn to my theatre experience. As I mentioned, I used to direct theatre and
musical theatre. Along the way I ended up with 3 rules that I would give to a cast at the
start of our rehearsal times.
1: It’s nice to give them a rule that they’re used to, one that gives them a way to succeed
and is a well-known thing actors get chastised over.
2: This one isn’t common, but given how bad traffic is in most communities these days,
and how far we have to travel from our places of work to rehearsal spaces, it’s only
reasonable. In return, as a director I was always a very organized type, meaning that I did
my best to split up rehearsals so that the entire cast didn’t have to come in every day.
And they appreciated it!
And then there’s rule #3 , which I added after I started running into problems with a
particular production. I had thought it was limited to that one production. As it turns out,
it’s not – and adding the rule at least gave me a way to push back. It can be surprisingly
disruptive to a small cast, and especially in small community theatre, disruptive to the
community at large. Turns out just saying that it’s a problem is enough incentive to deal
with most of the problems…of course, the really DETERMINED actors will ignore you just
the same and get themselves in trouble.
Does anyone know what kind of punishment you can dole out to a bad actor? (pause for
suggestions from the audience) What works well for the performing arts? (pause) Well, it
turns out giving dialogue away to another actor. It’s surprisingly effective, and if there’s any
38
2015-08-22

View Slide

actors in the audience, you can imagine how shaming it can be. But when there’s only 3 basic
rules…and you violate one of them…there has to be some kind of punishment.
Oh and in case you weren’t aware: community theatre rarely has the luxury of understudies.
You can’t really kick people off of the production, you don’t have the staff and you certainly
don’t have the time (deadline is fixed – you get the stage for so many days and that’s it!)
38

View Slide

In our gaming community, we had similar issues. Sometimes the violations of culture were
obvious: people using technological cheats or playing in an unsportsmanlike fashion.
You also had people who would leverage any sort of advantage they had to attempt to
obtain positions of power, what I’m calling underhanded politics on this slide.
This might include artificially creating conflict within a community, dividing the members
between nonsensical arguments just to keep them distracted while they got their way.
Or it might include openly campaigning against the active leadership, flaunting their own
approaches and being unwilling to discuss alternatives.
And in the worst situations, allegedly some individuals were committing illegal activities,
the details of which I don’t want to go into.
Ultimately, we didn’t have much of a choice – removal from the gaming outfit was required
– but this really is the nuclear option. It creates the biggest rift, the most visible tear in the
fabric of the group. So how could we help establish better ground rules and conflict
resolution approaches that would prevent having to use the nuclear option?
39
2015-08-22

View Slide

So in theatre, we evolved the production to do our best to incorporate bad actors. In fact,
the entire creative process of theatre involves pulling people together for a short period of
time, integrating them both horizontally, across all roles in creating something new, but
with a small vertical component (director, producer, etc.) to ensure that basic rules are
followed and censuring bad behaviour where necessary.
In the gaming group, we always had the nuclear option available to us, but the more we
used it, the more ham-fisted it felt, and the harder it became on leadership to justify the
need to take such drastic action.
It was obvious that something had to change.
40
2015-08-22

View Slide

So as an example, here you can see the gaming group’s rules, The Pillars. These have
existed in some form since 2002, largely unchanged, and it’s how the group has managed
to survive for so long, becoming one of video gaming’s oldest social organizations.
Pillar Zero reads “Real Life Comes First.” This rule is still critical, and it exists in the Apache
world as well. Remember, Merit doesn’t expire – it might get dusty but we recognize that in
volunteer efforts, your real life has to come first.
41
2015-08-22

View Slide

And our original Pillar 3 is here. But as it turns out, people have different definitions of
what it means to…um…be a problem person, so we had to refine our rules.
42
2015-08-22

View Slide

Here’s how they ended up after revision – a 7 point list of things we expect from our
players. This included a statement about how we value diversity in gamers – with a
“laundry list” of different types of diversity, pointers about being family-friendly, acting with
respect to each other, respecting our command structure, avoiding hacking or illegal
activity, and leaving certain aspects of running the outfit (like advertising) to those whose
role it is to do such (our publicity officers).
This was a pretty big change, and yet it only took about 2 weeks from the start of the
discussion period to the final voting-in of the changes.
43
2015-08-22

View Slide

In the CouchDB community, around the same time I spearheaded an effort to create a
CouchDB code of conduct for project activity (NOT for conferences, Apache already has one
for Apache-sponsored conferences) and a project diversity statement.
I didn’t start from scratch, though. Here’s a list of some other codes of conduct that you
can have a look at to see the variety that exists. There’s a lot of shared language, and it only
made sense to build upon others’ great work.
Where we did strike out in new territory is by raising empathy up to a top-level concept.
We define empathy as the awareness and understanding of the emotional state of others.
Put another way, back in the 90s we used to talk about newsgroup etiquette, and one of
the big things in etiquette was remembering that there’s a human being on the other side
of the keyboard from you. The point of the Empathy clause was to remind people of this,
and to try and see things their way before immediately digging in your heels and pulling a
contrarian position.
44
2015-08-22

View Slide

Sadly it took almost 10 times longer for us to get our Code of Conduct approved by the
CouchDB community than it did for us to
Unsurprisingly, we got the most pushback on this effort from the one or two individuals
we’d already identified as being our “bad actors.” They ranted and railed about how we
were politicizing the project, when it was pretty obvious from their own histories on the
project that they were doing just that – pushing a particular political agenda on the project,
with themselves at or near the epicenter of the changes.
Look folks, I’m up here on stage today and telling you that code doesn’t exist in a vacuum.
We are people situated in various socioeconomic strata, pursuing projects for all sorts of
personal reasons, and in volunteer projects personal motivations are closer than ever to
the modus operandi of the projects themselves. By not acknowledging that link you do
yourself, the project and the community at large a disservice.
We also got pushback from people who had the argument: “But everything is fine! I’ve
never run into these issues, and I don’t let my biases get in the way of my open source
work.” And by and large, this is true – there may be systemic problems of discrimination
against certain groups, but on the whole we have a lot of GOOD ACTORS. It took a fair bit of
explaining to these people, in the gaming community as well for Apache CouchDB, that
passing a CoC is a vote in favour of being positive, a way to show solidarity and to (by and
large) maintain good feelings. And by and large, they ended up voting for it.
45
2015-08-22

View Slide

And so we worked to resolve issues without having to descend to the nuclear option…and
eventually the vote was called and the code was passed.
So there we have it – a clear set of rules against which we can measure behaviour and
provide for an official grievance procedure. But the CoC was useless until we were prepared
to enforce it…and our hand was pushed, we ended up having to use it .
I’m also proud to say that shortly after CouchDB passed the code of conduct, Apache took
the text almost verbatim, removed some project-specific language and turned it into the
Apache Code of Conduct. And they too have been able to put it into action within weeks of
making it the letter of the law.
And I helped! :D
45

View Slide

Another way of putting this is the Apache saying: community before code.
How many of you would, all other things being equal, choose not to make a controversial
change to your code that you were 100% convinced was the right direction because your
community disagreed with it?
How many of you would take the time to consider the community’s reaction to something
first?
15 years ago if I asked that question of an audience like this one, the response would be
scoffing. Developers hadn’t yet realized that the life’s blood of their project was the
community that they served. In many ways, they could call the shots because they were
the only game in town. With the widening of the field and the increasing ability of anyone
to develop on inexpensive hardware and with access to many more ways to learn how to
code, community isn’t just important, it’s vital.
Community Before Code. Think about it, won’t you? Thank you.
46
2015-08-22

View Slide

What does Apache have to say? Well, a Code of Conduct is another pillar supporting the
notion of openness.
Openness ensures projects remain neutral. By having the decisions made on a public
mailing list with a code of conduct ensuring proper interaction, no one set of contributors,
no corporation, no one organization can command the project and use it solely for their
own ends. Everyone can see what is going on, and who is advocating what. Contrast this
with the Benevolent Dictator For Life model that some other projects have – Python, Linux
– Apache feels that this model is more scalable and doesn’t require that cult of personality
that can become controversial, especially given enough time.
Further, open communication about what’s going on and how decisions are made allows
for oversight. In those rare instances where someone needs to be reprimanded, or the
“nuclear” option of removing someone from, say, the project PMC, oversight is critical to
ensure that what little power has been granted is not being abused. Having the core values
articulated, and having the project's work happen in the open ensures that the board can
review the PMC and the PMC can review what's happening to ensure the core values are
accepted and followed. The Code of Conduct is just another leg in that stool.
47
2015-08-22

View Slide

The term "burnout" originated in the 1940s as a word to describe the point at which a jet
or rocket engine stops operating [12]. The word was first applied to humans in the 1970s by
the psychiatrist Herbert Freudenberger, who used the term to describe the status of
overworked volunteers in free mental health clinics [13]. He compared the loss of idealism
in these volunteers to a building – ”once a vital structure” – that had burned out, and he
defined burnout as the "progressive loss of idealism, energy, and purpose experienced by
people in the helping professions as a result of the condition of their work" [14].
This picture taken of me in game, illustrating a glitch that was present at the time,
represents how it can feel to be in charge, or in a position where you’re doing critical work
for a project. Too many things under your control makes it harder and harder to get things
done.
48
2015-08-22

View Slide

Remember that by and large Apache projects are run by volunteers. So let’s look at some of
the hard numbers about volunteering.
Statistics Canada has some of the best information on volunteers. Here’s survey results
from 2010 of thousands of volunteer workers across Canada.
So while the average number of hours worked a year is 156 hours, the median number of
hours worked a year is 55. That means that half of the volunteers surveyed worked
between 1 and 55 hours in any given year. The remaining half therefore worked more than
55 hours a year, with a whole 10% working a whopping 391 or more hours a year on their
volunteer projects.
Put another way, 10% of the volunteers put in more than half the volunteer hours. And a
quarter of the volunteers put in three-quarters of all hours volunteered.
49
2015-08-22

View Slide

So if you’re one of those 50% contributing less than 55 hours a year, how much is that?
With 2 weeks off a year, that’s only 1.1 hours a week.
Not a whole lot we can manage in tech in just 1 hour a week. Perhaps you read the mailing
list. Or you review a few filed bugs. Perhaps you can squeeze in 10 lines of code or so, test
them, commit them, and merge your PR the following week.
So the problem is with that other half, and specifically that quarter of people who are
working 161 hours a year or more, or on the order of 3¼ hours a week or more.
50
2015-08-22

View Slide

The Maslach Burnout Inventory (MBI) is a psychological assessment that has become the
leading measure of burnout. You can take the survey online for about $15. It’s short,
between 16 and 22 items and measures (in the general form) emotional exhaustion,
cynicism, and professional efficacy. All three of these are things that can lead to flagging
ability to engage with a project, and I’ll bet that many of you who raised your hands at the
start of this talk are looking at this thinking “I wonder how I score?”
But a key finding of these social scientists is that the blame for burnout isn’t chiefly on the
individual experiencing the burnout, much as our popular culture might like us to believe.
“Oh, he wasn’t strong enough to cut it,” I’ve heard countless times when someone
announces they are “retiring for health reasons.” Bullcrap.

51
2015-08-22

View Slide

Those same social scientists and psychologists tell us that there are a number of factors
that put one at risk for burnout, including
52
2015-08-22

View Slide

By far the most common source of stress and burnout among nurses is work overload
brought on by inadequate staffing
- WE CAN FIX THIS. GROW THE COMMUNITY.
A sense of control, or autonomy, is important to nurses, and job satisfaction is greater
when nurses, especially younger ones, feel as if they have some control over how they
perform their job
- This is critical for new contributors who don't have the context to contribute and wonder
why their ideas are immediately rejected!
Insufficient reward
- All contributions are welcome, reward is not measured based on how many lines of code
Absence of community
- The nurse's community consists of peers, physicians, patients, and leadership. Positive,
supportive relationships with all these constituencies have been related to job satisfaction
and a decreased likelihood of stress and burnout
- This is something we try and encourage with IRC, bots that keep us laughing by dancing,
cute animal pictures, jokes, etc. And while we aren’t all colocated enough to go out and
have fun after work, we make a point of trying to enjoy ourselves in person as a group
whenever we can.
53
2015-08-22

View Slide

Emotional demands
- from dealing with draining topics
- politically sensitive ones
- populations at risk
- bikeshedding
The shortage / burnout cycle:
Volunteer Dissatisfaction -> Burnout -> Coder turnover -> Coder shortage
53

View Slide

So looking at the CouchDB community, I saw a lot of parallels with my 501(c)3 non-profit
leading years. The burnout cycle looks something like this:
We start off with a contributor shortage, which leads to developers being unhappy about
there being so much additional work to get done. This leads to burnout as you try and pick
up the slack, and we start losing contributors as a result. This feeds back into the
contributor shortage.
54
2015-08-22

View Slide

So since some of you may be suffering from burnout RIGHT NOW, here are my immediate
recommendations to you.

55
2015-08-22

View Slide

We've come a long way since May of 2003. We've been through twelve different
leaders and countless officers since then. Though we've experienced periods of
bleak inactivity in the past, our active membership now grows steadily. We
successfully transitioned from an East Coast USA single-game guild to a
multi-gaming community that spans the globe. Our three-hour weekly "officer
meeting" full of ribbing and joking and very little work has now become a thirty
minute meeting where we are able to actually be productive. Where we used to
have a simple forum board, we now have a robust, powerful web site that allows
us to connect with and provide services to our members like never before. Where
the Internet is in many places a cesspool of trolling, hatred, and
discrimination, we've created a place that strives to promote respect, teamwork,
and equality. We have members that share these ideals and support us and each
other in our endeavors - and interestingly enough, this doesn't prohibit us from
performing in-game with an incredibly high degree of skill and organization.
Have we had our rough patches? Sure, and I imagine there will be a few more
somewhere down the line. What keeps me going and what keeps our community going
is that there are people here that will not only help us get through the rough
patches, but to help fix the problems in the system as well. Anyone can leave a
messy situation, but I am incredibly fortunate to have colleagues that believe
in our ideals enough to dig in and attack the problem instead of bailing out.
That is what makes the difference - people that want to see each other succeed.
56
2015-08-22

View Slide

57
2015-08-22

View Slide

Special thanks to: Rich Bowen, Shane Curcuru, Jan Lenhardt, Noah Slater, Michelle Phung,
Chris Davis, Shawn Meckler, Raena, Ira Glass and Charles Patrick Farris III.
58
2015-08-22

View Slide

Evolve Or Perish! Improving Communities The Apache Way

Evolve Or Perish! Improving Communities The Apache Way

Joan Touzet

More Decks by Joan Touzet

Other Decks in Technology

Featured

Transcript