The Open Road

President Obama gets a lot of credit for his pro-open source policies, but the United States has been funding open source well before he took office.

The U.S. Agency for International Development (USAID), which describes itself as the principal federal agency for extending "assistance to countries recovering from disaster, trying to escape poverty, and engaging in democratic reforms," has been in the habit of funding open source abroad since at least 2007.

As but one example, USAID kicked off its Open Source Development 2.0 challenge last fall.

The contest and other USAID activities led to a wide roll-out of Joomla, an open-source content management system, throughout the Mongolian government, including 200 of its Web sites, as Elin Waring, president of Open Source Matters, a company that advocates Joomla adoption, told me.

But Joomla is just one part of USAID's global investment in open source. The agency has also created the Global Development Commons, which promotes U.S. interests by encouraging open development abroad. Apparently, the idea is that U.S. interests are served as local economies sustain and grow on their own, rather than requiring ongoing foreign investment.

Microsoft recently funded an IDC study, which finds that "software is a significant contributor that drives productivity and innovation in almost every sector of the economy." This may be true, but as I've argued before, governments would do better to expand local economies by building upon open-source software rather than shipping rubles/pesos/etc. abroad to import software from vendors like SAP, Oracle, and Microsoft.

In the case of open source, the software may come from elsewhere but it quickly becomes a domestic good as local firms tailor and improve it. With proprietary software, local firms can provide implementation services but they, as well as the end-customers, are always dependent on a foreign vendor for the core value.

The U.S. continues to buy plenty of proprietary software, but it's encouraging that when it comes to international development, the federal government recognizes that open source pays better long-term dividends than subsidies for the export of proprietary software. Even more encouraging, this practice appears to be neither Democratic nor Republican in origin.

Perhaps there's hope for bridging America's partisan divide, after all.

For years, Red Hat has happily sold Linux to Unix shops anxious to save money at equivalent or better performance. During this time, the company largely avoided Microsoft, which has tended to compete much higher up the stack. No longer. Microsoft CEO Steve Ballmer argues that one of Microsoft's biggest opportunities lies in enterprise infrastructure and associated application development.

Red Hat, meet Redmond.

Red Hat wants to own the infrastructure market. The company is nearing its initial $1 billion goal, but has a far more audacious ambition: own half the associated middleware market.

This is a direct challenge to Microsoft, especially the manner in which Red Hat aims to go about it. As Red Hat CEO Jim Whitehurst noted in the company's earnings call earlier this year, Red Hat is "laser-like focused on that mission of commoditizing these key (infrastructure) layers" through open source.

It's not a strategy that will endear the open-source agitator to Microsoft.

After all, Microsoft is also focused on these opportunities, as Microsoft CEO Steve Ballmer told TechCrunch:

Biggest opportunity that we never talked about is enterprise infrastructure. Most of that goes to the database and mainframe vendors today who are in the business. We've got four billion in revenue and yet we're a small market share player.

Servers, there are going to be more new applications written in the next five years than any five-year period of time.

The two companies can't help but run into each other. Will they also be able to collaborate? They must. No customer is going to exclusively run either Microsoft or Red Hat technologies. The two have showed an ability to get along, if only a little bit. Can the two come together even as they seek to beat each other to bloody pulps?

Time will tell. But the market is about to get very interesting again. To achieve its goals, Red Hat must increase its investment in JBoss to make it an even better application platform that can effectively compete with Microsoft and its comprehensive infrastructure/middleware/tools suite.

As it does so, it's going to bump into Microsoft SharePoint, which is increasingly used as a platform for building applications, much like Red Hat's JBoss application server. SharePoint has come under threat from Google recently, but this is a battle Red Hat will have to fight, too.

As for Microsoft, I can't see how it can hope to compete with Red Hat's open-source strategy without including a healthy dose of open source, itself. Figuring out how to maintain its profit margins and sales potential, while simultaneously encouraging the growth of its developer ecosystem, is going to be difficult without open source.

It's a battle for the heart and soul of the enterprise, and it's going to get a little messy. It's about time.

Follow me on Twitter @mjasay.

Arguably Microsoft's biggest threat is its irrelevance to Web developers. Though the company dominates personal computing and is a major force in enterprise computing, it remains a distant also-ran to LAMP (Linux, Apache, MySQL, PHP/Python/Perl) development for the growing Web ecosystem. On Thursday Microsoft announced its WebsiteSpark program to build inroads with the Web crowd, but the program is unlikely to make a serious dent on LAMP's dominance.

The reason? There are some big strings attached.

Microsoft has gone after Web developers before, but products like Expressions haven't made much headway with Web developers, as The Seattle Times reports.

WebsiteSpark, following on the heels of successful student (DreamSpark) and start-up (BizSpark) technology seeding programs, will likely make more of a dent. Free, high-quality tools to Web developers, as TechCrunch suggests, are going to be a big win.

But it's not going to be enough.

The problem isn't one of cost. At least, not primarily. WebsiteSpark has that nailed. The program gives thousands of dollars of technology away for just $100 at the end of three years, and then two options ($999 per year for everything or a scaled down $199 per year option) that aren't much more expensive.

But this overlooks the larger issue: Microsoft constrains who can join the program (start-ups with fewer than 10 employees) and meters their growth after the three years. Open-source alternatives do neither.

No upfront cost...but what about the future?

The first constraint isn't a big deal. Many aspiring Googles have fewer than 10 employees, and will continue to be small through their first few years.

The second, however, is the killer. At the end of the three years, Microsoft doesn't require WebsiteSpark participants to buy anything, but if the start-up is successful, it faces big bills as it scales out its Microsoft technology. This wouldn't be a big problem if there were no free alternatives that offer equal or better performance. But there are.

Microsoft tries to spin the open-source LAMP alternative as disjointed, and further argues it is a more expensive development path, and even that Microsoft offers better Web performance than LAMP-based development.

But this isn't the way the Facebooks of the world see it. They view the open-source LAMP stack as the proven, scalable winner in Web development. Microsoft can't match that with a price tag.

LAMP gives Web developers control over their destiny, both in terms of source code (they can finely tune LAMP to fit their needs) and in terms of cost (they need not pay anyone to scale out). They may choose to pay someone like Red Hat or MySQL for a support subscription, but at scale, companies like Google simply don't. They have the expertise in-house to support themselves.

But that's at scale. The problem remains, however, for Microsoft, that many of those sub-10-employee shops are dreaming of being Google, not being a mom-and-pop shop forever. So, if they're seeing thousands of servers in their future, tying themselves to the Microsoft stack, with all the license fees associated with it, is going to look like a poor decision.

Most companies will fail. Most of the rest will remain small. Rationally, most of these small start-ups, then, should be content to get Microsoft's technology for a song, assuming they don't care about the flexibility that comes from LAMP.

The other side is that with open source--which many of these Web developers will have picked up while at school or just on their own--there are no barriers to how the developer wants to use the software. Ultimately, Microsoft's WebsiteSpark requires Web developers to color within the lines that Microsoft dictates. That may be well and good for a big population of developers, but it's not the path that Digg, Google, Facebook, etc., have taken.

Microsoft is huge in enterprise computing, in part because it lowers the cost and complexity of development for enterprises of any size. But the Web is built on open source. Microsoft is playing catch-up in this market, and it's simply not going to be enough to wave great tools in front of developers for a low fee.

Microsoft isn't alone in making such a pitch. Oracle, for its part, is touting the development of OraTweet, a Twitter clone built with Oracle Application Express Web development platform. But the reality is that enterprise ISVs like Oracle and Microsoft are largely invisible in Web development.

This is one reason Oracle is interested in picking up MySQL, the leading Web database. MySQL is almost entirely complementary, not competitive, to Oracle's enterprise-focused database.

Microsoft, however, has no such plans to buy its way into the open-source development community, which means it must rely on programs like WebsiteSpark to catch up. It's a start-up, but it's not enough.

Open source offers a fantastic way to reach developers and users of one's technology. Ironically, however, the very group most inclined to adopt open source is the least likely to pay for it.

Therefore, to make an open-source business thrive in enterprise software, vendors must learn to distinguish between developer-users and IT operations-buyers. As I'll explain, however, open-source companies may need to guard against becoming too successful in order to preserve their exit opportunities.

It is, of course, quite possible to make money in open source. Lots of it. Red Hat, for example, is approaching $1 billion in annual revenue. MySQL had generated more than $90 million in sales the year it was acquired by Sun Microsystems for $1 billion.

That's real money.

It doesn't, however, come from the developers that download open-source code. Developers, in former MySQL CEO Marten Mickos' words, "spend time to save money."

Hardly the ideal customer.

Developers download software, which a great way to initial a buying conversation but a terrible way to finish it. Open-source companies talk about selling support, but this is a losing proposition. Developers, after all, are highly likely to support themselves through online forums or other means. They don't pay for software, and they don't buy support. Not most of them, anyway.

This is one reason that pure-play support models simply don't scale in open source. They focus on the exact wrong audience.

Sure, there's a honeymoon period for new open-source companies that launch support offerings around established community-led projects. Some developers buy support, either through personal need or corporate requirements. After that initial rush for support, however, it's a tough slog selling support to developers. It's like selling ice to Eskimos.

This brings us back to a real dilemma in open-source companies: how to monetize popularity (i.e., downloads).

Developers are the most efficient way to spread adoption of one's product but perhaps the least efficient way to monetize it. To get paid, vendors must learn to separate IT developers from IT operations, and build offerings for both.

Red Hat is a classic example. People think that Red Hat sells support. It doesn't. Not really.

The primary reason enterprises buy a Red Hat Enterprise Linux (RHEL) subscription isn't for Linux support, and certainly isn't for the bits: you can get the bits free from CentOS, and support comes heavily discounted from Oracle.

No, the reason companies purchase a RHEL subscription comes down to certification that RHEL works with a wide variety of hardware and software, as well as with the Red Hat Network, which delivers updates to an enterprise's RHEL servers.

In other words, IT operations pay Red Hat to help manage their Linux servers in production. The money is in operations.

Red Hat isn't alone. Look at JBoss. The company started minting money, once it licensed Hyperic's software to build the JBoss Operations Network.

SpringSource took it one step further and actually bought Hyperic, the company, as the foundation for its Build-Run-Manage message, a message founded in selling to IT operations, not developers. (Rob Bearden, chief operating officer at SpringSource, was deeply involved in both decisions and remains one of the smartest people in the industry on building open-source businesses. If there's any wisdom in this post, it is his.)

For new open-source companies grappling with how to supercharge sales, the answer is operations. It may not be a systems-monitoring tool like Hyperic or Zenoss, but it likely is about systems management, as operations need and pays for it.

There you have it: the secret to your billion-dollar open-source opportunity. Except for one niggling fact: despite the value of IT operations to make sales, it's really developers who create the most company value, from an asset perspective. SpringSource's sales didn't justify its $420 million valuation. Its developer base did. Developers have strategic value, in terms of IT operations and creating tactical value.

In fact, SpringSource's valuation might well have gone down, had it been making more money, just as TechCrunch's Michael Arrington astutely argues could happen with Twitter. Sales provide a measurable, tangible valuation. Developer traction creates an amorphous, strategic value.

Hence, while IT operations is the crux of making sales in open source, it might well be that open-source companies should focus on community development and avoid making too much money so that they can maintain a healthy valuation. But not too healthy: there isn't an incredible amount of IT vendors that can swallow $1 billion acquisitions, the IPO era seems to be over.

Is this the new open-source entrepreneur's dilemma?

Follow me on Twitter @mjasay.

Linux may not represent the future of all computing, but it sure provides a compelling example of what a dedicated community can accomplish.

With over 1,000 developers actively working on the Linux kernel, representing some 200 different corporations, Linux is an exceptional example of the power of open-source communities, and also speaks to the value of groups like the Linux Foundation that help to shepherd it.

Jonathan Corbet, in conjunction with the Linux Foundation, has co-authored a report focused on who writes Linux code (PDF). I reported last month on a piece of the report's data.

As a reminder, Red Hat remains the top contributor to the Linux kernel, writing 12.3 percent of the kernel, though Intel (6.9 percent) is making a concerted effort to catch up.

Beyond these headline numbers, however, the Linux Foundation's report offers some intriguing data:

• Since 2008, the number of individual developers has increased by 10 percent, "reflecting the ubiquity of Linux across industries," according to the report.
• More than 70 percent of total contributions to the kernel come from "sponsored developers" (i.e., those paid to do Linux development by Red Hat, IBM, Novell, Intel, Oracle, and others).
• 2.7 million lines of net-new lines of code have been added since April 2008, with an average of 10,923 lines of code added each day (nearly triple the rate in 2008). According to the Linux Foundation, this represents a "rate of change larger than any other public software project of any size."
• Equally important as adding to the kernel's size, however, is the fact that an average of 5,547 lines are removed every day, keeping the code lean and relevant.

(Credit: Linux Foundation)

Clearly, the Linux kernel process is doing something right, given the amount of developers it is able to accommodate, without losing its quality advantages (or its customers). Importantly, expertise in Linux translates into a fatter paycheck, too: up to 50 percent bigger.

Small wonder, then, that Microsoft continues to fret about competition from Linux: competing with Linux effectively represents competing with the entire software and hardware industries...all at once.

Not even Redmond in its prime would want that fight.

Follow me on Twitter @mjasay.

In 2007 Red Hat stood on top of the Linux kernel contributor list with room to spare. At 12.7 percent of the Linux kernel contributed by Red Hat (measured in terms of lines changed), IBM was the runner-up at a comparatively distant 5.9 percent. In 2008, Red Hat slipped a little but maintained the top spot (11.2 percent), with Novell making a burst into second place at 8.9 percent.

In 2009, things get more interesting, with Intel making a serious challenge to claim the top spot in Linux kernel contributions.

Red Hat, Novell, and IBM all have substantial software businesses, with heavy investments in Linux, so it makes sense that they'd contribute heavily to the Linux kernel. But according to new data Jonathan Corbet of LWN.net announced at the Ottawa Linux Symposium on Wednesday, Intel has surged from 2.3 percent in 2007 to 4.1 percent in 2008 to 6.9 percent in 2009.

(Credit: Jonathan Corbet (LWN.net))

Red Hat still sits atop the corporate pile of contributors with 12.3 percent, but within the next two years it's possible that we'll see Intel top it. Since Corbet last compiled his kernel data in 2008, 2,559 developers added 4.8 million lines of code. Among the 339 employers found in Corbet's data, Intel ranks second.

This really is remarkable. Why is a hardware company, albeit one with significant software assets, making such an earnest effort to contribute to open-source software?

Intel's commitment, as Dirk Hohndel, Intel's chief Linux and open-source technologist, told me, signals Linux's critical importance to a broad community:

It's a sign of the strength of the Linux community that contributors come from all sorts of places. This shows how important Linux is.

Yes, but why Intel? Suffice it to say, Intel doesn't account for its Linux development as "charitable giving."

Indeed, John Treadway suggests that "at the very least [Intel's kernel development] means Intel-based platforms will continue to have the advantage," because presumably Intel chips inside servers, Netbooks, desktops, mobile phones, and more will run Linux as well or better than they do Windows.

Intel's Linux commitment, in short, could be a hedge on its longstanding partnership with Microsoft.

Or maybe it's more. For years Intel made a fortune buddying up with Microsoft in the so-called Wintel duopoly. The problem with this pairing is that Microsoft's portion of the pie cuts into Intel's to an ever-widening degree. And it's not just Microsoft: the more an original equipment manufacturer spends on software the less is left over for Intel's hardware.

So, as SAP's Dirk Riehle remarks, Intel's Linux strategy frees up more money to spend on its chips, a theme Riehle has touched on before with reference to IBM's commitment to Linux.

Watch for Intel to further increase its commitment to Linux, paying more and more developers like Jeff Dike to give lots of software away.

This makes the developers happy, but it also makes Intel happy. The more great open-source software out there, the more money is available to buy Intel hardware. Microsoft is the casualty, but that's business. One company's complement is another company's core. That's the way open-source capitalism works.

Follow me on Twitter @mjasay.

Open source's greatest strength may also be its Achilles' heel.

As a developer-driven phenomenon, much of the best open-source software ends up being written for other developers. For example, it's not surprising that Linux wins on the server (technical audience) but largely loses on the desktop (non-technical audience). Companies like Canonical and MindTouch can mitigate this by paying for usability design. But as an overall movement, it remains a weakness.

Apple has the opposite problem. It is religiously focused on usability, but struggles to open up to outside developers.

Even so, its attention to the user is something open source must emulate to reach the next level of adoption. Jason Snell of MacWorld writes:

Apple excels at creating products that the general public likes because the company is driven by design, not by engineering. Most tech products--heck, most products in general--aren't as good as they can be because they're put together by the people with the technical knowledge required to build them. And so the technical aspects of the product get pushed to the forefront.

The more complicated a product gets, the more technical acumen is required to put it together. Bad Web sites are built by people who know how to code HTML and JavaScript but don't understand how people use the Web. Bad software is written by people who are experts at knowing how a computer works and how to write code to make it do what they want, but no idea about how regular people behave and how those people expect to interact with that software.

Apple's the kind of company that makes decisions based on people, on users, and then challenges its engineers to find ways to fulfill those needs.

Why can't open source do this? Isn't there room in the open-source development process for the product manager, the focus group, and various other tools that software companies employ to determine what average users want and then to translate this into development plans?

The company (or project) that figures out how to do this will win.

Some projects already accomplish this to some extent. The strength of Mozilla, for example, is that it has figured out how to enable 40 percent of its development to be done by outside contributors, as BusinessWeek recently wrote. The downside is that these contributors are techies, but the upside is that they're techies who add language packs, accessibility features, and other "niche" areas that Mozilla might otherwise struggle to deliver.

This suggests a start: enable your open-source project to accept meaningful outside contributions that make the project reflective of a wider development community.

But the real goldmine is broadening the definition of "developer" to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won.

Until that day, don't be surprised to see Microsoft, Apple, and their ilk win most battles for the hearts and minds of common users. This is why Google comes across as naive in asking open-source developers to help it fight Microsoft on the "desktop." It's not a market developers are well-equipped to win because they're aren't reflective of the vast majority of end users.

Most people don't care how the software is written, and care even less for the supposed elegance of a given program's code. They just want the software to work in an easy-to-use manner, to look nice, and to fit their budget.

Open source does the last one better than most, but struggles at times with the first two. Fix that problem and open source will know no boundaries.

Follow me on Twitter @mjasay.

For all the discussion of the importance of transparency and openness on the Web today, it's very telling that the world's fastest-growing mobile platform may also be the most proprietary.

Apple wins rave reviews (including from me) on its technology but certainly not for its commitment to sharing its innovations with the world...unless, of course, you fork over $299 and sign a two-year mobile service commitment.

Indeed, Apple has earned the dubious honor of being more closed than Microsoft.

And yet, as Marc Hedlund reveals over on the O'Reilly Radar, application growth for the iPhone dwarfs that of the former leader in the smartphone category, PalmOS:

iPhone OS app growth vs. PalmOS app growth

(Credit: Marc Hedlund)

If openness matters so much, why is Apple doing so well with its uber-proprietary iPhone, just as Microsoft dominates the desktop with proprietary Windows?

There are at least two answers. One is that while Apple's iPhone (like Microsoft's Windows) isn't open in the open-source sense, it is open in the sense that it's easy to create applications that run on it. The second reason is that there's a huge financial incentive to do so, given the momentum behind the platform.

For some, these reasons aren't good enough, such as Mozilla Chair Mitchell Baker:

Many of us participate in closed systems where the rules are set for us and we don't see them, certainly can't change them, and aren't permitted to "participate" in building the rules. This is true of very popular web services. For example, I "participate" in Flickr and Facebook, but within the system and rules that those organizations set up to meet their own goals. That's fine; there's no reason for those sites to change.

Mozilla is trying to build a layer of the Internet that's different, where "participation" extends to the very core of what we build.

With 40 percent of Mozilla's Firefox written by outside contributors, it's clear that an open platform works for Mozilla to build a better browser, which is why Mozilla continues to improve the ways in which developers can contribute to it. But it's equally clear that there are other ways to be "open to participation," ways that pay the rent for Apple, Microsoft, and huge ecosystems of commercial partners.

Is one platform approach better than another?

While it's clear that the world has room for both proprietary-but-open-enough and pureplay-open approaches to platform building, I favor the more open approach. The reason is that eventually, it appears proprietary approaches can collapse under their own weight.

Take Windows, for example. To maintain its growth, Microsoft has had to include more and more functionality in the operating system, stepping on the toes (or outright devouring the toes) of its erstwhile partners. (Interestingly, while discussing whether openness matters for Apple over Google Android, Slate describes Microsoft's Windows approach as open.)

Eventually, Windows grew to such heft that the market, including Microsoft partners, started looking for open alternatives, causing then Microsoft chairman Bill Gates to dub Linux Microsoft's "most potent operating system competitor." The "good enough" operating system that performed certain tasks much more efficiently and powerfully than Windows has now grown to seriously threaten Microsoft in a range of applications and markets.

Eventually, even Microsoft's desktop dominance may be threatened by Linux as new classes of easy-to-use, cost-effective devices like Netbooks arise.

Back to Apple. Today, Apple's iPhone seems set to rule the world because it enables a huge community of application developers to reach a paying audience. Tomorrow, however, Google (Android/Linux), Nokia (Symbian, Linux), Palm (WebOS/Linux), and even Microsoft (Windows Mobile) threaten its cozy corralling of the mobile market.

Microsoft has made it clear that it's possible to build a massive business with an "open enough" approach to platform development. The question is, can Microsoft (and Apple) maintain that without truly opening up?

Follow me on Twitter @mjasay.

Google blew the minds of developers with the introduction of its innovative Google Wave, a new approach to real-time content collaboration, but its odds of breezing into enterprise computing anytime soon remain remote.

Within enterprise IT departments, starved for compelling ways to collaborate on application development, however, Google Wave may find a ready audience.

Enterprise computing remains in the Stone Age, by modern standards, a topic nicely addressed by the Financial Times recently. While the consumer Internet offers diverse ways to connect (via Facebook, Twitter, Gmail, and other services), the enterprise remains somewhat buttoned-down, relegated to Microsoft Exchange and the occasional fling with IBM's Lotus.

Pardon me while I stifle a yawn.

This isn't necessarily Microsoft's or IBM's fault, of course. Both offer other products that push the envelope on enterprise computing. But it's hard for enterprises to easily digest rapid-fire innovation, and it's not exactly easy for software vendors to recoup investments in groundbreaking innovations, either, as RedMonk's Stephen O'Grady noted in his review of Google Wave:

We don't see a lot of dramatic leaps forward in software, I'd argue, both because it's exceedingly difficult to develop and launch revolutionary products, and because the economics act against it.

It's difficult, of course, to produce them: how many vendors can afford the indulgence of turning high-quality resources loose on a multiyear project with no clear revenue plan in place? But it can be even more difficult to market (or sell such revolutionary products) because, well, they're not what people are used to, and they take some explaining.

So, given that Google Wave may have moved much further than most enterprises are able to willing to accept, at least for now, what good is it?

Equitas IT Solutions' Ryan Cartwright suggests an answer. He indicates that Wave offers "the chance to...make a big improvement in the way we develop free software."

He's absolutely right, but why stop there?

Most of the world's software is not written by open-source software developers, nor is it written by Microsoft or other traditional software vendors. It's written by enterprises for internal use. As such, if Google Wave has the potential to facilitate software development by facilitating real-time collaboration on code--and it does--then why not unleash its potential within enterprise application development?

Google Wave may well crash on the shore of enterprise adoption, but I suspect that it may well roll into the enterprise, anyway, as a code collaboration tool deployed by enterprise IT for its own use. Eventually, that "personal" consumption should trickle out to business users clamoring for their enterprise-computing experience to catch up with their consumer-computing world.

This could be Google's game to lose.

Follow me on Twitter @mjasay.