Inderjeet Singh's Blog

Can GroupThink result in poor decision making in strong open-source communities?

I recently came across a great article on GroupThink of Irving Janis. GroupThink is a behavior pattern that results in inferior decision making by a group of smart people when the cohesiveness of the group is too high. It happens because of a strong desire of the people to preserve the harmony in the group even if at the cost of better decision making.

Open-source projects are also typically run by groups of smart individuals who all have come together to solve a common problem. Sinc the team is working towards a shared goal, often voluntarily and to attain a higher ideal, the cohesiveness can be high. Moreover, for certain high-profile projects, the desire of the group members to remain associated with the group is strong because it gives them prestige and satisfaction due to the project's impact on the society.

As the article describes, cohesion in the group is a necessary but not sufficient condition for GroupThink. It also requires structural faults in the group because of poor leadership, lack of process and norms. Finally, for the group to slide into GroupThink, a provocative situational context needs to exist such as a recent failure, high stress or low self-esteem.

Have you seen an open-source group slide into GroupThink? Have you had experiences in an open-source project where the group collectively made some poor decisions just to preserve the group harmony? Share your thoughts as comments to this blog! Thanks for reading.

Comments

• Funny, the first groupthink example that popped up in my mind was the decision to go with erasure for Java generics. It must have sounded like a good idea at the time, and the schedule pressure probably gave little chance to reconsider. I think this was a weakness of the closed JSR model, and a more open decision making process might have averted it.

  Posted by: cayhorstmann on February 06, 2007 at 06:44 AM

• Ugh, I think I have. After time there comes a moment where you realise that the technology may be very open to being fixed but the group can't. Im not sure if there is a magical formula for what to do at that point. Weighing the situation in hand: very very small developer group, alot of ideas that I want to bring to fruition, good capabilities in working with the code... time to plan out and start a fork.

  leouser

  Posted by: leouser on February 06, 2007 at 07:03 AM

• Not only the technical aspect, but also the cohesion of the group gives value to an open source project. It's always a "small steps all together" vs "lonewolf" battle.
  But when you're leading an open project, you simply can't pretend that all people are aligned with the best skills present. It's not easy as in a company.
  For example, you shouldn't start to modify all the code you feel is "bad", because someday people could tell you "ok, superman... continue alone!". :-)

  Posted by: bitog on February 06, 2007 at 07:15 AM

• The recent and excellent book "The Trouble With Physics" by Lee Smolin discusses groupthink in the context of high energy physics and the recent history of string theory. Here is a quote :

  "If a highly disciplined subject like physics is vulnerable to the symptoms of groupthink, what may be happening in other, less rigorous areas?"

  ...Also, there is a synonym for groupthink, which I find pleasingly descriptive : "consensus trance".

  Posted by: johanley on February 06, 2007 at 03:20 PM

• Groupthink is often caused by strong leadership imposing their will on their followers who are afraid of the consequences (loss of status, being seen as idiots/heretics for questioning the Great Leader) of questioning that leadership for whatever reasons.
  So yes, it is likely very common in the open source community where a small group of people with Names rules the more prestigious projects. Being thrown out of such a project because you disagreed with the Boss may well seriously hurt your career, your financial future, so you're likely to go along with him even if you know he's wrong just to preserve your position within the group.
  

  Posted by: jwenting on February 06, 2007 at 10:33 PM

• Part of why I do open source work is to write code with a different set of compromises than I have at work. I get to explore areas either with one or two people I trust, or as a "lone wolf," and I get to decide when to compromise completeness vs. when to do a release. I'd be miserable working on an open source project with people who fall into a consensus trance. I'd probably ditch the project and do something fun instead.

  Has anyone seen open source projects die because people quietly drift off? That'd be a symptom you would see less of at work.

  Posted by: dwalend on February 12, 2007 at 05:58 AM

This work is licensed under a Creative Commons License.