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.
...being able to take and respond to criticism in a constructive way and justifying your design decisions with logical, well thought out reasons?
It takes one supremely special snowflake to believe they should be able to silence criticism from contributors and the community at large.
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.
Yes, Lennart Poettering should have been fired a long, long time ago. See what playing nice gets us? He's paid by Microsoft and is practically destroying the entire Linux community. Oh, and he also writes useless code and comes up with useless project which don't do anything new and don't work very well.
Don't the users have valuable opinions too?
Keep all of the idiots that want to work for a millionare for nothing. Fire the others.
Anyone with sense has by now joined a non-profit project.
Bruce Perens.
First, don't resort to name-calling. "Special Snowflakes" is name calling.
Set up a leadership structure. Stick to it. If it involves elections, include a nominating committee that decides who can run for leadership roles.
This is how it's done in grownup circles. The failure to do it doomed Occupy Wall Street from the get-go and has allowed many other movements to be hijacked over the years.
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.
In fact, it never works. If some douche tells me "nope ur wrong lol" and that's it, i dont give a damn what his name is, i'd ask for some proper explanation, or even some half assed one, because if you start getting a-ok with appeals to authority, then it will never stop and you will slowly but inexorably turn into some sheep or zombie doing and thinking because dear leader told you so, and that's ok, because that's what Leader thinks and if he says so he must be right.
This is the same thing that has tone deaf twits showing up for American Idol, convinced by their moms that they could be stars.
The phony self esteem syndrome starts very early these days, and is made monumentally worse by PC-infested public schools. It's become so unfashionable to simply tell people that they're not the geniuses they think they are, and so impossible to avoid parental wrath when a kid is correctly identified as merely average (or, unthinkably, less than average), that we're now manufacturing the whiners mentioned by TFA as an entire generation.
Wondering how to deal with it in the context of FOSS projects completely misses the point. Scratching around at the symptoms in every venue in which they manifest themselves is pointless. This is a deep-seated cultural problem created and exacerbated by both aging and nouveau hippies in the education and social/gov circles.
Don't disappoint your bird dog. Go to the range.
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.
how to address technically competent people who make nonsensical decisions.
for people who are completely hardened and unwilling to even consider the possibility that they are wrong, there is nothing you can do besides fork the code and go on. however, people may not be hardened like you think so in the case of UI choices, a usability study could be performed. it will require significant effort but it may change some minds. the question you must then contend with is if it's easier to fork or is it worth the effort to run a study. the windows 10 preview was effectively a study on how usable their UI was.
Anons need not reply. Questions end with a question mark.
This article can be summed up as "a lot of nerds need to grow spines".
If someone's primary contribution to a project is shit and noise, then get rid of them. And then get rid of anyone who whines about it, too.
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.
We invented something to fix this problem you speak of. It's called Science.
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.
.... looking into the mirror...
Perl Programmer for hire
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.
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.
You are right, sometimes decisions *do* need to be made to undo past fails. I think what the parent is suggesting is that these revisions of our current UIs be done with our UI history lessons front of mind.
We've known how to make a fairly decent UI for a while now, even Win7 is fairly intuitive (for varying definitions of 'intuitive'). Going back to Win '95-era UIs or doggedly pursuing a course of action because we've always done it that way is, as you say, not a solution but neither is it what was being suggested if I understand correctly.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
Just reading the question, there is no possible way that the anonymous person asking the question is unbiased. The question is full of insults. As such there's not a good answer to give because the problem may lie with the leadership.
Once someone starts insulting the coworkers it's really hard to be objective about their opinions. We're hearing only one side of the story and that side is already dysfunctional. I sense that there is a bigger problem than just one problem volunteer.
Maybe that's an open source thing though, where the "leadership" is not necessarily partaking in management or leadership training, even something as simple as a lunchtime seminar given by HR. Though this training does happen with many volunteer charitable organizations. Also in open source very often the "leadership" have a very strong sense of ownership with lots of invested emotions; ie, it started as their personal project perhaps.
Making changes to a design may be justified, but it is the responsibility of those who want to change the design to justify those changes by showing how it makes things easier for the common use case without making the uncommon use cases impossible. If the designer can't do that, then either the design change needs to be rethought or it needs to be a user preference.
Either way, if you're going against established norms, and if there were good, solid reasons for those norms, you'd better have a darn good justification for going against convention, because probably 99.9% of the time, when UI designers do so, they're making a serious mistake. To use an architecture example, the Centre Pompidou is quite possibly the ugliest building in existence. They went against the established norms, and they got away with it because it's an art gallery, and a part of what art galleries do is to challenge those norms. But try to design a law firm's headquarters that way, and you'll be asked to take a long walk off a short pier.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Fear leads to anger. Anger leads to hate. Hate leads to suffering
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.
...anything in the comment you replied to??? Apparently not.
So you put a minimalist and a maximalist together, one wants to remove pretty much every button, option and checkbox to go with "sane defaults" that'll work for 90% of the people 90% of the time. The other wants to give you a zillion controls to cover 99.99% of the people 99.99% of the time but it'll take a rocket scientist to tune every detail and corner case. Both directions have merit, but you can be sure at least one of them will be unhappy and call you a moron. Not to mention if you're known to compromise, people start taking absurd positions so the compromise is roughly where they wanted to end up. There's very often not one solution to make everybody happy.
Live today, because you never know what tomorrow brings
For HCI, this usually isn't difficult. There is a huge body of research that can be cited. Some of it changes. For example, we used to think that cancel buttons should go on the left and okay buttons on the right in left-to-right reading order countries, because the reading order influences how people perceive the direction that forward and backward buttons go. More recent research has shown that this doesn't depend on reading order: people perceive left as back and right as forward whatever their reading order. GNOME and Windows are particularly bizarre in this respect, putting okay on the left, cancel on the right, but having forward on the right and back on the left - they're not even consistent within the same dialog box!
I am TheRaven on Soylent News
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
He who would do battle with the many-headed hydra of human nature must pay a world of pain & his family must pay it along with him! & only as you gasp your dying breath shall you understand, your life amounted to no more than one drop in a limitless ocean!
Yet what is any ocean but a multitude of drops?
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.
> 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.
don't appear to be easy in hindsight either because gnome 3 still stand by all the bad choices users complained back then....
also I'm sure there were some hundreds of people saying that 4 were wrong...
When two theories are available and both are compatible with the facts, then there are no other criteria to prefer one over the other except the intuition of the researcher. So one can understand why intelligent scientists, cognizant both of theories and of facts, can still be passionate adherents of opposing theories.
- Albert Einstein
In short, one has to provide reasons why their way is better, and many are not interested in doing that.
I come here for the love
I remember politely fighting GNOME folks over design decisions they took around the `Open File` dialog box
Ah yes: GNOME because Motif is just too darn good. It's like they're on this perverse quest to prove it's possible to have a worse UI than an ancient, no longer updated and long obsolete system which was arguably not that great in the first place.
At some point along the way, they removed the ability to filter the contents of that box with wildcards. That's lovely and so if you need to pick out a file from a large directory, there's a lot of scrolling carefully by hand to find it.
Brilliant!
Oh they've also decided that $PWD is evil and if you start a program from project_directory_foo/ then CLEARLY you want the file-open dialog box to default to project_directory_bar becase that's where you were last.
Fantastic! Who needs the concept of current working directory? It's not like it's been a mainstay of operating systems from the 60s.
SJW n. One who posts facts.
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."
In Team management, a team is more productive with a devils advocate that challenges and pushes others. Linus holds the devils advocate position for Linux as he constantly challenges and even causes issues with others.
The problem of being a Devil's Advocate is that they are seen as "Obstructionists, nay Sayers, anti-anything, slowdown members, etc" and when given a choice are the first voted out of a team. When the Devil's Advocate (or Angel member as we try and name them) are gone, the team starts to lose focus and goes the effectiveness goes down.
This is management 101 training. The problem with any organization including FREE is that there has to be a strong discernment between the devils advocate and the complete slug. This is a hard thing to do and I have seen many projects kick the backbones off because they were "slowing the project down" and the project then gets worse, not better.
I can program myself out of a Hello World Contest!!
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.
every human project follows the same path; first, a few committed brilliant individuals who share a common vision and work together well to achieve it. then, people get attracted who aren't quite as 100% tuned in, and things need to be managed a bit. then, people get attracted who just see something's happening and want to be attached to it, but not necessarily are any kind of positive contribution. finally, the idiots, crazies, psychopaths and criminals make their contributions. the history of every human endeavor; any given religion, country, charity, company, kid's playgroup, you name it.
Star Trek transporters are just 3d printers.
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.
at some point, it's easier just to quit yourself than purge the deadwood. you can't fight entropy.
Star Trek transporters are just 3d printers.