Josh Berkus on how to destroy a community

It's been interesting to see a large number of non-technical open source presentations at Java One this year. It's a sign that indicates that not only has Sun embraced open source, but they are also attracting a new audience that is interested in open source. It's not quite OSCON, but it's definitely a more diverse audience than just a few years ago. Josh Berkus, Sun Community guy, gave a tongue in cheek discuss

It's been interesting to see a large number of non-technical open source presentations at Java One this year. It's a sign that indicates that not only has Sun embraced open source, but they are also attracting a new audience that is interested in open source. It's not quite OSCON, but it's definitely a more diverse audience than just a few years ago.

Josh Berkus, Sun Community guy, gave a tongue in cheek discussion about how to destroy your community. He made the point that many companies that start to adopt open source like the licensing model and the distribution mechanism, but don't know quite how to deal with community. It's something that many companies are not used to and they wonder if there's a way to not have to deal with this ever-demanding group. So to meet that challenge, Josh defined his own ten-step patent-pending (and don't think he won't sue you) method for destroying a community.

1. Difficult tools

Such as weird or obscure build tools, CMS systems, issue trackers, etc.

2. Encourage poisonous people

Argue at length with trolls, then denounce them and kick them off the project. Eventually it will drive everyone off the project.

3. No documentation

Don't document the code, it just clutters up the code! Or change things as soon as you document them.

4. Closed door meetings

Schedule meetings on short notice or only with your company staff. That way you will drive out any outside participants.

5. Lots of legalese

Make complex contributor agreements, web content licensing, and non-disclosure agreements. That will inhibit people from contributing.

6. Bad liaison

Make someone reclusive, too busy, with no authority or mismatched technical skills to do the job. That way they won't get it done right and will probably manage to piss-off everyone. Maybe if you're lucky they'll become a poisonous person.

7. Governance obfuscation

Make a complicated committee structure, perhaps borrowing from the UN, to have a structure that no one understands. Make decision making complex and lengthy so know one can understand it. 8. Screw around with the license

Even just threatening to change the license can drive people crazy.

9. No outside contributors

Don't make it clear how outsiders would be able to contribute code or become a committer. For example, you can use a catch-22 rule that the only people who can be committers are those that have, ah, committed code already.

10. Be silent

Perhaps the most powerful technique --as powerful as all the others combined. Just don't communicate to anyone about anything! If there's no dialog, it's hard for anyone to participate.

Josh's perspective is particularly appropriate for community-led development, but some of the lessons also apply to company led-projects. And most of the lessons are also helpful in starting or growing a community of users. Of course, the real idea is to *not* fall into the trap of these points and instead try to create a community that works with you. Does it require more communications and more transparency? Of course. But it's part and parcel of being open source.

Can you please everyone in the community all the time? Doubtful. Different people have different objectives, whether they are users, developers or business partners and sometimes those objectives come into conflict. But they key lesson is operating openly and with transparency. Communicate, listen and refine.

Related: