LCA: How to destroy your community

If you are a corporate developer, you're likely to realize early on that free software development communities are a pain. They'll mess up your marketing schemes by, for example, taking the software into countries where you have no presence and no plans. They'll interfere with product roadmaps with unexpected innovation, adding features which you had not planned for the next few years - or, worse, features which were planned for a proprietary version. Free software communities are never satisfied; they are always trying to improve things. They tend to redefine partner and customer relationships, confusing your sales people beyond any help. And they bug you all the time: sending email, expecting you to attend conferences, and so on. Fortunately, there are ways to get rid of this community menace. All that's needed are the following ten steps.

#1 is to make the project depend as much as possible on difficult tools. He noted that most companies have no real trouble employing this technique, since it makes good use of the tools they have around anyway. Community-resistant projects should, for example, use weird build systems not found anywhere else. A proprietary version control system is mandatory. Even better are issue trackers with limited numbers of licenses, forcing everybody to use the same account. It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find.

2: Encourage the presence of poisonous people and maximize the damage that they can create. There is a special technique to the management of these people which goes something like this:

1. Take pains to argue with these people at length and to denounce them on the project lists.

2. Eventually, they should be banned from the community by fiat; it's important to avoid any sort of community process here.

3. The banned people will take their flames elsewhere. Follow them and continue to argue with them in those external sites.

4. Eventually the community will complain about this behavior; respond by letting the poisonous people back in. Then go back to step 1 and do it all over again.

Properly managed, one effective poisonous person, according to Josh, can wipe out a community of hundreds.

3: Provide no documentation. There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM.

4: Project decisions should be made in closed-door meetings. An OK start is to have online meetings with very short notice, though, for best effect, they should be at a time which is inconvenient in the time zones where most community members are to be found. Better is to have meetings via conference call: that excludes about a third of the planet due to sleep requirements, and, for extra value, also excludes a number of people who are at work who might have been able to participate in an online meeting. Best, though, is to hold meetings in person at the corporate headquarters.

5: Employ large amounts of legalese. Working with the project should involve complex contributor agreements, web site content licensing, non-disclosure agreements, trademark licenses, and so on. For full effect, these documents should all be changed without notice every couple of months or so.

6: The community liaison must be chosen carefully. The optimal choice is somebody reclusive - somebody who has no friends and really doesn't like people at all. Failing that, go with the busiest person on the staff - somebody with both development and management responsibilities, and who is already working at least 70 hours per week. It's important, in this case, to not remove any of this person's other responsibilities when adding the liaison duty. It can also be effective to go with somebody who is unfamiliar with the technology; get a Java person to be the liaison for a Perl-based project. Or, if all else fails, just leave the position vacant for months at a time.

7: Governance obfuscation. Community-averse corporations, Josh says, should learn from the United Nations and create lengthy, complicated processes. Keep the decision-making powers unclear; this is an effective way to turn contributors into poisonous people. Needless to say, the rules should be difficult or impossible to change.

8: Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything; that will drive away contributors who like the current license without attracting anybody who might like the alleged new license.

9: Do not allow anybody outside the company to have commit access, ever. There should be a rule (undocumented, of course) that only employees can have commit rights. Respond evasively to queries - "legal issues, we're working on it" is a good one. For especially strong effect, pick an employee who writes no code and make them a committer on the project.

10: Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all.

Josh concluded by noting that he saw all of these techniques employed to great effect by Sun. But Sun is far from alone in this regard. Josh has been told by a veteran of the X Consortium that they, too, had made good use of all ten methods at one point or another. Community-destroying skills are widespread in the industry.

But what if you have a different kind of company, one which wants to encourage and build communities? Doing the opposite of all of the above clearly makes a lot of sense. But, Josh said, it all really comes down to trust. A relationship with a development community can be seen like a marriage: one can spend years building it up, but one affair will kill the trust it is based on. Similarly, a company can lose half of its community in a weekend. Those who would avoid that fate must trust their communities and act in a way which will cause that trust to be returned.