Once More unto the Breach

If We've Won, Why Are We Still Explaining Open Source?

At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source license. That's all really. Indeed, the last paragraph of Klint Finley's (@klintron) otherwise excellent article gets it wrong when it says, "But by moving programming languages and other core developer technology into the realm of open source, companies like Apple can provide some assurances that developers will be able to adopt these tools to their own needs without facing legal action." Not even a little bit true. The risks are all still there. Another company could still happily sue the living daylights out of anyone they believe to be infringing their property.

And it's not simply the community and legal basics people continue to misunderstand. There's still a surprising lack of understanding in companies big and small about the business and economic basics. John Mark Walker (@johnmark) recently completed a brilliant four-part series of posts outlining the basic "how to make money" with open source. The opening paragraph to the series begins:

"I never thought I’d have to write this article in 2015. By now, I thought it would be self-evident how to derive revenue from open source software platforms. But alas, no. Despite the fact that the success of open source software is unparalleled and dominates the global software industry, there are still far too many startups repeating the same mistakes from a thousand startups past. And there are still far too many larger companies that simply don't understand what it means to participate in, much less lead, an open source community."

I encourage you to find time to read all four posts [1][2][3][4]. While John Mark presently works at Red Hat, a company that deeply understands the business of open source, his experience goes back almost 20 years to when he worked at VA Linux. 

Companies are indeed contributing more and more to software licensed as open source. Google is building a community around Go and last year began a community around Kubernetes. Go is certainly an interesting language growing in popularity, but Kubernetes represents a decade of Google research and experience in deploying, managing and orchestrating application containers at a time when the industry at large is just catching up. Apple will launch Swift into the public eye. Even Microsoft has learned that they must engage differently with developers and has published .NET (for the second time) late last year. It is no longer about broadcast communities like MSDN.

Building community is where the work gets done for a company sharing assets and collaborating around software, and building community is hard work. There are lessons for Apple to learn and quickly. To build a community, it has to be blindingly easy to engage. The software needs to download and build to a known tested state on a known platform (ideally many) if you want developers to spend time. Otherwise your project becomes one more moribund collection of software thrown over the wall onto github or SourceForge that will frustrate developers and finally chase them away. There are a well known set of patterns and practices that work to enable and build successful communities. This isn't a secret.

And early communities are skittish fragile things. I was part of the original publishing of .NET under an academic research license. There are lessons here for Apple in how to get it "right". We published roughly a million lines of code for the C# compiler, Base Class libraries, and Common Language Run-time (and a complete platform abstraction layer, and a full test harness). Once a developer unpacked the source archive, it was a two [simple] line sequence to build and then test the components into a known state on Windows, Mac OS X, and FreeBSD. The two pages of documentation essentially told you how to do this small amount of work to get to a guaranteed known state, how to prove it running the sample code, and gave a brief discussion of the source tree so people could quickly begin to explore it. [There’s a good description of the original project on MSDN.]

Within 24 hours we received our first righteous patch. A simple 15 line change that provided a 10% boost in Just-in-Time compiler performance. And we politely thanked the contributor and explained we weren't accepting changes yet. Another 24 hours and we received the first solid bug fix. It was golden. It included additional tests for the test suite to prove it was fixed. And we politely thanked the contributor and explained we weren't accepting changes yet. And that was the last thing that was ever contributed. This was done with malice of forethought. And it was heartbreaking. The project was still successful for what it was -- a research platform for programming languages, but it never became a collaborative community around the platform itself. At the time, Microsoft was still very concerned (and conservatively hyper-cautious) about how close the academic code base was to the mainline .NET product space.

So I wish Apple well. It's great to see them participating more broadly in this particular space. They will have challenges in community building, getting the governance right, and thinking through how they want it to contribute to the business. Fortunately there are lots of excellent resources for them to use as they join the broader open source community. Maybe we’ll even see folks from Apple at this year’s Community Leadership Summit. Because as we all know, collaborative innovation is the new engagement mechanism.

"The Internet was Secured by Two Guys Named Steve"

Jim Zemlin has always been quotable. His keynote at this year’s Linux Collaboration Summit provided a great summary (as always) of the growth of the Linux ecosystem, but also focused on the serious problems in the security of the Internet in an era when key breaches have their own branding and logos. [Think Heartbleed and Shellshock.] He ran through some scary facts:

• OpenSSL secures most of the Internet and the small team at the OpenSSL Foundation (including the “two Steves”, Steve Henson and Steve Marquess) were only pulling in about US$2000 in donations per year. 
• Theo de Raadt supports OpenSSH part-time. 
• Harlan Stenn “runs the clocks on the Internet”, i.e. he’s responsible for ntpd, and until recently was earning about US$25K/year. 
• Werner Koch maintains GnuPG, which secures a lot of email and provides the confirmation that a software package is what it says it is. According to a recent interview, he was going broke. 

Before readers unversed in open source software get concerned with the security of open source software, let us remember this is a software problem, not an open source problem. Closed proprietary products have their share of exploits, etc.  But with open source licensed software, the broad community can do things. 

It is perplexing that if Linus’s Law is true, “Given enough eyeballs, all bugs are shallow", then such security problems persist.  Jim suggested as he gave the above examples that “there just aren’t enough eyes.” I’d offer a corollary. I think vibrant projects live a culture of review before code gets committed.  I think this is because the developers have perspective and context that can never be built into a static analysis tool. Tools can find obvious portability breakage, or some security related issues (e.g. buffer overflow problems), so issues that are likely syntactically based, but a human can understand the semantic content of the code in front of them.

There's even research to back this up:

• Walcélio Melo, Forrest Shull, Guilherme Horta Travassos, "Software Review Guidelines", Technical Report ES 556/01, COPPE/UFRJ, August 2001. "Code review is more effective than test because in review the faults in the code are found directly, while testing uncovers only the symptoms of problems, requiring debugging to find the direct cause. The seriousness of the wrong behavior by the system does not have a relation to the type of mistake, since even simple mistakes can cause complex behaviors."
• Reidar Conradi, Amarjit Singh Marjara, Øivind Hantho, Torbjørn Frotveit, and Børge Skåtevik, "A Study of Inspections and Testing at Ericsson, NO", a rewritten edition of the paper presented at PROFES'99 (Oulu, Finland, June 1999). From the Conclusion: "Software inspections are indeed cost-effective: They find about 70% of the recorded defects, take 6% to 9% of the development effort, and yield an estimated saving of 21% to 34%. i.e., finding and correcting defects before testing pays off, so indeed “quality is free”.” and: "Individual inspection reading and individual Code Reviews are the most cost-effective techniques to detect defects, while System Tests are the least cost-effective."

In the open source community bugs are found quickly, but this happens after the fact.  Vibrant projects live a culture of review before code gets committed so it’s much more like they find the bugs before they happen.  Many of the key projects that have had breaches are taken for granted and don’t necessarily have the vibrancy of a Linux, or an Openstack. These projects have simply become part of the fabric of the Internet. 

The Linux Foundation is stepping up to tackle these problems with the Core Infrastructure Initiative (CII).  The Foundation is in an excellent position at this point in time to be the centre of gravity for such industry action. Jim talked about the Initiative in his keynote.  A broad collection of players have banded together to provide a three pronged approach to the problem of securing the open source software that secures the Internet. 

• Invest in the people that are the most knowledgeable about key projects. 
• Provide deep audits for the key projects to work to prevent the next security breach. 
• Develop and disseminate best practices and guidelines for developing and deploying secure software. 

Jim’s big concerns are how not to perturb the market economics that drive open source software ecosystems and how to avoid creating an open source welfare state. He rightly used the example of I35W bridge collapse of an example of failing infrastructure that should have been fixed before a key transcontinental artery collapsed. I think that’s the right idea economically. 

Governments invest in infrastructure to enable economic growth. Support and investment for rights of way for railroads, deep port infrastructure, or interstate highway systems creates the transportation infrastructure that enables economic growth and free markets for all. All the projects Jim discussed are fundamental Internet infrastructure. If a project under consideration implements or secures an underlying universal communications protocol  or cryptographic algorithm then it is probably a good candidate for CII investigation.

Likewise, software projects that are not owned by corporations seem to be a necessary attribute. A database, even one as broadly deployed as MySQL, shouldn’t be a candidate. A fabulous engine for application deployment (node.js) is owned by a company. I’m pretty sure the investors would love the vendor community to invest in securing node.js “because it’s so hugely important going forward at enabling blah blah marketing blah.” Sorry — if a company controls the copyright, then you’re off the list. Private roads didn’t get government funded bridges. 

The Linux Foundation is obviously not a government, but it is a well-funded well-organized industry non-profit.  As such it provides an excellent place for the vendors that best benefit from the Internet infrastructure to collectively support the infrastructure on which they all depend. 

The Core Infrastructure Initiative efforts are fundamentally important.  A complete list of participants to date exists on the Linux Foundation site. Jim’s excellent keynote is up on Youtube, the slides will hopefully be up soon, and Jim’s blog post introducing CII is published on the Linux Foundation blogs. If your company isn’t supporting the initiative, it is well worth exploring how best to participate. 

When NOT to Make Open Source Software

I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in the past with a few new essays. One of the last topics I wanted to tackle is the question of when not to publish software under FOSS licensing terms from the perspective of companies in a position to "make" FOSS software.

Many managers are concerned with creating and contributing to the open source ecosystem for two primary reasons:

• Losing control of the “value” inherent in the IP creation, and
• the liability risks of contributing to or publishing the software.

If liability risk is the real problem, then one needs to be sure that one is comfortable with the FOSS license terms, any terms of service that may be involved in the project’s web presence, and the IP management process in place to vet contributions, regardless of whether one is accepting inbound contributions to one's own FOSS-licensed project or outwardly contributing to another project. There’s not much more that can be done about such perceived risk. A company will either be comfortable with the benefits against the risk analysis or not.

A good measure of the risk however is the number of lawsuits that have happened in the open source space relating to copyright. The few that exist tend to be focused on a company using open source software in their products and services while blatantly ignoring the FOSS licensing terms. Openly and honestly participating in an open source community doesn’t appear to lead to lawsuits. Liability risk is probably not a good reason NOT to make FOSS software unless you have a particular risk profile.

The value of the software published is a very different discussion. People need to be very crisp when discussing value. One should never publish one’s core value proposition to its customers. Geoffrey Moore published “Crossing the Chasm” in 1991, and helped business managers understand the concept of their core value proposition. This was a very customer-focused “core” value. Everything else was a complement around the core. It related to the problem one solved for the customer. In later writings (“Dealing with Darwin”) Moore once again discussed core value, but here he was discussing core competency. It was an inward focused core value, and everything else a company did was context. It wasn’t what the customer bought, but rather how one solved the customer's problem.

Core competencies and core value propositions shouldn’t be published for all to use. If the software you have represents the core competency of the company, or generates a substantial competitive edge, it shouldn’t be shared under liberal licenses. The trick, however, is in understanding the truth about the core competency.

Google is an excellent example of this idea. Google consumes a lot of open source, and contributes back in a myriad of ways. But it hasn’t historically shared certain changes it has made to the Linux kernel, nor does it publish all the tools it uses to rapidly deliver software to customers.

Red Hat is another more interesting example. One could argue they simply publish a Linux distribution. The reality is that they dominate the space because they understand it isn’t the software asset that the customer is buying (and over which Red Hat has no particular ownership or control) but all the value around the software in services and risk mitigation and quality and ease-of-deployment that made Red Hat Enterprise Linux such a great replacement for expensive proprietary UNIX systems, and now an excellent server platform going forward.

There is a lot of software in an organization that isn’t in and of itself mission critical to the value they deliver to their customers. Modern Internet properties like Facebook, Netflix, Twitter, and LinkedIn all collaborate on software infrastructure and publish tools they use because it improves the infrastructure for all. Their value to their customers and their competitive business lock is the data, and in some cases the data in aggregate. Or it will be otherwise unrelated to the software platform, e.g. their ability to deliver customer value through a particular channel at a particular price point. These companies deliver a high-quality robust software-based experience to their customers that would make the average enterprise IT shop envious — and they do it on a software platform on which they’re happy to collaborate.

Software is valuable. It represents an investment in its creation, and delivering good software isn’t easy. But in relation to a business endeavour, the cost of creating it may best be shared through collaborative development because it doesn’t represent the core value of a corporation. It’s context in the business.

An interesting further observation from Moore was that a company’s core competency changes over time. They leave a growing pile of context behind them. Google also provides an interesting example of how a company’s edge changes over time. When they were a young company, the company’s ranking algorithms were critical and it would have been idiocy to publish them. At this point in time, with the value that may have been built up in their indexes, they might well be able to share the algorithm because it only works properly in conjunction with the rest of the structured data they have amassed.

Likewise, Microsoft originally needed to protect the Windows NT core competency at the software level. Now, their competencies may be more around the release processes and delivery channels. While there is a lot of third party software in the Windows product of today that cannot trivially be shared, the company’s value is likely no longer tied up in the kernel software anymore than Red Hat’s value is tied up in the Linux kernel that they don’t own and only influence.

Reliably developing robust useful software is hard work. Liberally sharing software and collaborating in open communities is an excellent way to distribute the costs and gain domain insight and knowledge, regardless of whether one is an individual or a corporation. For companies, the challenge is to understand their real and evolving value proposition to customers and the core competencies that enable them to best deliver to those customers. Everything else can be shared.

Collected Ideas on Open Source Software

[Updated 17-Jul-2013, 12:47 PT: Added a couple of additional links from opensource.com.]

It seems to be time to pull together the past year's posts and ideas here.  I've not been writing as much on the Network World blog, focusing instead on the Outercurve Foundation blog.  I've been working to develop a theme on making open source software projects successful. To that end I started around a collection of writing on the basics of understanding the motivations and some of the mechanics:

• Making Open Source Software starts the theme by looking at the motivations around open source software, whether one is a user, a buyer, or a maker of FOSS, and if you're going to "make", why the economics works and what you need to consider. 
• Making Commercial Open Source Software picks up the theme of the maker but from a commercial perspective.  If a company is to contribute or make FOSS, then one needs to have a clear understanding of the return on investment and how to consider certain additional tools at one's disposal for making open source. [This post takes the theme from the idea of developing FOSS as a strategic product/service edge, and doesn't get into the nuts and bolts of customers versus community.]  This post appeared in opensource.com as well. 
• Building collaboration communities comes with certain realities.  One of the ideas I wanted to develop was the importance of "freeloaders" because if contribution is the lifeblood of a project, one needs a lot of users to find people interested in contributing.  I cover these ideas off in "The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success" [opensource.com link]
• Finally I wanted people to understand the role of software construction practices in scaling FOSS projects beyond a handful of users.  If you don't build onramps for potential contributors, you'll never see the contribution potential of your project.  These ideas were tackled in "Git[/SVN/Mercurial] and Growing a FOSS Community".  [This post also appeared recently on opensource.com.]

I also posted this past year from several perspectives on licensing and FOSS.  Software is protected by copyright law in the United States and other countries.  There has been an enormous rise in the power and popularity of github.com this past few years, but many feel they don't need to worry about licensing their software if they want to share it, living in a "Publication = Sharing" world.  Trying to sort out licensing can be daunting at times.  Depending upon my frustration levels, I've covered the topic from a number of perspectives this past year:

• "Open Source, Software Hygiene and STDs" starts the discussion about the problems of not licensing one's software.  [Also appearing in opensource.com.]
• "Which Open Source Software License Should I Use?" tackles the question head on explaining the broad levers available in FOSS licensing.  There was a crossover post on Network World discussing licensing versus business models for the commercially minded FOSS advocate. [Also appearing in opensource.com.]
• Finally I broke down to the very short "Everything You NEED to Know About Software Copyright and Licensing-to-Share in 2 Minutes". [opensource.com link]

Lastly, I've written in several places on the "theory of FOSS foundations" that Paula Hunter and I continue to expand on:

• The most comprehensive discussion is in the International FOSS Law Review in a refereed article Paula and I co-authored "The Rise and Evolution of the Open Source Software Foundation". 
• I tackle the fundamental differences between FOSS Foundations and forges in "Forges and foundations: Chalk and cheese".  [This post began on the opensourcedelivers.com website.]
• I've presented the FOSS Foundation ideas several times this past year, and slides can be found on slideshare.net.

All in all, it's been a good year of writing on the development of free and open source software. 

Coffee Houses and Code Communities (and other Network World blog posts)

I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the discussion around open source community, business, and IP management

• Of Coffee Houses and Code Communities
  We can learn a lot about successful community building from Starbucks
  Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident and it differentiates between the co-creation of the asset and the co-production of the community.
• Makers, Users and Buyers of Open Source Software
  Understanding your relationship to a project lets you ask the right questions.
  More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance. I try to frame a participants relationship to a project so they can best understand what they do (and don't) need to care about.
• How to Talk to Your Lawyer about Open Source Software
  Lawyers know surprisingly more than they think about open source software.
  If you’re a developer that wants to use free and open source software then sooner or later you’re going to need to talk to a lawyer. Many developers have a working understanding of software intellectual property, but unfortunately software copyright is a space fraught with exceptions and edges and ambiguities. Karen Copenhaver came up with a great way to explain open source to a lawyer, and I managed to find the recording of it again.
• It’s Not That Complicated
  Too much is being made of FOSS licensing complexity.
  We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. I'm tired of it. It's just not that complicated to maintain a clean IP environment in software development.
• Please Don’t Confuse Standards with Open Source Software
  While standards and FOSS may overlap, they can’t be merged into one mega concept
  Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community.
• Open Source: No one is working for free
  To understand the economics of open source, look to the R&D of collaboration.
  People continue to wonder how to make money in the free and open source software world. It’s dressed up in discussions of how one makes money when you give away the software for free, or why developers are working for free. It can likewise lead to a management backlash of not contributing to FOSS projects because some think their developers are working on FOSS instead of their own work. I take another run at explaining why the economics is in a business's best interests.
• A FOSS project isn’t necessarily a software product
  For FOSS the question isn’t just build vs. buy but also borrow versus share.
  Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? Fedora? CentOS? Should they use the community edition of the Alfresco content management server or buy the product? How does one judge the “software” and whether it’s “right” for one’s business? These are all questions that confront developers and IT managers as they encounter the FOSS world. I try to tease it apart for people so they understand the difference between a product for sale and an open source project.

Enjoy!

882 Patents

So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far:

The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below.

Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find:

• Patents with Novell as Assignee Name or Novell as Inventor Name: 467
• Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290

So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them.

So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago.

Open Core and the Open Source Business Model Debate (on CodePlex)

The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).

I add my take on the debate on the CodePlex Foundation blog.

Software Freedom and Open Source Software (on CodePlex)

I just posted my opening thoughts on the current debates over software freedom versus open source software as a foundation for a discussion about open core as a business model. They are over at the CodePlex Foundation blog. Please discuss there rather than here.

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.

Visualizing Open Source Business Models

Matt Aslett gave a great talk about the evolution of open source business strategies last week at the Open Source Business Conference in San Francisco. In it, he presented a model to allow one to visualize businesses that use open source in their solutions, and what it means in terms of relationships with customers and the community.

The community relationships are driven by the lower triangle:

The customer relationships are driven by the upper triangle:

Matt goes on to apply the model across a collection of companies and business models, visually demonstrating how different companies have made different choices and evolved those choices, as well as playing out a number of scenarios. It's an excellent model.

Matt and I have debated in the past as to whether or not there is such a thing as an open source business model. I've argued there's no such business model, but discuss it as a set of tools that are applied to the business. Regardless of one's opinions however, Matt has provided an excellent visual model for the discussion and presentation of the ideas. It works in much the same way as the Business Model Design template in visually capturing the information to ensure a completeness of discussion and an understanding of how the parts relate. I'm looking forward to the continuing evolution of the model over the coming year as he prepares the next major open source business report from the 451 Group, and would encourage you to give the entire presentation a read.