This session, attended by a good-sized audience of, I guesstimate, about 175 people and titled “Ten Ways to Destroy Your Community,” was described as follows:
“In this session, open-source-community expert Josh Berkus shares his 10-step method guaranteed to wipe out your community and bring your project back under control. Spread a little weed killer before that community growth gets too fast. Learn important tips and tricks from someone who has participated in some of the most unsuccessful open-source communities both inside and outside Sun.”
Josh spoke as someone who has been there and knows, who’s grown wiser – but alas, the thing to do with dysfunction and misery is convert it to knowledge to be passed on to others to make their lives easier. All suffering can be redeemed. And a little wry wit and irony helps get you through. I found it easy to see how human emotion could get the better of communities and lead them to get stuck in the madness he described.
Berkus consults with companies who are attempting to open source software and has a lot of insight. The fact that it’s the kind of insight that seems obvious after it’s articulated makes it no less useful. The fact that he presents his session as a way to do what we don’t want to do makes it fun, and perhaps, easier to own our more destructive tendencies.
Anyway, here are The Ten Ways to destroy an open source community:
1. Use difficult tools
2. Encourage poisonous people
3. Don't document anything
4. Conduct closed-door meetings
5. Use lots of legalese to confuse, alienate and intimidate people.
6. Have unresponsive liaisons who lack authority and competence.
7. Engage in governance obfuscation
8. Screw around with licenses
9. Stop outside committers
10. Be silent
Defining the Problem: Community
He began by pointing out the problem – community. “When you open source your software, you will contract a horrible disease that you will never get rid of, which is called ‘community,’” said Berkus. “You may attract and be unable to get rid of a community that will do horrible things to your ability to get things done. Communities do things without telling marketing and distribute information in places you cannot anticipate. Members of the community engage in public speaking you never authorized, and people randomly want to contribute code to your product related to things you never anticipated. Suddenly you have to work into your software things you never wanted. Communities want software to get better all the time; if you can’t do it, they will make it better on their own. Once you have an OS community, you cannot define the difference between a customer and a partner. People who were customers contribute to your software, making them a partner; and people who were partners start buying stuff from you that they don’t want to work on which makes them a customer.”
He shared his “patent-pending Ten Step Method guaranteed to destroy your open source community.” He promised that the method is so powerful that implementing even three of the methods will “keep you in development and marketing isolation for a long time to come”.
Herewith are comments on a few steps that especially got my attention.
Difficult Tools
Deploy weird, dysfunctional and outdated systems on all forums and sites. Be sure to use proprietary version control systems and single-platform conferencing software.
Poisonous People
Poisonous people are people who need to pick fights over trivialities, make ridiculous demands and get indignant when they are not met, and generally drain and demoralize everyone. Berkus showed how to make best use of their talents. You should argue with them at length, then denounce them venomously, then ban them from all sites and forums. They will go off to other forums to denounce you. Follow them and attack them there until your company begins to look like a jerk and gets criticized. Then allow them back in the project and begin the process over. (I couldn't help but thinking of some forum discussions in relation to this point.)
Never Document Anything
Do not document: the code, the build methods, the submission and release processes or how to install. And if there are any questions, always tell people to, “Read the f***ing manual.”
Bad Liaison
Berkus said that nothing is quite so satisfying as working on a project where it is absolutely essential to liaise and coordinate with other people in a different part of the organization, only to discover that they won’t answer your email or keep forgetting who you are. And when you finally get things moving, you discover that they have no authority to give you what you need.
Legalese
Open-source developers both fear and hate legalese, which makes it a perfect instrument to intimidate and alienate them. So make legal documents and language as long and complex as possible with contributor agreements, website content licensing, non-disclosure agreements, trademark licensing terms – and double up on your investment by changing all of these randomly without informing anyone.
Government Obfuscation
In case you find the words “government obfuscation” a bit obfuscating, here are the three principles to adhere to:
1. Decision making and elections should be extremely complex and lengthy;
2. Make it unclear what powers community officials and committees actually have;
3. Make governance rules nearly impossible to change.
All in all, a fun and useful session. And, if you want to go at this subject the other way around, I found it amusing that Josh ended his session by telling folks to stick around in the same room for the next session which was on, guess what, how to build communities. Interesting order for these two sessions :)
See Also
Josh Berkus’ Blog
2008 JavaOne Conference
Janice J. Heiss
“In this session, open-source-community expert Josh Berkus shares his 10-step method guaranteed to wipe out your community and bring your project back under control. Spread a little weed killer before that community growth gets too fast. Learn important tips and tricks from someone who has participated in some of the most unsuccessful open-source communities both inside and outside Sun.”
Josh spoke as someone who has been there and knows, who’s grown wiser – but alas, the thing to do with dysfunction and misery is convert it to knowledge to be passed on to others to make their lives easier. All suffering can be redeemed. And a little wry wit and irony helps get you through. I found it easy to see how human emotion could get the better of communities and lead them to get stuck in the madness he described.
Berkus consults with companies who are attempting to open source software and has a lot of insight. The fact that it’s the kind of insight that seems obvious after it’s articulated makes it no less useful. The fact that he presents his session as a way to do what we don’t want to do makes it fun, and perhaps, easier to own our more destructive tendencies.
Anyway, here are The Ten Ways to destroy an open source community:
1. Use difficult tools
2. Encourage poisonous people
3. Don't document anything
4. Conduct closed-door meetings
5. Use lots of legalese to confuse, alienate and intimidate people.
6. Have unresponsive liaisons who lack authority and competence.
7. Engage in governance obfuscation
8. Screw around with licenses
9. Stop outside committers
10. Be silent
Defining the Problem: Community
He began by pointing out the problem – community. “When you open source your software, you will contract a horrible disease that you will never get rid of, which is called ‘community,’” said Berkus. “You may attract and be unable to get rid of a community that will do horrible things to your ability to get things done. Communities do things without telling marketing and distribute information in places you cannot anticipate. Members of the community engage in public speaking you never authorized, and people randomly want to contribute code to your product related to things you never anticipated. Suddenly you have to work into your software things you never wanted. Communities want software to get better all the time; if you can’t do it, they will make it better on their own. Once you have an OS community, you cannot define the difference between a customer and a partner. People who were customers contribute to your software, making them a partner; and people who were partners start buying stuff from you that they don’t want to work on which makes them a customer.”
He shared his “patent-pending Ten Step Method guaranteed to destroy your open source community.” He promised that the method is so powerful that implementing even three of the methods will “keep you in development and marketing isolation for a long time to come”.
Herewith are comments on a few steps that especially got my attention.
Difficult Tools
Deploy weird, dysfunctional and outdated systems on all forums and sites. Be sure to use proprietary version control systems and single-platform conferencing software.
Poisonous People
Poisonous people are people who need to pick fights over trivialities, make ridiculous demands and get indignant when they are not met, and generally drain and demoralize everyone. Berkus showed how to make best use of their talents. You should argue with them at length, then denounce them venomously, then ban them from all sites and forums. They will go off to other forums to denounce you. Follow them and attack them there until your company begins to look like a jerk and gets criticized. Then allow them back in the project and begin the process over. (I couldn't help but thinking of some forum discussions in relation to this point.)
Never Document Anything
Do not document: the code, the build methods, the submission and release processes or how to install. And if there are any questions, always tell people to, “Read the f***ing manual.”
Bad Liaison
Berkus said that nothing is quite so satisfying as working on a project where it is absolutely essential to liaise and coordinate with other people in a different part of the organization, only to discover that they won’t answer your email or keep forgetting who you are. And when you finally get things moving, you discover that they have no authority to give you what you need.
Legalese
Open-source developers both fear and hate legalese, which makes it a perfect instrument to intimidate and alienate them. So make legal documents and language as long and complex as possible with contributor agreements, website content licensing, non-disclosure agreements, trademark licensing terms – and double up on your investment by changing all of these randomly without informing anyone.
Government Obfuscation
In case you find the words “government obfuscation” a bit obfuscating, here are the three principles to adhere to:
1. Decision making and elections should be extremely complex and lengthy;
2. Make it unclear what powers community officials and committees actually have;
3. Make governance rules nearly impossible to change.
All in all, a fun and useful session. And, if you want to go at this subject the other way around, I found it amusing that Josh ended his session by telling folks to stick around in the same room for the next session which was on, guess what, how to build communities. Interesting order for these two sessions :)
See Also
Josh Berkus’ Blog
2008 JavaOne Conference
Janice J. Heiss
Subscribe