Once More unto the Breach

I've Joined the CodePlex Foundation as it's Technical Director

All: I've joined the CodePlex Foundation starting Monday, 17 May as the Technical Director reporting to the executive director. My responsibility is to set the strategic technical direction of the Foundation, and work with the gallery managers and project leaders on a day-to-day basis. I'm excited about this. I believe the CodePlex Foundation has a great role to play as we continue to see more and more commercial organizations participate in open collaborative software development.

The CodePlex Foundation exists to encourage and support the creation of more open source software, specifically working with commercial organizations. People have shared software since we started programming computers. The sharing bandwidth used to be mag tape sized packets and conference schedule delivery rates. Now we have the Internet which changed the dynamics and economics dramatically. Historically, software foundations tied to free and open source software grew to support a particular licensing scheme or project technology community. I think the CodePlex Foundation complements existing organizations quite nicely. The Foundation is an excellent opportunity to broaden the contribution base from commercial organizations and I want to ensure processes and education are in place to enable those contributions.

My first order of business will be to meet with the existing gallery managers and project leads to begin to put in place any process and services they urgently need. From that point forward it will be to help define and shape the rest of the project and IP management processes that are needed to make the Foundation's value proposition a reality for new sponsors and contributors.

A few friends and colleagues have asked what it means for Microsoft's open source initiatives. I don't know. I certainly don't speak for Microsoft. The CodePlex Foundation has a very straightforward mission and I work for the Foundation. Microsoft is the first and founding sponsor, essentially putting their money where their mouth is with respect to managing their own contributions. I expect there will be more sponsors and participants over the coming year and my goal is to enable them all.

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.

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.

Berkus's Ten Ways to Destroy Community and Bacon's Art of Community

This was a great week for reviewing "community building" resources in my world. I discovered Josh Berkus's recent Java One presentation, "Ten Ways to Destroy Your Community", and I received my reviewer's copy of Jono Bacon's "The Art of Community". [srw — I was a pre-publication reviewer for Jono.]

Berkus's presentation is absolutely brilliant. After pointing out very tongue-in-cheek why your community is such a painful group of people (e.g. "They mess up your marketing plans by doing their own marketing and PR" or "They mess up your product plans with unexpected innovation"), he proceeds to give you a perfect run down of ten ways to be rid of them with excellent examples. In order:

1. Difficult Tools
2. Encourage Poisonous People
3. Don't Document Anything
4. Closed Door Meetings
5. Lots of Legalese
6. Bad Liaison
7. Governance Obfuscation
8. Screw Around with Licences
9. Stop Outside Committers
10. Be Silent

The sad part of this list is how true it is. While Josh picked examples from his experiences, too often you visit a site to evaluate a company-led (or consortia-led) open source project to find too many of these counter principles in play.

Jono's book was published last Summer. His lyrical metal prose conveys his brilliant experiences over past years in community involvement, then community development, culminating in one of the best led community examples around Ubuntu. While Jono's eleven chapters don't align neatly with Josh's ten weapons of mass distraction, there is method and madness to attack each of the problems (or hopefully to avoid them altogether).

1. Difficult Tools [Chapter 5]
2. Encourage Poisonous People [Chapter 9]
3. Don't Document Anything [Chapters 3-5]
4. Closed Door Meetings [Chapter 3,4,8]
5. Lots of Legalese[Chapter 8]
6. Bad Liaison [Chapter 11]
7. Governance Obfuscation [Chapter 8]
8. Screw Around with Licences [Chapters 1,2,8]
9. Stop Outside Committers [Chapters 4,8]
10. Be Silent [Chapter 3]

If you need a quick litmus test to check on your community, read the presentation. Once you [honestly] suspect there may be a problem [or two], dig into book. Enjoy.

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.