By Jonathan Corbet
January 18, 2010
Josh Berkus is well known as a PostgreSQL hacker, but, as it happens, he
also picked up some valuable experience during his stint at "The
Laboratory for the Destruction of Communities," otherwise known as Sun
Microsystems. That experience has been distilled into a "patented
ten-step method" on how to free a project of unwelcome community
involvement. Josh's energetic linux.conf.au presentation on this topic was
the first talk in the "business of open source" miniconf; it was
well received by an enthusiastic crowd.
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:
- Take pains to argue with these people at length and to
denounce them on the project lists.
- Eventually, they should be banned from the community by fiat; it's
important to avoid any sort of community process here.
- The banned people will take their flames elsewhere. Follow them and
continue to argue with them in those external sites.
- 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.
(
Log in to post comments)