Slashdot Mirror
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?
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?
Yes, Lennart Poettering should have been fired a long, long time ago. See what playing nice gets us? He's paid by Microsoft and is practically destroying the entire Linux community. Oh, and he also writes useless code and comes up with useless project which don't do anything new and don't work very well.
Why do these posts always get modded down? Where are these people who actually respect the work of Poettering? This topic is very very much about people like him.
He causes damage, does nothing of quality or value... And then... and THEN, he has the gall to openly criticize the entire freaking OSS community because they don't want him working on their projects and he's all butthurt because the project maintainers speak their mind.
It's unrealistic to simply accept everyone who wants to help. Some cannot be worked with in a positive way.
If you want a welcoming, inclusive community, you don't get to decide certain elements don't belong and remove them.
If you want to do that, you don't really want a welcoming, inclusive community, what you want is a community of elite according to a set of standards.
So, decide what it is you're choice will be and focus in on it, then everything will become obvious.
-1 Uncomfortable Truth
What makes things difficult, is that the people who are wrong don't know they're wrong.
So you have 2 people who think differently and thinking the other is wrong. Which one is? Who knows! Its easy in hindsight of course.
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.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
Commits count.
Turning up to a gig doesn't give you the right to dictate what the band plays. But if you turn up to the REHEARSALS for the gig armed with recordings and knowledge of the band's previous performances and sheet music containing instructions on how to correctly play something that the band had previously been fucking up without knowing it, then there's a chance that the squiggles and dots you've written might be performed at the next gig.
If the band chooses to not perform your squiggles and dots then just leave and perform them yourself.
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.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
What makes things difficult, is that the people who are wrong don't know they're wrong.
No, that's not the difficult part. That's just a given.
The difficult part is trying to control something you have no control over.
Once you're willing to ignore that "destructive" blogger. And once you're willing to accept that you won't be able to change that person's mind, everything will be infinitely easier for you.
I can't say I'm happy about what's happened to Debian. Having Ubuntu as a commercial derivative really has been the kiss of death for it, not that there were not other problems. It strikes me that the kernel team has done better for its lack of a constitution and elections, and Linus' ability to tell someone to screw off. I even got to tell him to screw off when he was dumping on 'Tridge over Bitkeeper. Somehow, that stuff works.
IMO, don't create a happy inclusive project team full of respect for each other. Hand-pick the geniuses and let them fight. You get better code in the end.
This actually has something to do with why so many people hate Systemd. It turns out that Systemd is professional-quality work done by competent salaried engineers. Our problem with it is that we're used to beautiful code made by geniuses. Going all of the way back to DMR.
Bruce Perens.
Completely agree.
Better yet introduce trial periods and reviews so that everyone understands that membership is not guaranteed and something to be respected/valued and help reduce feelings of self entitlement.
And as much as they are not special snowflakes this problem is not either. I mean if you let in candidates unfiltered into your workplace what exactly do you think will happen?
Be aware that many people are not very good at rating their own abilities or contributions and generally live in a self absorbed bubble which may have a highly variable relationship to the real world. (this can include the hirers/firers.)
Be warned that introducing any system of "hiring and firing" is VERY hard to get right (research says most people are terrible at it) and can be abused.
Also, just because someone is a great team member, it does not automatically follow that they will make great recruitment decisions.
Its tough.
This is just how the human race is. Deal with it or live in a cave, those are your choices.
PS: The cave thing was a joke...they will come find you regardless.
The C4.1 contribution protocol I eventually wrote for ZeroMQ solved this problem. You have to develop rules that catch bad actors (yet not learners) and then educate project managers on how to fire people when needed.
Our rules for instance ask that you solve one problem with one patch, that you never break existing stable APIs, that you respect style guidelines, and so on. When people break these rules we give them several chances to improve their behavior. If they persist in doing it wrong, we remove them.
Turns out, when the rules are very explicit and teach people how to make good patches, then it's very rare we have to fire people.
The rules are at http://rfc.zeromq.org/spec:22
My blog
Debian did it because Red Hat did it. And Red Hat did it because, wait for it, it was THEIR employee that created Pulseaudio AND systemd. If we truly needed to replace init, there are other open source projects already that do that (upstart, SMF, and launchd).
And the GNOME team isn't exactly a favorite of many people either, so don't look to them for being happy community members (and they are known to reject outside patches anyway. Unless you're going to tell me that Linus himself contributes bad patches...)
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Same problems that led SUN and Apple to built new init systems ?
If the Debian mailing list is anything like Slasdot, I don't blame them. Any vaguely related topic gets instantly spammed to shit by the same dickheads copy/pasting the same comments about how systemd is an NSA plot to read everyone's worthless secret diaries, how Red Hat are trying to take Linux closed-source and how Poettering is the fucking anti-christ.
I'd rather read "cheap Canadlan m3ds" spam. At least that's informative.
Where are these people who actually respect the work of Poettering?
As a FreeBSD developer, I have a lot of respect for the work Poettering. Every time he releases a new piece of software, we gain a load more users and developers. I can't wait for his next project.
I am TheRaven on Soylent News
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.
Agree completely. One of the things that really impresses me with systemd is just how event-driven it actually is, and how it separates events from services.
I can have a service that performs some task. I can trigger it to run when another service runs. I can trigger it to run when a target/"runlevel" is activated (the traditional rc.d approach). I can trigger it to run at certain times. I can trigger it to run when a particular udev rule is satisfied. I can trigger it to run when when a file is modified. I can probably trigger it to run when a filesystem is mounted. I can trigger it to run when somebody connects to a socket. I can even trigger it to run conditionally if one of those things happens and the device is in a particular power state, etc.
I think the systemd devs have done a pretty good job of building on the richness of the whole dependency/event-based paradigm.
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.
Cheap storage VM.
This thread is evidence of the problem: Many commenters here post one-sided, one-size-fits-all solutions in which they believe. But, flexibility is the hallmark of successful people. Your ability to see each contributors' strengths and weaknesses, and help them contribute from strength and evolve from their weaknesses is what successful managers and executives do. The rest are just "wannabes."