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?
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.
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.
Completely agree.
Better yet introduce trial periods and reviews so that everyone understands that membership is not guaranteed and something to be respected/valued and help reduce feelings of self entitlement.
And as much as they are not special snowflakes this problem is not either. I mean if you let in candidates unfiltered into your workplace what exactly do you think will happen?
Be aware that many people are not very good at rating their own abilities or contributions and generally live in a self absorbed bubble which may have a highly variable relationship to the real world. (this can include the hirers/firers.)
Be warned that introducing any system of "hiring and firing" is VERY hard to get right (research says most people are terrible at it) and can be abused.
Also, just because someone is a great team member, it does not automatically follow that they will make great recruitment decisions.
Its tough.
This is just how the human race is. Deal with it or live in a cave, those are your choices.
PS: The cave thing was a joke...they will come find you regardless.
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.
Yeah, some number of that lower 80% or 50% have the ability to become a top performer. If you cut them off, you kill your training pool. Some percent are also contributing in smaller ways that allow your top performers to concentrate on the parts where they are top performers and let others muddle through the parts they don't like.
It's easy for the "elites" to talk down the regular people and dismiss their contributions, but don't let your shop turn into some sort of uber coder jock circle that's destined to implode.
Cheap storage VM.