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?

Comments

Anonymous, eh?

[Anonymous Coward]

You're not fooling anyone, Lennart.

Re:Anonymous, eh?

[Sique]

The problem was that with ever changing hardware due to hotplugging during the runtime of a system, the concept of different runlevels was rendered obsolete. You can't have a runlevel for every hardware configuration that is possible. And if you have mobile devices, you have to take care of different power states, of connectivity, power saving modes and lots of other things that change during runtime. You simply can't solve that with a concept that was developed under the premise that the system gets powered up once and then runs forever without any further changes, until it has to be powered down for hardware maintenance.

So there was a system required that while running can adapt to different hardware configurations on the fly and automaticly solves the interdependencies for different demons, drivers and configurations.

While that is in principle possible with a set of scripts, it easily becomes un-maintenable, as every new hardware or state to support might need a hands-on on every script that might directly or indirectly affected by it, and you'll soon get runtime errors because a required service is not started, or a service, that is no longer required, is eating resources that long should have been freed. There was a system necessary for each demon and service and driver to report their requirements, and to calculate the new set of required resources and running processes, and to automaticly stop, reconfigure and start the approbriate things.

Personal Anecdote

[Anonymous Coward]

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.

What if the leader/decision maker is incompetent?

[bogaboga]

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.

Don't let them in?

[Mr. Freeman]

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.

Re:How about...

[Immerman]

In fairness - if you're actually the one(s) doing much of the work to create something being used by millions of people with minimal compensation - you *are* a pretty special snowflake. *Especially* compared to the asshat who contributes nothing but vitriolic, non-constructive commentary.

Re:Fire them quickly.

[pnutjam]

Yeah, some number of that lower 80% or 50% have the ability to become a top performer. If you cut them off, you kill your training pool. Some percent are also contributing in smaller ways that allow your top performers to concentrate on the parts where they are top performers and let others muddle through the parts they don't like.

It's easy for the "elites" to talk down the regular people and dismiss their contributions, but don't let your shop turn into some sort of uber coder jock circle that's destined to implode.