The Open Road

In the past week, the open-source business community appears to have reached consensus: making money from open-source software is a bad model, but making money with open source is golden.

This can't be good for Microsoft.

Microsoft has long maintained that as the open-source industry has matured, it has become more and more like the commercial world it sought to leave behind. Fundamental freedoms of open source, like the right to modify source code, are signed away to secure a support contract with Red Hat or another vendor.

In many ways, Microsoft was right. Unfortunately for the Redmond giant, however, the new consensus should lead to less commercialization of open source, and more commercialization around open source. There's a big difference, and it's one that threatens to seriously undermine Microsoft and every other traditional software vendor.

That is, unless Microsoft responds in kind.

The new consensus

This consensus has been articulated by TechDirt, Redmonk's Stephen O'Grady, GigaOm, and here on The Open Road.

In fact, it's a drum I've been beating for over a year as Tim O'Reilly's wisdom on the topic finally caught up with my 33MHz brain.

There are fundamental, strategic benefits to open source: ease of distribution, friction-less adoption, costs, etc. There are also serious downsides when it comes to selling it: people chafe at paying for something if they can get it, or something similar to it, for free.

Such problems don't plague companies like Google, which distributes open-source software to drive more adoption of its proprietary advertising or SaaS services. Even Red Hat isn't really in the software business: not with its Linux distribution, anyway. It's in the business of providing certification and update services; of managing the complexity of an operating system.

It's a great business, but if you had to choose between Google's sales or Red Hat's, it's a no-brainer.

Microsoft's response

As this lightbulb goes on across the industry, companies like Microsoft, which insist on direct monetization of software, with little in the way of open-source complements to fuel adoption (or simply undermine competitors), are going to struggle. More and more companies will give away Microsoft's core business as open-source complements to their own.

So, here's a suggestion for Microsoft as just one good way to respond: open-source Internet Explorer.

Forget Office. Forget Windows. Forget all those other billion-dollar cash cows. Microsoft has no revenue directly tied to Internet Explorer, but IE is the gateway to the next phase of Microsoft's growth. Open-source it.

Cut Google's Chrome and Chrome OS off at the knees. Undermine Mozilla Firefox's raison d'etre. Give the European Commission a reason to love you.

More importantly, give developers something to embrace and extend. Microsoft has been steadily losing browser market share as Firefox eats into it. In some countries, like Germany, Firefox has even surpassed IE's market share.

Fight fire with fire. IE is still the world's most popular browser. Make it the world's most open browser, too.

Every Microsoft business could benefit from this move. Even if one assumes that Microsoft isn't ready to take the plunge and fully open up the development process around IE, here's some comfort: neither has Google around Chrome. Microsoft can still steer the IE ship, even if it were open source.

Microsoft needs a proactive open-source strategy, rather than the reactive policy it has had to date. Open source is a threat, yes, but it's a threat to everyone, especially as the industry collectively comes to grips with open source as a business enabler, rather than as a product to sell.

If Microsoft wants to win big in the new world of Web-based software, it needs a bold strategy. Open-sourcing IE is the starting point.

Follow me on Twitter @mjasay.

With open-source software businesses, you have two options. Actually, three, but the third belongs to Red Hat, and it applies to roughly no one else.

The first option is to sell support for open-source software. This option is generally advocated by those who have never grown a business beyond $10 million. It's a terrible model unless your only aspiration in life is to run a services company.

Hence, the support model might be good for Accenture or systems integrator, if they want to take on the burden of support, but it's a poor model for Red Hat, MindTouch, Microsoft, or other software company.

The second option is to contribute heavily to open source but not build your revenue model around monetizing that software directly. This is what the New York Times points to in its Sunday expose of allegedly fizzling open-source business models.

Open source can drive adoption like little else. It's not, however, necessarily a great driver of revenue. For that, you need to be selling something beyond the source code, and that "something" is often going to be proprietary, be it hardware, software, or a service.

Google is the master of this model. It gets roundly criticized for its half-open, half-closed open-source efforts, but the reality is that Google's products--Chrome OS, Android, etc.--are open enough to facilitate adoption without giving away the keys to the car, which drives wherever Google wants it to go.

That's the way successful companies are run: they take ownership of what they ship. They are influenced by but not controlled by the mystical whims of The Community.

Even Red Hat, which piggybacks on a lot of Linux kernel development, increasingly includes more home-grown software in its distribution and takes great pains to certify its Red Hat Enterprise Linux will work in the most demanding environments before putting its brand on the label.

Some, including me, have wrongly concluded that Red Hat's business model would apply to other product markets beyond the operating system. It doesn't. It only applies where the moving parts in the product are complex, multitudinous, and frequently changing.

For everything else, there's Option 1 (if you want a business that doesn't scale well or possibly at all) or Option 2 (which is really no different from the old proprietary model except that it effectively uses open-source complements to lower engineering costs and possibly sales/marketing costs).

Even Option 2 won't work if you under-invest in marketing and development, as Symbian is learning to its hurt. It turns out that there is no free lunch, even in the land of free software. It always takes work. And money. Lots of both, actually.

If something seems too good to be true, it probably is. That popular aphorism never seemed truer than today when reading The Wall Street Journal's analysis of Wikipedia's declining volunteer base. Despite countless articles extolling the virtues and seeming omnipotence of "community" over the past several years, the technology industry seems to be settling back into old habits:

Command and control.

It's not that the "wisdom of crowds" idea hasn't influenced the way technology is developed, or how news and information are gathered and distributed. It has.

It's just that the promised sea change has proved to be far less disruptive than we expected.

Take Wikipedia. As the Journal calls out, volunteerism has declined as the ease of contribution has waned. The easy topics are taken. Rules for upping the quality have proliferated. Wikipedia is becoming...corporate.

Nick Carr has been pointing this out for years, but it's only now becoming self-evident. Wikipedia has grown up and, in so doing, is looking more and more like the encyclopedic world it sought to displace.

Nor is it alone. Open-source business models increasingly look like proprietary software models, as the Software Freedom Law Center's Bradley Kuhn suggests.

Even uber successful open-source communities like Joomla have discovered that reliance on volunteers falls short of what a few good paid developers can do.

That's a positive discovery by Joomla. A more worrisome discovery is that Mozilla remains far too dependent on Google to fund development of Firefox. Mozilla has lots of community, right? Yes. As Mozilla CEO John Lilly has said, 40 percent of Firefox's code comes from developers not employed by the foundation.

But that still leaves 60 percent, and virtually all of the core development work, that relies on "company," not "community," which is how much of the world's best open-source software is developed: funded by IBM and other "community" members.

For those who think "community" is a euphemism for "everyone else doing my work for me," think again. It just doesn't work that way.

Of course, companies can go to the opposite extreme, too. Apple, for one, gets beat up for a heavy-handed approach to its App Store approval process. Apple, in other words, doesn't seem to care one iota what "the community" thinks.

But then, this is the same App Store with more than 100,000 applications and 2 billion downloads to date. No wonder Apple isn't apologizing: it's clearly benefiting most people most of the time, or the application developers would take their complaints to a different platform.

But they haven't, and this calls out the problem with deifying "community." It's accepted wisdom that one shouldn't "anger the community," as if it's some unknown god that demands the occasional virgin to be thrown into the volcano. But the truth is, "community" is not really much different from the "customers" and "partners" the industry has sought to satisfy for decades.

So, yes, by all means seek to work with your community of users and partners, but don't expect "the community" to do your work for you. Guess what? "The community" already has a day job, and can't afford to work full-time for you unless you pay it.

All of which leaves us largely where we started. The most successful software companies don't rely on some vague "community" to build their products. Microsoft, Oracle, IBM, Google (Android, anyone?), and even, increasingly, Red Hat (JBoss, KVM, etc.) build great software based on their own, internal plans and expertise and "the community" buys it (or resells/embeds/etc. it).

The big shift, however, has been in the transparency of the feedback loop, which has been a welcome change in the industry. So, to the extent that "community" simply implies a more open way of developing and distributing software, then, yes, it has been significant.

But it hasn't changed the world. It has only changed the way the dominant technology companies...dominate.

The natural state of a market doesn't appear to be broad competition between Lilliputian-sized competitors. Rather, markets tend to crystallize around a few dominant players.

Ironically, this is as true of open source as it is of proprietary software.

In September I asked if open source can monopolize a market. ZDNet's Dana Blankenhorn and others gave great feedback, but the market since then has provided the best evidence:

Yes, we can have an open-source monopoly (at least, a natural monopoly). In fact, this may actually be the normal state of a healthy open-source market.

If we think of markets broadly, e.g., the "e-mail/messaging market," we're unlikely to have open source dominate such a market in the near term, though with Linux, Firefox, and other open-source projects gaining momentum, full market monopoly may not be too far off.

If we constrain a market to just open-source competitors, however, we're already there.

Within the open-source market, Red Hat dominates Linux. Firefox dominates browsers. VLC dominates media players. MySQL dominates databases. Android dominates mobile operating systems. SugarCRM dominates CRM. And so on.

Name the market, and you're almost certainly going to come up with just one dominant open-source project or vendor. There are exceptions, of course: Drupal and Joomla duke it out over supremacy in Web content management. We'll call them a duopoly. But these exceptions prove the rule:

Open source loves a monopoly.

This shouldn't be surprising. While the theory of unfettered competition sounds great, it's actually hard for mere mortals to process.

For example, when I walk into a grocery store, I don't want 30,000 cereals competing to be my morning meal. I want just a few. (Ever notice that the same cereals sold when you were a kid persist on those store shelves? We don't seem to want much competition over time, either.)

It is convenient for open source to think itself different, and to rally the troops against "Darth Vaders of IT." But that's all it is: convenient. A convenient fiction that makes us feel that this time it will be different, that this time it's all about kumbaya and the customer.

The customer doesn't want 50 vendors providing support for one open-source project. It wants to invest in Red Hat, Canonical, or Novell, and probably just one of those. It wants Android or Symbian, MySQL, or Postgres. And so on.

Manageable choice. Choice that starts to look an awful lot like monopoly. It's not that customers want to have a market dominated by a single vendor. It's just that they'd rather have a limited choice of a few good vendors, rather than an unwieldy choice between scads of competing vendors.

The difference is code transparency, process transparency, data transparency, standards transparency, and so on. This lets customers buy into a limited choice, but have a more open option for exiting that choice. It's a distinction that is more meaningful in theory than in practice, but it's still worth something.

Just not as much as we thought.

Despite the broad and deep trend toward open-source software, it's telling that Red Hat remains the only large, pure-play open-source vendor.

Without a strong, standalone open-source leader, will commercial open source endure?

The obvious answer is yes, but there are reasons to think that the industry would benefit from a billion-dollar open-source company. Actually, several.

It might seem counterintuitive to suggest that open source, which by its very nature tends to be decentralized and bottom-up in its growth, would benefit by concentrating wealth in a few hegemons.

David is nice, but the fact is that Goliath generally wins.

Take baseball, for example. The New York Times on Monday reported on the importance of the spending power of the New York Yankees and Boston Red Sox to the overall strength of the American League. A rising tide may raise all boats. But in the case of baseball, a few dominant teams force the rest of the league to follow suit or die, a curse/blessing that the National League doesn't share.

The stronger Red Hat is, by analogy, the better-positioned it is to set the pace of spending and innovation for other open-source companies.

The same is true in football, i.e. soccer. "Soccernomics" traces the importance of the Manchester Uniteds, Arsenals, and Real Madrids for pulling in fans: fans flock to watch the big teams, either to cheer for them or against them. The prospect of cheering on Hull City to best Bolton simply isn't that appealing.

In a similar manner, Red Hat serves as a beacon for would-be open source buyers. It may be hard to get excited about buying into No-Name Open-Source Vendor X, but buying from an established brand-name vendor like Red Hat? Much more appealing.

The problem, however, is that Red Hat is still a minnow in the global software pool, and its fixed focus on baseline infrastructure leaves it ill-equipped to lead the open-source market. Most open-source start-ups simply don't need Red Hat to thrive, and they derive little value from a partnership with the company.

A lot of companies make money in the shadow of Microsoft. Not so in Red Hat's.

Nor is Red Hat a viable exit for most open-source companies. Google, IBM, and others actively contribute to open-source projects--and arguably contribute even more to the continued health of the commercial open-source ecosystem by offering healthy exits for open-source start-ups.

Tim O'Reilly called out this phenomenon years ago when he suggested that the likely exit for most open-source companies would be acquisitions by proprietary software vendors. This is good for the open-source companies, but it may not be good for open source.

It would be ideal to have a large open-source applications vendor, but it's unlikely we'll get one anytime soon, particularly since successful open-source companies keep getting swallowed by proprietary vendors before they can crack the $100 million mark, much less than $1 billion mark.

It's also possible that we don't need IBM-sized, pure-play open-source companies. After all, we have IBM and its ilk already funding open source.

It's equally likely that getting to such a size with a pure-play open-source model simply isn't possible.

But I think we need a few open-source hegemons, companies that can offer a clear alternative to Oracle and Microsoft for both buyers looking for open-source software solutions and vendors looking for open-source software partners. Such hegemons can also help to fund the growth of the next generation of open-source innovation.

But from where will they come? I'm not sure. Your thoughts, please.

A recent survey suggests that CIOs are loosening the purse strings on IT spending. IT vendors may want to hold off their celebrations, though, because much of the spending appears to be headed for deflationary forces like cloud computing, virtualization, and their kissing cousin, open source.

An economic rebound never looked so dire.

That's unless you're an IT buyer, of course, suggests a new report from Goldman Sachs. In this week's report, titled "A Paradigm Shift for IT: The Cloud," Goldman Sachs said it expects that pent-up IT dollars will flow in the short term to building out next-generation data centers (e.g., cloud computing). But in the long term, less money is expected to find its way into fewer wallets:

After the initial build-out, Cloud Computing could drive some headwinds for the IT industry, as a result of two factors. First, we see virtualization as a deflationary technology. Second, we see IT spending consolidating in the hands of fewer buyers--the Cloud providers, hosting vendors, and large enterprises. These factors will likely dampen IT spending growth due to greater utilization and buyer pricing power.

Even short-term build-outs may prove disappointing, however, as Goldman Sachs expects large enterprises to grow existing virtualization and automation technology adoption in the rollout of private clouds, shifting slowly to an embrace of public clouds over time. The chart below gives some idea as to when cloud computing will hit its stride:

Who wins in this scenario?

According to the report, Red Hat stands to benefit from the cloud-computing craze. ("Red Hat is well positioned for the emerging Cloud Computing ecosystem, largely due to its open source background and current ubiquitous deployments in data centers, including enterprises, as well as in Cloud providers such as Amazon," the report states.)

But the real beneficiaries will be...the same old crew. "[K]ey suppliers for internal Clouds are likely to be those that have the most complete portfolio of hardware, software, and services," including IBM, Hewlett-Packard, Cisco Systems, EMC, and Oracle.

New boss...same as the old boss.

The other beneficiaries are the start-ups that provide critical components of cloud computing, with an emphasis on management tools. Here we may see open-source companies benefit, including Reductive Labs (Puppet project), Cloudera, and the two rising private cloud companies, VMOps and Eucalyptus, among others.

While open source doesn't factor heavily into this particular Goldman Sachs analysis, the firm has before called out open source's role in wringing more value out of fewer IT dollars. Open source is a primary driver of the global reset in IT spending expectations.

With less money flowing into the pockets of fewer vendors, we can expect to see both increased consolidation and fierce competition for the IT spending that remains. Those vendors that can help CIOs do more with less stand to benefit from this shift to low-cost, high-value computing.

And those that can't? Well, let's just say they may pine for the good old days of the global recession.

Some open-source software may not be open enough. While "open source" refers to software's underlying license and its adherence to the Open Source Definition, there are numerous examples of open-source projects that offer an open license but a relatively closed development process.

It's been called "fauxpen source" and worse, but we may have to get used to it. It seems to be the new normal in open-source development. Only open source foundations like Eclipse, Apache Software Foundation, and Mozilla appear to be able to escape it completely.

Java is one example people cite of "fauxpen-ness." SAP CTO Vishal Sikka on Monday called for a more open process for Java development, arguing that Sun too tightly controls Java's development. It's a complaint that has plagued the Java community for years.

Not that Java is alone. While Google gets plaudits for its open-source investments, some are quick to allege that Google maintains a closed Android community. The same sort of complaints have arisen over Google's management of Chrome and Chrome OS.

Even Red Hat, the quintessential open-source company, is primarily known for what it distributes, not what it develops. Red Hat, of course, works alongside IBM and other corporate and unaffiliated developers to write the Linux kernel, and scrupulously releases its software under open-source licenses.

But when it comes to development of its Red Hat Enterprise Linux distribution or development of its JBoss middleware or other technologies (e.g., KVM), good luck finding many significant external contributors.

MySQL? It's largely the same. The company (now Sun Microsystems) does virtually all of its own development, which is true of every commercial open-source company of which I'm aware. This is one reason Richard Stallman can unblushingly worry about MySQL's openness despite the fact that it uses his preferred GPL license.

Open source, but not necessarily open process.

There are very good reasons that Google, Red Hat, MySQL, and others keep a tight grip on their open-source development efforts. They are responsible--fiscally and legally--to their customers, and have to be able to guarantee quality and security. Understandably, they exercise some control to ensure the products they ship protect the integrity of their brands.

But such corporate open source indicates a real divide between "open source" as a license and "open source" as a wholly transparent way of developing and distributing software. The former is now common and relatively easy. The latter, quite simply, is not.

The companies that seem to do it best are those that don't rely on direct monetization of open-source software. In other words, if you aren't selling open source, it's easier to be open. Doc Searls captures this brilliantly by arguing "you make money because of [open source], not with it."

Examples abound. IBM is a good example. So is Google, though I agree with its critics that it can do better. Facebook, Oracle, and others also provide examples.

In the future, I think we'll see this "fauxpen-ness" fade as companies clearly separate their open-source efforts from their revenue models. Open source can provide a platform for monetization, but it isn't the best way to actually generate cash. Not for most companies, anyway.

Google CEO Eric Schmidt argues that competition is just a "click away." By opening up Google's access to personal data as well as the software that collects it, Google is adding substance to that claim.

It won't work to write better software than Google, because Google is not a software company. The only way to beat Google is through superior execution; through better operations.

The way to lose to Google? That's easy: try to sell software that Google is shoveling out the door as free (open source) software.

This thought hit me last week as Google announced the open-sourcing of its Closure tools. These are JavaScript compression tools that Google uses to build its own Web services like Gmail. Basically, Google was saying, "Here's how we build our software services. You can, too."

This follows on the heels of Google open-sourcing other software like Android ("Here's a free mobile operating system to help more people connect to our services"), Gears ("Here's how to run Google-like services offline"), and more, each opening up windows into the software that runs Google's services.

In many ways, Google is giving away the recipe to those that would like to build a Google clone.

The problem? Google is so much more than software.

In fact, one of the primary reasons that Google can write and open-source so much software is that it isn't a software company. Not even remotely. I could have every line of Google's software, both open source and proprietary, and I couldn't hope to compete with Google.

Google is what Google does with the software, and not the software itself.

Ditto for Red Hat. The company used to retain significant chunks of proprietary code in its Red Hat Network offering, but it has released that software under and open-source license in the last year. Doing so hasn't had any effect--positive or negative--on Red Hat's sales, because Red Hat isn't in the business of selling software anymore.

Red Hat, like Google, is in the business of providing services to customers, services enabled by software but which are much more dependent on IT operations and overall efficiency of execution.

And while both companies rely on open-source software to fuel those operations, Google, more than Red Hat, realizes that the conversation has moved on from open-source licenses to higher-order value, a theme that is going mainstream. Cloudera CEO Mike Olson captures this theme well:

The license terms attached to products have become secondary to the value it offers. People now are much more rational about how they adopt technology across the board. Open source is a detail, not a defining characteristic. At Sleepy Cat, we were proud to be an open source company. At Cloudera, I think of us as an enterprise software company that happens to be built on open source software.

Such sentiment would resonate well within the walls of Google's Mountain View headquarters, I suspect.

Even within their respective open-source communities, neither Google nor Red Hat company is particularly saintly. Red Hat has never waited on the Linux Standards Base or industry efforts to coordinate Linux distributions (like United Linux), but instead forged ahead with its own efforts...until the LSB simply adopted Red Hat's distribution as the standard.

Google, for its part, takes flak for dominating its open-source project communities like Android. Google's contributions (or lack thereof) to outside projects, like Linux, don't always mesh well with others in the industry.

To open-source community critics of Red Hat and Google, some advice: get over it.

The companies that spend the most time chumming around, talking up interoperability and the need for everyone to work together are usually the ones losing the race, a race whose rules may be written in software but whose victory depends upon execution.

Google and Red Hat have moved beyond software. Software enables their operations, but software doesn't define such operations. Google, for its part, is open sourcing Microsoft, one line of code at a time, and Microsoft hasn't a clue as to how to respond, because it only knows the old world: competition through better IP.

That world is gone. Open source has killed it. The new world is built on execution and superior IT operations. Google gets this. Red Hat gets this. Microsoft? Not so much.

For years, open-source advocates have been praying for someone to free us from Microsoft's proprietary grasp. We've prayed in vain as Linux, OpenOffice, and other open-source software programs have failed to dent Microsoft's dominance.

Until now.

Google, not Red Hat or Sun, appears to be the long-awaited redeemer of both personal computers and servers, and has even staked a credible claim in the mobile world, as well. Google achieves this, in part, by writing copious lines of open-source code, but pays for this "generosity" with insanely profitable proprietary services, services that have long appealed to consumers but increasingly appeal to enterprises, too.

Google, in other words, is arguably not the open-source savior we were expecting, but it's probably the one we deserve.

Despite more than a decade of trying to make "pure" open-source software businesses work, it's telling that only one company--Red Hat--has managed to pull together more than $100 million per year in revenues for its troubles. For its part, Red Hat is quick to downplay the relevance of its revenue model for just about any other business.

Hardly a rallying cry to the still-growing open-source ecosystem.

Yes, MySQL got to $94 million before Sun gobbled it up, and yes, other start-ups (my own, included) are getting closer to the mark, but none, including MySQL, is wholly dependent on selling open-source software subscriptions to achieve this goal.

We also include proprietary add-on value. Like Google.

So we're left with Google, which is, perhaps, the world's largest open-source company, contributing more open-source software and resources than any other, in my estimation. (Sun likely wins on sheer volume of code, but being an "open-source company" involves more than simply code.)

How does Google do it? Well, for one thing, it learned long ago that monetizing open-source software directly is tough. So it simply uses open source to shepherd prospective customers to its other services, like Search or Google Apps.

Indeed, it is the success of these proprietary products that enables it to be such a generous open-source benefactor, much like IBM, Intel, or, for that matter, Sun (which sells a lot of proprietary hardware). Take away these companies proprietary product lines, and overnight we'd see dramatic decreases in their investments in Linux, Apache Software projects, etc.

And we'd all be the poorer for that.

In an ideal world, open-source software companies would thrive by simply giving away lots of code, and having enterprises and government organizations serve their long-term interests by paying for support.

We don't live in that world. Some organizations do buy support for open-source software, of course, though many others do not, and some only pay long enough to become self-sufficient whereupon they dump their support contracts, as former CTO of NBC iVillage Jon Williams once declared.

Until we cross the border into Utopia, we're going to continue to see the biggest investments in open-source innovation come from Google and its peers: companies with wallets fat with proprietary profits.

As I said, this may not be the open-source world for which we've hoped, but it's the one we deserve, because it's reflective of what we value and, hence, what we pay for.

See also Mark Hinkle's response to this post.