Once More unto the Breach

The Community Leadership Summit and the Art of Community

Good community leadership is desperately needed. Too often companies mistakenly think of it as some small adjunct to marketing, an extra channel over which to broadcast messages and through which to generate leads. Likewise product engineering can equally confuse community purpose and disrespect its impact, relegating it as "beta tester" or ignoring its contributions with Not-Invented-Here blinders. We've understood community since before we climbed down from the trees, and we've understood the social dynamics: despite our best intents every village has its idiot and every playground has its bully. But when community in its truest collective sense meets business, we seem to forget all our lessons and expect something to manage with the efficiency and efficacy of a time-motion study in an automobile factory.

This weekend, 18-19 July 2009, marks the first Community Leadership Summit in San Jose, California, at the San Jose Convention Centre (McEnery Conf Centre). Jono Bacon, community leader for Ubuntu at Canonical, Ltd. has done amazing work organizing the event and it promises to be a great opportunity to share experiences and learn from one another. It is a free event in front of O'Reilly's Open Source Conference, supported by a small savvy set of vendor sponsors, but the event is about community development experience and not any one vendor's take on it. While free, one should go to the registration page to register.

Jono has also been busy this past year writing "The Art of Community". He developed it over time in conjunction with the Art of Community blog. I was a reviewer, and I think it's an excellent book covering the breadth of the subject. It will be available in August, and you can pre-order it here.

I was hoping to participate in this year's inaugural summit, but unfortunately I'll not be attending it (or OSCON) for several personal reasons. I will certainly miss friends and colleagues, but trust next week will be as brilliant as always!

The Microsoft SD Forum Open Source Event

Microsoft and the SD Forum jointly sponsored the Zero Day event this year before the Open Source Business Conference. The past two years this has been a Microsoft sponsored day for ISV partners developing businesses around open source. There was time dedicated in each event to presentations of the relevant Microsoft programs for ISVs, and Sam Ramji would kick off the day with a good Q&A session discussing Microsoft's positions, accomplishments, and announcements around open source software. This year the content was broader, with the afternoon's sessions being organized by the SD Forum. Participants that wanted to engage with Microsoft around their programs could talk with any of the program directors present.

This being the age of Twitter, people were encouraged so to do under the tag #msoss09, and there was some reasonable discussion throughout the day. I also posted a few photographs on Flickr.

www.flickr.com

Bryan Kirchner is now Director of Open Source Software at Microsoft. He acted as master of ceremonies and kicked things off in the morning with a brief discussion of his hopes to continue developing a mutual understanding and deepening relationships with the open source community at large.

Sam Ramji then took the stage. What followed was interesting. This year, with not much new or contentious before OSBC got underway, he chose to talk about the health of the Windows ecosystem in the context of the current economic crunch (reminding people that a staggering 96% of Microsoft revenue comes from partners, i.e. no direct account control). Microsoft is seeing CIO training budgets dropping to zero and many projects are deferred so there was a definite move to cost savings around virtualization and consolidation. (It's interesting that this is how the world started to move when the bubble burst seven years ago.) He also talked about the growth of Windows in the low cost server space and on netbooks. Sam was essentially conveying that the Windows platform is healthy and people should continue to consider it as a deployment platform for open source. He also discussed the new Web Application Gallery initiative at Microsoft as an attempt "to connect markets and forges" around open source so users can easily install and support PHP-based web applications. It's not that the Gallery is particularly an open source initiative, but rather that it supports the sharing of applications written in PHP.

Matt Aslett from the 451 Group took the stage next presenting his latest analysis from their report Open Source is Not a Business Model. Essentially, the 451 Group analysed 114 vendors using open source software within their businesses, against (i.) their choice of open source license, (ii.) their development model, (iii.) their own vendor licensing strategy, and (iv.) the actual revenue trigger. Matt's blog post covers a lot of the ground he presented, so I won't cover it here. I will be debating with him soon on other things to consider in the report. (An added perk for morning participants was a copy of the report.)

Next up was a panel on "Working together in an Open Source World in a New Economy" moderated by Cliff Reeves, who runs the Emerging Business Team at Microsoft which runs the BizSpark program. Panelists included:

• Clint Oram, VP Product Management, SugarCRM
• Erica Brescia, CEO, Bitrock
• Aaron Fulkerson, CEO, MindTouch
• Dan Merrits, VP Marketing, Eduify

It was a good discussion. SugarCRM and Mindtouch certainly saw the rise of downloads and leads as the economy failed and people became more interested in low cost open source based solutions. There was also interesting honest discussion from the participants on what it's like working with Microsoft as a partner, with concerns being expressed about the complexity of the programs at times, as well as praise for engineering support (FastCGI and PHP being the typical example cited).

After lunch we got to the more general open source part of the program organized by SD Forum. Larry Augustin kicked off the afternoon with his keynote on "The Future of Software: Why Open Source is the Safe Bet". [Larry has kindly allowed me to host his slides. Download SDForum-20090323-v4.pdf (493.5K).] Larry started the presentation with the idea that just like no one got fired for buying IBM in the past, at this juncture in history no one gets fired for buying open source software. He then went on to present the health of the open source based business world from the perspective of investment and adoption (with several case studies).

Next we had two brief mini-talks.

• Andrew Aitkin (Olliance Group) talked about his views on open source adoption differences between Europe, North America, and Japan.
• Sam Ramji returned to give a shortened version of his morning's presentation for those that just joined for the SD Forum part of the program.

The final two sessions of the day were panels. First we had "Is there still Open in Open Source" with Mike Fauscette (IDC) moderating, and Jack Repenning (CTO, CollabNet) and Adam Blum (Rhomobile). It was an interesting panel and very much a development process perspective. Discussion revolved around the idea that it's not about the source code, but about the openness of the development process, the social contract, the transparency, and building a community that wants to contribute.

Last up was the venture panel on "Where's the Money?" Mark Radcliffe (DLA Piper) moderated Robert Theis (Scale), Andrew Braccia (Accel), Tim Guleri (Sierra), and Peter Sonsini (NEA). Not surprising but the VCs want us to know they're still open for business, and they're interested in Software-as-a-Service and Cloud related technologies. Also not surprising we learned VCs will fund deals with a compelling solution to a customer problem, or a compelling way to monetize a solution. [This is why I generally don't have a lot of time for VC panels.] There was one point where Peter Sonsini (NEA) observed there needed to be a compelling way to monetize the community for an existing project (with which I violently disagree), but Andrew Braccia (Accel) supported the richer idea that rather than trying to monetize the community one should look at upstream value of a new solution based on the project.

All and all a worthwhile experience. We finished the day with the hosted reception!

Does Your Community Manager Report to Engineering or Marketing?

I asked a question during Matt Aslett's excellent presentation on Monday at the Microsft/SD Forum OSBC Zero Day event: Does your community manager report to engineering or marketing? Matt gently stepped out of the way, but there is exactly one right answer: Engineering.

Here's why:

Community is concerned with the software project and it's complementary assets. Customers care about buying product solutions to their problems.

Engineering cares about software development. Marketing cares about product lead generation and qualification.

Engineers manage software. Marketing manages messages and expectations.

This doesn't mean that the community isn't an enormous source of word-of-mouth evangelism for the company, the project brand, and self-qualified leads over time. But the community doesn't want messages and they don't want to be qualified or converted. The community is already setting their own expectations around the project instead of buying the product. Neither does this mean that marketing is out of the loop at developing inbound requirements from customers for the engineering team as they develop the software that feeds into the product.

While marketing traditionally managed the "developer network" in closed source companies, that's because the software wasn't a community engagement mechanism for users that weren't customers. Growing the developer community around your platform was a marketing function based on the business strategy of growing market share and providing complement value with lots of "knowledgeable developers" for customers. The software part of the solution wasn't a source of customer contribution, innovation, and testing resource. Your community equated to your customers.

There are companies that historically have strong product management departments that are often staffed by engineers that have crossed the floor to marketing. There's still a problem here with the community manager reporting to marketing, because the marketing department is traditionally measured on marketing functions. They will behave against how they're measured.

So community development and management is an engineering function.

More on Open Source Conversion Rate Myths

A year ago I posted on open source business practices and conversion rate myths. A colleague asked yesterday whether we shouldn't still use it as a measure until a better one is found, since it's the best we have.

The problem isn't that it's a poor measure, but I believe it's a wrong and misleading measure. It is NOT similar to lines-of-code in software engineering (a poor measure). Variation in LoC is still within a few percentage points when you resolve for the project differences. Conversion rate is orders of magnitude different between companies. Business measures are typically within percentage points. Think of ratios like gross margin. They vary between types of businesses by as much as 30% but within an industry they're pretty steady and act as a benchmark.

Using a wrong or misleading measure will put you in jeopardy if you're the marketing or community manager. (You're being judged against the metric.) If you distribute for "free" as open source software, you capture your user base depending upon how good you are at getting the word passed onward. If you're good, you build community around your software. Remember software only forms part of the value network that is your solution — and customers buy solutions to problems. Mårten Mickos well observed that your early community is willing to trade time to save money and your later community is willing to trade money to save time — and the later community contains his customers. The observation implies a timeline for community growth depending upon the software project. Companies starting a business around a new project need to be sensitive to this. Customers (people that are going to buy something) will use free access to test that your software might solve their problem before they pay for your solution.

Many users in community do not have money to spend today. They can't be converted. As a "lead" they will never become a "qualified" lead, and getting in their way trying to sell to them will only be a source of frustration for everyone involved. BUT while in a normal proprietary software company this means you've disqualified someone that isn't a customer in the pipeline, in the open source corporate world, I believe they sit in a different process. Instead of a manufacturing metaphor (pipelines) we need a more organic social metaphor to track success and growth of the community. Lead generation is a measure of community engagement. You want to grow your community. Customers will self-qualify.

This WILL be reflected in a number of downloads, but this is correlative not causal, and it's an ambiguous metric. It's very software function dependent. If a user downloads one copy and installs it on a hundred machines, your knowledge is already off by two orders of magnitude — counting downloads is useless.

The greater user community still needs care and feeding because they contribute code, bugs, time to answer one another's questions, beta bodies, and interesting applications of your software you may not have thought about or had time to develop yet. They are a source of innovation, not simply within the software (small contributions) but at the solution level. They will tell your BUSINESS new places to go to capture money in the network around your software. These are very valuable people. Growing your community is important for this reason. Don't simply measure downloads and compare to a number of customers. Measure everything you can think of about your community:

• Unique members on the forums.
• Time to answer a question (internally versus community). [And don't reward your employees for answering quickly or your community will never get a chance to answer.]
• Number of code contributions.
• Number of bug reports.
• Number of documentation contributions (howto, tutorials, etc.)
• Feature requests.
• etc.

For numbers that tie back to specific releases of software, use them to tune your engineering process, i.e. involve your users in your engineering process. Consider letting USERS vote on importance of bugs so they feel a part of the process. (Don't draw the line between customers and users. It will be tempting, but customers probably buy something else from you in their solution. Disenfranchising users is disenfranchising the larger community of interest and probably a false feature.) Engage their time (appropriately) and you will win community mind share. Mind share is everything for profitability. It's the stickiness. It will create customer advocates.

There will come a time when the users move to other organizations bringing their knowledge with them and the new organization will self-qualify to become a customer. Or the user's own company grows to a point that they become customers. But they don't "convert" in the traditional sense. The lead did not become a qualified lead and you don't need to "sell" to them to convince them to buy your solution. They have internal needs that makes buying your solution more important than using your software. I'm betting those internal needs are very function-centric (e.g. one company will buy JBoss support while using RHAS for free). Determining those functional decisions in relation to your solutions will give you better insight into how to grow your customer base, i.e. revenues, without sacrificing your community in "conversion" games.

This comic is licensed under a Creative Commons Attribution-NonCommercial 2.5 License from xkcd.org.