Open source, like digital media, doesn't suck money out of hitherto profitable industries. Instead, the opening up of software and information simply changes where the money gets made.
This is obvious to the Googles of the world. It's probably equally obvious to the Microsofts of the world. The difference is that the latter can see the train coming but is powerless to stop it, and the former is driving the train.
The evidence for this is increasingly clear and is driven by a shift in how content is sold and consumed. The problem is neatly summarized by Google CEO Eric Schmidt in a Wall Street Journal op-ed piece directed at the newspaper industry:
[T]he Internet has broken down the entire news package with articles read individually, reached from a blog or search engine, and abandoned if there is no good reason to hang around once the story is finished. It's what we have come to call internally the atomic unit of consumption.
That newspaper was "the package," but is increasingly too slow and out-of-sync with how people prefer to discover news content. New packaging is rising, including Google News, that will shift who makes money on news content.
Reporters will still get paid. They'll just have a new employer on their payroll check. Maybe it will be Google.
Think about what is happening in music. I could download New Order's "Regret" for free using LimeWire, but I bought it on iTunes because of the "packaging" which makes my experience easy, high-quality, and legal.
Still, the primary drivers are ease and quality.
Such packaging is worth a lot of money--and to an entirely new breed of vendor--as a quick look at Google's latest income statement suggests.
It's happening in software, too, particularly in open-source software. Red Hat is an example of a company that does a great job of turning software license into an ongoing service contract that enterprises buy. It does this by packaging the power of others' development in the form of a subscription, as Red Hat CEO Jim Whitehurst recently highlighted.
But Red Hat is just Open Source 1.5. Open Source 2.0 looks more like Google or IBM. For every dollar Red Hat makes selling subscriptions to use open-source software like Linux and JBoss, both Google and IBM make multiples of that dollar using open-source software to sell something else, something they've packaged in hardware or Web-based services.
The hardware is running open source. The services are based on open source. The money is made in the packaging of open source.
... Read moreThe mobile-computing world is increasingly a two-horse race between Google and Apple, with Apple clearly in the lead but Google Android making up ground quickly. Microsoft and Symbian are also still in the game, but the ultimate winner will be the one that best appeals to consumers or developers.
Or both.
Sexy? Yes. But what about the developers?
This struck home while reading Mark Sigal's analysis of the "inevitability" of Google Android. On his way to dismantling the idea that Google's victory is assured, Sigal stumbles into apparently divergent interest groups:
[U]nlike the PC, where "good enough" was the bar required to seize the market,...for most consumers, their mobile device of choice is a lifestyle decision, a personal, ever-present extension of themselves that is resident in a way that never existed before with the PC--a value proposition that Apple has completely run with on iPhone (and iPod before that).
Fundamentally, though, mobile is a platform play, a game that is largely won by securing the hearts and minds of developers, and for them, the expectation bar is now set pretty high, owing to the success of iPhone across so many domains....
If you're Google (or Microsoft or Symbian), then, who do you target? Developers or consumers?
It's a real question, as while both parties' interests ultimately converge (consumers want developers to make great applications so that those same consumers can pay the developers lots of money), the short-term interests of consumers (sexy product) and developers (ease and richness of development platform) don't necessarily go together.
Motorola RAZR? Sexy product, lame development platform. Windows Mobile? Arguably a solid development platform...with almost zero sex appeal for consumers.
This is why John Carroll is probably right to argue that Microsoft should reinvigorate its mobile strategy with an emphasis on .Net as a powerful way for developers to write powerful mobile applications, it's not going to be enough. Microsoft can port all the business applications it wants for Windows Mobile. It won't matter.
Consumers don't buy business applications. Not until after they've chosen a phone that meets their personal needs, first.
Yes, enterprises do try to dictate corporate standards with Blackberrys and dull Dell PCs heading the list. But in the fast-changing mobile market, you can't hope that consumers will be forced to use your software. You want them to want to do so.
This is why I believe Google has a good chance of taking a serious bite out of Apple, and Symbian and Microsoft do not. Symbian is too difficult an application development platform, as Gartner notes, and Microsoft...is boring.
Not that it needs to be. XBox certainly isn't, and actually helped Microsoft surpass Apple in a recent consumer survey focused on product innovation.
But not in mobile, or even in computers. Apple understands how to create wicked cool products that consumers want, which is why its Mac sales are projected to grow by 26 percent in 2010, right through the recession, and why its iPhone continues to thrive.
But Apple's Achilles heel could well be developers, which are reportedly tiring of Apple's apparently arbitrary application approval and updating process. If Google can continue to help handset manufacturers to achieve the "Wow factor," while simultaneously creating a more open, robust development platform, it just might be able to beat Apple at the game it started.
In other words, the winning mobile vendor will be the one that marries sex appeal for consumers with platform appeal for developers. Google is on course to deliver, but it probably needs to win big with consumers before it makes waves with developers.
President Obama is gathering 100 leaders from across the U.S. for his jobs summit in Washington on Thursday to brainstorm how to create new jobs.
While the list of invitees is heavy on academics, labor unions, and business, it appears only two people from technology made an early invitation list: Eric Schmidt, CEO of Google, and Jim Whitehurst, CEO of Red Hat.
FedEx. Yes. Nucor. Yes. But no Microsoft. No Oracle. No Salesforce.com. What gives?
Yes, Schmidt is a key advisor to Obama. But his invitation, along with Whitehurst's, could have a lot to do with the fact that Google and Red Hat, unlike many of their peers, are actively hiring.
Red Hat and Google have thrived through the recession, perhaps suggesting that they have a clue as to what it will take to create new jobs in a tough economy, one that has seen 23 straight months of job losses.
Intriguingly, Google's hiring may be crimped more by a desire not to aggregate all of the best and brightest than an inability to do so, as evinced by Google Vice President Bradley Horowitz's comments at Supernova this week.
When I asked Whitehurst on Wednesday what he thought the two companies had in common, he was quick to respond: "open source."
It's an interesting observation. While the two companies use open source in different ways, their business models are actually more similar than different, and both depend on open source.
As I've written, both Google and Red Hat (along with Facebook and other new-school "software" companies) depend upon and help to create abundance--of code, of Web sites, of information--and then make money by filtering that abundance.
It's a model that works, and it's a model that heavily depends upon and contributes to open-source software.
It would be going too far to suggest that open source is the critical component of any successful technology business today, especially as just about every company now includes it in their offerings in some way. Plus, CIOs have discovered other ways to stretch IT budgets and keep their workers on the payroll, as Gartner advises.
But the mentality of open source--more with less, sharing code and expertise--does seem to be a hallmark of successful technology companies, and particularly at Google and Red Hat.
Everyone hates patent trolls (except, perhaps, the patent trolls' mothers). But it's easier to despise patent trolls when you either have a lot of patents, or none. What if your company were awarded a significant patent that could be used to shake down Google and the rest of the industry for corporate benefit.
Or buy food for your family?
Is it your fiduciary duty to exercise that patent? Is it a personal duty? And do you have the legal right to do so?
The first two questions are tricky, but the last one is currently being considered by the U.S. Supreme Court. Consider yourself lucky that you don't have to decide it.
Bilski and business method patents
Recently, the U.S. Supreme Court heard oral arguments in the controversial Bilski case where IBM, typically friendly to open source and innovation, backed the wrong horse. According to The Wall Street Journal's coverage of the arguments, the justices were skeptical--if not contemptuous--of the case put forward by Bilski and the proponents of business method patents.
Chief Justice John Roberts quipped that business method patents are akin to patenting the idea that "I buy low and sell high. That's my patent for maximizing wealth."
Silly when presented in this way. But perhaps silly when presented in just about any way.
Business method patents came into being 20 years ago with the Federal Circuit's State Street decision, the case that spawned Bilski. Two of the best-known technology examples of such patents are Amazon's one-click checkout and Priceline's reverse auction.
In a September blog I took IBM to the woodshed for its stance on Bilski. Big Blue filed an amicus brief (PDF) that I argued was disingenuous at best. IBM argued:
Patent protection has promoted the free sharing of source code...which has fueled the explosive growth of open source software development.
Really?!?
IBM was not alone. Novartis, the big pharmaceutical company, also filed a supporting brief.
The industry's moment of (in)decision
I think that the Bilski case is a divider of wheat from chaff, a moment that forces technology companies to take sides on a critical issue that goes to the heart of innovation in our economy.
On one side, companies such as IBM and Novartis maintain that patents should not be tied to "primitive physical technology" but should also embrace a broader range of modern business activities.
But other companies, including Google and Symantec, took the other side and filed briefs (PDF) with the Supreme Court arguing that expanded business method patents would open them up to infringement lawsuits over the "very mental processes and ideas that are the building blocks of innovation."
What would you do? LogLogic and Sponster examples...
I was reminded of this issue by an announcement today from LogLogic, a log management and security company I wrote about last year as an example of the pervasive use of embedded Linux.
LogLogic was granted a patent in October that appears to be rather sweeping in its scope, covering the collection of logs and the management of the data in those logs.
Imagine if LogLogic went "troll" with this patent....
At a minimum it could be a nuisance to its competitors and at a maximum it could possibly shake down any company that sold a product that relied on log collection (describing hundreds, if not thousands, of products on the market today).
Or how about this one? Sponster has a patent on a system for delivering contextual ads against electronic messages like e-mail, SMS, tweets, etc. Google filed for a similar patent, but over a year after Sponster, and while Sponster's patent was recently granted in October, Google's was denied. (Disclosure: I know and am friends with one of the Sponster executives.)
On the one hand, Sponster could go troll and sue just about everyone on the Web. On the other hand, I know from talking with the executives that they have no desire to do so. The fact that the company has not sued anyone in its six-plus years of existence is a clear indication of this. Sponster wants to build its business around the patent, but Google or Microsoft with their heft can squash that desire.
Should Sponster fight or capitulate? It's easy when you think of patent trolls as trolls that create no real value. But what about when they are real people and real companies like Sponster and LogLogic?
LogLogic makes its choice
LogLogic appears to have made its decision. In a company blog on Wednesday, a LogLogic executive points out the potential harm they see in a Bilski decision by the Supreme Court that would allow broader business patent methods.
LogLogic also (correctly, in my view) argues that the anti-business method lobby of Google et al "represent[s] the true innovative spirit of Silicon Valley where entrepreneurs are rewarded for risk taking and embrace the thinking of Austrian economist Joseph Schumpeter and creative destruction."
LogLogic decided to take a defensive posture with this sweeping patent rather than go troll. Who knows what Sponster will do, or should do. Presumably it worked just as hard on its technology as Google: shouldn't it get paid?
More broadly, do you agree with IBM that business methods should be upheld, or with Google that they should be crushed? What would your company decide to do? Where do you stand?
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.
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.
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.
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.
Google's biggest threat is no longer Microsoft. It is itself.
As the company harvests copious quantities of personal data, it becomes dramatically better at serving customer needs...
...and at freaking them out over privacy concerns.
In other words, Google gets stronger with every Google Doc created, every Google Voice call dialed, and every Gmail e-mail sent. It becomes stronger because data is the heart of the Web's biggest businesses, as Redmonk analyst Stephen O'Grady implies.
But in so doing Google also becomes more threatening to the very consumers it is trying to serve.
Google Dashboard is meant to change this by putting consumer data back in the hands of consumers. It's a move that follows on Google's earlier pledge to "open data" and its Data Liberation Front.
As CNET reports, Dashboard lets people review the personal data Google has stored for them, delete it, and alter future collection policies. It's a great way for Google to mollify concerned users, putting control back in their hands.
Still, it's almost certainly never going to be used by the vast majority of Google users. Ever.
Why? Because for all our hand-wringing over privacy--and for good reason--the reality is that most of us, most of the time, really don't care. Or, rather, if accessing useful services or getting work done more efficiently requires some privacy concessions, we gladly concede.
It's not that we don't value our privacy. It's just that in many contexts, we value other things as much or more. We weigh the risks versus the benefits, and often the benefits trump the privacy risks.
It's the same thing with file formats. For years we've been agonizing over Microsoft's lock-in of customers through proprietary file formats (.pst, .doc, etc.). Now Microsoft is opening up the specifications for file formats like .pst (Outlook file format), and yet it will almost certainly change little to nothing in what products most people use most of the time.
People don't use Microsoft Office because they're forced to. They do so because it's convenient. (Yes, an argument can be made that it's convenient because Microsoft has forced network effects through lock-in.)
This, incidentally, is exactly the reason that Wednesday night I declared a ban on Microsoft Office in our family in favor of Google Docs--and didn't opt for OpenOffice (which we also use). I got sick of having to recover documents and perform other IT tasks related to a locally installed office suite, open source or proprietary. And I find it easier to let Google handle the back-end IT operations.
I wasn't trying to evade lock-in. I was trying to increase personal happiness.
Am I concerned about Google snooping on the documents we write and store in Google Docs? Let's just say I worry more about my time fixing Office than whether Google gleans any information from my 12-year old's seventh-grade essay.
Dashboard leaves Google in the prime position of being able to honestly say that it doesn't control user data, while still delivering increasingly beneficial services based on that data. It will not change the way that the vast majority of consumers use Google, but it just might change the way they think about Google.
A very smart move by Google, one that all data-driven businesses should emulate.
Follow me on Twitter @mjasay.
