Slashdot Mirror
On Firing Open Source Community Members
An anonymous reader writes: 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. So what's the best way to foster a welcoming environment while still being able to remove the destructive elements?
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. So what's the best way to foster a welcoming environment while still being able to remove the destructive elements?
Would you rather take a bullet to the head or three to the gut. Fire them as quick as possible, then show them the door.
You're not fooling anyone, Lennart.
I was involved in a particular Open Source project for a long time (between five and ten years). I was an early developer on the project, and at least for a while, one of the leading contributors. Over time my contributions lessened as I had to also make a living, but I was still active in the project and its community.
The leadership got taken over by one developer who was able to work full-time on the project. This developer was overbearing and a subscriber to the idea that being nasty to people made you "as smart as Linus." This developer also ignored input on direction for the project, as it was now "his."
I served as a gadfly, trying to correct the technical issues, and trying to create a more friendly environment for new programmers to participate. Eventually, though, I was "fired" from the project because I was a "non-contributing whiner."
It's disappointing to see how much of my work was trashed, and how the project went from being something interesting to one of the also-rans. Still, it primarily highlighted the biggest problem of software: people suck.
Maybe have a slashdot-like karma system, where bad comments on the forums are modded down, and you build up good karma.
Seems like bad people would soon ensure the community would "fire" them.
--PM
Many would think if this term referring to folk who write code. This is OK for me. My problem though, would be how to address technically competent people who make nonsensical decisions.
I remember politely fighting GNOME folks over design decisions they took around the `Open File` dialog box, only to be slammed with what was referred to as "Won't Fix" because it is what they called a "Deliberate Design Decision." No wonder GNOME suffered soon after.
I know that many folks in the FOSS community feel more comfortable behind a keyboard than they do in front of others, but none of us live in a vacuum away from others. As such, these are golden opportunities to assert the type of leadership and expand skills necessary for personal as well as professional growth.
More fundamentally, every project needs to have clearly defined goals as to what they want to accomplish. The schedule of such projects, by the generally voluntary nature of FOSS contribution, may slip, but the cohesion required to achieve these project milestones is only possible in the presence of relatively strong leadership. Strong leadership should also recognize the skill inventory available to the project on a per-contributor basis and encourage those with particular strengths to be used in needed areas modulo personal goals (e.g. growth in coding skills, UI/UX, etc.). Leadership also needs to set down ground rules like mutual respect and positive communication style.
Therefore, project leaders need to manage the relationships between contributors, recognize political and personal differences, and reconcile them reasonably but quickly for the betterment of the project. If that includes terminating the relationship of one or more contributors to said project, then it needs to be done. But before all that happens, project leadership has to set the base of the building correctly before building subsequent floors, as it were.
There's an old saying that says "the fish rots from the head down" and it applies here too: if things are getting out of hand with a project, deal with it but make sure all of the rules were set and the relevant parameters understood prior to drastic action such as terminating a relationship.
If you want a welcoming, inclusive community, you don't get to decide certain elements don't belong and remove them.
If you want to do that, you don't really want a welcoming, inclusive community, what you want is a community of elite according to a set of standards.
So, decide what it is you're choice will be and focus in on it, then everything will become obvious.
-1 Uncomfortable Truth
What makes things difficult, is that the people who are wrong don't know they're wrong.
So you have 2 people who think differently and thinking the other is wrong. Which one is? Who knows! Its easy in hindsight of course.
Why are you blaming people who responded to your invitation for anyone to join? You can't advertise an open bar and then be surprised when a few angry alcoholics show up.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
Commits count.
Turning up to a gig doesn't give you the right to dictate what the band plays. But if you turn up to the REHEARSALS for the gig armed with recordings and knowledge of the band's previous performances and sheet music containing instructions on how to correctly play something that the band had previously been fucking up without knowing it, then there's a chance that the squiggles and dots you've written might be performed at the next gig.
If the band chooses to not perform your squiggles and dots then just leave and perform them yourself.
In fairness - if you're actually the one(s) doing much of the work to create something being used by millions of people with minimal compensation - you *are* a pretty special snowflake. *Especially* compared to the asshat who contributes nothing but vitriolic, non-constructive commentary.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
It's just that I object folks who would be good community contributors being lured into being unpaid employees instead.
The GNU Radio project was funded in part by a United States intelligence agency. They paid good money and the result is under GPL. What's not to like?
Bruce Perens.
What makes things difficult, is that the people who are wrong don't know they're wrong.
No, that's not the difficult part. That's just a given.
The difficult part is trying to control something you have no control over.
Once you're willing to ignore that "destructive" blogger. And once you're willing to accept that you won't be able to change that person's mind, everything will be infinitely easier for you.
So what's the best way to foster a welcoming environment while still being able to remove the destructive elements?
Benevolent Dictatorship.
Make it clear from the start to everyone on the project that while you're going to remain hands off as much as possible and let everyone do their thing, you're still the ultimate authority and you won't hesitate to step in and start cracking heads if people start causing drama and/or forget how to be adults and let their disagreements get out of hand.
The C4.1 contribution protocol I eventually wrote for ZeroMQ solved this problem. You have to develop rules that catch bad actors (yet not learners) and then educate project managers on how to fire people when needed.
Our rules for instance ask that you solve one problem with one patch, that you never break existing stable APIs, that you respect style guidelines, and so on. When people break these rules we give them several chances to improve their behavior. If they persist in doing it wrong, we remove them.
Turns out, when the rules are very explicit and teach people how to make good patches, then it's very rare we have to fire people.
The rules are at http://rfc.zeromq.org/spec:22
My blog
When no one wants you to work for free, it's time to recognize that you have some serious personality and skillset defects.
I've never worked on an open source project other than my own, but I've spent many a long hour with the "negative contributors" in the business world since around '87. Unfortunately, we never could get rid of those people on the project teams because they were always managers and "key business users" (i.e. The worst employee in a customer department that they wanted to shuffle off onto someone else, such as working on another department's project instead of in their own.)
The thing is, sometimes those complaining users are a goldmine of information who just have a tough time explaining themselves. One of the shop floor managers at my second "permanent" job with Northern Telecom was a real hard case. He'd pin you with a barrage of questions, berate you for not meeting his needs, and was just generally a real asshole to most of the people he dealt with. But if you were able to answer his questions for a couple weeks and could take care of a couple of the backlogged items on his "need" list, he became an absolute joy to work with.
You see, the man was just jaded by decades of working with "elite" programmers who wouldn't listen to him about how the shop floor should be running. For years and years and years, the engineers and programmers had done what they thought was right for systems design instead of listening to the people who would be using it. It turns out he had tremendous insight into the way his people were actually doing their work, and how the computer systems could fit into that workflow instead of being a hindrance.
I've also dealt with people who were just cranky deadweight, contributing nothing of value to any of the projects they were on. Alas, they couldn't be fired without going through channels. Only once did I manage to get someone who was so negative terminated by a company. They reported to me, and were so poisonous to the department that productivity improved 20% after they left -- without hiring a replacement. It turns out they spent so much time complaining in meetings and during "cube visits" that they were slowing everybody in the department down, as well as stressing everyone out with their negativity.
So, yes, there are people who should be fired -- even if they aren't getting paid in the first place. But before you write someone off as being a belligerent know-nothing, take the time to talk to them and learn if their concerns and issues are legitimate. You could be missing out on some valuable opportunities by writing off someone with poor communication skills as being "just an asshole."
I do not fail; I succeed at finding out what does not work.
One of the things I learned early on as a tweenager within the FOSS was that if you have a good idea and can communicate well & civilly, nobody actually seems to care terribly much if you possibly are a dog that somehow learned how to type. You don't necessarily have to be good at coding, if what you bring to the table is a good ability to understand the basics and play a living 'rubber duck'--basic sanity checks, to see if what the coders are attempting to do makes sense to somebody who, if nothing else, has at least managed to sleep in the past week. (This isn't meant to be insulting: I've been on the coding side as well: Sometimes I will grab random lusers for the job, and I've learned everybody's happier sometimes when you have a volunteer handy. Less chasing people down in hallways, cornering them in bathrooms, and...I'd certainly have answered a few times the question "Did you sleep in the last week?" with "...Does passing out count?")
I honestly don't really trust communities that say they're 'welcoming' to be so, in my experience, though. What I want is one which gives me nice, clear, well-defined rules: I can deal with being told that I need to contribute things to the group that they value in order to gain status, and live with the baseline rule that if somebody is kicked out, it will be for violating clearly-defined objective rules ("Fails to brownnose correct people" should never be on the list!) and we will all know this. I'm even okay with it if leniency can be earned: If you somehow can bash your head on a keyboard and still generate code that works perfectly, I can put up with a lot of crazy--and I know how to ignore somebody.
Really, I think a basic rule of "The community decides the value of your contribution, not you" isn't unwelcoming, as long as it's clearly and openly stated from the start.
This thread is evidence of the problem: Many commenters here post one-sided, one-size-fits-all solutions in which they believe. But, flexibility is the hallmark of successful people. Your ability to see each contributors' strengths and weaknesses, and help them contribute from strength and evolve from their weaknesses is what successful managers and executives do. The rest are just "wannabes."