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?"
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.
I think we should cut their goolies off*.
On a more serious note, one of the major issues with computing is that some of the most brilliant minds are also some of the most obnoxious. To the point that, without mentioning any names, a major free software operating system project was founded in part because the founder had his privileges removed from another major free software operating system. The offshoot is considered by most to be far, far, more successful, yet there's little question the founder isn't easy to work with, and whether just or not, the fact his privileges were removed in the first place wasn't exactly a surprise.
* I'm probably dating myself with that reference.
You are not alone. This is not normal. None of this is normal.
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.
You are talking, perhaps, about ciaranm and Paludis. But given the size of the Paludis team and the rapid progress they're making, I wouldn't say he's hard to work with. If you can't deal with being told bluntly that you're wrong, I guess you won't like Ciaran. But if you don't mind the occasional amusing insult, you'll learn a lot from him.
LOAD "SIG",8,1
Catcher in the Rye?
"There's only 1 way that I know of: Remove their privileges."
Then you're a dumbass. (Offended? Good. Shows that if you don't know the person or the context, or how something is phrased, it may or may not be civil. In this case, I mean it literally, but you might also know that I say this regularly to posters I heavily disagree with.)
First, the project head needs a a simple needs assessment. What is the overall goal of your project? What is your major plan. Please note that "advancement of coding for Project X" and "building a community around Project X" are not goals; they are inherent to the aims of the community. Do you want good code? Secure code? A better GUI? A state of the art setup? A friendly user base? A knowledgeable user base? Great support? Cutting edge ideas? Examine closely what you want.
Then prioritize. Do you want a community, or something that serves society? Note these are NOT the same. Many advancements are made by the so-called criminals and delinquents, only to be recognized later as major contributors to economies and that society. The same can be said of your open source project. Simple neglecting of key users, removing of privileges because someone is aggressive more than community tastes, can only hurt you if they are hurting your goals.
You may realize that you might want to stage things depending on the project aka figure out how to get to those goals. If early on in a project, you can sacrifice a "nice community" for assinine coders, because you need good coders. Try to influence the coders to be more civil as time goes on; many grow out of it as responsibility increases. As the code matures, give more emphasis to better documentation, support, civility on the mailing lists.
For example, take the creation of OpenBSD. Supposed pain in the ass Theo wants to contribute code at a high rate to NetBSD. Maintainer of said Sun port of NetBSD is a slow poke and seems clearly subpar in knowledge to Theo. Theo also wants to focus on security and bug fixes. He makes his issues known. Again. And again. He's largely ignored. Now, you can have opinions on whether what he did was civil or not (I find it simply straightforward for nearly all of it), but he was asked to leave/pushed out.
Which led to OpenBSD. Which had clear goals. A small userbase. Great code. And is used today by those in the know of security. Theo, in turn, has matured and shaken off a lot of his old reputation; in fact, you can tell those who are just badmouthing OBSD or Theo since they stick to the reputation he garnered.
Meanwhile, NetBSD still exists, but has largely fallen off the map because Linux has taken it's role over (in addition to the roles Linux has). Great portability without security or without speed means little these days. Except if you need to run a BSD on some archane hardware.
Second, PITA people on projects aren't always a bad thing. I dislike Havoc Pennington, think he's an ass, but I still use GNOME, and if you are strong enough to set aside personal dislikes, he makes good points too. Do you want a community that can stomach disagreement, or a boring paradise of user friendliness? A community can have a combative environment, be near hostile, but if the user base is robust and understand that's the nature of things, this can keep out newbies who are easily offended as well as grow the code and documentation by getting people involved who stand their ground and want to be involved even in a disputive environment.
Third, be really careful who you kick out. Look at their history. And look at what they are saying. Look at the intertwining relationships carefully to see if the person you are removing is doing more than you think. Be careful also who you listen to; most politically connected influential people in an org are also the least contributors in many areas (since they are focusing mainly playing the middle ground). Also, maybe YOU need to deal with things better even if they a