The Open Road

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.

It's a convenient fiction that Microsoft is the source of all evil in the technology world, particularly for a vocal minority within the open-source community.

For such people, Microsoft hate is an excuse for a distinct lack of introspection, and credits Microsoft with far better execution and strategy than it actually possesses.

Microsoft CEO Steve Ballmer has a goofy laugh. I'm not sure it's an evil one.

I mention Microsoft because some within the open-source community quickly pounced on the company's inadvertent violation of the GPL in its Windows 7 USB/DVD Download Tool. Microsoft's Peter Galli was quick to acknowledge it:

[The license violation] was not intentional on our part. While we had contracted with a third party to create the tool, we share responsibility as we did not catch it as part of our code review process.

As conspiracies against open source go, it sounds pretty harmless--because it probably is. Open-source licensing is complex enough and the process for acquiring open-source software is loose enough, that there is room for all sorts of error, both nefarious and benign.

Guess what? People--and corporations filled with people--make mistakes. Even Microsoft. If it was as evil as some suspect, the devil himself would be out of a job.

As open-source adoption dramatically increases, we should expect to see errors of this kind increase, and not out of any sinister plan to pilfer open-source code. Errors are natural and are evidence that adoption is spreading beyond the inner sanctum of open sourcerors.

We shouldn't expect open-source adoption to be flawless or painless.

Consider Symbian. The foundation decided to aggressively embrace open source as a way to guide it to an optimistic future, but the process of open-sourcing its code is taking time. A lot of time. As Rich Sands suggests, Symbian may actually be taking too much time, frustrating its community and allowing Google Android to assume the leadership position in open-source mobile platforms.

Who knew that giving away things for free could be so hard?

It's tempting to think that open source should be an automatic reflex for companies and individuals alike. It's not. It takes time to learn how to do it properly, and even then mistakes are possible. Perhaps likely.

In the case of its Windows 7 tool, Microsoft screwed up. It's not the first time, and it's not the last.

But error is not evil.

There's something different about the Apache Software Foundation. While Apache hosts some of the world's most important software development, its members seem more concerned with good code than good politics.

It's no secret that I've become enamored lately with the Apache License, but it's less well-known what first attracted me to the license: the wonderfully nice people affiliated with Apache. From Greg Stein to Geir Magnusson to Brian Behlendorf, it's hard to find a jerk at Apache. I'm sure they exist, but they hide pretty well.

In fact, in a presentation today I attended at SAP in Walldorf, Germany, Apache Software Foundation President Justin Erenkrantz called out the importance of good manners to good governance at Apache:

There are going to be people on an open mailing list who are idiots, or maybe they're just having a bad day. Don't feed the trolls. Don't become a poisonous person.

It seems like reasonable advice, but it's discouraging to see this basic rule of polite society regularly broken within the wider open-source community. Some feel that a license to code is a license to shout others down. It's not. At least, not at Apache.

Perhaps this is particularly important to Apache because of the way it manages project development. It's one thing to be open source but, as I've written recently and as Erenkrantz highlighted in his presentation, open source doesn't necessarily equate to real openness:

You see a lot of people doing open source, but not a lot of people doing open development...At some open-source projects [Erenkrantz mentioned Mozilla], all of the technical decisions, even if the license is open source, are not subject to public comment. At Apache, everything is done in the open over public forums.

Or, as Day Software's Roy Fielding says, "If it doesn't happen on-list, it didn't happen."

Such transparent development creates great software, given that it fosters a true meritocracy. You know exactly who's doing what at Apache: it's all on the mailing lists.

Erenkrantz also noted a few other interesting aspects of Apache:

• Each Apache project is independent, which means that status on one Apache project is not fungible to another Apache project. I can be a core committer on the Apache HTTP project and it won't get me any brownie points with the Apache Cocoon project.
• Microsoft was a sponsor before it was a contributor. Its sponsorship was meant to send a message to Microsoft internally that it was OK to contribute to Apache projects.
• Erenkrantz stressed that Apache developers tend to believe that code, not licensing, should motivate contributions. Apache doesn't believe in forcing contributions through licensing or other mechanisms.

It's a great way to do development and, as Day Software and other companies have discovered, it's also a great way to do business. Open-source development, done openly.

And no jerks allowed.

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.