Brian Prentice

For those of you not familiar with commercial open source software – which I will now refer to as COSS (hey, I’m an analyst, it’s my job to create acronyms) – it is essentially a business model loosely tied to the concept of “freemium.” On one hand a vendor provides a free, open source offering (and by that I mean that it’s covered under a license agreement recognized by OSI) which is usually supported by the community. On the other hand there is a “value-add” solution which is not free, is directly supported by the software vendor and is a proprietary-licensed offering.

First things first. COSS doesn’t mean you get some hybrid software that’s half open source and half proprietary (a dessert topping and a floor wax). You pick – you’re either using the open source version or the proprietary version. And if you’re picking the latter than you might as well remove the words “open source” from the term commercial open source software. You’re basically just acquiring good old fashion software in the good old fashion way.

So, from the users’ perspective nothing really changes. The innovation in commercial open source software is largely on the vendor side of the equation. COSS is a way for a software vendor to leverage the positive aspects of open source – particularly community development – as a way to build a business and defray some of the engineering and sales & marketing costs. Not that there’s anything wrong with that!

But, as a user, if you decide to go down the free open source route – especially as a long term decision – you need to be crystal clear on how the vendor is “value adding” their proprietary version. If you don’t, you could be in for a surprise.

The most common way of value adding commercial open source is via the product. In this approach, the vendor not only separates the open source and proprietary versions of the product by providing direct support but also by adding more features to the proprietary version. The proprietary version is therefore a functional superset of the open source solution (this is a topic I’ve explored in more detail in “Commercial Open Source Software: Is All That Glitters Usually Sold” – Gartner subscription required)

Product differentiated COSS has a specific weakness. If the vendor is the primary, or sole, committing organization (in other words there’s not much of a community outside the vendor) then unless you’re either happy with the product as is, or plan on doing all the needed product modifications yourselves, then you are highly dependent on the vendor for product improvements.

The problem comes from the fact that over time the vendor has a financial incentive to see a growing functional gulf emerge between the open source and proprietary versions. After all, they make their money only when you move to the proprietary version. If those couple of extra features you need require an “upgrade”…well so much the better. And that incentive is fuelled when the vendor has a group of venture capitalists hounding them for revenue.

This problem is simply solved. COSS vendors should create a fully transparent charter of development that describes the criteria they will use in determining whether new capabilities go into the open source project or when they’re allocated to the proprietary version. Additionally, it should describe the conditions under which features in the proprietary version will migrate their way into the open source project. That charter of development should be open for audit. With such a charter there may still be a yawning gap between the two versions of the software but at least you’ll know exactly what you’re getting into.

Unfortunately, development charters like this are rare – really rare. Most COSS vendors I have spoken to assure me that they have criteria and they’re committed to assuring a good open source version is available. But there’s no documentation nor full transparency so it basically boils down to “trust me.”

If you’re a trusting type of person, working for a trusting type of organization then no problemo!

By the way, not all COSS is product differentiated. Some COSS providers differentiate themselves based on their service levels (things like indemnification, certifying stacks, consolidating release intervals, etc.) – what I like to call “Community Gap Coverage.” That approach I consider to be much cleaner than differentiating by product.

Why is it that Open Source Software hasn’t had as big an impact in the area of business applications as it has for infrastructure software? It’s a question that regularly circulates around Gartner.

[note: by "business application" I'm referring to the acronym-laden category of software that encompasses an organization's business processes - things like ERP, SCM, HRCM, CRM, ETC., ETC., ETC.)

Now, don’t go overreacting to that first sentence, please! I am not denying the existence of many good Open Source business applications (ERP5 is still one of my favourites in terms of the elegance of its approach). Nor am I denying that there are organizations benefiting from the use of such projects.

But let’s be honest here. Open Source business applications have just not had the same disruptive impact that Open Source operating system, database, middleware and collaboration projects have. The fundamental question is whether this is simply a matter of timing or whether there is a structural impediment to this ever happening.

Personally, I think it’s a combination of both.

In order to explain this I need to come back to the concept of “Collective Competency” (Gartner clients can also read the associated research note – “Collective Competency: A New Business Pattern“). Collective Competency represents the strategic decision frameworks and ongoing tactical efforts needed to create collectively-owned assets. These types of assets – distinct from “entity-specific assets” – are emerging as the only real way for an organization to deal with distortions in a value chain system created by a dominant supplier.

When you look at Open Source as a manifestation of Collective Competency what starts to become clear is that it has been the software vendors’ efforts to alleviate themselves of value chain system dependencies which have fuelled so much Open Source development. Oracle doesn’t want to be dependent on Microsoft for an operating system so they support Linux. SAP doesn’t want to be dependent on Oracle for the DBMS so they try to drive MaxDB. Those concerned about Oracle, Microsoft and SAP dominion over middleware get stuck into things like JBoss.

But the story changes when it comes to business processes. The fact is that there is no real value chain dependency between vendors when it comes to the business process layer of the software stack (that will probably change in the future as SOA matures – but that’s a separate discussion). Generally they have been happy to build their own discrete process stacks and customers have been happy to buy them.

This is the structural impediment. Without a value chain system dependency somewhere it is doubtful that Open Source will have a serious impact on the business applications landscape. But that brings me to the timing issue, because I think there is a value chain system dependency which has the very real potential of emerging.

It is a mistake to see enterprises as the “user” of a business application. The processes represented within these products are ultimately used to deliver their products and services to market. From that perspective, business application providers are part of these organizations’ own value chain system. So the question here is whether or not business application vendors start distorting the value chain systems of their collective customer base.

I think this is absolutely a possibility, if it isn’t already happening in some areas. Increasingly business applications are cementing organizations into high dependency relationships with their suppliers, bound by steep exit costs and vendor copyright control of the IP. Those relationships are becoming increasingly expensive as maintenance costs continue to defy gravity (with the potential of taking on a whole new dimension as some business application vendors continue to explore “value-based” pricing models). All of this for what is effectively a partially used collection of non-differentiating process capabilities.

So, is there a point where enterprise IT organizations will start questioning the long term value they’re receiving from these business applications? If that starts to happen what they’ll rapidly realize is that the only sustainable long-term solution is to participate in the creation of collectively-owned business application assets.

In other words, it would be the Collective Competency efforts of the user community, specifically targeted at business application vendors, that will be the most likely scenario that will drive Open Source business applications.

There are some examples of this happening already. The SAKAI project in higher education is one. Collaborative Software Initiative is a company which is building a business model targeted at creating exactly these types of solutions.

But in general I’m not holding my breath. The fact of the matter is that most enterprise IT organizations do not look at business applications through the lens of value chain system dependency. They look at it through the lens of mitigated custom development cost. I’m not suggesting that’s not valid – but if that’s the only measure its a dangerous mistake on the part of the CIO and his or her IT organization.

I think the will be a growing realization by users on the nature and extent of the value chain system dependency they have on their business application providers. And if business application vendors don’t manage this carefully then watch out! Those users will do unto them the way software vendors have been doing unto each other for the last decade.

So says the law of Collective Competency!

I have long held the view that the Open Source license agreement has been one of the most disruptive ideas to have hit the IT industry. The core concept of providing non-discriminatory modification and re-distribution rights within a copyright agreement has been, and continues to be, as great an innovation as any single piece of technology. But over the years that I’ve been researching Open Source I’ve been wondering whether it is actually part of some other, bigger, disruptive trend.

While so much interest has been put on the pricing and commercial dynamics of Open Source, I’ve found myself continually drawn to its other significant business value proposition. That’s the way its been used to normalize distortions in a value chain system.

Modern Western business models have long since moved on from the concept of vertical integration. For the last two decades the driving philosophy has been “core competency.” Organizations which focus on core competency are ultimately bound together in what Michael Porter called a Value Chain System.

But this business control system has a inherent risk. Should an organization monopolize a specific segment of a value chain system they can extract a higher percentage of its total proceeds. If the product, or service, in question is price elastic than those additional proceeds will come from other participants in the value chain system.

What then does a CEO do when facing a squeeze on their profits because a direct, or downstream, supplier is dominating a segment of the value chain system? Besides negotiating a better deal – if they can – they’ve been left with little choice but to get directly into that segment of the value chain system themselves. But by doing so their organization is distracted from focusing on its own core competency.

The risk of such an undertaking can be mitigated if there is a collective response by similarly affected members of the value chain system. After all, it is usually a shared problem. But collective responses have always had an inherent, and often fatal, flaw. Who owns the resulting assets? Either organizations enter into complex joint venture agreements to sort this out or run the risk of shifting the distortion in the value chain system to another organization.

What’s now being recognized is that there’s another option. Seek a collective response to a shared problem and make sure no one owns, or can control, the resulting assets. When the assets in question are intellectual property this becomes quite achievable. The solution, therefore, is the creation of collectively-owned assets as opposed to entity-specific assets.

The strategic decision frameworks and ongoing tactical efforts needed to create collectively-owned assets is something I’m calling Collective Competency (Gartner clients can read the associated research note – “Collective Competency: A New Business Pattern“). It doesn’t replace core competency. But what’s being realized is that core competency must be augmented by collective competency to be a sustainable model.

What’s interesting to note is that mechanisms to create collectively owned assets across the major types of intellectual property classes have emerged. Open Source and Creative Commons licenses are examples of collectively-owned copyright assets. Patent commons such as Eco-Patent Commons create collectively-own patent assets. And industry-specific standards organizations like 1SYNC and ACORD are resulting in transparent, standardized process and semantic definitions that previously would have been seen as organization-specific trade secrets.

In this broader context, Open Source is essentially an IT-industry specific instantiation of Collective Competency. And that, in part, explains why Open Source is becoming dominated by proprietary vendors. It’s because they are the ones that most acutely appreciate the existing or potential value chain system distortions that can impact their businesses.

Have you been noticing that just when an open source project starts building some momentum – things like mySQL, WebTide or Spring – along comes some cashed up proprietary vendor to buy it ? Even the venture capitalists are in on the act! Companies like New Enterprise Associates, Accel, and Benchmark Capital – organizations noted for their interest in getting high returns ASAP – are funding open source startups like Pentaho, Alfresco, and SugarCRM.

Big software vendors and VCs throwing money around is not particularly interesting – that’s just the nature of the beast. But the fact that there are so many members of the “open source community” ready to sell out – now that’s interesting.

Well, actually, it’s interesting only to the extent you still believe the romantic narrative that commonly circulates around Open Source. That story involves bands of fiercely independent geek-heroes. Armed only with an Eclipse IDE, a weekend’s supply of Jolt Cola for energy and a poster of Jean-Luc Picard for inspiration, they set out to usurp the big software companies in their attempt to control the software universe.

Who would have thought such esprit de corps would be so easily bought. Not cheaply…just easily.

But let’s be clear here. While the romantic open source narrative is failing, Open Source continues to get stronger. And it’s doing so because it is becoming an integral component of modern software businesses. Gartner has been predicting that by 2011, at least 80% of all commercial software solutions will include elements of open source. That prediction is based on our observation that nearly all software vendors are finding ways to weave Open Source Software within, and around, their core offerings. It’s becoming quite common to find open source software that is tightly bound to some proprietary component – either other software or vendor-specific service offerings.

But a word of warning. There is a midpoint as a narrative moves from being relevantly insightful to quaintly nostalgic. And that’s when it’s dangerously distracting – exactly the point where so many find themselves caught in the evolution of Open Source. The fundamental principle upon which this aging narrative has been crafted – that Open Source sits in juxtaposition to proprietary software rather than being connected with it on a continuum – is today a false dichotomy. And the hardcore adherents of that dichotomy are apt to frame it in increasingly ideological terms. In their world you’re either with them or you’re against them.

From my experience it is enterprise IT organizations most likely to be caught up in the dying Open Source narrative. The software vendor community has long since figured out what’s going on. While the latter group sees Open Source through the lens of nuanced strategic objectives and synthesizing engineering endeavours, the former sees Open Source through the lens of a tactical sourcing option. For them it is the anti-proprietary option that can be used selectively to cut cost – quite often as little more than a negotiating tool. Then reality bites. TCO benefits turn out to be elusive. There is no vibrant community to assure the long-term viability of the project. Needed new features require the adoption of a proprietary version. All these problems, and a few others, are more easily identified if the IT organization would make a greater commitment to identifying what is actually driving the Open Source phenomenon.

And that will only happen when you, and your organization, are prepared to put away the fairy tale book. Let me make it easier by telling you the ending…

…and Open Source lived happily ever after.

Australian’s take pride in several things – it’s flora and fauna, it’s successful actors and the fact it’s the only place on Earth where they enjoy eating Vegemite. Originally brought to the world’s attention in the 80’s Men At Work hit “Land Down Under,” it is best described as a foul-smelling dark brown paste which is salty than salt. It’s a brewer’s yeast extract – which polite way of saying it’s the part of beer that doesn’t make into the bottle.

This quintessential Aussie icon is now owned by American food conglomerate Kraft Foods (the same company famous for inventing the first laboratory-based cheese). Recently, in an effort to launch a new flavor (and I use that term in its broadest sense) of Vegemite, Kraft decided to ask Australians to come up with a new name.

After 48,000 suggestions were submitted Kraft made their selection. And this weekend, during the Aussie Rules Grand Final the name was unveiled…

iSnack 2.0

Sometimes decisions are just so intrinsically stupid that no further comment is required. iSnack 2.0 is one of those.

Well, it’s Wednesday, three days after the big reveal, and news has just broken that iSnack 2.0 has been axed. iSnack 2.0 has officially become Australia’s New Coke.

To put this process into perspective the original name Vegemite was decided in a national poll conducted in 1923. So how marvelously symmetrical to conduct another national poll 86 years later to come up with the new product’s name. You can just see the ad agency pitching this to Kraft Foods executives.

But as Kraft now painfully understands, the collective operates differently in this millennium. Had their marketing team been switched on they would have tapped the power of the collective to select the name rather than just have it make suggestions. So, in twist of Web 2.0 irony It turned out the collective did just that. Through blogs and Twitter feeds like #vegefail, Kraft Foods learnt in Internet time what a lame name they’d selected.

That was an expensive and embarrassing way to learn the lesson!

Just a note to all you food & beverage industry readers out there. Whatever you do don’t use IT naming conventions for stuff we eat. We in the IT industry are not proud of the way we name products. So don’t emulate us.  In fact, we’re busy trying to name IT products after food (i.e. Apple, Mint.com, cookies, SproutCore, SugarCRM, Java, etc.). Personally, I refuse to put anything with a version number in my mouth.

Recently, Google was granted US Design Patent No. 599, 372. Ostensibly, this was to protect the design “innovation” of Google’s home page from blatant rip offs.

As I’ve noted, the design innovation of Google.com is basically the white space. That makes this a Seinfeld patent – it’s a patent about nothing. But let’s for a moment assume that a search field and a couple of pieces of hyperlinked text above it constitute a design innovation.

Well then, it seems to me that Bing is a flagrant infringement. Here’s Google’s submission to the Patent & Trademark Office:

And here’s the Bing display:

Keep in mind that the logo isn’t included in the design patent. And most of Bing’s linked text is the same as Google’s.

So Google, it looks like its time to stand up for your property rights. You sought the patent and its clearly being infringed. If you decide not to press your rights as a patent holder it would be most appreciated if you can help us all understand what the point of seeking the patent was in the first place.

Mind you, if Google does sue and lose without an invalidation of their patent I think we’ll all have to admit that they indeed hold a design patent for an empty screen because the only thing that differentiates bing.com from google.com is a picture behind the fields and linked text.

If I went into an Apple Retail Store and got irate with staff at the Genius Bar because there were no Windows-based PCs being demonstrated you’d think I’d was loco. So I am at a loss to understand all the commotion about Apple’s rejection of the Google Voice iPhone application.

When dissecting the name “Apple App Store” I think it’s important to recognize that the operative word here is “store.” And store owners have a right to determine what they’ll be stocking on their shelves – even if the products in question are digital. If you’re looking for a Volkswagen I suggest you go to a Volkswagen rather than a Toyota dealership. Chanel boutiques are probably not the best place to go if you’re looking for a Prada bag. And by all means, if you need a new set of tires don’t waste your time at the neighbourhood florist.

So, whatever Apple wants to put in their App Store is entirely up to them. If they don’t have what you’re looking for just go somewhere else.

Of course there’s two sides to this story. There is also the mobile application developer. At the moment most of these people have to accept Apple’s App Store policies because the iPhone is a pretty unique platform to create some pretty unique solutions. But, for how much longer?

This is a scenario that Apple should already have seared into their collective consciousness. Back in the late 80’s and early 90’s, Apple understood the economic importance of having developers write applications on their operating system. So the now famous Apple evangelist team set off far and wide to convince developers the Mac was an elegant platform that allowed them to create compelling and cutting-edge solutions for their customers. Apple’s problem though was that they didn’t understand the developers’ economics. And the lesson they learnt the hard way – or so I thought – was that addressable market size trumped elegance.

Enter Android. Already we are seeing many of the unique aspects of the iPhone being duplicated with Android. I also believe that Apple’s ability to sustain an innovative edge over Android will be reduced to months – if that. The collective development opportunities made possible by the fact that Android is Open Source will see to that. Will it be as elegantly executed as the iPhone? Probably not. But it won’t matter to the mobile application developer if there are eight or ten Android handsets shipped for every iPhone. Addressable market will again trump elegance.

The question that Apple has got to ask itself is whether there will be an inflection point in the smartphone market. Is it possible that consumers will become more entranced by mobile applications than they will with the mobile phone itself? And, if this happens, what are the chances that the mobile application developer free-for-all will be replaced with a diminishing set of very large mobile application publishers?

If both of these conditions emerge Apple must realize that Android can do unto the iPhone the way Windows 95 did unto the Macintosh. In such an environment it’s more likely that Apple will have to be accepting other organization’s terms and conditions than dictating them as they do today.

Last week I had a chance to speak to Keith Bergelt, CEO of Open Invention Network (OIN), about their recent acquisition of 22 “Linux-focused patents.” The objective of this purchase, as stated in their press release, was to avert “the prospect of these patents being placed in the hands of non-practicing entities …whether or not the patents truly read on Linux.”

Now first off I like OIN. They featured in my “Cool Vendors In Intellectual Property, 2009” research report (Gartner subscription required). But there is some irony in them railing against “non-practicing entities (NPE).” They are, after all, a non-practicing entity themselves. They buy and hold patents with no intention of using them in a product they manufacture and sell. There is, of course, a big difference between NPEs. OIN’s objective is not to profit directly from the patents but to protect Linux from infringement actions. They’re kind of a patent knight in shining armor.

One of the things I asked Bergelt was the basis upon which OIN decided whether these patents were worth purchasing. The answer was sobering. These patents were assessed basically on their potential to result in an infringement action. In other words, the value of the patents are not based on the incremental benefit they could add to a product but rather in their potential to mitigate legal costs.

I’m not about to argue that arbitraging legal costs is a socially-productive economic activity. But we have to be philosophical here. Gaming a system is one of the oldest business strategies around. Just look at the use of ultrafast computerized stock trading systems that are at the heart of the Sergey Aleynikov case with Goldman Sachs. And when these games get identified, it’s perfectly reasonable for people to advocate systemic change in order to remove these unproductive and market distorting behaviours.

The problem with legal cost arbitrage is that the debate is being distorted by the IT vendor community. Many outspoken IT vendors are happy to seek and hold software patents. They’re happy to profit from these patents without actually using them in their own products. And they’re happy to apply a little legal cost arbitrage of their own when they need to defend their economic interests.

But what really rubs these vendors up the wrong way is that companies like Intellectual Ventures and Acacia Technologies – the ones they’re calling NPEs – game the system differently. They’ve devised a business model that renders themselves largely immune to counter-suits and cross-licensing arrangements that are so effective in allowing IT vendors with big patent portfolios to shut down infringement actions from other “practicing entities.”

In fact, the whole term “non practicing entity” is a ruse. The underlying activities of the patent system – seeking patents, buying patents, licensing patents and litigating patent infringement – are practiced by a range of organizations including vendors, universities, governments and patent commons organizations like OIN. “NPE” or “troll” are just convenient terms used by those want to skew a broken system rather than actually fix it.

So, by all means, let’s fix the system to remove the arbitrage of legal costs. We can do this by focusing on the quality of granted patents and on creating greater transparency and accessibility in the system. Doing these things will reduce the uncertainty which underpins the legal cost arbitrage model.

But the goal here is not to eliminate NPEs. It’s to switch their focus to something far more productive. Pooling patents has value. It can be done to facilitate the sharing of innovation (like when vendors cross-license). It can be done to provide open access to innovation (like what OIN does). Similarly, patent pooling from companies like Intellectual Ventures and Acacia Technologies can provide small inventors access to a defensible portfolio normally available to the largest organizations.

The top shelf of the closet in my home office can be affectionately described as my digital device graveyard. It serves a dual purpose. First, it allows me to avoid the realization that I probably wasted my money buying these things in the first place as I can pretend that an emerging market for vintage computing devices will allow me to recoup my costs (anyone interested in a 1999 Palm V with matching Dooney & Burke leather protection case). Second, I can open my closet to remind myself of the fallibility of “must have” digital devices every time a new one hits the market.

With all the eReader discussion going on I’ve just gone back to my closet for a look.

Now, I don’t want to come across as a Luddite but I really can’t see these things being anything more than a niche solution unless they provide a meaningful cost or experience advantage over the current state of the art – the pBook. And that is an advantage as defined by your average human being – someone like Grandma, your neighbourhood 4×4 driving soccer mom, or Joe the Plumber. The philosophical waxing of the world’s device whores doesn’t count. We already know you’ll be shoving a Kindle in the same bag you use to carry your laptop, iPhone, and Flip Video camera. You have a reputation to maintain – we understand that.

So, what about the experience? Well, call me a romantic but I’m having a hard time with the idea of snuggling up in bed with a plastic-cased screen. I have been known to nod off mid-sentence dropping my book to the ground – a harmless activity with a paperback. A potential warranty claim with an eReader. I’m also definitely not keen on the idea of a flight attendant telling me to turn off my book because we’ve started our descent.

But I’ll forgive those foibles, as I think most people will, so long as an eReader provides a simple and elegant reading experience.

Alas, given the track record of the IT industry I’m quite confident in predicting that any semblance of elegance will disappear under an onslaught of superfluous features. Heck, it’s already started – ASUS is planning a “high end” reader with inbuilt 3G, a web browser and expandable storage. Poor old Grandma – she’ll need to log a support inquiry to figure out how to swap between her copy of Harlequin’s latest page turner, “The Spaniard’s Defiant Virgin” and “Conquering Arthritis: What Doctors Don’t Tell You Because They Don’t Know.”

By the way, from a design perspective, can someone explain to me why we need a dual screen eReader? Surely the two-page paradigm resulting from a physical binding process has been rendered obsolete.

So, that gets us to cost. After a quick cost comparison on Amazon it’s clear that Kindle eBooks are less expensive than their paperback equivalents (when they’re available). Kindle eBooks go for about $10 while paperbacks are $16. OK, good so far.

But after dividing the number of paperbacks sold per year by the population of the US I discovered that the average person buys about 8-9 books a year. After pocketing their $54 savings per year it will only take 5.5 years to pay off the cost of their Kindle. That is assuming the device lasts that long – that it isn’t superceded or ends up on the top shelf of someone’s closet.

And if don’t live in the US you’ll probably have to contend with region codes. As it stands today I can place an order for a good old fashion pBook on Amazon and have it shipped to Australia where I live. As long as I buy a couple of books I save a lot of money over what I’d pay in a book store here – even with shipping costs. But Kindle Books are only available in the US due to “other restrictions.”. So I’m also predicting that when they are finally made available globally they have the same region code set up which results in non-US residents paying big premiums on things like movies and video games. That cost equations starts looking much worse.

So sorry, but I think I’ll avoid adding anything new to the top shelf of my closet for the time being.

Google – an organization deeply committed to reforming our broken patent system – has just taken advantage of that very same system to get a patent for…well…nothing.

Google has just been granted US Design Patent No. 599, 372 S for a “graphical user interface for a display screen.” It looks like this:

Note – the design patent doesn’t include the dashed lines. And the logo is covered under copyright. Doesn’t leave much, does it?

Of course we all recognize Google’s homepage. But how many of us have been consciously thinking, “wow, what a groundbreaking GUI?” I seem to remember the first couple of HyperCard programs I created back in the 1980s looking pretty much the same – a field, a couple of buttons and some linked text.

Well, as I’ve commented before, I do believe that Google’s UI was innovative. But it wasn’t the simple positioning of a search field, some buttons and links that was novel. The novelty of Google’s home page was it’s notable absence of all but the most basic requirements. In other words, the innovation is the white space! So, Google has essentially received a patent for a void. That would make this perhaps the single most existential patent in the history of mankind.

What’s next? A patent for the sound of one hand clapping? If a tree falls in a forest and there’s no one there to hear it can I still patent it?

Dennis Crouch has also pointed out that Google did not submit any prior art with the patent claim. Gee, one piece of prior art jumps right out for me!

I understand that there are a range of strategic reasons to seek patents. I also realize that design patents get little traction in the courts. But given their moral high ground on patents I would suggest that for Google this is also a PR issue. On that basis I would hope Google puts this farcical example of a patent in a patent commons ASAP.

As for the USPTO…shame!