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?
Would you rather take a bullet to the head or three to the gut. Fire them as quick as possible, then show them the door.
You're not fooling anyone, Lennart.
Pot meet kettle?
...being able to take and respond to criticism in a constructive way and justifying your design decisions with logical, well thought out reasons?
It takes one supremely special snowflake to believe they should be able to silence criticism from contributors and the community at large.
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.
don't air all the dirty laundry in public. not even to defend a contributor you feel was wronged.
Maybe have a slashdot-like karma system, where bad comments on the forums are modded down, and you build up good karma.
Seems like bad people would soon ensure the community would "fire" them.
--PM
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.
I know that many folks in the FOSS community feel more comfortable behind a keyboard than they do in front of others, but none of us live in a vacuum away from others. As such, these are golden opportunities to assert the type of leadership and expand skills necessary for personal as well as professional growth.
More fundamentally, every project needs to have clearly defined goals as to what they want to accomplish. The schedule of such projects, by the generally voluntary nature of FOSS contribution, may slip, but the cohesion required to achieve these project milestones is only possible in the presence of relatively strong leadership. Strong leadership should also recognize the skill inventory available to the project on a per-contributor basis and encourage those with particular strengths to be used in needed areas modulo personal goals (e.g. growth in coding skills, UI/UX, etc.). Leadership also needs to set down ground rules like mutual respect and positive communication style.
Therefore, project leaders need to manage the relationships between contributors, recognize political and personal differences, and reconcile them reasonably but quickly for the betterment of the project. If that includes terminating the relationship of one or more contributors to said project, then it needs to be done. But before all that happens, project leadership has to set the base of the building correctly before building subsequent floors, as it were.
There's an old saying that says "the fish rots from the head down" and it applies here too: if things are getting out of hand with a project, deal with it but make sure all of the rules were set and the relevant parameters understood prior to drastic action such as terminating a relationship.
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.
Don't the users have valuable opinions too?
If you want your "product" to be "bought" by people who care more about image than about getting the job done, then you need to be wary of those dissenters. A good product, like a good comment, stands on its own and doesn't need the "support" of advocates to reach people who appreciate substance and don't care about the number of your Twitter followers and Facebook friends.
Many Open Source projects value "market share" far too much and consequently give too much power to "politicians", people who see their contribution in steering the project. Whether they end up making the project decisions or ranting on their blog about the project decisions: They are the same kind of people. Code is law. Never forget it.
Keep all of the idiots that want to work for a millionare for nothing. Fire the others.
Anyone with sense has by now joined a non-profit project.
Bruce Perens.
First, don't resort to name-calling. "Special Snowflakes" is name calling.
Set up a leadership structure. Stick to it. If it involves elections, include a nominating committee that decides who can run for leadership roles.
This is how it's done in grownup circles. The failure to do it doomed Occupy Wall Street from the get-go and has allowed many other movements to be hijacked over the years.
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.
In fact, it never works. If some douche tells me "nope ur wrong lol" and that's it, i dont give a damn what his name is, i'd ask for some proper explanation, or even some half assed one, because if you start getting a-ok with appeals to authority, then it will never stop and you will slowly but inexorably turn into some sheep or zombie doing and thinking because dear leader told you so, and that's ok, because that's what Leader thinks and if he says so he must be right.
All the firing seems to be SJW who can't deal with people who don't buy into their bullshit narrative. Too many special snowflakes in the open source community.
I find it amusing that we are using a social media sight that is legendary for its users' complaints, rants, flame wars, burns, etc. to talk about how to get people to stop the very same activity when it pertains to social media on topics that impacts us.
This is the same thing that has tone deaf twits showing up for American Idol, convinced by their moms that they could be stars.
The phony self esteem syndrome starts very early these days, and is made monumentally worse by PC-infested public schools. It's become so unfashionable to simply tell people that they're not the geniuses they think they are, and so impossible to avoid parental wrath when a kid is correctly identified as merely average (or, unthinkably, less than average), that we're now manufacturing the whiners mentioned by TFA as an entire generation.
Wondering how to deal with it in the context of FOSS projects completely misses the point. Scratching around at the symptoms in every venue in which they manifest themselves is pointless. This is a deep-seated cultural problem created and exacerbated by both aging and nouveau hippies in the education and social/gov circles.
Don't disappoint your bird dog. Go to the range.
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.
TFS reads as if the anonymous submitter wrote the summary text that is actually copied from the linked article. The author of the article and the quoted summary text is Jono Bacon.
The idiot throwing away hard learned lessons about UI design without providing clear and compelling reasons is the idiot or precious snow flake or whatever your term of choice is. Doesn't matter if he/she can code or not.
how to address technically competent people who make nonsensical decisions.
for people who are completely hardened and unwilling to even consider the possibility that they are wrong, there is nothing you can do besides fork the code and go on. however, people may not be hardened like you think so in the case of UI choices, a usability study could be performed. it will require significant effort but it may change some minds. the question you must then contend with is if it's easier to fork or is it worth the effort to run a study. the windows 10 preview was effectively a study on how usable their UI was.
Anons need not reply. Questions end with a question mark.
it also created people who believe that simply making a website and a GitHub project with no code in it, being an annoying twat on youtube, never producing anything, is some sort of LEADERSHIP position and if you contribute or criticize it, you are some sort sociopath.
at least in the Crypto space 90% of projects are completely empty frauds. usually just some lame fork of a project that does something, lots of marketing and graphic design, and a annoying-as-!@#$ 20 something with an extremely high estimation of himself.
This article can be summed up as "a lot of nerds need to grow spines".
If someone's primary contribution to a project is shit and noise, then get rid of them. And then get rid of anyone who whines about it, too.
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.
We invented something to fix this problem you speak of. It's called Science.
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.
So what's the best way to foster a welcoming environment while still being able to remove the destructive elements?
Benevolent Dictatorship.
Make it clear from the start to everyone on the project that while you're going to remain hands off as much as possible and let everyone do their thing, you're still the ultimate authority and you won't hesitate to step in and start cracking heads if people start causing drama and/or forget how to be adults and let their disagreements get out of hand.
.... looking into the mirror...
Perl Programmer for hire
We can look to the Starks and the Torvalds of this world for the solution to this problem.
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
In the sight of the newsgroup, in the name of software stability and maintainability, I Linus Torvalds, creator and maintainer of linux, creator of git, sentence you to die. You will speak no final word.
Some of these "opinionated" people have been placed into open source communities by competitors to confuse and befuddle projects and to destroy goodwill and productivity.
It's working well.
People who want to be noticed and heard but don; t have the knowledge, skill and ability to persuade others have to be controlled. So, ask them to list at least one are two contribution to Open source, list their credentials, ask them to list their priority to change or modify any thing based on evidence and are polite and know how to communicate without being abusive should be heard. Kick the ass of attention seekers with "entitlement mind set). Some dogs bark and bite but majority are attention seekers without worrying about contributing any thing. You see how our elected (??) politician behave without respect for any thing but themselves at the mercy of the lobbyist, you get the picture. Constructive critism is amust for the betterment of all.
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
While this might not be the most subtle way of handling things, it could be quite effective to repeat the same question every time they are critical. "What have you contributed?"
Just ignore their arguments and ask them what they have contributed. Over and over and over again.
They will either go away, stop posting so much, contribute, or perhaps realize that the whole point of the movement is to contribute actual code and functionality.
On the Internet, ignore them. In real life, talk about them every time they open their mouth and complain. "Oh there goes Joe again, whining and NOT CONTRIBUTING." Then return to your regularly scheduled activities of doing things.
When no one wants you to work for free, it's time to recognize that you have some serious personality and skillset defects.
I've never worked on an open source project other than my own, but I've spent many a long hour with the "negative contributors" in the business world since around '87. Unfortunately, we never could get rid of those people on the project teams because they were always managers and "key business users" (i.e. The worst employee in a customer department that they wanted to shuffle off onto someone else, such as working on another department's project instead of in their own.)
The thing is, sometimes those complaining users are a goldmine of information who just have a tough time explaining themselves. One of the shop floor managers at my second "permanent" job with Northern Telecom was a real hard case. He'd pin you with a barrage of questions, berate you for not meeting his needs, and was just generally a real asshole to most of the people he dealt with. But if you were able to answer his questions for a couple weeks and could take care of a couple of the backlogged items on his "need" list, he became an absolute joy to work with.
You see, the man was just jaded by decades of working with "elite" programmers who wouldn't listen to him about how the shop floor should be running. For years and years and years, the engineers and programmers had done what they thought was right for systems design instead of listening to the people who would be using it. It turns out he had tremendous insight into the way his people were actually doing their work, and how the computer systems could fit into that workflow instead of being a hindrance.
I've also dealt with people who were just cranky deadweight, contributing nothing of value to any of the projects they were on. Alas, they couldn't be fired without going through channels. Only once did I manage to get someone who was so negative terminated by a company. They reported to me, and were so poisonous to the department that productivity improved 20% after they left -- without hiring a replacement. It turns out they spent so much time complaining in meetings and during "cube visits" that they were slowing everybody in the department down, as well as stressing everyone out with their negativity.
So, yes, there are people who should be fired -- even if they aren't getting paid in the first place. But before you write someone off as being a belligerent know-nothing, take the time to talk to them and learn if their concerns and issues are legitimate. You could be missing out on some valuable opportunities by writing off someone with poor communication skills as being "just an asshole."
I do not fail; I succeed at finding out what does not work.
Sometime negative people won't go away and make a new fork of the project is the only way to go around the issue.
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.
The problem is a lot of developers fail to appreciate the big picture and process the second and third order effects of leadership decisions.This often leads to the dynamic where many of the developers loudly complain that management is incompetent but in reality they are the ones who are failing to use critical thinking skills. However, every good leader knows you have to throw a few intentionally poor decisions for political reasons or to satisfy the ego of a few individuals.
The fact that they disagreed with you doesn't (necessarily) make them incompetent. They had different goals in mind than you, and they made the choice that supported those goals.
Just reading the question, there is no possible way that the anonymous person asking the question is unbiased. The question is full of insults. As such there's not a good answer to give because the problem may lie with the leadership.
Once someone starts insulting the coworkers it's really hard to be objective about their opinions. We're hearing only one side of the story and that side is already dysfunctional. I sense that there is a bigger problem than just one problem volunteer.
Maybe that's an open source thing though, where the "leadership" is not necessarily partaking in management or leadership training, even something as simple as a lunchtime seminar given by HR. Though this training does happen with many volunteer charitable organizations. Also in open source very often the "leadership" have a very strong sense of ownership with lots of invested emotions; ie, it started as their personal project perhaps.
with systemd.
(.....Are you secretly talking about linux with systemd?)
Actually, it does make them incompetent. A competent leader would look at your point of view, recognize that your points have merit (assuming they do), and try to find a compromise design that meets your needs without compromising too much on their goals. Only an incompetent leader is intransigent and is unwilling to adapt his or her views when presented with new information that contradicts them.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Fear leads to anger. Anger leads to hate. Hate leads to suffering
Even very negative criticism often has some usefulness that developers would be foolish to ignore.
If I am a GNOME user, do I have to "shut up" when the GNOME developers ruin their project?
If I'm a Debian user, do I have to "shut up" because I don't like the changes that systemd brings to my system?
Open Source means community, not just developers, and users also have their say. Everyone used to take this for granted, and it's only when entitled assholes like Lennart Poettering came around (the real "special snowflakes") that some developers started thinking their projects should be immune to criticisms by the users of the project. The Linux community has existed for a long time, and so have criticisms of Linux. You know what? The things that people have been criticizing for the last 20 years are still problems, and they could be solved if the OSS community actually listened to OSS users.
In the future, I will probably leave the Linux community too, because Linux is turning into a pile of bloated garbage. When I leave, I'll move on to greener pastures that haven't been ruined by the Lennart Poetterings of the world, or UX designers who want to hide every feature ever behind one single button.
Maybe some people would say that people like me leaving doesn't matter, but those people are fools. Open Source projects can't go on existing in any meaningful sense without their users. Just like politicians need to listen to the people, OSS developers should be using feedback from their users. That's the basic principle of democracy -- that the "little people" aren't treated like peasants who need to just shut up and follow whatever the "great leader" says.
It should be embarrassing that so many Slashdotters have fallen for Lennart's snake-oil and actually believe this bullshit that community members don't matter, just because they happen to be end users, or advocates, or have some other role in the community other than bashing a keyboard and making code.
A vulnerability of open source software projects is the person who damages morale and takes the fun out of development. I have in mind a senior member of the Arduino.cc forums and a participant in the Arduino developers mailing list.
The person I have in mind promptly replies to many of the newbie posts on the Arduino forums. The person writes in a hasty manner, never posts a URL, never clarifies a reference, and sometimes multiplies the problem possibilities creating a miasma that the darn little microcontroller is actually a vague black box. Just a few exchanges with an "expert" like this pretty quickly drained off my energy. I have 25 intermittent amateur years programming microcontrollers. The development environment has changed but microcontrollers are fairly simple and they require ingenuity and an extended sense of humor to figure out when programmed wrong.
The first thing to point out is the Arduino forums are an unstructured place with a lot of first time newbie "help" posts. The Forum software itself without a qualfiied and deliberately sympathetic and helpful moderator is a mostly un-searchable mess, a heap of questions where the closure as often as not is simply silence when the original poster discovers a signal wire accidentally plugged in wrong.
Now on the unpaid "expert" volunteer. Here is the open source dilemma. The "expert" that has been answering newbie "help" questions for years has developed fatigue from the frequently repeated questions. The dilemma is, why after years and years haven't these dozens and dozens of more or less repeating questions been organized into a knowledge, troubleshooting and software and documentation tree that is indexed by the terms and vocabulary and experience of the newbies?
The previous post "Define rules clearly" is a part of the answer. The Arduino is in the eyes of it's creators a hardware and program writing system. For a user like me, the Arduino is more: I am learning how to organize code, schematics, documentation for purchased sensors and devices, and drawings and a data storage, analysis and documentation suite for the resulting science instrument I have constructed. Lucky for me the underlying software, software included from outrside authors, and open source processing and analysis tools is all very high quality.
But building that larger system around the Arduino microcontroller, that is uncharted territory where thousands of project builders are now spreading out like a Sirpenski gasket.
One of the things I learned early on as a tweenager within the FOSS was that if you have a good idea and can communicate well & civilly, nobody actually seems to care terribly much if you possibly are a dog that somehow learned how to type. You don't necessarily have to be good at coding, if what you bring to the table is a good ability to understand the basics and play a living 'rubber duck'--basic sanity checks, to see if what the coders are attempting to do makes sense to somebody who, if nothing else, has at least managed to sleep in the past week. (This isn't meant to be insulting: I've been on the coding side as well: Sometimes I will grab random lusers for the job, and I've learned everybody's happier sometimes when you have a volunteer handy. Less chasing people down in hallways, cornering them in bathrooms, and...I'd certainly have answered a few times the question "Did you sleep in the last week?" with "...Does passing out count?")
I honestly don't really trust communities that say they're 'welcoming' to be so, in my experience, though. What I want is one which gives me nice, clear, well-defined rules: I can deal with being told that I need to contribute things to the group that they value in order to gain status, and live with the baseline rule that if somebody is kicked out, it will be for violating clearly-defined objective rules ("Fails to brownnose correct people" should never be on the list!) and we will all know this. I'm even okay with it if leniency can be earned: If you somehow can bash your head on a keyboard and still generate code that works perfectly, I can put up with a lot of crazy--and I know how to ignore somebody.
Really, I think a basic rule of "The community decides the value of your contribution, not you" isn't unwelcoming, as long as it's clearly and openly stated from the start.
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.
Good luck ... but it won't be that easy getting rid of Linus.
...anything in the comment you replied to??? Apparently not.
So you put a minimalist and a maximalist together, one wants to remove pretty much every button, option and checkbox to go with "sane defaults" that'll work for 90% of the people 90% of the time. The other wants to give you a zillion controls to cover 99.99% of the people 99.99% of the time but it'll take a rocket scientist to tune every detail and corner case. Both directions have merit, but you can be sure at least one of them will be unhappy and call you a moron. Not to mention if you're known to compromise, people start taking absurd positions so the compromise is roughly where they wanted to end up. There's very often not one solution to make everybody happy.
Live today, because you never know what tomorrow brings
All the difficult people will leave and only the latte crowd will be left! :-)
This is exactly why Linus works the way he does and why the Linux kernel hasn't turned into a pile of crap full of bizarre decisions and heated infighting like so many other large Linux projects.
Remember that next time anyone even thinks of complaining about his management style.
There are too many alpha assholes out there for nice polite management and mutual respect to work when a project grows above a certain core size.
Lennart Poettering
...when is Linux being fired?
"From a leadership perspective"... it's this perspective that is wrong. Take people's criticism seriously, treat them as equals, don't look down on them, don't stigmatize them, don't go ad hominem. Of course you will still encounter antisocial assholes and trolls. The best way to handle these is to ignore them, not to whine on Slashdot.
Those are the cretins they are talking about, right?
Linus Torvalds needs to be fired from Linux and it should be forked and renamed quickly so there is no more mention of his name in it. With the massive number of contributors his significance really is more of a mouthpiece and his contribution to it- compared to the work of others- is about as significant as a single atom in the whole of an object.
The way I see it, it's often the programmers who are the problem. They think they're the special snowflakes and their way of seeing things is the one and only way of doing things and everybody else got it wrong.
The best example I can think of is GIMP. Every other pixel-based editor on the planet works similarly enough that there's almost no learning curve. If you know one, you can work in the others. But GIMP? Of course not, GIMP is a special snowflake and the users are the problem.
Get free satoshi (Bitcoin) and Dogecoins
There's a guy I know. Call him Charlie. Not his real name. In fact, it's more than one guy. I'm sure you know many Charlies, too.
Charlie is a core contributor to half a dozen high profile open source projects. Not that he actually, contributes anything useful. But he hangs out on the irc channel and did just enough (which probably involved closing tickets as "will not fix") to get invited as a core team member. Based on his name, other projects invite him as a core contributor.
I run an open source project. It was featured somewhere (not slashdot!) and had a hype boost. Almost instantly, I get an email from Charlie asking if he can be a core team member. His only contribution was sending that email. Not even starring it on github. So I told him to fuck off.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
> 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.
don't appear to be easy in hindsight either because gnome 3 still stand by all the bad choices users complained back then....
also I'm sure there were some hundreds of people saying that 4 were wrong...
When two theories are available and both are compatible with the facts, then there are no other criteria to prefer one over the other except the intuition of the researcher. So one can understand why intelligent scientists, cognizant both of theories and of facts, can still be passionate adherents of opposing theories.
- Albert Einstein
In short, one has to provide reasons why their way is better, and many are not interested in doing that.
I come here for the love
I remember politely fighting GNOME folks over design decisions they took around the `Open File` dialog box
Ah yes: GNOME because Motif is just too darn good. It's like they're on this perverse quest to prove it's possible to have a worse UI than an ancient, no longer updated and long obsolete system which was arguably not that great in the first place.
At some point along the way, they removed the ability to filter the contents of that box with wildcards. That's lovely and so if you need to pick out a file from a large directory, there's a lot of scrolling carefully by hand to find it.
Brilliant!
Oh they've also decided that $PWD is evil and if you start a program from project_directory_foo/ then CLEARLY you want the file-open dialog box to default to project_directory_bar becase that's where you were last.
Fantastic! Who needs the concept of current working directory? It's not like it's been a mainstay of operating systems from the 60s.
SJW n. One who posts facts.
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."
How about those of us who put hours into bug fixing and submitting patches, only to find out who the real opinionated bastards are. The people who have a monetary stake in certain projects. WINE project, I'm staring directly at you.
In Team management, a team is more productive with a devils advocate that challenges and pushes others. Linus holds the devils advocate position for Linux as he constantly challenges and even causes issues with others.
The problem of being a Devil's Advocate is that they are seen as "Obstructionists, nay Sayers, anti-anything, slowdown members, etc" and when given a choice are the first voted out of a team. When the Devil's Advocate (or Angel member as we try and name them) are gone, the team starts to lose focus and goes the effectiveness goes down.
This is management 101 training. The problem with any organization including FREE is that there has to be a strong discernment between the devils advocate and the complete slug. This is a hard thing to do and I have seen many projects kick the backbones off because they were "slowing the project down" and the project then gets worse, not better.
I can program myself out of a Hello World Contest!!
> There's very often not one solution to make everybody happy.
Expert mode and regular mode.
I miss being able to flip a switch and get a ton more options. Even when the expert mode is ugly as sin, its still better than erasing the options from the UI completely.
I think every project should fire all its members after four years. Then, a one-year "cooling-off period" during which no changes can be distributed. Dedicated members could continue working on something secretly during the cooling-off period, but they're gonna have trouble merging it if others are doing the same. On the fifth year, work can resume.
The cooling-off period gets rid of the twitter mob who is just around to discuss things endlessly and play politics. If nothing is happening, it's not very interesting. It also gets rid of developers that don't have any compelling ideas, just want to tinker with something they know well, vomiting code into it. Forcing them onto a new project should prevent what happened to Gnome.
The 4:1 cycle could be encoded into the license. "It is GPL, except on years divisible by 5 during which no one may distribute any version of the code or binary newer than the December 31st snapshot." It will take consent of all owners, or the "foundation" if developers assign their copyrights as SFLC suggests, to change that, so it will really stick.
Coming from the world of proprietary software, I was slow to accept open source. Given time though I became a fan of the GNU universe. From the start though I found Richard hard to take. In time Linux became strong enough to compete with OpenBSD and there the contest was between the egos of those two. This free enterprise-like competitive environment, both in systems and applications has resulted in a very rich choice of software available for us to use, free or otherwise. As far as the dynamics within development organizations, this is similar to the climate in early silicon valley where people with a better idea (or so they thought) would strike out on their own (we would call it forking a project). Some people lack social skills, or the balance between computing skills and social skills. Just because someone had a great idea and the computing skills to create a widely used program, doesn't mean they can exercise shared dominion over the project when it grows up. John draper is a good example of this. Surely a man with moments of genius, but in my opinion, no-one who should ever be managing others. Two factors seem important to me in the growth of open source projects. One is the emotional chemistry that bonds people together such that they are happy to donate time towards the project's goals. The other is the financial aspect, because some projects have financial needs to support healthy growth, and people with money have to relate to the project leaders if money can be expected to flow. There are people that wear suits and have technical skills, and they are very valuable to open source projects as well.
every human project follows the same path; first, a few committed brilliant individuals who share a common vision and work together well to achieve it. then, people get attracted who aren't quite as 100% tuned in, and things need to be managed a bit. then, people get attracted who just see something's happening and want to be attached to it, but not necessarily are any kind of positive contribution. finally, the idiots, crazies, psychopaths and criminals make their contributions. the history of every human endeavor; any given religion, country, charity, company, kid's playgroup, you name it.
Star Trek transporters are just 3d printers.
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.
at some point, it's easier just to quit yourself than purge the deadwood. you can't fight entropy.
Star Trek transporters are just 3d printers.
What exactly did Jono contribute to the Ubuntu Community? He took a huge paycheck ridiculed people publicly who had anything unfriendly to say about Canonical or Ubuntu and basically used Ubuntu to build his career up and get published.
The community is much more healthy now that he has gone and lets be honest Jono and Mark Shuttleworth forced out a lot of really talented contributors who put years of work into Ubuntu.
http://www.orafaq.com/wiki/FreeBSD - BTW - some of the stuff in Systemd might be good functionally, just in need of an open implementation... and be put on a serious diet!
When you tailor things for idiots, only idiots feel at home using it. When you actually make it a quasi-religion, you become an idiot yourself.
Yes, an advanced/expert button would have done it. But by that time, the "less-is-better", "our users are dumb people who cannot learn, instead of smart people that don't know how to use the system fully yet" mentaility had taken hold.
Dammit, good defaults are key. Uncluttered is excellent, and flattens the get-things-done curve, so it is good for newcomers. An advanced/expert tab or button hiding everything else keeps the braindamage "feature removal" dragon away, and keeps the top 10% power users on your side.
I don't know how people still manage with gnome, it actively gets in the way of getting work done. OTOH, more people using xfce, enlightenment, awesome, and other "lean and powerful" window-management/desktop envirionment engines can only be good for the environment (less waste of power) and skillset.
And there is still KDE for everything else, it may be weird, but it is not dumbassiffied yet.