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.
We can look to the Starks and the Torvalds of this world for the solution to this problem.
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
In the sight of the newsgroup, in the name of software stability and maintainability, I Linus Torvalds, creator and maintainer of linux, creator of git, sentence you to die. You will speak no final word.
I can't say I'm happy about what's happened to Debian. Having Ubuntu as a commercial derivative really has been the kiss of death for it, not that there were not other problems. It strikes me that the kernel team has done better for its lack of a constitution and elections, and Linus' ability to tell someone to screw off. I even got to tell him to screw off when he was dumping on 'Tridge over Bitkeeper. Somehow, that stuff works.
IMO, don't create a happy inclusive project team full of respect for each other. Hand-pick the geniuses and let them fight. You get better code in the end.
This actually has something to do with why so many people hate Systemd. It turns out that Systemd is professional-quality work done by competent salaried engineers. Our problem with it is that we're used to beautiful code made by geniuses. Going all of the way back to DMR.
Bruce Perens.
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
While this might not be the most subtle way of handling things, it could be quite effective to repeat the same question every time they are critical. "What have you contributed?"
Just ignore their arguments and ask them what they have contributed. Over and over and over again.
They will either go away, stop posting so much, contribute, or perhaps realize that the whole point of the movement is to contribute actual code and functionality.
On the Internet, ignore them. In real life, talk about them every time they open their mouth and complain. "Oh there goes Joe again, whining and NOT CONTRIBUTING." Then return to your regularly scheduled activities of doing things.
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.
I've never heard "SJW" used before of someone engaging in actual combat! I suspect someone was being ironic. The term generally means someone who's idea of activism exclusively involves social media - a variant of "keyboard warrior" - for self-described "social justice" causes.
Socialism: a lie told by totalitarians and believed by fools.
Actually, it does make them incompetent. A competent leader would look at your point of view, recognize that your points have merit (assuming they do), and try to find a compromise design that meets your needs without compromising too much on their goals. Only an incompetent leader is intransigent and is unwilling to adapt his or her views when presented with new information that contradicts them.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
The way I see it, it's often the programmers who are the problem. They think they're the special snowflakes and their way of seeing things is the one and only way of doing things and everybody else got it wrong.
The best example I can think of is GIMP. Every other pixel-based editor on the planet works similarly enough that there's almost no learning curve. If you know one, you can work in the others. But GIMP? Of course not, GIMP is a special snowflake and the users are the problem.
Get free satoshi (Bitcoin) and Dogecoins
There's a guy I know. Call him Charlie. Not his real name. In fact, it's more than one guy. I'm sure you know many Charlies, too.
Charlie is a core contributor to half a dozen high profile open source projects. Not that he actually, contributes anything useful. But he hangs out on the irc channel and did just enough (which probably involved closing tickets as "will not fix") to get invited as a core team member. Based on his name, other projects invite him as a core contributor.
I run an open source project. It was featured somewhere (not slashdot!) and had a hype boost. Almost instantly, I get an email from Charlie asking if he can be a core team member. His only contribution was sending that email. Not even starring it on github. So I told him to fuck off.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
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."
Coming from the world of proprietary software, I was slow to accept open source. Given time though I became a fan of the GNU universe. From the start though I found Richard hard to take. In time Linux became strong enough to compete with OpenBSD and there the contest was between the egos of those two. This free enterprise-like competitive environment, both in systems and applications has resulted in a very rich choice of software available for us to use, free or otherwise. As far as the dynamics within development organizations, this is similar to the climate in early silicon valley where people with a better idea (or so they thought) would strike out on their own (we would call it forking a project). Some people lack social skills, or the balance between computing skills and social skills. Just because someone had a great idea and the computing skills to create a widely used program, doesn't mean they can exercise shared dominion over the project when it grows up. John draper is a good example of this. Surely a man with moments of genius, but in my opinion, no-one who should ever be managing others. Two factors seem important to me in the growth of open source projects. One is the emotional chemistry that bonds people together such that they are happy to donate time towards the project's goals. The other is the financial aspect, because some projects have financial needs to support healthy growth, and people with money have to relate to the project leaders if money can be expected to flow. There are people that wear suits and have technical skills, and they are very valuable to open source projects as well.