Slashdot Mirror
Discipline in Open Source Projects?
An anonymous reader asks: "I've recently been elected (with another project member) to lead an open source project that we helped start several years ago. One of our goals as project leads is to implement some way to discipline project members who are disruptive to the project. In the past, the project has been slowed by flames, trolls, and even filibustering. Everyone says they want to work together, but some refuse to accept majority opinion. This passive-aggressiveness, coupled with growing despair on the part of other members, would have caused the project to dissolve if a vote had not taken place to elect new leadership (which the project has been lacking for some time). As co-leads we want the project to continue and grow, and we welcome all opinions, but how can disruptive members be told 'enough is enough'? We've read Ubuntu's Code of Conduct, but how can it or something similar be enforced?"
There's only 1 way that I know of: Remove their privileges.
In a project, that means removing their ability to contribute. You can do this by either breaking their arms or removing their commit privileges.
Seriously, though, if someone is disruptive and filibustering, WHY are you letting them have important tasks? Either go on without the task or give it to someone else.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Caning would be better, or possible the rack.
Any reason you are posting anonymously and without mentioning the project name? I suspect that you would be able to solicit better advice if you did not withhold those crucial details. I also believe that the very reason for why you are posting anonymously has to do with your problems in that project.
Football Odds
If somebody is detrimental to a voluntary project, you only have 2 real choices. If they are in charge, fork the project. If they aren't, ignore them.
Trying to punish them is kind of futile. Unless you want to keep this person around and are trying to "reform" them, just add them to your killfile, ban them from your forum, and revoke their CVS access.
Just as important as having people working together in harmony is having them working together without stagnating creatively --- and that requires acceptance of well-reasoned criticism of the current design, instead of immediately calling it "disruptive" and rejecting it.
It also requires telling your own fanboys and groupies to stop defending the status quo on principle and to start thinking for themselves for a change. While theoretically on your side, fanboys are actually deadly to a project's interests in their total antagonism to any thinking outside of the box.
In other words, you need some disharmony in a project, or in time it will lose its novelty and interest and stagnate. Just seeking absence of heated argument as an important goal is not at all wise --- it's just too easy to throw away the baby with the bathwater.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
It's a good idea to kick such people out of the project. Why is that? Because they often go off on their own, and create their own projects that often far exceed the usefulness of the project they were booted from. The BSD world has two good examples of this: OpenBSD, and Dragonfly BSD.
In the case of OpenBSD, Theo was ejected from the NetBSD project, and has gone on to create the most secure general-purpose operating system known to mankind. Matt Dillon will be doing something similar with the Dragonfly BSD project. In short order it will be the only BSD-based system able to scale well on the 100- to 500-core CPUs we will soon be seeing in typical, low-end desktop systems. There have even been predictions that it'll scale better than Solaris and IRIX on lone systems with 1500 to 3000 cores.
So do us all a favour, and kick those people out. What they will create will trump whatever it is you are working on.
First of all, be grateful that you have people who are willing to go to such lengths to make their voices heard in this group. It means that people are thinking and are interested enough to make their ideas heard. I assume that these people are making their time available for free. You can tell them that their help is no longer wanted, but that's about all the group can and should do if they are truly disruptive. Otherwise, appreciate the effort they are putting into trying to make the group's work better.
Second, take a hard look at the group's decision-making procedures. Decisions, which often entail compromises, are necessary for the group to come together as a team. Many decisions can be made informally. But, a lack of a good process for dealing with controversial decisions can give members the sense that they have not had a full voice---that their input is being ignored. Is "majority opinion" in this group a result of formal votes? Or are the "co-leads" simply laying down "majority opinion" by fiat? Are decisions are being driven by personality or by deliberation?
Third, consider designs for your system that allow dissidents the freedom to introduce alternatives outside of the core project. Linux, Apache, Perl, Gimp, and Mozilla are all examples of systems that are extensible without modifying the groups official code-base. The members of your group who want to create alternatives may even go out of their way to create the appropriate hooks in the official code-base to enable this freedom outside the constraints of the group priorities.
Fourth, spend some time studying leadership as a discipline. Start small. Read The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni. Ask for honest feedback from the members of your group on your own effectiveness as a co-lead. Learn how to develop the leadership skills in others. Some of these disruptive members may be leaders who have just not learned how to communicate and compromise. The most effective way of dealing with them might be to help them develop those skills, rather than trying to disciplining them.
Fifth, get some cats. I've heard that herding them makes good practice.
Sometimes it's better not to bring public attention to the tribulations of a project. It sounds like a pretty small project at that, so it may not help to tame the "problem" developers to bring them under public scrutiny as being such. I don't really see why it matters which project it is or who is involved -- there are plenty of different ways to deal with personnel (or personal) problems and the slashdot crowd probably has lots of experience with lots of them. I think it'll be an interesting and perhaps even helpful thread, even without public exposure for the project that inspired the question.
OK, this is from a different context, but I'm talking about a non-profit organisation of which I was elected president for two years, leading a committee of 40 or so volunteers organising things for thousands of people.
One of the harsh realities you discover when you take on such a role is that sometimes leadership and executive decision-making have a place, but at the same time, most people contributing their time and/or resources to your project aren't the leader and still want to have their views taken into consideration.
The bottom line is that if people are volunteering for an effort you lead, you have nothing on them but the support you inspire and any vested interest they have in supporting/influencing your project. If they do not feel sufficiently involved, they will leave.
On the other hand, if you let them remain involved but they are incompetent (or otherwise unwelcome), they may actually be damaging to your project. There comes a point where someone's contribution is a net loss, and you have to ask them (or, if necessary, force them) to step down.
There really isn't much of a middle-ground by default, and it's very hard to create one. If you want their input you have little choice but to permit their actions and respect their opinions to some extent, even if you do not agree with them all the time. The best I could ever do was try to keep people focused on the areas where their main interests lay, which at least tended to keep them motivated, happy/courteous, and at least somewhat useful.
FWIW, I usually found that being positive with people about what they did well worked better for keeping that focus than being critical of what people did badly. Put another way, IME you're asking the wrong question, or at least looking for the wrong answer. But this really varies from person to person and your mileage most certainly will vary.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Let me say it again.
Do NOT Feed Trolls
Honest; it's a simple as that.
As a further protection take away their posting
rights to the SCM system you use, and be sure to keep offline
backups because poisonous people can get very nasty.
The only way to get things done is with an odd number of leaders, and 3 is too many.
"just add them to your killfile, ban them from your forum, and revoke their CVS access"
reversing the order might be a good idea too.
Consensus works when all parties are reasonable and the group is small. It also leads to horrible compromises.
I can throw myself at the ground, and miss.