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
Remember the Catalyst debacle a while back?
It's questions just like the one posted here on slashdot that made me question why that whole process was kept secret. If every project deals with conflicts in a secretive fashion, how can anyone else benefit when they have to deal with problems of their own?
Here's a slightly pared down version of my Perlmonks post:
I can read between the lines like anyone else, but who can deny that some of the best, most enlightening discussions here on PerlMonks have been heated. Someone feels strongly about something and they end up providing great detail about their reasons. Regardless if you agree, you've probably learned something.
Catalyst has become a very significant project. Aren't we missing the benefit of how such a project is lead? Wouldn't we benefit from the technical details such as how changes impact other projects? Wouldn't we also benefit from seeing other's passion for their projects? At minimum, maybe it would expand our awareness of the community as a whole.
"I can be self-referential if I want to," said Tom, swiftly.
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.
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.
We all know it's you... http://en.wikipedia.org/wiki/Debian
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.
Kick them out. They're not worth the pain.
Instead of trying to stop the debating, why not set up a few subprojects for each of the warring factions and see what emerges? Let your user community try each one out, and see which they like better.
Well, everyone has to deal with personalities, but if it's a matter of trying to argue and figure out what features get implemented and how, there are plenty of systems engineering practices that can help create a streamlined, even automated process for collaboratively plotting out what gets added to the project plan.
Start with establishing a gate review process for evaluating and accepting change requests to any of your roadmaps and requirements. If someone can't get their feature through the peer review, they haven't done enough homework and must go back and twiddle with their proof of concepts or gather more convincing benchmark figures or background research to back up their proposal.
Have a set of policies, coding conventions and guidelines, etc. established in advance, and allow the gate review to reject change/merge requests that fail to meet these.
These layers of bureaucracy is somewhat antithetical to the idea of open source, but someone has to be the guardian of the trunk of the svn repository. Properly implemented and streamlined, they won't encumber the development process too much, while allowing many people to take part in approving changes while preventing a few dissenters from causing too much damage.
The overall software architecture should be constrained to a relatively small team, but they should be flexible enough to modularize a contentious component in such a way as to allow people to explore a few competing branches. That way, if someone insists on doing something their own way, you can somewhat pigeonhole them into their own little corner or "development branch" while you take the rest of the functional team and run circles around the rest of the components, including ones that supercede the poor fellow's sandbox. But they still get to feel proud that they contributed something that can break your program in awesome ways with a simple flick of a compile-time switch.
Anyway, it's really difficult to try to recommend a solution not knowing the specifics of your challenges, but there are several technical measures you can take to help mediate your trolls and wayward egos. Welcome to management. Just remember to try to stack your cards in such a way that keeps people happy and feeling productive, even the trolls and spoilsports.
Good luck!
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.
I agree-- if there's a dispute of the direction of the project, give the dissenters their own fork.
Let them work on implementing the feature they must have but nobody else wants.
If they're worried about security, let them put the code to the test and find the holes.
If there's disagreement over whether something will work as designed, try it both ways.
In the end, it's better to have all options open to move forward, no matter who turns out to be 'wrong.'
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.
Do you really need these coders who are disruptive? You should weigh what you would get in keeping them against how much damage they are causing. If they are excellent coder(s), maybe you could look the other way. But if they are only OK (or not great), you probably should look for someone else to save yourself some pain.
I'm the PAUSE (CPAN) Administrator that negotiated the Catalyst settlement.
The main problem was one of mixed ownership permissions on the namespaces, it was possible with either side of the split to utterly destroy the project.
One of the terms that was insisted on by one of the parties involved was a gag order on the reasons for the split for a period of 1 year, to prevent bad-mouthing in blogs and such. Due to the sensitivity of the situation, these were felt to be best for everyone, particularly as there were multiple mortgages and the feeding of children involved on the line for the core team if the whole project collapsed.
That year ends on the first of May.
From then, those involved are allowed to talk about what lead to the problems, and what happened behind the scenes.
Let us take your issues one by one.
1) Flamewars slows the project.
The only way that is possible is if the
project depend on the result of the flamewar to make a decision.
So, make sure that the decision process is flame prove.
See my suggestion further down.
2) Some refuse to accept majority options.
The 2 extreme cases for this is.
a) The majority is wrong. He is an expert.
b) The majority is right. He is an agent.
The first option is that he is an expert on the subject and
know that the majorities solution is wrong in some way.
The second options is that he works as an agent for
the competitions and is here to ensure that the project fail.
Your job is determine if he is an expert or an agent
and take the right action.
Some characteristics is:
Expert typical work on many projects so he might not have much time to work on the projects.
While agents typical have lot of time and being payed to do the "sabotage".
To make the decision process flame prove I will suggest
that you organize in a democratic hierarchy.
First split your project in some working groups.
(a game project might have graphic engine, play development, physic engine, AI design, etc.)
Now, make contributers join the groups in the area of there contribution.
Then make them chose a group leader, now the way to chose a new leader for the group
is for a member of the group to challenges the leader.
When this happens the group vote which of them should be the new leader.
Then all group leaders join a leader-group and choce a leader for entire project in the same way.
The job of the leaders is now to listen to members and make decisions.
The decision now don't depend on the result of a flame war and
the work on the project can continue.
If a leader make to many bad decisions he will quickly be replaced.
You might say that a democratic hierarchy is finding a balance
between the cathedral and the bazaar.
"I know you've been caught with your pants down using Windows XP. Naughty boys of open source call Mistress Richard now to receive your punishment. Strict discipline."
Next to this is a photo of Richard Stallman clad in PVC and leather, wearing high heels and wielding a whip.
I hear that Bill Gates already pays for this at least once a month.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Remember Freedows, the primary discipline problem for us was Reece Sellin, the project lead/owner/overlord.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
a) The majority is wrong. He is an expert. b) The majority is right. He is an agent. The first option is that he is an expert on the subject and know that the majorities solution is wrong in some way. The second options is that he works as an agent for the competitions and is here to ensure that the project fail
How about option C, he thinks is an expert, he thinks the majority is wrong. That's far more common in my experience. Besides, some of the most vicious flame wars I have ever seen are over issues where there is no right or wrong, just differing preferences. You're sort of assuming that anyone flaming on a project mailing list is either a transcendent genius who can see things us mortal cannot, or is a paid agent of the competition. Let me assure you, lots of them are merely opinionated idiots.
"I realise this is not a very popular opinion but it's the truth, and there for needs to be said" -Bill Hicks
Post the follow on Craigslist....
FREE COMPUTER EQUIPMENT
First come first serve; btw, my front door is sticky so you may have to lean into it...
-- www.globaltics.net
Political discussion for a new world
Video presentation: How Open Source Projects Survive Poisonous People (And You Can Too)