Building Vibrant Open Source Communities

Building Vibrant and Sustainable Communities John Mark Walker openCollabNet Community Manager October 16, 2008

Building Communities
What is community building?
Building relationships with a critical mass of people such that these relationships may be leveraged for current and future business
Community development == business development for the 21st century
Your success now lies in the hands of people with a non-binding relationship to your business
How do you keep them engaged while attracting more to your community?

Community Best Practices
Lose the fear
Don't be afraid of a phenomenally successful community or project
Commonly heard (mistaken) phrases:
“But it will cannibalize our sales!”
“Our #1 competitor is our Open Source product”
Factor in the risk and go with it
Majority will happily use free product and never pay for it
While they may not buy from you, they're also not buying from your competitors
How do you attract a mass audience to your free project and still maintain a lucrative sales pipeline?

A: Don't be afraid to let your community develop its own identity
Lifetime community user will be different from your enterprise buyer
Will expect a more flexible, “hackable” product
Do not like to be forced into a particular approach
Bottom line: Community product will differ from enterprise product
This is an opportunity!
What's the biggest mistake companies make when differentiating between free and something to sell?

Community Worst Practices
Let's Design Our Project to Fail!
Boxing in your free product as a lesser competitor will ensure that it stays that way
It's a self-limiting, self-fulfilling prophecy
Free product Enterprise Product

What to do Instead?
Your community is where new things should be attempted
Your community is not the place to design all facets of a product by PRD
“Total Innovation Opportunity”
Maximizing of innovation points around your product offerings
Must increase the variety of people using your software
cross-section of users, developers, tinkerers, etc.

“Total Innovation Opportunity” continued
Maximize the points where your community participates in your project and product design
Different types of users will touch the product at different stages
A hacker / tinkerer / hobbyist might prefer a lighter-weight product in a less developed state
A sysadmin can make do with a product that works but requires some manual labor
Typical end user will want something that “just works”
Product development must capture feedback at each stage
All users will be capable of producing documentation

Feedback Loops
Feedback Loops
Tinkerers should be engaged with your engineering team
Do you have the mechanisms in place to allow for that?
Do you have projects of interest for them?
Sysadmins can engage with your developers, product management and QA
Are there adequate paths of communication between them?
End users can provide valuable feedback for QA and technical writers
So now what does our product visual look like?

Side projects in the
open
Freewheeling
community
Solid enterprise
product
Enterprise Product Free Product Experimental UI New, open API

Total Innovation Opportunity
New feature experimentation should happen in the community, where you can afford to make mistakes
Side projects can also take place in the community
May develop into product features, or not
Development should happen at a faster pace in the community
Corollary: development should happen at a much slower pace for your enterprise products
How do you identify which community participants fill which role?
Much of it will happen without your interference
However, demand generation does help – Eloqua, Loopfuse

That's great, but how do I get more people involved?
Be a part of the conversation!
aka, The Community Development Long Tail
Engage with outside groups
Recruit internally those with a voice (or can develop one)
Don't worry about strict adherence to corporate messaging

Community Development Long Tail
Where and How should I reach out to other groups?
Outside groups can be broken into 3 basic tiers
Tier 1: Groups with obvious connections - Partner companies, relevant consortia Tier 2: Groups with less obvious connections - Educational orgs, community-driven projects Tier 3: Find some common interests among your community members and invest in them

Tier 1 Groups
Most obvious and should receive the most focus
Should justify each example with tangible business opportunity
Tier 2 Groups
Community-driven projects related to your technology
May be a quasi-competitor
Educational organizations with a technical focus
Might be able to justify each example with future business opportunities
Tier 3 Groups
Driven by common interests of your community
Social causes, eg. political or charitable orgs

Rules of Engagement
Identify strategic groups within each tier
Within your organization find those who can express themselves
Engage in conversations in and around strategic groups
Blogs, social networking, community web sites
Sponsor events and groups as resources allow
Messaging is so 20th century
Not all conversations are going to adhere to your messaging
You need to be flexible, within limits
Train messengers in basics, and then turn them loose

Community Best Practices Enterprise Product Free Product Experimental UI New, open API Pol. org Char. org

Community Best Practices - Examples
Red Hat Software
Has successful enterprise product - RHEL
Has successful, growing community with its own identity – Fedora
Community product differs substantially from enterprise
Invests in social causes – OLPC, FSF
Leverages community value into $$$
But Red Hat is not my favorite example...

Community Best Practices - Examples
My favorite example – Google
Google's Open Source Program Office is a model to be emulated by tier 1 vendors
Google invests in many social causes
Invests in many communities, whether there is a direct relationship or not
Google Summer of Code
Community experience very different from their premium product
Net effect: developers around the world ready to pounce on initiatives like Open Social, Android, etc.
Net effect2: Google gets a pass for some PR miscues
Some press attention may be negative, but “people on the ground” very much revere Google

Potential pitfalls
Product differentiation is good, but don't go too far
Community users need a convenient path to enterprise
If you want people to buy from you, must give them a compelling reason
Don't over-invest in tier 2 or tier 3 community efforts
If your product doesn't give people value, they're not going to join your community
“Loose lips sink ships”
turning people loose on blogs is great, but make sure they have adequate training on what is and is not acceptable

Key Takeaways:
Creating an Open Source product means creating a different product, not just a downsized version of what you sell.
You must create an emotional tie-in between you and your community

Thank You Contact Info: [email_address] http://twitter.com/johnmark http://collab.net/community http://tinosc.blogspot.com

http://tinosc.blogspot.com	73
http://blogs.open.collab.net	14
http://www.johnmark.org	4
http://www.linkedin.com	2
http://tinosc.blogspot.com.br	1

Building Vibrant Open Source Communities

by John Mark on Dec 15, 2008

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 94

Statistics

Building Vibrant Open Source Communities Presentation Transcript