Once More unto the Breach

Open Source Communities and Customers in Pictures

[Update (19-Nov-2010, 15:41 GMT): Voici une traduction en Français par Philippe Scoffoni.]

[Update (11-May-2010, 10:37): Matt Aslett posted commentary on this post at the 451 Group CAOS blog.]

Debate continues on whether open core business models are a winning strategy with a capital "w" or not, and whether customers care. Matt Aslett's recent excellent posts continue the discussion. The big concern for those that criticize or express concerns is that customers are mis-lead, essentially that there's a bait-and-switch free-versus-product or a deliberate lack of clarity in the marketing around the product value.

I want to take a different approach to the discussion here. Before we had Internet-sized bandwidth on which to collaborate around software, traditional software business looked something like the first diagram. R&D delivered product. Marketing delivered messages. Sales and marketing managed and qualified leads through a pipeline and if the product solved a customer problem properly, a market was made and you could measure the profits.

The Internet happened, dramatically removing friction from the process of collaborative software development and delivery. Developers could share the economic cost of software creation (innovation and construction) and large repositories of useful building blocks were born and made available through these project-focused communities. The Web accelerated the early Internet trend.

Companies began to form around some of the projects and for the past decade and a half there's been confusion as people debated how to make money when you give away the software, or the other side of the economic equation around variations on why people work for free. This has unfortunately led to the idea of community and customer interaction akin to the following diagram. The community is jammed into the middle of the customer pipeline. The community gives stuff to R&D which still delivers product. Marketing now messages to customers AND [worse] the community, and the company tries to "convert" the community into customers.

This probably started around the time that MySQL AB observed they had a paying customer for every thousand downloads. This mis-set expectations in a fundamental way. People assumed causality. It created false metrics around driving downloads and improving conversion rates. (We'll come back to this ....)

Marten Mickos (while CEO at MySQL) observed that the early community has time but no money while the later community has money but no time, and that his customers are in the latter bucket. This is the start of a better model for understanding community and customer. Let's use the "time is money" line as the division between community and customers because by forcing the separation of the two groups we can add clarity to both and the things a business would need to do differently with each.

Instead lets treat the community (time but no money) as a completely separate entity from the customer pipeline (money but no time). The community members engage with R&D over the project. They engage with marketing in a conversation about project direction, and ancillary things like translations in other markets. Customers are qualified through the pipeline based upon the product.

Indeed you can start to see how to think about these different groups of people using different well understood and documented processes for community development and sales channel management.

This allows you to clearly address each groups's selfish needs.

Community	Customers
They have time but NO money	They have money and no time
They want a problem solved and look to the project	They want a problem solved and look to the product
They can’t be converted	Your Community is the litmus test of solution viability.
They can contribute time, so: What do you want them to do? What do you need to enable? What do you need to let them know?	You manage leads through the qualification pipeline and conversion process like any other customer-focused sales process
They will not waste time, so the project needs to solve a problem for them before they will invest themselves in it

Product for customers is clearly differentiated from project and community. How the product is differentiated depends upon the company and the value proposition to customers. At it's simplest, the product may be a supportable and maintained collection of software, certified to run on specific supported platforms and with particular applications, and trivially installable. The product may be the support and maintenance itself. Some companies pack more "enterprise ready" marketable differentiated features or attributes into the product. Others (e.g. Red Hat, JBoss, MySQL) develop a valuable network offering that includes support, maintenance, certifications, additional warranties, monitoring, indemnifications, and the like into a single subscription model. Regardless, there is well-defined value that solves a customer's problems.

Companies like Alfresco and Hyperic and JBoss all saw conversions in the pipeline because potential customers came to the web site, learned what they needed to learn, downloaded the appropriate things to try, and used the community as a litmus test of the solution before returning (self-qualified) to buy product.

This visualization also clears up debate about "open source" and "community". Some companies publish their product source code under open source licenses and never try to develop a real community. There's nothing wrong here if indeed they're running a more traditional software business model and don't care specifically about enabling the community to directly engage with the project. Publishing the software is a sign of strength and confidence in their product and their ability as a company to satisfy customers with a valuable solution that is more than just the software.

Some companies also develop large successful communities without ever publishing their product software. This is why community building is so important for your company and why community development is an essential ingredient in your solution pitch to customers. Communities historically anchored your customers. Communities create knowledge, expertise and experience, all necessary to provide a complete solution for your technology pitch to the customer. Communities create advocates and evangelists to spread awareness about your solution. Communities create enormous inertia in the status quo around your technology. This is why companies like Microsoft invested millions in developing the Microsoft Developer Network (MSDN). It has taken more than a decade for other Internet communities around interesting open source projects to wear down the inertia inherent in MSDN. Likewise, IBM has invested enormous amounts of money in the IBM Developer Network, incorporating free and open source software to meet their solution needs and value propositions to their customers. With open source projects relating to your company, the community is anchoring your solution.

This is the real "conversion". The community enables customers. It is correlative not causative. Community members that have solved their problems using your technology base will carry their excitement, knowledge, and commitment into new places where customers exist. With well organized open source communities, the community now fronts your technology to new customers as well as later anchoring customers once they exist.

Conversion Rates (Again), Open Source Business Execution, and JBoss

Readers know I disagree with the facile answer that businesses that use open source software need to "convert" their user community into customers. I've laid out my concerns in two blog posts over the past couple of years (here and here). Today, reading Matt Aslett's (always useful) 451 CAOS Links I came across this gem from David Skok on developing the JBoss business pipeline.

If I had to summarize my overarching concern with conversion discussions (and wearing my customer hat), it's that sales and marketing types confuse conversion with selection. They're trying to jump start leads by applying historical pre-web lead qualification thinking in a world where the web allows potential customers to self-educate and then self-select. The process and thinking that goes into this JBoss case study isn't simply good for open source related business strategy. (I really wish we'd had this level of process and the tools to support it 15 years ago when we started Softway Systems.) Quotes that stood out for me:

The first question we looked at was: Did they know the names of the people that had downloaded their software 5 million times? The sad answer was no. Not only did SourceForge not allow them to collect names, but even if they did allow it, there was clear evidence that developers would simply not go through with the download if they were asked to provide their name.

Following one of the key principles of this methodology, we immediately realized that they needed to find a motivation to get the customers to provide the company with their contact information. The best motivation appeared to be the documentation, that they were currently selling. There was one big problem: selling the documentation was resulting in $27,000 per month in revenue, which was paying the rent and several peoples’ salaries. To me it was obvious that this was a small price to pay to get the names, but to the JBoss team, who had battled their way to get every dollar of revenue, that was less obvious. We debated this issue over the next three months, but finally they gave in and switched on the offer. It turned out to be a huge success: over 10,000 leads started pouring in every month. Over time this grew to 16,000 leads per month.

And ...

Later on the process, JBoss was able to look back at the customers who had actually bought the product and close the loop, by testing whether they had predicted the right events as qualification events. They did a lot of analysis to refine the events based on this information. Several of the original assumptions, based on common sense, turned out not to be true. For example, the amount of time that a lead spent on the website had little impact on their likelihood of becoming an opportunity or a closed deal. The same was true for time spent using the Wiki or the Forums.

Here was a process used specifically to "weed out" (qualify) customers from the noise of lead potentials in user and developer communities using the web site. The entire article is worth reading and careful consideration within your business. This is how JBoss "went on to reach an annualized bookings run rate of about $65 million a year within two and a half years after starting the process." Execution requires the right team, but it also requires the right process.

Making Money from Open Source and the Business Model Debate

Matt Aslett makes great observations about open source business models in a recent blog follow-up discussion:

I am very glad that they took that decision, because in hindsight the statement “there is no open source business model” would have been inaccurate in the context of our report. We identified that there are multiple models used to build a business around open source: theoretically hundreds.

The 451 Group did a lot of research as they developed their model of discussion, and their definitions around development model, license choice, and revenue trigger are great. But it still feels like they start falling victim to the shades of grey slicing problem.

I'm still more of a fan of the tool analogy. As a company, you have a certain budget to spend developing the product, it's marketing, sales and distribution. Imagine a proper old hardware shop where you have a certain budget and need to figure out how you're going to spend to buy what tools from which aisles (development, marketing, sales, legal) to launch and build (and maintain) your product. "Open source licensing" is a set of new tools in the legal aisle and "collaborative community development" is a new aisle. It's not that there are hundreds of business models, but rather one can combine the tools in hundreds of ways. (Some ways are more proved than others depending upon the business.)

Indeed, "dual licensing" doesn't even belong in the open source licensing tools. It's an attribute of copyright law. I can license my intellectual asset to as many people as I want in as many ways as I choose. The Microsoft EULA attached to software at the local office supply store is different to the Enterprise Agreement signed when a corporation purchases based on a bundle of units and services is different again from a volume license to a smaller organization. No one accuses Microsoft of "dual" or "multi-licensing" their software. The fact that MySQL began closed licensing royalties as well as selling service agreements subscriptions (i.e. product) of their GPL distributed software does not mean that they invented "dual licensing".

The fundamental question around which this all revolves is the confusion embodied when one asks, "How can you make money when you give the software away for free?" Large "software" companies (Microsoft, SAP, Oracle, Adobe, etc.) have spent a lot of time questioning the scale of "the business model(s)" rather than looking at the opportunities the tools provide. In the end, they need to understand that it's not the "software" that a customer is buying but the solution and the support and maintenance and certified tested warranted removal of risk embodied in their product packaging and testing capabilities. (This is a core competency Microsoft has over most "software" companies when you consider the size of the test matrix defined by OEMs, ISVs, and device manufacturers that needs to be exercised between code complete and release-to-manufacturing.) Whether you call it a "license" fee and then charge 20% of the license fee per year for maintenance, or distribute the "license" fee into the maintenance "subscription" over time isn't a discussion about open source. It's just business.

Open Source Business Models Redux

I debated again yesterday with a colleague on open source business models. I don't believe there is such a thing. Several well documented models have been articulated and debated (see Matt Aslett, Roberto Galoppini, Carlo Dafarra for excellent cogent examples) but when you get into the discussion it immediately degenerates when you try to assign certain companies to certain models. It degenerates further when you try to invert the discussion to argue that these stylized business models share attributes or can be applied together when discussing example companies. To me it's a useless rat-hole of a discussion.

It confuses audiences into thinking "open source" (or "free software") is different in a business context. Such confusion:

• Slows adoption by customers.
• Causes investors to hesitate.
• Can lead inexperienced start-up executive teams to chase ghosts instead of focusing on the business at hand.

Here's how I tried to articulate the counter-debate yesterday:

1. Customers buy solutions. In the immortal words of Theodore Levitt (Harvard Business School), “People don't want to buy a quarter-inch drill. They want a quarter-inch hole!”
2. Geoffrey Moore wrote "Crossing the Chasm" in 1991. As well as clearly articulating the Technology Adoption Life-Cycle (that he has evolved over the ensuing ~20 years), it helps people understand that developing a "whole product" offering (the core product and its complements) provides a better solution to customer needs and companies in a market that provide the best whole solution succeed better than their competitors and peers.
3. For technology solutions companies, there are a well understood collection of tools that product development management uses to deliver solutions.
• Buy or build complements and include them in the base product.
• Publish interfaces to encourage complement value add in an ecosystem of partners.
• Provide tools and frameworks to ensure partners can easily build complementary products in the ecosystem, providing an even bigger "whole solution" or enabling it to be re-positioned into new markets (i.e. onto new problems).
• Publish tutorials, how-tos, books, etc. to ensure people understand the product solution and can provide complement value add in the ecosystem. And publish here is a very loose word. Consider magazines and conferences and user groups here as well, and how the web helps or supplants each. The web removed enormous friction from this collection of related tools.
• Develop training programs to ensure people understand the product solution.
• Develop certification programs to ensure a good supply of knowledgeable people on the solution.
• Provide consulting services to ensure an immediate supply of knowledgeable people on the solution. Really though it could be other services as well (maintenance, repair, operational, etc.)
4. Companies can choose to sell (or license) the complement or give it away. In each case there's an opportunity for direct or indirect revenue. As long as the sum of the revenues is greater than the sum of costs of providing the whole solution (and operational margins are within tolerances specific to the "tool" or tactic or mix in the portfolio) the company is profitable and thrives. [Indeed, over time as value moves around the solution network — and it's a network not a stack — companies have a better chance of survival if they control more of the higher margin pieces of the network that is their whole solution or ecosystem. Think IBM with the breadth of whole solution they can deliver posting better than expected results September 2008 as the rest of the economy tanked.]
5. The larger the company, the more tools it likely uses in providing a whole solution. Maybe this is the corollary to the above statement. It certainly explains why we all rat-hole when trying to fit large complex companies into the stylized business models.
6. Adding open source licensed software repositories on the web and collaborative community development into the mix adds new tools, and evolves old tools:
• To "buy" vs "build" for complement value add, you can add "borrow" (IBM Websphere and Apache, and Red Hat and RHAS) and "share" (IBM and the original Eclipse project, and Intel and moblin).
• New companies (Red Hat) with lower margin business models (compared to the incumbent) can use F/OSS components to rapidly develop products that either serve new markets or serve the bottom end of an over-served market and then evolve over to or up into an incumbent’s market space. [Classic Christensen economics here.]
• It broadens the base of "users" which opens future customer opportunities and locks out competitors. (JBoss and MySQL used this tool.)
• Companies that participate in communities:
• Can rapidly develop complements to core offerings in their solution network (without necessarily building complete products), e.g. SAP and MaxDB and MySQL
• Can amortize dev/support/maint costs of software components across customers/partners/competitors (e.g. the vendors in the Linux Foundation today are no different than the vendors in the OSF 20 years ago sharing the development costs of OSF/Motif and OSF/1 as royalty free base technology).
• Get to interact directly with like-minded customer prospects in community, influencing customer/partner developers.
• Build brand awareness and trust through transparency of actions.
• Companies that participate deeply in communities better influence those communities (e.g. participate, hire, or acquire).
• Companies developing their own communities increase the opportunity for partners to provide complement value add as well as encourages engagement and commitment through participation and contribution.
• Companies can use F/OSS projects to reduce the cost of sales by allowing users to try and pre-qualify themselves as customers.
• F/OSS projects are an interesting publication strategy against competitors from an IP strategy perspective.

What all of this means is that the ideas need to be turned around. Technology businesses and technology adoption is well understood. We know how to measure successful companies and compare them. We understand the tools those businesses use to engage customers and solve problems. Open source software is a key economic driver from an engineering efficiency and software reuse perspective, but it also opens new opportunities and additional tools for product management to engage better with customers and improve both the top line and the bottom line.

But there is no open source business model.

SourceForge Acquires Ohloh!

First, congratulations to Scott Collison (Ohloh CEO) and the Ohloh team. [Caveat lector: I've been an advisor to them for some time.] It's a great exit for a great little company. As with all the companies I advise, there needs to be something unique going on. Ohloh has always been unique. As I described in January:

When a potential open source user wanted to find out "what open source software is available" to solve a problem, they were invariably left hunting across Google, SourceForge, and sites like java-source.net and FreshMeat. There was no consistency. The depth of information was sketchy. Some of it was bleeding edge software, some tied to the site. There was no sense of "what's good" unless you were already involved in a particular community, and even then community bias could get in the way. This gave way to a collection of directory solutions and companies that tried to bridge this gap.

Ohloh has always had the most useful and interesting directory for me. First, they have no direct sales model tied to the directory, so my trust in the depth and breadth of the information is high. Second, the beauty of the analysis is that the core data is metrics based on what programmers do, not what they say. I can see how big or small a community is, how long it's been around, how active it is, and this provides hard data when one then looks at the qualitative commentary. Third, it's always been comprehensive across the open source world and getting better all the time.

...

Over their several year history, they have continued to expand and add features to their core statistical analysis. They've built the community and expanded the number of repositories they support. Once one finds a project, one can see other projects immediately that are related through the tagging and stacking other Ohloh users share. The site is a proper social network for open source developers. It's been used to get a project manager's view of an open source project by the project's own leadership. As a resource for job hunters and recruiters it's invaluable to be able to see the visual resume of a developer. They've evolved their offerings to act as download host, and provide job and support services classifieds.

In one commentary, Jon Sobel (SourceForge group president of media) made reference to "Another advantage for SourceForge ... is that Ohloh's data will help the company deliver advertising that is more targeted and effective." This is the real key to the acquisition. A primary revenue driver for SourceForge is advertising across the forges and online media properties. Ohloh has been successfully developing a data service that would wildly improve the ability to target technology advertising and provide data rich feedback for high-tech marketing campaigns. [Frankly, Google should have acquired Ohloh.] They have a number of large corporate customers. So through this acquisition:

• Ohloh can improve SourceForge's advertising revenues.
• The Ohloh data service itself provides an excellent additional revenue stream in the high-tech corporate marketing world.
• The Ohloh community site is complementary to SourceForge's forges, providing open source communities better tools for understanding their projects.

This is a great acquisition for SourceForge. Hopefully along the way, the original and unique aspects of the directory that make it so valuable to open source users (as opposed to open source developers) are not destroyed or lost, and that SourceForge continues to recognize the difference between the core data competency Ohloh represents, the core value proposition to SourceForge's customers, and its complementary uses as a separate directory at strengthening the SourceForge brand in non-revenue producing ways.

Other commentary:

• The official press release
• Matt Asay's interview with Jon Sobel, SourceForge group president of media
• Ars Technica Article

Partner Programs and Open Source Software Businesses

I was discussing partner programs with colleagues the other day. Partner programs tend to need careful thought — much more than many young companies realize. The simplest summary I can offer is that partner programs aren't about marketing — they're about sales, which means they're about compensation plans and metrics aligned with those plans.

Four years ago when Optaros announced what it was doing (consulting services based on open source building blocks) many companies approached us to "be partners". This meant everything from at its most innocent "let's share leads and swap logos" all the way to "Optaros would be a great sales channel for our product." All this requires (a.) a lot of time, and (b.) needs to be tracked against revenue. As a channel, it needs management just like a company's sales team does, so you can figure out who is really performing and so as to get rid of the non-performers. We did sign several light weight partnerships (i.e. logo swap and a joint press release) in the first year because it gave us a press release with a high profile (i.e. newsworthy) partner. We expected nothing else from the partnership — no leads, no co-marketing, no co-sales. Some partners never called with leads despite promises and follow-up from us. They did, however, call to give us a hard time if they heard us using a competitor's project/product to solve a problem for our customers. Obviously our customers were more important to us and our revenue than the partners lack of leads/revenue. [To be clear, Optaros has strong partner management in place and developed a number of excellent partners over time with strong complementing business relationships.]

Aside from the day-to-day management, you also need to ensure there's no channel conflict. You will encounter problems with partners where their business development people may love you, but their sales force may never think of you because:

• You're not helping them meet their quota
• Worse, your product/service competes with the higher margin items they sell to make their quota
• They'll take a lead from you, but have no need to return the favour on their way to closing their quota. (Contrary to popular belief, they will not call you because they like you — they are sales people and there needs to be some bottom line benefit to calling you because otherwise you're taking away valuable time from them making their quota and "salesperson of the month/quarter/year" and the perks attendant on that title. These are highly competitive revenue-focused individuals. Good sales people in a channel conflict won't call because it wastes their time.)

Business development managers that don't sell for a living don't necessarily understand the channel conflict problem. They also might be compensated on something like "partner satisfaction" or "# partners signed", etc., rather than on revenue numbers. Not only that, if the partnership is one sided (they get sales, you don't) they still may not care. Partner programs aren't worth anything if the channel and compensation programs aren't well-aligned to mutual benefit.

Gaining visibility through partners is an interesting idea and a Big Name Partnership MAY help as a marquee sort of "partner" regardless of sales, but THEN you need to ensure you have a solid business development person on their side that will speak GLOWINGLY on your behalf to potential investors or act as a direct customer reference to close a deal. That's when they count. Otherwise, you're lost in a sea of all their partners. [Softway was a Microsoft partner back through the late 1990s before the acquisition. It was a fascinating relationship when it came to getting them to admit that they wanted to see UNIX/Linux applications running natively on Windows NT.]

I'm not saying don't set up a partner program — I'm saying set one up with your eyes wide open and with a realistic eye on the revenue that could otherwise be gained by (for example) hiring another sales person rather than a partner manager. Once you understand exactly how you want to make revenue directly for yourself, you can better determine how to organize a partner program (by region, by vertical, by function) such that your needs and your partners's needs and compensation are properly aligned and your partners trust you to not conflict.

Photo by Robert Scales

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.

Cloudera Launches Around Hadoop

Copyright Peter DaSilva for the New York Times

Congratulations! Cloudera launched today to bring Hadoop to the enterprise. It's anchored by Mike Olson, Christophe Bisciglia, Amr Awadallah, and Jeff Hammerbacher. Hadoop is the open source project that implements MapReduce, the algorithm that allows companies like Google and Yahoo (and even Microsoft) to search cheaply and easily enormous quantities of data and assemble the results. As most enterprises don't have the sort of operations staff that a Google might have, Cloudera will provide enterprise qualified software, training and consulting.

I've known Mike for a long time now since his days as CEO at SleepyCat before they were acquired by Oracle. I had the pleasure of working with Christophe as a speaker at the inaugural Open Source Forum at the Beijing Software Innovation Summit in China a couple of years ago while he was still at Google. It was Christophe that put together the original training program around Hadoop for university students. Congratulations and best wishes!

P.S. Christophe seems to have gone all corporate with his hair.

The launch video on YouTube

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.