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?"
Spanking is definitely the way to go.
Dan East
Better known as 318230.
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
but how can it or something similar be enforced?
If someone starts creating problems, ban their account and reject all access. Block their e-mails and IM. Don't take their phone calls.
Or, alternatively, turn the "open source is a good thing for building your reputation" concept to your advantage: post a "hall of shame" page on your project's web page or in its release notes, that lists the names and all known contact information for people who have caused problems. Ammend your license terms to require that the list be distrubted along with the source for the software.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
The fact is this is why democracy and open source projects are prone to breakdown: Because they are demographically challenged, either mentally or in terms of skill.
That's the real issue, there are many ways to solve the same problem. The real problem is everyone wants THEIR VISION of what the program or implementation should be realized, that's really the issue... contests of will imho.
All too often open source software neglects usability, i.e. 'designed by programmers, made for programmers'. It may be programmed well but you have to remember who your end user is in the end: The end user, not a programmer.
Even if you have the best team and discipline it means nothing without perspective and proper understanding of the issues of usability, I don't care how amazing your program is if it is clunky and inefficient to use. This is one of the reasons the market to some degree works: You find the best people and you are forced to hunker down under the vision of leads, sometimes which are carefully chosen, othertimes not. At some point it doesn't matter and you just have to take the risk and get things done or nothing gets done at all, because you call can't commit to a unified vision.
http://video.google.com/videoplay?docid=-421601196 1522818645
we speak the way we breathe --Fugazi
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
You could study how the Friends (Quakers) handle discussions and disputes. They've managed to do quite well for about 400 years or more without using voting and majority rules. One problem with a majority rule is that there is always the chance of a person or people feeling left out and ignored. While working with building a consensus takes longer, when you reach a decision and move forward, you're moving forward with everyone able to put their full support into it.
Whenever I bring this up in discussion forums, especially in "geek" forums, quite often I see strong reactions that it won't work and can't work and so on, but it has been working for close to 400 years. I've used it in special ed classrooms with emotionally disturbed students and they found they could work with it when they got used to it. I have seen it work in many groups. The principal ingredient, in most cases, is for the leaders to treat all with respect and to expect others to do the same.
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.