There is no mysterious monolith of Open Source Community. Given this, what are some best practices for establishing and growing open source development and distribution communities? Here's what was talked about at OSBC West:
This bunch of community experts was moderated by Peter Fenton of Accel Partners:
- Ranga Rangachari, CEO, Groundwork Open Source Solutions
- Dan Frye, VP Linux Technology Center, IBM
- Adam Trachtenberg, Manager of Technical Evangelism, eBay
- Clint Oram, Co-founder, SugarCRM
- Mike Olson, CEO, Sleepycat Software (acquired today by Oracle)
Frye started out by defining a couple of community categories that the panel seemed to agree on:
- Communities built around a single commercial effort or a single individual. Most of the work here is done by a few people.
- Communities that work around many different commercial interests.
These two models are both effective, but are used for different things. There are also differences in governance models. IBM learned the hard way that it is hard to start communities; it's much easier to join and adapt to communities.
The most important thing in building a community is to ask yourself what someone would get. Why would they join? Frye reminds us that the number one rule of open source development is that 'everyone scratches their own itch.'
Grand myths surround how much open source code is contributed by the community. Sleepycat's code is almost all developed by staff, and the panelists all felt that no company has more than ten percent of their code contributed from outside the company.
What helps communities develop best? Oram says that hosted collaboration tools such as SugarForge are what really kicked things off. Trachtenberg cited eBay's large user community as being more important than the developers; the latent demand for web services from the users is what drove eBay to open things up to and initialize their developer community. (Access to eBay development platforms used to cost a good amount, and has been getting closer and closer to free each year.)
Fenton wondered - is there a linear relationship between development costs and the cost of fostering these communities? eBay looks at questions such as how much more would sellers sell, if they used an easy tool instead of having to go through an 8-page form? They've also noted that 45% of their listings go through a listing service, but that more specifically, 24% go through a third-party listing service. You can point to these numbers to show how providing access to outside developers has been profiting eBay.
What backfires in the community? Olson felt that what Sugar did right was the collaboration infrastructure. But when Sugar focused inward to get operations up, they just let the community sites sit out there and run themselves. There was a backlash - people wanted to know where the core developers were, and why they weren't they participating in the community? Had Sugar sold out the community in order to focus on the commercial aspects of the business? This happened over just three months, and forced Sugar to reprioritize.
Some VCs, according to Fenton, think that open source represents a radical new distribution
model, since you already have a relationship with potential buyers via
the community. Olson sees a false dichotomy here. There are different
assumptions underlying the various open source models and associated
types of communities. Vendors need to think hard about what's right
for their solution. Also, foundation open source projects function differently. Olson sees that you can build different communities and leverage them
in different ways, but you need to communicate purpose clearly up front, and not
shift the community's purpose midstream.
Frye thinks that the goals of distribution,
development, beta testing, etc. all require very different communities, but
that you can't build a community towards any of these goals specifically. You
have to attract constituents to your community, and then work with the members as it becomes clear what the community wants to do around your product. Communities don't
seem to mind monetization as much if it provides the community with leverage without taking away
control.
What about the customer in all this? Rangachari believes that customers don't care where the product comes from, so long as it provides value. Customers still believe that you get what you paid for. Fenton sees customers segmenting themselves out; some are willing to pay, some will never pay.
Olson reminded the audience to be careful when mixing free and professional sales models. Keep the two activities separate - commercial activities in one sandbox, and community activities in another. SugarCRM tries not to upsell from its free services. When you need the community, you don't want backlash from customers that just want the solution and not the support. In particular, the pure open source community is not a channel.
Sleepycat CEO Olson addressed the concerns about what hapens when a large company takes over a small project (ha). It's an art to speak to free users and see who would be willing to buy the paid version. There are certainly open source community members who object to a company making profits; and you must make room for them in the discourse or risk alienating the larger commuity. Large vendors must remember to either be quiet or be constructive in the midst of a community flamefest. The panel also felt that a community's fundamentals would not change if the buyer was a closed-system vendor, presuming that community management was not altered. As the financial structures change, continued penetration can still occur.
It was interesting to learn that licenses, since they affect community governance, must be carefully considered as a facilitator for the type of community interaction you are looking for. SugarCRM decided that things would never take off unless there were opportunities for everyone to make money, not just the original author of the product. They believe that this is what helped them to build out a vibrant ecosystem.
This was a very enlightening exploration of community - in particular for my own work, as I look at bottom-up media and other forms of user content that are abolutely dependent upon community engagement. What lessons can we learn?
Tags: christine herron christine.net space jockeys osbc community open source technology
