The Open Road

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.

Open source needs a few more of these.

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.

But is it open enough?

(Credit: Open Source Initiative)

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.

Google's secret sauce? Operations.

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.

(Credit: Matt Asay)

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.

The European Commission may be taking its time analyzing the competitive impact of Oracle's proposed acquisition of Sun/MySQL, but the industry can't afford to dither. On Tuesday, MySQL competitor EnterpriseDB announced that Red Hat joined its $19 million Series C funding round, which follows IBM's own investment in EnterpriseDB.

Is the software industry, once devoted to MySQL, preparing to shift allegiances to Postgres?

Probably not, but clouds are forming. On Monday, I talked with EnterpriseDB CEO Ed Boyajian, a former Red Hat executive, and he suggested several reasons for Red Hat's investment of "a significant amount of money" in the open-source database vendor, EnterpriseDB. As he told me:

This is a great step forward for our company and for Postgres. Red Hat has done heroic work bringing commercial open source to mainstream enterprise adoption. And it's making a difference: arguably billions of dollars of spend in operating system and middleware has gone back to customers. You want to talk about returning control to users? That's the real yardstick. That's real disruption.

For EnterpriseDB to have the trust and support of Red Hat as a partner and investor is a huge help to our company and I think it gives another strong indication to enterprise customers challenging their old spending habits, that there is more they can do.

It's important to note that Red Hat has been distributing Postgres for some time. It's in every copy of Red Hat Enterprise Linux and Fedora that Red Hat ships. As such, it's already in the hands of thousands of Red Hat customers and users, and is in heavy demand in some geographies, particularly Latin America. But until now Red Hat has not provided robust support for the database on par with its support for Linux and JBoss.

That's about to change.

The change is good for Red Hat customers, but this isn't the only area in which Red Hat has been seeking to expand its influence. Red Hat has been actively looking for opportunities to invest in a variety of open-source companies, most recently investing in JasperSoft.

Red Hat CEO Jim Whitehurst, however, nicely marries pragmatism with idealism, as suggested by his comments on EnterpriseDB's subscription model:"EnterpriseDB is also working to create customer value through a subscription support model. Clearly, this is a model we see as beneficial."

He's right, but it's interesting to hear him laud a model (i.e., a subscription to proprietary and open-source software, plus maintenance and support) from which he distanced Red Hat in Red Hat's Q1 earnings call. ("I certainly hope for and we certainly like to work with other open source companies out there. But those are fundamentally different business then what we're doing.")

He's right the second time (in the EnterpriseDB news release). They are not fundamentally different business models. I suspect his comments on the earnings call reflected an attempt to get out of an inaccurate and misleading question from the ever-entertaining Trip Chowdhry.

Regardless, Red Hat's investment in Postgres vendor EnterpriseDB suggests that it, along with IBM and others, is prepared to bolster alternatives to MySQL in its larger quest to provide real competition in the database industry.

To be fair, Red Hat's interest in Postgres and EnterpriseDB precedes the EU's intervention in Oracle's proposed acquisition of MySQL. The interest is understandable: Postgres is a great choice for a wide variety of database workloads. It's built for transactions and higher-end use cases, like the Oracle and IBM database workloads that it can replace (or augment).

EnterpriseDB plays into Red Hat's overarching strategy of commoditizing key infrastructure, as Whitehurst has noted. Given that the $20 billion database market is concentrated in just three vendors who control 85 percent of the market, databases are ripe for disruption, disruption that Red Hat can feed from a distance.

Red Hat's investment in EnterpriseDB says more about Red Hat's increasing awareness of its larger role in the open-source ecosystem than it does of any competition with MySQL. It's about time.

It boggles the mind, but it's apparently true: nearly half of enterprises think a software purchase is successful if the software is installed/deployed, according to a new study. If ever there was reason to believe there's room for improvement in enterprise IT, and billions of dollars to go with it, this is it.

Working software should be the starting point, not an end point.

According to a study recently released by Neochange, Sandhill Group, and the Technology Services Industry Association (TSIA), 45.3 percent of the 353 IT professionals surveyed call a software purchase successful if "the software is deployed/installed."

No, this isn't enterprise IT's only criterion for software success. After all, 75.4 percent pegged their aspirations a bit higher: "Business benefits realization (cost reduction, revenue generation, etc.)." (Note: respondents could choose more than one answer; hence, the results don't add up to 100 percent.)

But it's scary that the software industry has conditioned IT buyers to expect so little. No one should claim victory on the basis of getting software installed, and we should be hitting close to 100 percent actually getting tangible business value for their software investments.

But then, more than half the survey's respondents admitted to not even measuring success criteria. Could this be a sign that IT executives, like the sign greeting Dante on his descent into Hell, have abandoned all hope of getting real value for their software spend?

Things may be getting better. As reported on Tuesday, Google and Red Hat topped CIO Insight's Vendor Value survey. Times are tight, and enterprises apparently can't afford to call software purchases successful just for running as they should.

Red Hat's chief of European operations, Werner Knoblich, says as much in an interview with The Register:

Microsoft was untouchable until recently, but now everything gets considered, which is one of the reasons [Red Hat's] results have been pretty strong. Clearly a downturn is never good generically, it's a bad thing. But our value proposition resonates pretty well all the same.

In the case of both open source and SaaS, enterprises don't pay a dime until they actually see the software working. Working software is the default. It's not cause for special celebration.

The Neochange, et al, survey also asks, "What is the most important factor for realizing value from enterprise software?" The answer "Gaining user buy-in and ensuring effective usage to deliver business impact" garnered a 71.7 percent vote. That's more easily achieved with open-source software, in particular, which allows enterprises to evaluate and use software long before they opt to purchase support or add-on services/software (if, indeed, they ever elect to do so).

In this way, open source improves upon typical IT success. With more than half of those surveyed reporting "less than 49 percent effective software usage," there's clearly room for a better model to optimize software utilization.

We can do better. We must. About 30 percent of those surveyed look to software to enable "business innovation, revenue generation, and market competitiveness."

Such enterprises are increasingly looking to open source to serve as the foundation for innovation. This probably wasn't the "fundamental economic reset" Microsoft CEO Steve Ballmer had in mind, but it will do. And it's about time.

Follow me on Twitter @mjasay.