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!
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.
21 Comments