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.
For those who have fret about Microsoft fighting against open source, I have news for you: Microsoft's impact on open source may be worse as a friend than as an enemy.
Now with MySQL inside! Yes, we can.
(Credit: Microsoft)Over the past few years, Microsoft has steadily warmed to open source, to the point that it now hosts its own open-source code repository and has seen its Microsoft Public License used more often than venerable licenses like the Mozilla Public License or the Eclipse Public License, according to new data released by Black Duck Software.
The open-source world should be worried.
After all, as IBM's Savio Rodrigues points out, an open-source-friendly Microsoft no longer has qualms about embedding open-source software like MySQL into its products. In particular, Microsoft supports MySQL as part of its Azure cloud service...without paying Sun a dime for the privilege.
It's a completely legitimate way to offer open-source value to Microsoft customers, and is very similar to what Amazon is doing with MySQL.
However, as Rodrigues notes, it's not necessarily good for MySQL, or other open-source projects that could be used this same way:
The larger point is if Amazon, Microsoft, IBM, HP, Google, Cisco, EMC/VMware, or Oracle/Sun offer a simple and supported cloud service for running MySQL, Tomcat, JBoss, Mule, or Apache HTTP instances, what reason do customers have to acquire "enterprise subscriptions" from the vendors developing these open source projects? Until now, the value of an open source "enterprise subscription" has largely been access to support and access to administration and management tooling. In the case of MySQL, the former is provided by Amazon RDS and Azure SQL as part of the per-hour service. Again in the case of MySQL, the latter is rendered unnecessary or replicated through Amazon RDS and Azure SQL tools.
Consider it a super-friendly, and super-dangerous, bear hug.
For those who think that this affects commercial open source and not community-led open source, think again. Money and open source don't grow on trees.
The explosion of open-source development has directly correlated to the explosion of cash investments into open-source projects, starting with IBM's $1 billion commitment to Linux. MySQL, the database, would be a pale shade of what it is today without MySQL AB, the company that has funded the overwhelming majority of its development.
So, is this cause to castigate Microsoft? No. After all, it's really no different from what Amazon, Google, Apple, and others do with open source.
Rather, Microsoft's move should serve as a reminder to open-source companies that they need to upgrade their business models or risk being rendered irrelevant by the cloud and all that it enables vendors to do with open-source software.
After all, the protections that the GNU General Public License (GPL) and other open-source licenses offer in the traditional software world are essentially meaningless in the networked world, where software is used to create services, but isn't actually distributed.
This is as true for Red Hat as it is for open-source start-ups like Openbravo and Talend. Imagine if Amazon decides to start offering JBoss as a cloud service. Or Red Hat Enterprise Linux, for that matter (minus the trademarks).
It could happen. Actually, I'll go one step further: it will happen. It's just a matter of when.
This is why companies like IBM, Google, and increasingly Microsoft strategically invest in open source, but don't try to directly monetize open source. It's also why the "open-source companies" need to figure out a Plan B before Plan A gets taken from them.
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?
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.
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.
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.
A recent survey suggests that CIOs are loosening the purse strings on IT spending. IT vendors may want to hold off their celebrations, though, because much of the spending appears to be headed for deflationary forces like cloud computing, virtualization, and their kissing cousin, open source.
An economic rebound never looked so dire.
That's unless you're an IT buyer, of course, suggests a new report from Goldman Sachs. In this week's report, titled "A Paradigm Shift for IT: The Cloud," Goldman Sachs said it expects that pent-up IT dollars will flow in the short term to building out next-generation data centers (e.g., cloud computing). But in the long term, less money is expected to find its way into fewer wallets:
After the initial build-out, Cloud Computing could drive some headwinds for the IT industry, as a result of two factors. First, we see virtualization as a deflationary technology. Second, we see IT spending consolidating in the hands of fewer buyers--the Cloud providers, hosting vendors, and large enterprises. These factors will likely dampen IT spending growth due to greater utilization and buyer pricing power.
Even short-term build-outs may prove disappointing, however, as Goldman Sachs expects large enterprises to grow existing virtualization and automation technology adoption in the rollout of private clouds, shifting slowly to an embrace of public clouds over time. The chart below gives some idea as to when cloud computing will hit its stride:
Who wins in this scenario?
According to the report, Red Hat stands to benefit from the cloud-computing craze. ("Red Hat is well positioned for the emerging Cloud Computing ecosystem, largely due to its open source background and current ubiquitous deployments in data centers, including enterprises, as well as in Cloud providers such as Amazon," the report states.)
But the real beneficiaries will be...the same old crew. "[K]ey suppliers for internal Clouds are likely to be those that have the most complete portfolio of hardware, software, and services," including IBM, Hewlett-Packard, Cisco Systems, EMC, and Oracle.
New boss...same as the old boss.
The other beneficiaries are the start-ups that provide critical components of cloud computing, with an emphasis on management tools. Here we may see open-source companies benefit, including Reductive Labs (Puppet project), Cloudera, and the two rising private cloud companies, VMOps and Eucalyptus, among others.
While open source doesn't factor heavily into this particular Goldman Sachs analysis, the firm has before called out open source's role in wringing more value out of fewer IT dollars. Open source is a primary driver of the global reset in IT spending expectations.
With less money flowing into the pockets of fewer vendors, we can expect to see both increased consolidation and fierce competition for the IT spending that remains. Those vendors that can help CIOs do more with less stand to benefit from this shift to low-cost, high-value computing.
And those that can't? Well, let's just say they may pine for the good old days of the global recession.
Some open-source software may not be open enough. While "open source" refers to software's underlying license and its adherence to the Open Source Definition, there are numerous examples of open-source projects that offer an open license but a relatively closed development process.
But is it open enough?
(Credit: Open Source Initiative)Java is one example people cite of "fauxpen-ness." SAP CTO Vishal Sikka on Monday called for a more open process for Java development, arguing that Sun too tightly controls Java's development. It's a complaint that has plagued the Java community for years.
Not that Java is alone. While Google gets plaudits for its open-source investments, some are quick to allege that Google maintains a closed Android community. The same sort of complaints have arisen over Google's management of Chrome and Chrome OS.
Even Red Hat, the quintessential open-source company, is primarily known for what it distributes, not what it develops. Red Hat, of course, works alongside IBM and other corporate and unaffiliated developers to write the Linux kernel, and scrupulously releases its software under open-source licenses.
But when it comes to development of its Red Hat Enterprise Linux distribution or development of its JBoss middleware or other technologies (e.g., KVM), good luck finding many significant external contributors.
MySQL? It's largely the same. The company (now Sun Microsystems) does virtually all of its own development, which is true of every commercial open-source company of which I'm aware. This is one reason Richard Stallman can unblushingly worry about MySQL's openness despite the fact that it uses his preferred GPL license.
Open source, but not necessarily open process.
There are very good reasons that Google, Red Hat, MySQL, and others keep a tight grip on their open-source development efforts. They are responsible--fiscally and legally--to their customers, and have to be able to guarantee quality and security. Understandably, they exercise some control to ensure the products they ship protect the integrity of their brands.
But such corporate open source indicates a real divide between "open source" as a license and "open source" as a wholly transparent way of developing and distributing software. The former is now common and relatively easy. The latter, quite simply, is not.
The companies that seem to do it best are those that don't rely on direct monetization of open-source software. In other words, if you aren't selling open source, it's easier to be open. Doc Searls captures this brilliantly by arguing "you make money because of [open source], not with it."
Examples abound. IBM is a good example. So is Google, though I agree with its critics that it can do better. Facebook, Oracle, and others also provide examples.
In the future, I think we'll see this "fauxpen-ness" fade as companies clearly separate their open-source efforts from their revenue models. Open source can provide a platform for monetization, but it isn't the best way to actually generate cash. Not for most companies, anyway.
Vishal Sikka, SAP's CTO
(Credit: SAP)It's a fundamental tenet of classical economics that vendors want complementary goods to be cheap and plentiful.
It's therefore not surprising that SAP Chief Technology Officer Vishal Sikka is calling for a more open Java Community Process (JCP).
What is surprising is that it is SAP, the bastion of proprietary software, that delivers this message.
Irony, thy name is SAP.
SAP, after all, is hardly the most open-source or open-process friendly company on the planet. Despite early involvement in Eclipse, some interaction with MySQL (MaxDB), and a new commitment to the Apache Software Foundation, SAP remains a firmly proprietary company.
Even Microsoft, which arguably has the most to lose from open source, has consistently and continually experimented with greater open-source involvement.
SAP? Not so much. In large part, SAP hasn't been forced to embrace open source because it hasn't been threatened by it. ERP (enterprise resource planning) is such a complex beast that it has remained largely impervious to open source (with the exception of open-source start-ups like Compiere and Openbravo, to which I'm an adviser).
A few years ago I was asked to speak at SAP's Palo Alto campus. I spent an hour talking about open source's commodity influence on the industry. During the question-and-answer period, one attendee said: "This is all fine, but open source has not touched our business. ERP is different."
Apparently, that thinking prevails, as Sikka's argument about a more open JCP process fails to apply the logic to SAP's own software. He wrote Monday in a blog, laced with italics and bolds:
The Java industry is currently going through important changes, and there are many discussions around the openness of Java and the Java Community Process (JCP). To date, the JCP is heavily dominated by Sun Microsystems which was not always to the benefit of all parties interested in Java. Java is the lifeblood of the IT industry, and IT is a fundamental underpinning of the way business is conducted in the 21st century....
To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation. Java should be free of any encumbrances to permit fair competition between compatible implementations for the benefit of customers. By preserving the integrity of Java, the IT industry can ensure a vibrant developer community and continued innovation for enterprise software customers. This ensures the continued global economic success brought about through open innovation.
It's a good argument, but it sounds funny coming from an SAP executive. After all, Sikka starts his argument by asserting that SAP's software is indispensable to the world's IT systems: "SAP systems are at the core of large parts of global IT, and are powering more than 65 percent of the transactions that make up the world's Gross Domestic Product (GDP)."
Surely any system upon which 65 percent of the world's GDP depends should be open, right?
Apparently not. SAP NetWeaver and, well, everything the company ships remain firmly proprietary last time I checked. Complements to SAP's proprietary products should be open, however--or so the argument goes.
Sikka does suggest that "SAP software also needs to be open and adaptable in order to allow customers and partners to be nimble and benefit from the speed of innovation within the SAP ecosystem," but apparently he means that everything but SAP's software should be open and adaptable.
Complements are best when they're free and plentiful, after all.
Again, Sikka's message is not wrong. It's the messenger who has the problem.
Disclosure: I will be presenting at SAP in Walldorf, Germany, on Thursday on SAP's track record with open source and open standards. Please share your thoughts on how SAP is doing.
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.
