Facebook’s response to Yahoo’s patent lawsuit

Like many in tech, I believe all software patents should be abolished. That said, I think Facebook made the right move by filing a lawsuit against Yahoo’s patent attack.

As I see it, Facebook had 4 choices:

– Settle. Given their pending IPO, this would have been the easiest route. But, by rewarding Yahoo, settling would have encouraged more frivolous patent lawsuits.

– Defend without countersuing. On the surface this would have been the “principled” stance, but it would have severely weakened their legal position, and therefore would have made it more likely that Yahoo profited from the lawsuit.

– Countersue without signaling any aversion to patent lawsuits.

– Countersue and signal that they are averse to patent lawsuits, which in turn signals that they will drop the lawsuit if Yahoo does. This seems to be what Facebook has done:

“From the outset, we said we would defend ourselves vigorously against Yahoo’s lawsuit,” Ted Ullyot, Facebook’s general counsel, said in a statement. “While we are asserting patent claims of our own, we do so in response to Yahoo’s short-sighted decision to attack one of its partners and prioritize litigation over innovation.” [emphasis added] – NYTimes

Countersuing gives Facebook the best chance of fending off Yahoo’s lawsuit – and therefore not rewarding patent lawsuits. And signaling they are only doing so in response to Yahoo (hence might drop the suit if Yahoo does) keeps them on the right side of innovation.

Chris Sacca on the implied user contract

Chris Sacca nicely summarized today’s FB vs Google vs Twitter controversy:

It comes down to what each company has promised its users. Facebook promised its users their stuff would be private, which is why users rightfully get pissed when that line blurs. Twitter has promised users, well, that it will stay up, and that is why users rightfully get pissed when the whale is back.

Google has promised its users and the entire tech community, again and again, that it would put their interests first, and that is why Google users, rightfully get pissed when their results are deprecated to try to promote a lesser Google product instead.

It’s all about expectations.

Google’s social strategy

It is widely believed that Facebook presents a significant competitive threat to Google. Google itself seems to believe this – Larry Page recently said that all employees would have their bonuses tied to the success of Google’s social strategy.

Why does Facebook present a threat to Google?  A few reasons:

– The utility of Google’s core product – web search – depends on the web remaining fragmented and crawlable.  Facebook has become the primary place web users spend their time and create content, and is mostly closed to Google’s crawlers.

– Facebook controls a large percentage of ad impressions and will likely launch an off-Facebook.com display ad network to compete directly with Google’s display ad business (built from its $3.1B acquisition DoubleClick). It is generally thought that display ads will become a larger portion of online advertising spend (versus direct response text link ads) as more brand advertising moves online.

– There are many other “wildcard” risks – e.g. Facebook competing with Google (and Apple, Paypal etc) in payments, Facebook gaining power on mobile (threatening Android), and the possibility of a greater share of internet intent harvesting happening on Facebook through not-yet-released features like a search and/or shopping engine.

When going after Facebook, Google has at least three key strategic choices to make:

Strategic choice #1: Should Google try to make social networking commoditized or new profit center? (For more about what I mean by this, please see this post on Google’s overall strategy and these posts on “commoditizing the complement” herehere and here).

The advantage of creating a new social networking profit center is obvious: if you win, you make lots of money. The advantage of commoditizing social networking is that although you forgo the potential direct profits, you open up a wider range of pricing and product options. For example:

– When you try to commoditize a product, you can offer a product for free that other companies charge for. This is what Google did with Android vs iOS and Google Apps vs Microsoft Office. Of course, making social networking free to users won’t work since Facebook doesn’t directly charge users (I say “directly” because they make money off advertising & payment commissions, among other ways). However reducing the cost to zero for 3rd-party developers like Zynga who have to pay Facebook large commissions would entice them toward a Google platform (note that, not coincidentally, Google invested $100M in Zynga).

– Interoperate / embrace open standards – Normals don’t care whether a product uses open standards, but by interoperating with other social networks, messaging systems, check-in services, etc., Google could encourage 3rd-party developers to build on their platform. If Google chose, say, RSS for their messaging system, it would already work with tens of thousands of existing tools and websites and would be readily embraced by hackers in the open source community. The web itself (http/html) and email (smtp) are famous examples where the choice to open them unleashed huge waves of innovation and (eventually) killed off closed competitors like AOL.

Strategic choice #2: How should Google tie its new social products into its existing products?

Besides a mountain of cash ($30B net, generating $10B more per year), Google has many existing assets on top of which to build. Google Buzz tried to build off of the “implicit social network” of Gmail contacts, which hasn’t seemed to work so far and raised privacy concerns.

Google’s recent mini-launch of its “+1″ button seems to be good use of the strategy known as “anchoring”. Google is apparently trying to create a federated network where websites embed +1 buttons  the way they embed Facebook’s Like button except the +1 button would be a signal into Google’s organic ranking algorithm (as an aside, this is where Gmail becomes useful as having millions of logged in users makes spamming +1 buttons much harder). Websites care a lot about their Google organic search rankings (which is why, for example, helping websites improve their rankings is multibillion-dollar industry).  A button that improved search rankings would likely get prominent placement by many websites. Making +1 appealing to users is another story.  The user value is much clearer for the Facebook Like and Twitter Tweet buttons – you send the link to your friends/followers. Providing value to users in addition to websites is a good reason for Google to acquire Twitter (something I think is inevitable if Google is serious about social – see below).

Finally, Android and YouTube are intriguing potential anchors for a social strategy. I’ll leave it to smarter people to figure out exactly how, but products with such large footprints always present interesting tie-in opportunities.

Strategic Choice #3: Should Google buy or build?

Historically, it is very rare to see tech companies adjust their “DNA” from within. Google’s best new lines of business over the past few years came through the acquisitions of YouTube and Android. Moreover, these acquisition were unusual in that they were left as semi-independent business units. Facebook’s hold on social is incredibly strong – besides the super-strong network effects of its social graph, Facebook has made itself core infrastructure (e.g. Facebook Connect) throughout the web. If Google really wants to catch up, they’ll need to go back to the strategy they succeeded with in the past of acquiring relevant companies and letting them run as separate business units.

* Disclosure: I’m an investor in a bunch of startups, so you could reasonably argue I’m highly biased here.

The importance of predictability for platform developers

A platform is a technology or product upon which many other technologies or products are built. Some platforms are controlled by a single corporation: e.g. Windows, iOS, and Facebook. Some are controlled by standards committees or groups of companies: e.g. the web (html/http), RSS, and email (smtp).

Platforms succeed when they are 1) financially sustainable, and 2) have a sufficient number of developers that are financially sustainable. Fostering a successful developer community means convincing developers (and, possibly, investors in developers) that the platform is a worthwhile investment of time and money.

Developers who create applications for platforms take on all the usual risks related to launching a new product, but in addition take on platform-specific risks, namely:

  1. Platform decline: the platform will decline or go away entirely.
  2. Subsumption risk: the platform will subsume the functionality of the developer’s application.

The most successful platforms try to mitigate these risks for developers (not just the appearance of these risks). One way to mitigate platform decline risk is to launch the platform after the platform’s core product is already successful, as Facebook did with its app platform and Apple did with its iOS platform. Platforms that are not yet launched or established can use other methods to reassure developers; for example, when Microsoft launched the first Xbox they very publicly announced they would invest $1B in the platform.

To mitigate subsumption risk, the platform should give developers predictability around the platform’s feature roadmap. Platforms can do this explicitly by divulging their product roadmap but more often do it implicitly by demonstrating predictable patterns of feature development. Developers and investors are willing to invest in the iOS platform because – although Apple will take 30% of the revenue – it is highly unlikely that Apple will, say, create games to compete with Angry Birds or news to compete with The New York Times. Similarly, Facebook has thus far stuck to “utility” features and not competed with game makers, dating apps, etc.

Platforms that are controlled by for-profit businesses that don’t yet have established business models have special challenges. These companies are usually in highly experimental modes and therefore probably themselves don’t know their future core features. The best they can do to mitigate developers’ risks are 1) provide as much guidance as possible on future features, and 2) when developer subsumption is necessary, do so in a way that keeps the developer ecosystem financially healthy – for example, by acquiring the subsumed products.

The least risky platforms to develop on are successful open platforms like the web, email, and Linux. These platforms tend to change slowly and have very public development roadmaps. In the rare case where a technology is subsumed by an open platform, it is usually apparent far in advance. For example, Adobe Flash might be subsumed by the canvas element in HTML5, but Adobe had years to see HTML5 approaching and adjust its strategy accordingly. The predictability of open platforms is the main reason that vast amounts of wealth have been created on top of them and investment around them continues unabated.