The Open Road

Life has never been better for enterprises and consumers. From free music to free software, the digital economy is an all-you-can-eat free-for-all.

That is, unless you're a vendor.

Traditional vendors are getting shellacked by the digital economy, spurring some, like Rupert Murdoch and his News Corp., to threaten to stick a finger in the dike and demand that users pay for content. (At Murdoch's Wall Street Journal, users already do pay to access some stories online.)

The problem with this approach is that not everyone is willing to follow suit. Why? Well, not everyone needs to. The BBC responded to Murdoch's plans by declaring it won't charge for content. It doesn't need to. U.K. taxpayers already fund it.

Different strokes for different folks. And different business models, too.

Google makes money by making it easy to discover others' content. So does Apple's iTunes. Google can afford to give away lots of free software (and even free hardware) to nudge people into its advertising model.

That's hugely disruptive.

In software, Microsoft doesn't like competing with free Linux. Microsoft spends a lot of money developing Windows. It must seem unfair to have to compete with the rest of the industry, which increasingly coalesces around Linux (or Android, or MySQL, or...).

But that's life in the open-source economy. Your core competence is always going to be someone else's throwaway complement, and ripe for open-source commoditization.

In fact, it may be getting worse, and not just for Microsoft. The Wall Street Journal reports that Domino's Pizza has rolled out a multimillion dollar, homegrown pizza-ordering/fulfillment system.

Could Domino's have bought an off-the-shelf system from Oracle, SAP, or another vendor and customized it? Probably. But then, this isn't how most IT gets built, anyway.

Most software is written by enterprises to use, not for sale, as Bruce Perens and others point out. So while we credit Microsoft, Oracle, and others as the backbone of the "software industry," the reality is that these companies are really a drop in the software bucket, with companies like Sony, Wal-Mart, and GE the true backbone of a much larger software ecosystem than the vendors comprise.

As open source matures, we're going to see these "software users" develop more software in-house, often building from open-source projects. Gartner calls out intriguing proof of this trend, but it's equally evident in anecdotes like this one, highlighting Virgin America's adoption of open source to reduce costs and improve innovation.

Virgin America is writing few checks to external vendors. That money is paying internal developers instead.

Digitization, then, may not be destroying the software market so much as reshaping it. In this new model, companies like Domino's will need more internal developers as they rely less on outside software vendors.

There will still be a need for companies like SAP, of course, as there are broad industry needs that a company or open-source foundation can satisfy. But for strategic IT projects, we're likely to see more open source plus internal development, and less packaged software purchases.

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.

For those who have fret about Microsoft fighting against open source, I have news for you: Microsoft's impact on open source may be worse as a friend than as an enemy.

Over the past few years, Microsoft has steadily warmed to open source, to the point that it now hosts its own open-source code repository and has seen its Microsoft Public License used more often than venerable licenses like the Mozilla Public License or the Eclipse Public License, according to new data released by Black Duck Software.

The open-source world should be worried.

After all, as IBM's Savio Rodrigues points out, an open-source-friendly Microsoft no longer has qualms about embedding open-source software like MySQL into its products. In particular, Microsoft supports MySQL as part of its Azure cloud service...without paying Sun a dime for the privilege.

It's a completely legitimate way to offer open-source value to Microsoft customers, and is very similar to what Amazon is doing with MySQL.

However, as Rodrigues notes, it's not necessarily good for MySQL, or other open-source projects that could be used this same way:

The larger point is if Amazon, Microsoft, IBM, HP, Google, Cisco, EMC/VMware, or Oracle/Sun offer a simple and supported cloud service for running MySQL, Tomcat, JBoss, Mule, or Apache HTTP instances, what reason do customers have to acquire "enterprise subscriptions" from the vendors developing these open source projects? Until now, the value of an open source "enterprise subscription" has largely been access to support and access to administration and management tooling. In the case of MySQL, the former is provided by Amazon RDS and Azure SQL as part of the per-hour service. Again in the case of MySQL, the latter is rendered unnecessary or replicated through Amazon RDS and Azure SQL tools.

Consider it a super-friendly, and super-dangerous, bear hug.

For those who think that this affects commercial open source and not community-led open source, think again. Money and open source don't grow on trees.

The explosion of open-source development has directly correlated to the explosion of cash investments into open-source projects, starting with IBM's $1 billion commitment to Linux. MySQL, the database, would be a pale shade of what it is today without MySQL AB, the company that has funded the overwhelming majority of its development.

So, is this cause to castigate Microsoft? No. After all, it's really no different from what Amazon, Google, Apple, and others do with open source.

Rather, Microsoft's move should serve as a reminder to open-source companies that they need to upgrade their business models or risk being rendered irrelevant by the cloud and all that it enables vendors to do with open-source software.

After all, the protections that the GNU General Public License (GPL) and other open-source licenses offer in the traditional software world are essentially meaningless in the networked world, where software is used to create services, but isn't actually distributed.

This is as true for Red Hat as it is for open-source start-ups like Openbravo and Talend. Imagine if Amazon decides to start offering JBoss as a cloud service. Or Red Hat Enterprise Linux, for that matter (minus the trademarks).

It could happen. Actually, I'll go one step further: it will happen. It's just a matter of when.

This is why companies like IBM, Google, and increasingly Microsoft strategically invest in open source, but don't try to directly monetize open source. It's also why the "open-source companies" need to figure out a Plan B before Plan A gets taken from them.

Is Apple an enterprise software or hardware company? That's the question Gartner's Nick Jones asks, ultimately answering with "you have to have a pretty relaxed definition [of enterprise] before Apple fits it."

It strikes me, however, that "enterprise" isn't something you define. It's just what gets used within the enterprise.

With this definition in mind, Apple clearly fits the "enterprise" moniker, whether Apple wants it or not. As BusinessWeek reported back in 2008, the Mac is finding its way into enterprise computing, with or without the IT department's blessing. Ditto the iPhone.

Is it somehow less enterprise because the CIO didn't issue a policy giving permission?

Maybe "enterprise" means something more than "gets used a lot within the enterprise." In fact, Jones points out a few reasons he, personally, doesn't feel Apple is an enterprise vendor:

Apple does the bare minimum for enterprises, they aren't deeply committed to security, management, road maps, low TCO and so on. And they don't open up the architecture of iPhone enough for third parties to fill the holes.

But, again, is this really how we should define "enterprise?"

It reminds me of the criticisms leveled at open-source software early in its adoption. Originally Linux, for example, wasn't considered "enterprise grade" or "enterprise ready," presumably because it didn't meet Jones' hurdles above.

Now, however, Linux is considered an essential enterprise technology. What changed? Nothing...except adoption.

Here's a test for Jones: while Gartner pooh-poohs Apple's iPhone as an enterprise mobile device, perhaps for a variety of good definitional reasons, will it hold to such a rationale once the iPhone's market share within the enterprise dwarfs that of Windows Mobile, which has lost a third of its market share since 2008?

Seriously, at some point it won't be enough to listen to Microsoft's Ray Ozzie deprecate the iPhone's enterprise credentials because its 100,000-plus applications are "not very deep" and lack the "thousands of man years" that have gone into the applications that run on Windows. It won't make sense. Why? Because no matter how "enterprise grade" those Windows Mobile applications are, few within the enterprise are using them.

Enterprise is as enterprise does. Would you rather work for the company that builds software for the enterprise, or would you prefer to work for the company whose software gets used by the enterprise?

If you can have both, great. But it's silly to say Apple isn't an enterprise company simply because it sells to the enterprise without even trying.

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.

There was a time when Microsoft could skimp on Internet Explorer innovation. Having trounced its Netscape rival, Microsoft rested on its IE laurels for years, barely updating the browser.

Today, Microsoft can't afford to rest on any laurels, least of all with IE.

In part this is due to rising competition. The open-source Mozilla Firefox browser, for example, now tops 24 percent market share and it, along with the Google Chrome browser, and Apple's Safari browser, regularly push well beyond IE's comparatively glacial development.

However, the biggest challenge to Microsoft's IE development inertia is Microsoft itself. As Mozilla's Asa Dotzler posits:

That [IE] team has some really strong people and they're not going to let another release go by where they're still seen as badly trailing. Not with Office moving to the Web. Not with Search and other web services becoming huge revenue opportunities.

Falling short with IE 9 would be the last straw for Web developers' little remaining faith in Microsoft and so they won't miss this opportunity.

The browser used to be a sideshow to Microsoft's Windows and Office cash cows. In the future, however, the browser is the gateway to the next generation of Microsoft dominance...or irrelevance.

As the world moves online, how well Microsoft delivers an innovative browser experience will largely determine the future of the company.

At the same time, how well Mozilla delivers a neutral, innovative Firefox is the industry's best defense against Microsoft and Google too tightly coupling their browsers to their Web services.

It's therefore time for Facebook, IBM, Oracle, Salesforce, and others with a vested interest in an open gateway to an open Web to put their development resources where their mouths are. Contribute to Firefox. Microsoft (and Google) has an interest in building a better browser, yes, but to ensure that browser runs others' services as well as Microsoft's, Microsoft must be kept honest.

Firefox is the best way to accomplish this.

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.

Government policies favoring open-source software adoption should be wildly popular within the open-source crowd. Yet, at an open-source conference in Amsterdam today, I kept hearing the opposite. Despite the Dutch government's best intentions to foster open-source adoption, some people think it may actually be doing the opposite.

By many measures, the Netherlands is a great place for open-source software. In 2007, the government started to phase in a policy that gave preferential treatment to open-source software in IT purchasing decisions. Initially, at least, the policy seems to have been a success, with a July 2009 study highlighting a wide array of open-source software in use by government.

Sounds good, right?

Maybe not. According to sources within the government and others that sell to the government (both proprietary and open-source vendors), the government's rigid definition and management of the policy has more often than not thwarted its attempts to go open.

At its core, however, the problem derives from a mismatch between ends and means. The government's goal--"to increase the sustainability of information and innovation, while lowering costs through the reuse of data"--is not always best achieved by open source. A proprietary program with a broad community that is fully open standards-based could actually be a better solution to achieve this end than an open-source solution, particularly if it has a small community and smaller adoption.

That's because "openness" is not simply a measure of software's licensing. That's not even necessarily the most important consideration, as Tim O'Reilly reminds us.

But the government's policy doesn't look beyond whether the software in question is licensed under an OSI-approved license. This is what we thought of open source five years ago, but these days, this line of thinking is increasingly outdated.

An OSI license is a fruitful beginning to an open-source policy, but if it's the end, then the Dutch government's policy begins and ends with lawyers, who are almost certainly not the best equipped to evaluate IT solutions.

Indeed, the commentary I heard today confirmed that inbound software is first reviewed by the Dutch government's lawyers. If there's not an OSI-approved license attached to it, even if the software is provided by an open-source vendor with full rights to view and modify the software (but not redistribute it), it's out.

This wouldn't be so bad if there was a plethora of alternatives in each given product category for the government to choose. But there isn't.

Hence, more often than not the government ends up buying an established proprietary solution. It's very difficult for most products to run the legal gauntlet that the government has established. The vendors that do are either too small to effectively service the government's requirements, or they're Red Hat, which focuses on a limited infrastructure product portfolio.

Having painted itself into a legal corner, there's one easy thing for the government to do: buy the same proprietary software it always has.

Given that the policy allows for selection of a proprietary product if a suitable open-source alternative doesn't exist, the stated preference for open-source solutions is turning into a minor speed bump on the way to continued acquisition of proprietary software.

This is silly.

The Dutch government should focus on the end: open, interoperable solutions. True, doing so requires more thought than a binary decision based on a license. But it's a much smarter policy to balance a range of factors (freedoms and constraints of the license, community associated with the product, open standards, payment model [license fee vs. subscription], etc.), in order to reach a more thoughtful position on a given piece of software.

Such a policy would result in more open-source software adoption, not less. It would let open-source software compete on broader criteria than the license. Open source, and the trends it has inspired, are much more than a license. Other considerations, such as open data policies, take precedence in our networked age.

The Dutch have the right intentions. But the way they're managing their open-source policy is not helping them most effectively reach the goals they seek.

In the battle of the open-source mobile platforms, developers have at least two choices: Google Android, which is open source but (relatively) closed development, or Symbian, which is open source...once it gets around to releasing the full source code.

Guess which one is winning?

Gartner expects Android to become the second-most popular mobile platform within the next few years as it continues to gobble up Symbian's declining market share.

But why?

Symbian has been dismissive of Google Android, as well as smaller upstarts like the LiMo Foundation, arguing that the latter is overly focused on middleware for wireless operators and the former is fake open source with more hype than substance.

All of which might be true, but the reality is that it seems to be working for Android. Google has been signing new handset manufacturers at a frenetic pace, while Symbian has been holding steady with Nokia...and that's about it.

Despite Symbian announcing new handsets, Google is actually shipping Android. There's a big difference between marketing and reality. Google Android offers the latter.

For all the buzz that Android gets from developers, its success owes more to handset manufacturers than to open-source developers. Handset manufacturers and wireless carriers are hungry for alternatives to surging Apple and declining Microsoft. And while others may not be seeing source code in copious amounts, handset manufacturers are apparently getting their fill.

More than this, though, Google gives them a safe, consumer-friendly brand. Symbian does not.

This is the reason Google Android is winning. It's not about developers--at least, not yet. Neither Symbian nor Android really offers developers open communities and open code.

No, the difference today is brand. Google has it. Symbian does not, and that's despite decade-long dominance of the mobile market.

Symbian still has a ways to go. It has a weak user interface (UI) that is supposed to get better, but that describes much that is wrong with Symbian today. Everything (source code, revamped UI, and resumption of market dominance) is always spoken of in the future tense.

Meanwhile, Google Android rolls on--not because it out open-sources Symbian, but rather because it out-executes it.