Firing community members

No readers like this yet.
Javascript code close-up with neon graphic overlay

Photo by Jen Wike Huger

Welcome back folks, for the second post in my Six Degrees column. While I am delighted to be returning, you all kinda screwed me with my first column. The article, in which I mused about the ramifications of Ubuntu phones for open source, seemed to do rather well, subsequently setting entirely unrealistic expectations for the good people at Opensource.com. Thanks for reading it.

Well, it is time to come slamming back to reality, but as a reasonable middle-ground to get you all to read something again, I decided to pick a topic that is likely to raise a few eyebrows ("click bait?") and thus wedge a few angry emails into my INBOX.

Rewind

I have been in the business of building communities for about 16 years. When I first submerged myself in this murky pit of people, we were all secretly scared of the millennium, Ricky Martin was wooing us with "Livin' La Vida Loca," and open source was populated by odd people wearing t-shirts with ironed-on transfers of a cartoon penguin.

We were manually compiling kernels, manually installing boot-loaders, manually setting up PPP daemons, and generally doing a lot more work than we should have needed to do to achieve things that other (normal) people took for granted.

Subsequently, the kind of people who wanted to improve this open source platform were generally pretty technical. It wasn't uncommon to have to know C or C++ to get involved. Even writing documentation required you to know how to code in LaTex. Perl? Well, that was for n00bs.

Things changed. We were starting to see more non-technical people joining, and when I started at Canonical as the Ubuntu community manager, I set my core goal to make Ubuntu a community in which anyone could participate. Others did the same, and the open source world started diversifying in skills. We started seeing designers, artists, advocates, translators, writers, marketeers, and more joining up.

While lowering the bar was wonderful for getting more people involved, it ended up causing a bit of a problem.

Bring forth the opinions

As open source started booming, more people joined. Opinionated people. People who listened to the "we welcome everyone!" message and felt that their opinion could be their primary contribution. For some, they felt showing up at the gig gave them the right to dictate what the band played.

From a leadership perspective, this was a tough spot to be in. On one hand, you want to foster an open, welcoming, and empowered community. You want that diversity of skills, but you also want value and quality. Low-quality contributors don't bring much other than noise: they are a net drain on resources because other good contributors have to take time away to support them.

In addition to this, those entitled, special-snowflakes who felt they deserved to be listened to would invariably start whining on their blogs about what they considered to be poor decisions. This caused heat in a community, heat causes sweating, sweating causes irritability, and irritability causes more angry blog posts. Critical blog posts were not the problem; un-constructive, critical blog posts were the problem.

I have always stayed consistent on this topic: I believe all views and perspectives should be welcome if they are constructive and solutions-oriented. Feel free to rabidly disagree with me, but don't just come to me with complaints. Come with a desire to find solutions, and then we can work together.

The magic of open source is the exchange of ideas built on a foundation of talent and opportunity; we can truly action our ideas and make something happen. If we only bring the idea, but not the time and willingness to execute, the core essence of what makes open source beautiful is compromised.

Sadly, not everyone shared this viewpoint, and invariably got rather annoyed when I would call them on it. As such, many open source communities were in a position where they wanted to be open to everyone, but they didn't want to spend the political capital to tell some people that they were not welcome (or more subtly, not as interesting as other community members), either due to them not possessing the skills to bring value, or because their attitude sucked.

This creates a dangerous cycle and an inhibitor to innovation. The nature of innovation by definition means saying, “We want to do something different.” Invariably these folks who would sharpen their pitchforks were either against change or only open to change if it met their precise set of technical, ethical, and aesthetic requirements.

This caused conflict—enough so that in some cases people would get frustrated and leave. I saw many great people with good intentions and wonderful talents leave in the wake of similar disasters. I didn't blame them—it took a thick skin to navigate some of this. In fact, I wrote a short e-book called Dealing with Disrespect to share approaches to handling some of this.

Sadly, this wasn't isolated to just a few communities. Many, many, open source communities experienced the same challenges, and many of you reading this will have your own stories.

"This ain’t no soup kitchen"

One evening I was in a bar in Portland chatting to a guy who worked in business development for a large technology company. We were talking about this topic and he said, “When I deal with customers who behave like this, I fire them.”

“You fire them?" I queried, still trying to grok what he was talking about.

“Yup. Just because you offer a service, doesn't mean everyone gets to play. This ain’t no soup kitchen.”

This got me grinding over two questions. Firstly, is there an algorithm that defines great contributions, or at least a core collaborative work ethic that we should expect from participants? Secondly, is it even possible to politically fire community members, outside of obvious trolling and obscene behavior?

For the latter, I am not so sure. There are few cases where, outside of banning someone for racist/sexist/hateful conduct, someone has been asked to leave because they are too much noise and not enough signal. We did it once in Ubuntu, and it took a year of the community council going back and forth to eventually make a confident decision. It was the right thing to do—it took a steady hand and careful consideration.

The reason, I think, that we don't do this is that it feels weird. We live in such an environment of collaboration that blocking it would be like a stoner blocking Taco Bell. It also presents a potentially dangerous cultural shift. We don't want to kick them out because they challenge us, disagree with us, or seek to try something new. We have to get the balance right when considering such drastic action.

It is also an emotional drain. When you are weary from the bickering, kicking someone out will result in more bickering, so it is often easier to just deal with it and just accept it as part of life. Sadly, the same approach seems to ruin many marriages too.

Communication

I believe the solution for this piece (and a successful marriage) is communication. In many cases over the years, I have sat down and had some rather sensitive discussions with people where I have challenged them on their behavior, their social approach, or their attitude. In almost all cases they had no idea they were doing what they were doing, and when they did understand it, they were very open to improvement. In the earlier case that I mentioned with Ubuntu, the community council took a similar approach: mentoring, support, and guidance, but ultimately the noise prevailed, and thus did the ban-hammer.

As such, my thinking here is to be considerate, empathetic, and human in guiding these folks to success, but at some point if they are unwilling or unable to work within the community constructively, the right thing to do is to ask them to find somewhere else to participate and share their energy and talents.

This now leads us to the former of the two questions: Is there an algorithm for what makes a good collaborative community member? If there is, could we build software to detect great contributions (and potentially reward them), but likewise find people who don't cut the mustard?

Could a machine deal with the awkward scenario of booting someone out?

Again, I don't have any clear-cut answers here, though I have tried some experiments with mixed results.

A while back, I worked on a gamification system for Ubuntu called Ubuntu Accomplishments. The idea was simple: we identify a set of "good contributions,” such as filing a bug, creating a branch, organizing a local group, and more, and together with some friends we built a system that could detect those contributions and reward people with a trophy. We structured the map of tasks and trophies in a logical way: some trophies needed to be unlocked before others could be achieved, and we made sure we didn't reward people on quantity (e.g. filing a bug report for the first time is a great skill to reward because it is new, but filing 20 bug reports could be open to abuse).

We built the system to what I consider to be a prototype and had about 700 people start using it. It was interesting to see how people utilized it, and it definitely gave us a metric of where participation was happening and which people were most active. Where the experiment fell short is that it didn't get to the heart of what makes a great contributor.

For example, some people would achieve few trophies, but they participated outside the gamification system and achieved other things that we couldn't track in an automated way. In addition to this, some elements of great collaboration—mentoring, support, guidance, recommendations for great books, hearing people's ideas, providing input, etc.—went untracked. We were merely tracking (some) execution, not the elegance of all execution.

So, we tried other methods. I asked a guy on my team to process the data in Launchpad to pull out developer trends: When did developers participate? What external forces prevented them from participating? Which events acted as a spike to enthuse participation?

Again though, this data proved interesting but inconclusive, and it was nowhere near close to automating the process of rewarding great contributors and ejecting the noise.

Conclusions

The conclusion I have come to is that determining a great contribution is very much a human skill, one that can be augmented by, but not effectively replaced by, data. This human skill differs between us too: we all see greatness (or even mediocrity) in different ways. I know some people who would consider very frank critical feedback to be the sign of a dissident who needs to be silenced. I know others who cherish this feedback, act on it, and harness it.

A part of me does still have a belief, though, that we could automate and mentor great communities. We know there are certain things that when well executed can result in success. Regular cadence, clear planning, simple tooling, regular meetings, accountability, and regular releases all help to make us effective. If we could build a system that provides tools as well as guidance, we could help people to be successful in a scalable way. It would not, though, give us the full picture of what makes community so magical: we need a human for that.

Now, while I don't believe we can automate the firing of noisy, un-constructive, and unproductive community members, I do believe that this bitter pill is something we do need to swallow. If, through an empathetic, mentored, and considerate approach, we identify that someone is just noise, is bringing down the motivation of the community, and is an inhibitor to innovation, it is our responsibility as leaders to remove them. If we don't, we compromise the very fabric of what makes open source incredible: human relationships connected by a core mission and ethos, and underlined by the spirit and acknowledgement of doing.

As you can probably tell, this is a story that doesn't have a conclusion. There is still lots of thinking to be done, and I would love to hear your thoughts and opinions in the comments. Thanks for reading!

Six
Degrees

This article is part of Jono Bacon's Six Degrees column, where he shares his thoughts and perspectives on culture, communities, and trends in open source.

User profile image.
Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, developer workflow, and other services. He also previously served as director of community at GitHub, Canonical, XPRIZE, OpenAdvantage, and consulted and advised a range of organizations.

21 Comments

I don't understand what you mean by "remove them". Linus Torvalds occasionally bans people from making any more contributions to the kernel because their contributions break more than they fix. Is that what you mean?

You emphasis "noisy". Does that mean that the people who annoy you talk a lot and produce nothing useful thus wasting other people's time?

---------------------------
Steve Stites

hmmm.... jono, you've asked some very interesting questions. a few things spring to mind.

the first is that there are no strategic managers keeping an eye on the software libre community. canonical: interested in canonical's business and no more. redhat: interested in redhat's business and no more. linux kernel devs: interested in developing the linux kernel and no more. distro maintainers: interested in maintaining their distro and no more. upstream package developers: interested in maintaining their package... and no more. this makes it *incredibly hard* to effect critical strategic actions even if the entire community is at risk from certain inexorable and really bad compound (herd-style) decisions. in many ways the BSD communities are far more robust and much better off for being smaller.

secondly: canonical made a severe mistake in forking the entire debian repository, and is living by the consequences. they *were* told - right back when the project began in oxford, around 2004/5 or so: "create an additional repo similar to deb-multimedia" and they *were* told why, but they chose to ignore that. so you now have a very stressed-out community with the pressures of 6-month forced releases causing things like the python 2.5 -> python 2.6 fiasco where you couldn't apt-get upgrade, as python 2.5 would be removed before python 2.6 was actually installed. little mistakes like that..

thirdly: despite (1) and (2) it is critical to have a clear goal, and to ensure that everyone is reminded of it, repeatedly (even if it's annoying to do so), and for any contributions *including* discussions to be measured against whether they "contribute to" or whether they "aggravate" that goal.

fourthly: for persistent community members who won't take the hint, i have found that publicly repeating the same clear description of why what they are doing is aggravating rather than contributing to the goal, helps to silence them. *however* - this *only really works on forums and mailing lists*. if you have however built an entire community based around "blogs", then you deserve everything that you get - the egos, the soap-boxing, the shouting, the time wasted and much more. remember what jesus said (and if you don't like that it was jesus, then just think about the advice he gave rather than that it was jesus ok?) - he said if someone is doing something wrong, first tell them privately. if they don't listen, tell their friends and family. if they *then* don't listen, tell absolutely everyone. in that context, blogs are *the* worst possible fit with software libre development practices i can possibly imagine, as they cause a cascading feedback of negativity based on self-defending, self-serving egoism, but worst of all they allow people to break the rules on private then friends and ONLY then public criticism. why is this? well... you try finding people's email addresses on blogs, and let me know if you have any success.

so to summarise,, then: canonical has, by setting the rule of "being open to anyone", taken on a shit-storm entirely of its own making, by endeavouring to "modernise" tried-and-tested development practices by permitting people to "contribute" through "modern" social media platforms and "modern" communication practices - ones which we *know* have been molded to suit people with an attention span of a few seconds.

i was shocked a couple of years back when Mozilla B2G invited people to contribute to a security audit, and some ar*e-f***wit top-posted a 3-line single sentence comment to a comprehensive report that i wrote... from a f*****g iphone. my follow-up comments asking why that person was even *permitted* anything more than read access to the security lists were not well received.

so in short: the attention spans of people who are good at developing code are long, they are good communicators who work hard to keep a model of what other people are thinking, and as such they are good team members. and you opened the doors to "everyone", and found that it's causing huge problems.

well... as one friend in debian told me: he said he's glad that ubuntu exists, because it keeps the people who like ubuntu away from the debian mailing lists.

so i apologise that this might not be what you were expecting - for someone to point out that you are living by the consequences of your choices. i hope that above i have given you some insights that will help.

In reply to by stites

First let me say that I wholeheartedly agree with your criticisms of the idea of lowering the bar for getting started by employing social media techiniques. I have a background in translations and as such feel that launchpad translations if probably the single worst thing that ever happened for people that wish to deliver quality translations. An yes, I, along with the rest of the community, has delivered constructive feedback more than once.

However, for the rest of your post, you seem to center a lot of your critique around the notions that this is a Canonical/Ubuntu only problem. Surely, you cannot mean, that you have not encountered this problem outside if Canonical-controlled projects of projects that use Canonical tools. I know I centainly have.

In reply to by Luke Kenneth C… (not verified)

Part of your explanation seems a little blurred.

"If we only bring the idea, but not the time and willingness to execute, the core essence of what makes open source beautiful is compromised."

You shouldn't need to have the expertise to implement something if you can help discuss how to implement it.

Furthermore, there's no requirement for an OSS project to accept every patch or pull request - just because someone has the time to build a code change doesn't mean it should be included if it's the wrong way of doing the change. It becomes really important for those with commit access to focus on good solutions, not just the volume of code available. Ultimately a "do-ocracy" is going to run into problems unless there's some leadership directing the efforts, and saying "no" when appropriate.

I think you misunderstand my point.

I am not suggesting we *require* community members to write code, or that we always accept code from community members. What I am suggesting is that there is a social contract in a good community between participation and constructively helping the overall goals.

If someone wants to just help discuss a solution, and they do it in an informed, productive, and constructive way, then brilliant! What I think is less brilliant are people who just want to rant at the community about their opinions.

In reply to by Damien McKenna (not verified)

This is a double sided sword. Some of the low quality people with time and expernence develop into higher quality personal.

Now the interesting point is not everyone has the same skill set. Like people who are able to perform bug triage may not be able to write a single line of code. So part of this is organisational structure. Also not all coders have great people skills.

""Linus Torvalds occasionally bans people from making any more contributions to the kernel because their contributions break more than they fix. Is that what you mean?""

This is not exactly right. Linus bans people from making direct submissions. When banned from direct you are now required to submit to one of the lower maintainers. So you are punished for poor code.

This is where "This ain’t no soup kitchen" does not exactly apply. There is no requirement to offer just 1 forum or just 1 mailing list. It can be supprising by shoving all the worst behaving in one area can magically cause improvement. Sometimes 8 heads are better than one. Why one of them alone was not able to express clearly what the issue was.

And how about the case when the leadership of a FOSS community team is going the wrong way, members of the team get public with their legit criticism and are fired?

I personally was "fired" myself from a community and to this day I still believe I was right and the team leader was wrong. I got no help from other leaders in the project, since they are employees of the same company.

The net result, I found a new life outside contributing to FOSS projects and I am now a mere user.

A case of open-source projects where the bulk of the team is from the same company is actually *not* a case of community-driven project. I currently am the de-facto technical lead for an open source project, moved from the company where it was originally developped. One member of the development team has a really problematic atittude, something that has been acknowledged to me in private. However, office politics kick in and this person is virtually non-"fireable" from the project because he is non-fireable from the company.

In reply to by Nicu Buculei

I'll be honest some of the ideas Jono has been letting out since he left Canonical seems to show why the Ubuntu Community was struggling. I do not think despite Jono's 16 years of building communities that he actually gets the communities that were growing around him.

Case an point look at Ubuntu today much more healthy now that he has departed and when he was there he basically made a profession ridiculing people who disagreed with him or his employer.

You may well be right. I am not suggesting I know everything about this. I do think I have a reasonable track record, but I still have *much* to learn.

Is Ubuntu better today than it was while I was there? Who knows? There are a multitude of metrics assessing this, and to accurately assess the impact I had there you would need to know all the things I did (or didn't) do while at Canonical. Given that you don't know those things yet are willing to jump to this conclusion, I would go so far as to suggest you don't like me, as opposed to making an objective assessment.

This is further illustrated by your view that I made a profession ridiculing people. This is entirely untrue: what I did though was stand up to idiotic comments such as this.

In reply to by JohnNs (not verified)

This is all very instructive (article and comments). First, I am most appreciative of all the effort that has gone into the FOSS movement and I enjoy the fruits of that effort. I am not a complainer in that regard. I live by the motto, if it's broken, learn how to fix it or if not, work around it. I am not privy to the inner workings of the development community but I would think it would only be appropriate that not any Tom, Dick or Harriette should be able to throw their two cents worth in to a discussion. Contributing is a privilege not a right. Of course, that doesn't mean one is immune to the politics and egos that make up the contributing group. If everything was simply a technical matter there shouldn't be much discussion other than the trade offs involved. But then human beings are involved so it ceases to be a technical matter. Despite the countless books, seminars and academic papers on people and management and all that sort of stuff, no one has yet figured out what really works. I suspect there is no small amount of luck involved in having the right people at the right time and that is an indeterminate variable if there ever was one.

I always say not all business is good business. So maybe not all contribution is good contribution even though it is contribution. Well intentioned people can differ but if one is to achieve any sort of harmony there must be a line which when crossed is not worth the disruption no matter what the contribution is. Sometimes such lines lead to a form of elitism or clique forming and that is unfortunate. Such inbreeding however usually results in an eventual diminution of the project. The great thing about FOSS however is that there is usually a group that knows how to avoid that pitfall and move forward through forking.

Now when a company primarily controls a project, it's a bit of a different story I'm sure but I can't imagine that such a company would think their control is absolute or perpetual. One need only examine the tech landscape in a rear view mirror to see the wreckage of those who may have held such beliefs.

Meanwhile, many thanks to all the contributors out there who have made computing so much better over the decades. It wouldn't have happened without you.

My main gripe with what you said is this statement: "I believe all views and perspectives should be welcome if they are constructive and solutions-oriented. Feel free to rabidly disagree with me, but don't just come to me with complaints. Come with a desire to find solutions, and then we can work together."

Most times I see this attitude (and since I don't know you, lets assume you aren't like this) it boils down to "if you don't like how we did X, feel free to write your own solution." This is a sentiment that hurts communities more than anything. All that does is say that the community is really only for developers, everyone else can sod off. How do you build an open community with attitudes that exclude anyone who is not a developer?

In my opinion, the biggest hurdle to open source communities isn't the noise of the unhelpful, its the inability or unwillingness of main contributors who don't want to deal with them. How many real contributors are being turned away while they are noobs? How many potential contributors are leaving because of the way they see others being treated?

I don't know how open source works, but the process has produced the best solutions in the computing business, so like the comment about Democracy and Free Markets, it is better than the other alternatives, congratulations and keep trying to improve.

Fire (or kill) them only when the mob demands it.

Yep, I got lazy and clicked the link in unsolicited e-mail, thanks a lot, when am I going to learn to google the link instead of taking the bait?

I agree. Blogs and lists contain at least 95% of noise (useless and meaningless opinions quite often based on poor understanding or low level expertize of the matter), therefore I almost never participate nor read them.

My suggestion: In the scientific community there is the peer review system for publishing articles in the scientific journals. In a way it is a burden for the community, but it also reduces the noise. If one considers that also an opinion is a publication, one could create restrained discussion lists and consider participation granted only upon approval by several peer reviewers/editors.

Noise - un-constructive and unproductive people are present in all areas of life.
"Communication" indeed is the right direction to go. One aspect here which I would like to highlight is - setting the right expectations. Once this is done, it has to be reiterated often.

As soon as we see the first signs of cultural mismatch, it is better to communicate and give constructive feedback mentioning the definite expected results rather than procrastinate the discussion. As it is said - one rotten apple spoils the whole basket, it is only wise to protect the greater community by compromising on the one that doesn't fit in.

Jono, insightful article.

So if I am reading this right, projects are going to gather people of different opinions and different expectations and sometimes that includes people that are more detrimental to the project than beneficial.

Unfortunately with projects you don't have the same hierarchy to address the situation to a "boss" as a reasonably sized company. It is generally a very flat hierarchy except in the larger and more structure projects. But then there can be arguments of it being too controlling.

One attribute that helps is having a clear goal to focus on.

Questions can be framed around "how does this help the goal?" and depending on how well defined the goal is, can end many arguments before they start.

Smaller projects communication is more personal, while larger projects can have things fester out of sight. Focused goals provides a means for people to self-regulate.

Another part is defining clear expectations.

Expectations provides a focus and goal for the ego. It allows the individual to keep their thoughts in context of the situation. The more expectations lines up with reality the less stress there is involved for the individual. Expectations can also be called the "culture" of the group.

A Machiavellian corporate-owned project is going to have a very different flavor than a grassroots laid back group. Going into either group with the opposite expectations is going to cause friction.

I laughed when I saw training for the Boy Scouts on the subject of "removing unwanted volunteers" but when I thought of it, it makes perfect sense. People don't know how to remove a volunteer or how to counteract the "but we are only volunteers" counter-point.

All this sounds like business/entrepreneur/non-profit management. Are there resources available for the project leaders or potential leaders, focused on open source and volunteer groups?

Wah mantep nih diskusinya, tapi intinya sih ga usah pada ribut, bertengakr apalagi sampe adu fisik. Dewasalah kalian semua...wkwkwkwkwkw

As someone who often struggled in both finding a productive place in the Ubuntu community and with fundamental disagreements with how Canonical conducted it's affairs within the community; I see both sides of your argument here.

When it came to day to day affairs the CoC and community management style worked quite well. But it was those far-reaching trends, the big vision stuff. That was often so badly botched that from the outside it seemed like Canonical set the tone of the community management team to deliberately omit them.

But *shrug* we can't do anything about that now. Ubuntu looks like it's on pause waiting for Microsoft to catch up and the Free Desktop space is wide open with it's wild west experimentation and lack of general focus. It's not great, but it's what it is.

I'm not sure this is fundamentally different from how you deal with toxic people on your (hired) team. Occasionally, you will hire people who are both smart and skilled, but turn out to be toxic to your organization.

This needs to be handled as quickly as possible.

Depending on the nature of their behaviour, you might try to have a serious conversation with them to get them to behave more appropriately or maybe you need to just let them go.

Toxic behaviour is no less toxic in an open community than it is in a corporation and it needs to be dealt with.

It depends on the nature of your community how you can deal with it. A web forum can simply ban a problematic user. Everyone else can see that the person is no longer around and their posts may show that they've been banned.

Something like Ubuntu is much more problematic. There are mailing lists, bug trackers, forums, etc. Do you ban all activity or only some?

I think it's hard to provide a recipe for *how* to deal with it. It's fairly clear to me, though, *when* to deal with it: As early as possible. It's called "toxic" for a reason. It's extremely detrimental for your organization as a whole.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.