In the past week, the open-source business community appears to have reached consensus: making money from open-source software is a bad model, but making money with open source is golden.
This can't be good for Microsoft.
Microsoft has long maintained that as the open-source industry has matured, it has become more and more like the commercial world it sought to leave behind. Fundamental freedoms of open source, like the right to modify source code, are signed away to secure a support contract with Red Hat or another vendor.
In many ways, Microsoft was right. Unfortunately for the Redmond giant, however, the new consensus should lead to less commercialization of open source, and more commercialization around open source. There's a big difference, and it's one that threatens to seriously undermine Microsoft and every other traditional software vendor.
That is, unless Microsoft responds in kind.
The new consensus
This consensus has been articulated by TechDirt, Redmonk's Stephen O'Grady, GigaOm, and here on The Open Road.
In fact, it's a drum I've been beating for over a year as Tim O'Reilly's wisdom on the topic finally caught up with my 33MHz brain.
There are fundamental, strategic benefits to open source: ease of distribution, friction-less adoption, costs, etc. There are also serious downsides when it comes to selling it: people chafe at paying for something if they can get it, or something similar to it, for free.
Such problems don't plague companies like Google, which distributes open-source software to drive more adoption of its proprietary advertising or SaaS services. Even Red Hat isn't really in the software business: not with its Linux distribution, anyway. It's in the business of providing certification and update services; of managing the complexity of an operating system.
It's a great business, but if you had to choose between Google's sales or Red Hat's, it's a no-brainer.
Microsoft's response
As this lightbulb goes on across the industry, companies like Microsoft, which insist on direct monetization of software, with little in the way of open-source complements to fuel adoption (or simply undermine competitors), are going to struggle. More and more companies will give away Microsoft's core business as open-source complements to their own.
So, here's a suggestion for Microsoft as just one good way to respond: open-source Internet Explorer.
Fight Firefox with fire
Cut Google's Chrome and Chrome OS off at the knees. Undermine Mozilla Firefox's raison d'etre. Give the European Commission a reason to love you.
More importantly, give developers something to embrace and extend. Microsoft has been steadily losing browser market share as Firefox eats into it. In some countries, like Germany, Firefox has even surpassed IE's market share.
Fight fire with fire. IE is still the world's most popular browser. Make it the world's most open browser, too.
Every Microsoft business could benefit from this move. Even if one assumes that Microsoft isn't ready to take the plunge and fully open up the development process around IE, here's some comfort: neither has Google around Chrome. Microsoft can still steer the IE ship, even if it were open source.
Microsoft needs a proactive open-source strategy, rather than the reactive policy it has had to date. Open source is a threat, yes, but it's a threat to everyone, especially as the industry collectively comes to grips with open source as a business enabler, rather than as a product to sell.
If Microsoft wants to win big in the new world of Web-based software, it needs a bold strategy. Open-sourcing IE is the starting point.
With open-source software businesses, you have two options. Actually, three, but the third belongs to Red Hat, and it applies to roughly no one else.
The first option is to sell support for open-source software. This option is generally advocated by those who have never grown a business beyond $10 million. It's a terrible model unless your only aspiration in life is to run a services company.
Hence, the support model might be good for Accenture or systems integrator, if they want to take on the burden of support, but it's a poor model for Red Hat, MindTouch, Microsoft, or other software company.
The second option is to contribute heavily to open source but not build your revenue model around monetizing that software directly. This is what the New York Times points to in its Sunday expose of allegedly fizzling open-source business models.
Open source can drive adoption like little else. It's not, however, necessarily a great driver of revenue. For that, you need to be selling something beyond the source code, and that "something" is often going to be proprietary, be it hardware, software, or a service.
Proprietary search revenue funds a lot of open-source development at Google.
That's the way successful companies are run: they take ownership of what they ship. They are influenced by but not controlled by the mystical whims of The Community.
Even Red Hat, which piggybacks on a lot of Linux kernel development, increasingly includes more home-grown software in its distribution and takes great pains to certify its Red Hat Enterprise Linux will work in the most demanding environments before putting its brand on the label.
Some, including me, have wrongly concluded that Red Hat's business model would apply to other product markets beyond the operating system. It doesn't. It only applies where the moving parts in the product are complex, multitudinous, and frequently changing.
For everything else, there's Option 1 (if you want a business that doesn't scale well or possibly at all) or Option 2 (which is really no different from the old proprietary model except that it effectively uses open-source complements to lower engineering costs and possibly sales/marketing costs).
Even Option 2 won't work if you under-invest in marketing and development, as Symbian is learning to its hurt. It turns out that there is no free lunch, even in the land of free software. It always takes work. And money. Lots of both, actually.
Twitter and Facebook are duking it out to own the future of the social Web, though users won't have noticed. Indeed, for those who use both, this may come as a surprise, since the two, while both social media platforms, seem to serve very different purposes.
Tell that to Twitter and Facebook, which increasingly have painted big bull's-eyes on each other.
Facebook groks this more than Twitter, which is why your mom/dad, teenage neighbors, and friends all use Facebook, and probably don't use Twitter.
Both companies have open APIs that encourage third-party developers to build out their respective platforms. Facebook has the Open Stream API; Twitter, the ">Open API Service.
These are critical components of a platform strategy, but they're secondary to the lesson that Microsoft and Apple have taught us: if users don't care about the front end of software/services, developers won't care about the back end of the same.
Facebook largely works because people know how and why to use it. Twitter...not so much.
It's telling that Twitter's "big" feature of the last six months is...lists. I use and love Twitter, but after a month I still can't get myself excited about creating or following Twitter lists. I'm not even sure why I'd want to do so.
Is this the best Twitter can do?
This is perhaps why Twitter seems to work for a narrow class of user: Caucasian, middle-aged urbanites with no kids.
In other words, not teens, not your mom/dad, and probably not you.
Facebook's demographics look very different, probably because its current range of uses is very different.
To me, this is a user-interface problem, and not a defect in the DNA of the Twitter platform. It's simply not immediately obvious what one should do with Twitter. That's not the case with Facebook.
We learned this long ago in open source. What separates a good but doomed project from a truly great project is documentation (to help developers know how to use the system) and user interface (to help end users know how to deploy the software). That's why Linux was interesting but not ubiquitous until Red Hat, IBM, and others added the finish that made its power usable by the general business world.
Twitter has a lot of promise, but not yet much polish.
It's nice that New York gangs have found new ways to dis each other using Twitter. It will be better when Twitter makes it easy and obvious for me to talk with my parents using Twitter.
When an open-source project is working optimally, can proprietary-software companies hope to compete?
Eat my dust, proprietary sloths
Greg Kroah-Hartman, a prominent Linux kernel developer and Novell fellow, suggests that the answer is no. Speaking to the How Software Is Built blog, Kroah-Hartman makes the case that the pace of Linux development leaves competition in the dust:
[The Linux kernel development team adds] 11,000 lines, remove[s] 5,500 lines, and modif[ies] 2,200 lines [of code] every single day.
People ask whether we can keep that up, and I have to tell you that every single year, I say there's no way we can go any faster than this. And then we do. We keep growing, and I don't see that slowing down at all anywhere.
I mean, the giant server guys love us, the embedded guys love us, and there are entire processor families that only run Linux, so they rely on us. The fact that we're out there everywhere in the world these days is actually pretty scary, from an engineering standpoint. And even at that rate of change, we maintain a stable kernel.
It's something that no one company can keep up with. It would actually be impossible at this point to create an operating system to compete against us. You can't sustain that rate of change on your own.
Microsoft might beg to differ, as would Apple, but the reality is that neither is updated as often or as extensively as Linux is, which supports a far broader hardware portfolio than any other operating system in existence.
Linux is pretty incredible. But it's not alone. Mozilla Firefox, Eclipse, and other projects produce best-in-class software at an almost frightening pace.
Can anyone compete with an open-source project at the top of its game?
The answer might well be no, as the top open-source projects are collaborative efforts between multiple companies that pool resources and expertise to drive development. And while it might seem reasonable that a single corporation could best open source's seeming "development by committee" approach, the reality is that well-managed open-source projects have none of the inertia that one might expect from a communal approach.
Quite the opposite.
Having said that, very few open-source projects actually meet the criteria that enable Linux's success. Most appeal to a too-narrow and too-small population of developers (i.e., single-company projects) to glean the benefits and scale of Linux-like development.
As such, the proprietary-software companies probably won't have to worry about competing with indomitable open-source competitors. Not most of the time, anyway.
For those that do, however, better stock up on the pumpkin pie. It may be the only thing to be grateful for this Thanksgiving season.
Greg Kroah-Hartman interview discovered via @glynmoody's ComputerWorld blog.
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.
How would you like your software today?
(Credit: Domino's (Screenshot by Matt Asay))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.
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?
You can't code me, but at least you can buy me.
(Credit: Google)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.
Justin Erenkrantz, President, Apache Software Foundation
(Credit: Matt Asay/CNET)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.
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.
Together we can figure this out
Despite Apple's tremendous success with the iPhone, we're still in the early innings of mobile adoption. As such, a strategy of "throwing-lots-of-things-against-the-wall-to-see-what-sticks" makes a lot of sense.
It's true of platforms like Google Android, but it's also true of applications.
Even on the iPhone, which reportedly drives $2.4 billion worth of applications in annual sales, very few application developers appear to be making much money. Zynga, creator of Farmville, is an exception, as BusinessWeek notes, doing more than $100 million in annual sales.
This isn't to suggest that developers should stop trying. Quite the opposite. Now is the time to try a range of applications to see what sells.
Google is following the same strategy with its Android platform. The company is happily promiscuous with its code, allowing and even encouraging fragmentation to see where the industry will take Android. Fragmentation enables handset manufacturers and others to find the best fit for Android in the market, rather than going the Apple route. ("If we build it, they will come.")
It's very possible, as Bill Weinberg notes, that such fragmentation and experimentation will result in Android getting greater play beyond mobile than it does in the smartphone market.
I suspect Google won't mind. As in other areas, it's using the broad-based, open-source approach to increase adoption of its services like Search, services which generate more than $22 billion each year.
It's an approach that works particularly well for a fast-follower: someone tracking the progress of an early market leader. An open-source strategy basically enables the industry to determine, by itself and for itself, what the market leader is missing and how to resolve the voids.
However, it's also a good way to generate developer interest and, hence, modifications and add-ons. Application developers might be well-served by open-sourcing their applications to encourage adoption and make their road maps a community affair.
There are over 4 billion mobile phones on the planet, with virtually no one outside of the wireless carriers and handset manufacturers making money from this extensive device reach. The market is ripe for software businesses, but first we need to experiment to discover what sells. Open source just might be able to help with that.
