Ten Ways to Destroy Your Community
Note: these are live notes. It was a great talk, I’d rate it as excellent (and I’m not just saying that because Josh and I work in the same group at Sun). I’ll have to also comment on his thoughts and talk, in due time. MySQL, as an open source project, has a lot to learn.
Ten Ways to Destroy Your Community
A How-To Guide
Josh Berkus, Community Guy
Part 1: The Evil of Communities
- you may attract and will be unable to get rid off a community
- they mess up your marketing plans, because the community goes out and does its own marketing and PR and distributes your software in places you didn’t expect to
- they also mess up your product plans, because they contribute to code and features to your project, with unexpected innovation!
- communities are never satisfied by any amount of quality and keep wanting to improve it – if you can’t make it better fast enough, they sometimes do it on their own!
- you have to re-define your partner and customer relationships… people who were your customers start contributing to your project, sort of making them partners… “confuse your salespeople” :)
- the worst part about having a community, is that they require to you communicate constantly (and who has time for that?). Emails, chat channels, web forums, you get constant pestering
10 Ways to Destroy (The Berkus Plan, Patent Pending!)
1. Difficult Tools
- weird build systems
- proprietary version control systems
- limited license issue trackers
- single-platform conferencing software
- unusual and flaky CMS
This will limit attracting new community, and eventually people will get frustrated with the tools and go away.
2. Poisonous people
Maximise the damage they do – argue with them at length! So if people give you problems, continue feeding the trolls. Then denounce them venomously, and finally ban them. Josh then goes into a funny way of making use of poisonous people, which eventually leaves your team and the troll(s).
3. No documentation
Don’t document the code, build methods, submission process, release process, install it.
4. Closed-Door Meetings
Short notice online meetings are good. Telephone meetings are even better, because of timezones and limited conference lines. Meet in person, in your secure office, is the best way! (even if you dial in on a conference line so that others can here). People that are most involved will leave your project right away.
5. Legalese, legalese, legalese
The longer and more complex the better! Hate and fear of attorneys help drive people away from your open source project. Contributor agreements that are long/complicated, with unclear implications are particularly good. Website content licensing, non-disclosure agreements (NDAs) [European developers usually never sign an NDA], trademark licensing terms (name and logo of your project… good way to dissuade people). Used properly, you can use legalese to keep out developers!
Bonus: change the legalese every couple of months without informing folk!
6. Bad liaison
A bad liaison/community manager is someone reclusive (least social, hates answering email, unplugs phone regularly, etc.). Also, someone with no time works very well. They’ll spend a few weeks, but pretty soon they’ll give up, and if you’re really lucky they’ll be snappy and make bad comments to the community!
Assigning someone with no authority also helps. As a community manager, you have no chain of command, and you just get to deliver bad news (we decide, and you just say something). That person usually leaves your company, and becomes a poisonous person, and its a win-win.
Someone unfamiliar with the technology also helps. An open source Java project, getting a PHP programmer, is the best person for you :)
Having no liaison also helps. Refer to the project liaison, but have no one!
7. Governance obfuscation
A good model for this is none other than the UN (He has a slide on the UNDP).
Get your legal team to write a governance document. Like they’re dealing with a hostile outsider. You’ll be impressed what they come up with!
Three principles:
1. Decision making and elections should be extremely complex and lengthy
2. Make it unclear what powers community officials and communities actually have
3. Make governance rules nearly impossible to change
8. Screw around with licenses
Licenses loosely translate to Identity. You’re not just a Linux contributor but a GPL person… You’re not just a PostgreSQL contributor but a BSD person…
9. No outside committers
I. No matter how much code outsiders write, only employees get to be committers. This is a surefire way to annoy contributors eventually.
II. If they ask why they’re not being able to commit, just be evasive! Talk about needing a mentor, decision not made yet, etc…
III. Make sure there are no written rules on who gets to be a committer, or that the criteria are impossible to fulfil.
IV. Bonus: promote an employee who doesn’t code to committer! Most will get disgruntled by this and go away and they’re not your problem anymore.
10. Be silent
He demonstrates out live, by giving him a minute… what silence really is. Just do nothing, be really silent.
Q&A
How does Sun score?
All of these techniques have been successfully employed at open source projects at Sun and elsewhere. He gave this talk at a Sun internal event and people came up to him asking if they were talking about their project! Sun is scoring pretty well, but not necessarily any better than other corporations.
I missed the question, but the answer was: If you are fast and clear about explaining mistakes, communities tend to be forgiving.
Examples of a successful community?
Kernel.org, and the Linux kernel community.
What about using forking to destroy community?
Combines poisonous people and playing with licenses. It fragments the outside community as people have no idea which to use. You can’t plan a fork (as it requires a lot of motivation to do the fork – finding people with that level of commitment and masochism is hard). Keep your poisonous people around and encourage them (poisonous people who are also code writers), then you sort of foster their image in the community by giving them a voice, and if you do something to really mess with the community’s mind (say a change of license), then the poisonous person will take the project and fork it.
The other way of forking, is to take a legitimate outside developer, build them up, and then after they have become a major developer, abruptly lock them out. The danger here is that they might not fork the project, and change the project back…
How do you prevent companies from supporting your project? Because this also means more developers will come to your project. And these companies are now selling services around your product.
Monkeying around with licensing. Then you change the commercial services around that. The second thing to prevent ISVs, is to play around with trademark rules, and lots of legalese. Prevent them to get code into your project, that should help too.
