Cookie Lickers, Headless Chickens & Other Open Source Troublemakers
BURLINGAME, Calif. -- OPNFV Summit -- Open source projects can attract toxic personality types -- and well-meaning bad influences -- along with other problems that can send them off in the wrong directions. Red Hat's Dave Neary laid out some of the problems, and how to fix them, in a breezy talk here at the OPNFV Summit.
"Some people with the best of intentions engage in behaviors that harm the community," said Neary, a member of the open source and standards team at Red Hat Inc. (NYSE: RHT) He added that he's engaged in some of this non-productive behavior himself at times.
Comms companies are increasingly participating in open source projects as they seek the agility and innovation required in the New IP economy. But they can encounter pitfalls along the way.
Neary started by describing the Cookie Licker. This person is like a child who's too full to eat any more cookies, but doesn't want other kids to get the last cookie, so the child licks the cookie and puts it back on the serving plate.
In open source communities, the Cookie Licker over-commits. "They say, 'I'm going to do this,' and two months later, nothing happens," Neary said.
These are, however, often the best and most valuable members of the community, he said.
"I know that I have exhibited this behavior in the past," Neary said.
The Cookie Licker knows he can do something twice as good as anyone else, and may be right. But "half as good and iteratively improved by others is better than not done at all," Neary said.
The Cookie Licker is acting with the best intentions. They truly believe they can make time.
The Cookie Licker problem can be solved by setting deadlines and milestones and taking the problem away -- without any blame -- when the Cookie Licker misses a deadline or milestone, Neary said.
Headless Chicken communities, meanwhile, lack direction. There's a lot of activity, but nobody can tell where they're going, Neary said.
Bike Shed Discussions plague communities that are Headless Chickens, Neary said. He explained that the expression "bike shed discussion" came from a construction project to build a nuclear reactor costing hundreds of millions of dollars. The committee overseeing the project flew through the discussion quickly, because the issues were confusing. But then came time to decide on how to build a bike shed next to the reactor for commuting workers. There, the committee discussed materials and other issues in great detail. "You end up having a half-hour devoted to a $200 bike shed," he said.
Mob Rule takes place when the strongest and loudest members of a project have the most power, rather than the most productive members. The solution there is strong leadership -- not leadership by the loudest, Neary said.
Alpha Males can sabotage a group by talking too much, monopolizing discussion. "If you want to speak and the alpha male is [dominating discussion], raise your hand," Neary said. "Rather than entering the game of having two people exchanging like verbal ping-pong, raise your hand and keep it politely raised."
Command and Control projects develop when a single vendor controls interest in an open source project, Neary said. Symptoms are when community members have to sign copyright agreements and assign work to the vendor, but the vendor doesn't assign back to the community. Also, in these projects, all contributors are often from the same company. The projects don't release public roadmaps, but they do release new versions every six months without any visible sign of development work.
The treatment for Command and Control is to define policies for community access, generate public roadmaps, and exchange influence for control, Neary said.
Projects operating in secret are operating in Smoke Filled Rooms, Neary said.
A related problem is the Water Cooler, where project participants who work for the same company, or in geographic proximity, meet together and talk face to face to hash out problems. Problems need to be resolved publicly, in the group, even if it takes longer, Neary said.
The Shy Developer Syndrome afflicts developers who are uncomfortable talking on mailing lists.
The Big Reveal is the end result of projects worked on in secret. The solution to the Big Reveal is to hold discussions in public forums, on public mailing lists and IRC; post code publicly, and give all stakeholders an opportunity to contribute.
Shy Developer and the Big Reveal are all aspects of Fear of Community, the opposite of Mob Rule, Neary said. These problems occur when open source community members don't really trust the process.
Finally, Broken Windows takes its name from a 1980s theory of law enforcement: Enforcing laws against petty crime like writing graffiti can reduce big crimes, like murder. Likewise, if a building has a broken window that goes unrepaired, that encourages others to throw more rocks and break more windows.
"If your standards slip on something like the wiki, you end up with the wiki quality quickly degraded. If you allow threads to go off-topic or become abusive on a mailing list [or IRC], you find the general tone of the community goes down quickly," Neary said.
The treatment for Broken Windows is to document best practices, warn offenders early, and spread policing responsibilities around, because nobody likes to always be the bad guy, Neary said.
"Communities are emotional places," Neary said. "A lot of this is human."