Did Google Reinvent the Wheel by Adopting the Protocols They Chose?

In a response to my article here, DeWitt Clinton of Google defined what he deemed the definition of “open” to be.  According to DeWitt, “the first is licensing of the protocols themselves, with respect to who can legally implement them and/or who can legally fork them.”  I argue if this were the case, then why didn’t Google clone and standardize what Facebook is doing, where many, many more developers are already integrating and writing code for?  Facebook itself is part of the Open Web Foundation, and applies the same principles as Google to allowing others to clone the APIs they provide to developers.

DeWitt’s second definition of “open” revolves around, according to DeWitt, “the license by which the data itself is made available. (The Terms and Conditions, so to speak.) The formal definitions are less well established here (thus far!), but it ultimately has to do with who owns the data and what proprietary rights over it are asserted.”  Even Facebook makes clear in its terms that you own your data, and they’re even working to build protocols to enable website owners to host and access this data on their own sites.  Why did Google have to write their own Social Graph API or access lesser-used protocols (such as FOAF or OpenID) when they could, in reality, be standardizing what millions (or more?) of other developers are already utilizing with Facebook Connect and the Facebook APIs to access friend data?  Google could easily duplicate the APIs Facebook has authored (even using the open source libraries Facebook provides for it), and have a full-fledged, “open” social network built from these APIs many developers are already building upon.  I would argue there are/were many more developers writing for Facebook than were developing under the open protocols and standards Google chose to adapt.  I’d like to see some stats if that is not the case.  Granted, even Facebook is giving way to Google to adopt some of these other “open” standards so developers have choice in this matter, even if they were one of the few adopting the other standards.

I still think Google is adopting these standards because it benefits Google, not the user or developer.  If Google wanted to benefit the majority of the audience of developers they would have cloned the already “open” Facebook APIs rather than adopt the much lesser-adopted other protocols they have chosen to go by.  This is a matter of competition, being the “hero”, and a brilliant marketing strategy.  Is Google evil for doing this?  Of course not.  Do I hate Google for this?  Only for the reason that I have to now adapt all the apps I write in Facebook to new “open” APIs Google is choosing to adopt.

IMO, if Google wanted to truly benefit the developer they would have chosen to clone the existing “open” APIs developers were already writing for.  This is a marketing play, plain and simple.  It may have started with geeks not wanting to get into the Facebook worlds, but management agreed because in the end, it benefits Google, not their competitors.  If you don’t think so, you should ask Dave Winer why Google is not implementing RSS or rssCloud instead of Atom and PSHB (I’m completely baffled by that one, too).

Image courtesy http://northerndoctor.com/2009/04/17/re-inventing-the-wheel/

29 thoughts on “Did Google Reinvent the Wheel by Adopting the Protocols They Chose?”

  2. [Copying my comment from your Buzz feed over here.]

    @Carsten Pötter is correct — the OWF is comprised of only individuals, not companies. So Facebook isn't a member, nor is Google, Microsoft, etc. A lot of employees from those companies are members, though.

    The OWFa is a license (http://openwebfoundation.org/legal/agreement/) produced by the OWF, and the OWFa can be applied to specifications to help make them open.

    Activity Streams, authored by MySpace, Microsoft, Facebook, and others, is indeed covered by the OWFa. Activity Streams form the basis of the Google Buzz APIs, so we're already converging. Here's a link to how Facebook uses Activity Streams over Atom: http://wiki.developers.facebook.com/index.php/U…

    Some parts of the Facebook platform, like Facebook Connect, aren't licensed for others to use (yet?), so Google didn't have a choice on that one. Actually, it's not quite clear whether or not Facebook wants other people to clone all of their platform, or if they will ever allow for it, so we're all waiting to see what happens with that. (Personally, I think it would be great if they licensed the whole thing, but that's up to them of course.)

    My guess is that it will be a little bit of a lot of protocols, with all of us working together. The Atom+AtomPub+Activity Streams+OAuth+OpenID+Media RSS+PSHB approach is the one that everyone seems be converging on—those parts aren't controversial, everyone from Microsoft to Facebook to Yahoo to MySpace to Google to Status.net to Cliqset seem to agree there.

    There might be some details that differ between the implementations, but it is wrong to paint this as a divergence. On the contrary, we're all working together on these protocols. If anyone says otherwise, feel free to ask them where they'd like to see further alignment, and please point them my way.

    Like

    Reply

  3. DeWitt, I would like to see the same calls I make to Facebook to get a
    social graph, get profile information, obtain details about a user, etc.
    work on Google's APIs. That will simplify my coding considerably, and I'm
    pretty sure if you guys got your lawyers on it you could figure out if that
    was legal or not, If not, and confirmed by your lawyers, let me know and
    I'll put the same pressure on Facebook to open that up. Facebook is giving
    into Google with ActivityStreams, OAuth, etc. – why not give into Facebook a
    little?

    Like

    Reply

  4. Now we're getting somewhere!

    Unless Facebook says it is okay for Google (and other people) to clone their APIs by releasing them under an open license, we're simply not allowed to.

    I too want all of these APIs to be released under an open license. I really do.

    Like

    Reply

  6. Not sure what you mean by “giving into Google a little”.

    Remember, Activity Streams were created by MySpace, Microsoft, and Facebook, not by Google. We're following their lead here. (Which we're allowed to do, because those protocols were openly licensed).

    The last thing we want to do is reinvent the wheel.

    That's the whole point.

    Like

    Reply

  7. Wasn't Kevin Marks one of the leaders of that movement (while he was at
    Google)? I don't think David Recordon was even working at Facebook when
    that movement started. I understood it to be started by Kevin Marks and the
    Social APIs teams at Google. It seems to me Facebook was Bearhugged into
    supporting it, hiring David Recordon, and joining in on the effort. Don't
    tell me Google wasn't involved. Not to mention Google now has employed
    Chris Messina, also one of the originators of that movement.

    Like

    Reply

  8. Oh, one more thing I wanted to add. Even if Google doesn't directly clone the Facebook API or the Twitter API, etc., there's nothing stopping someone else from providing a bridge between things like AS and Portable Contacts, etc., and those other formats.

    Someone might even find that to be a potentially lucrative business. (Though they should obviously check with Twitter and Facebook to see if it was okay first.)

    Like

    Reply

  10. That's besides the point. The point is that Google isn't doing this for the end-benefit of the developer or user. They are doing this for the benefit of Google's main proprietary technology: search. Google is participating and pushing strongly these open protocols because it benefits Google, not the end user. We would have seen a Facebook-compatible API a long time ago if that weren't the case. You have to admit this is strategy for Google to be supporting these other “Open” APIs.

    Like

    Reply

  16. I don't think that's necessarily good either. They're just as guilty. But
    let's get back on subject – if it were good for the web, why not just
    standardize the protocols more developers are already working on anyway?
    Why not integrate with a Facebook API clone? Why not support RSS and
    rssCloud? It would seem that's a better strategy than hopping on these
    other standards.

    Like

    Reply

  18. Jesse, I think I can see where you're coming from, but I certainly don't arrive at the same outcome when I put the same pieces together. I also think that you're not really listening to what DeWitt is saying — or at least providing a fair assessment of the situation.

    First, DeWitt's statements are accurate — the Facebook API is the property of Facebook. We can't just clone it or implement it without permission. Facebook may someday provide that permission to everyone, but so far, they haven't… therefore, it's not so straight-forward for Google to just go and implement their API (the same is true of the Twitter API — and I've asked the Twitter folks to choose a license for the API as well).

    Second, Google is really trying to NOT reinvent the wheel where technologies already exist (and are open and free to implement). ATOM has been around for ages, and is the format that Google has chosen to standardize on. ActivityStreams, as an XML format, is designed to work over ATOM, but can also be represented in RSS.

    Third, I started the ActivityStreams project as an offshoot of the Diso Project and laid out my vision for this effort here:

    http://factoryjoe.com/blog/2008/12/20/where-wer…

    In case my blog is down (sigh) you can reach it from here: http://74.125.155.132/search?q=cache:r_uRDgT_Bn…

    Kevin Marks has been an advocate for the project and of activity streams in general, but didn't start the work on the ATOM extension. That early work really was a combination of me, Mart Atkins, and other members of the Diso Project. Later, Monica Keller (MySpace) and Rob Dolin (Microsoft) and Ari Steinberg (Facebook) joined up. I begged for someone from Google to join and couldn't seem to really spark any interest (though Kevin dropped in for a few meetups, and Ryan Boyd started work on a JSON serialization of ActivityStreams for use in OpenSocial).

    Thus the ActivityStreams work has been underway for over two years now — with the participation of small and large vendors — but with seldom Google participation. By joining Google, I hope that this will change and the effort achieves wide adoption — to serve the need that you're reflecting — which is to write your apps once, and have them essentially work anywhere.

    While it'd be nice to suggest that the answer is to be found in Facebook's APIs, however, overlooks a major problem with their API design — that it's designed to work against the kind of data that Facebook uniquely has, expressing the features that Facebook wants to make available to developers. While that may functionality may be more than enough, I don't think that it's sufficient to simply take a protocol designed for a large, centralized social network, and attempt to build a decentralized social web on top of it. Surely there are concepts and ideas that apply globally, but the design itself is network-centric, rather than user-centric.

    Fundamentally the technology list that DeWitt mentioned is intended to be used in component parts — to bring in to existence a distributed, decentralized social web, where there are MANY players, rather than just a few. I think it's really important to understand that, and to think hard about the difference that the architecture of technology has on whether that kind of goal can be supported.

    We've made some really great strides in the past several years on these technologies working through open, community-driven processes. I'm looking forward to seeing that work pay off over the next few years.

    Like

    Reply

  19. Jesse, I'm a product manager/developer who has not jumped into the facebook “open” APIs because the platform goals (to date) have not been inline with my open goals. Basically I read this entire article as “I already know facebook/twitter APIs and don't want to learn a new one”.

    Just cloning an open API to a closed walled garden would be the most ridiculous thing a company even remotely interested in openness would do. Someone would have to evaluate all the use cases, learn the ins and outs and see if it is not only a fit for today but provides enough flexibility for the future. Open APIs developed in the open for the benefit of the community are already taking most of those details into account.

    I am not a Buzz or Google fan, if anything I am probably it's most critical user.. but I also realize how much easier it would have been to roll their own specific solution for every situation. The connected sites methodology is a complete pain in the ass, a nice add your feed dialog here would have been much simpler and quicker to implement.

    Facebook and twitter have their own focused APIs that while open certainly don't cover everything the community wants to do with them.. Will Google benefit from open using open APIs? hell yes.. but so can everyone else!!

    Like

    Reply

  20. Chris, thanks for your clarification. And, FTR, I'm not going to give
    Facebook a break either. I didn't realize their other licensing was not
    respective of the OWF. I am also putting pressure on Twitter to do the
    same, as you can read on the Twitter mailing lists. IMO, were Facebook and
    Twitter to just apply the OWF agreements to their own API licensing, it
    would make much more sense (and perhaps be a bit more strategic to them) to
    just adopt those APIs rather than other open agreements and standards that
    were being utilized by much fewer developers.

    Like

    Reply

  22. Chris, the entire premise of this, while I am a Facebook and Twitter
    developer, has nothing to do with me personally. It has to do with the fact
    that there are many, many more (millions) developers already using these
    platforms that would now have to change their code to adopt these other open
    standards. What I'm saying is that if Facebook and Twitter were (I realize
    now they don't yet do this) to adopt a more open licensing structure to
    their APIs, it would still be open, and more advantageous to developers
    everywhere to adopt these standards even more than the ones Google is
    choosing to adopt. There is more than one open standard – my argument is
    Google could be choosing the wrong ones based on developer population.

    Like

    Reply

  23. Fair enough. I hadn't specifically seen the efforts you mentioned, but I'm glad you're not giving anyone a break! 😉

    As it turns out (and as I've learned — even before joining Google) big companies often communicate through lawyers and lawsuits — which can be avoided when there are clear or open licensing terms applied to their intellectual property. Having formerly worked for myself, I never really understood how important the legal regimes that organizations use are — but as it turns out — the law makes it hard to give things away and thus requires very clear declarations of intent when you actually want other people to build on your work.

    This is why the OWF exists — as you pointed out — but its existence, or companies' employees' participation in it — is not sufficient to create the conditions for companies to use each other's technologies. Instead, every time a new technology is released, an IPR agreement needs to be executed making specific promises. This is why it's not enough to just point to Facebook employees' membership in the foundation — instead Facebook actually needs to sign off on using the OWF licenses for the various technologies that they wish to release openly.

    Certainly Facebook has aggressively open sourced a number of libraries recently, and that's very promising — but the protocols of Facebook Connect remain an open question (hence the independent work we're doing on the Buzz API — for which the underlying elements should be licensed under the OWF license).

    Like

    Reply

  24. Chris, I am definitely a proponent of that. Until Facebook (and possibly
    Twitter, although they're not near as large) does that with their own APIs I
    guess this conversation and argument will remain in “the open”. Although I
    still argue that Google could probably still arrange a business deal with
    Facebook to legally be able to adopt these APIs. In that case I would
    definitely not discourage Google from continuing work on the open standards
    you're working on, but arranging such a deal would certainly make things a
    lot easier on the millions of developers that already have code in this
    space. Maybe holding back would encourage Facebook to go about it the right
    way though, I don't know.

    Like

    Reply

  25. I don't think that's necessarily good either. They're just as guilty. But
    let's get back on subject – if it were good for the web, why not just
    standardize the protocols more developers are already working on anyway?
    Why not integrate with a Facebook API clone? Why not support RSS and
    rssCloud? It would seem that's a better strategy than hopping on these
    other standards.

    Like

    Reply

  26. Oh, one more thing I wanted to add. Even if Google doesn't directly clone the Facebook API or the Twitter API, etc., there's nothing stopping someone else from providing a bridge between things like AS and Portable Contacts, etc., and those other formats.

    Someone might even find that to be a potentially lucrative business. (Though they should obviously check with Twitter and Facebook to see if it was okay first.)

    Like

    Reply

  27. Now we're getting somewhere!

    Unless Facebook says it is okay for Google (and other people) to clone their APIs by releasing them under an open license, we're simply not allowed to.

    I too want all of these APIs to be released under an open license. I really do.

    Like

    Reply

  28. [Copying my comment from your Buzz feed over here.]

    @Carsten Pötter is correct — the OWF is comprised of only individuals, not companies. So Facebook isn't a member, nor is Google, Microsoft, etc. A lot of employees from those companies are members, though.

    The OWFa is a license (http://openwebfoundation.org/legal/agreement/) produced by the OWF, and the OWFa can be applied to specifications to help make them open.

    Activity Streams, authored by MySpace, Microsoft, Facebook, and others, is indeed covered by the OWFa. Activity Streams form the basis of the Google Buzz APIs, so we're already converging. Here's a link to how Facebook uses Activity Streams over Atom: http://wiki.developers.facebook.com/index.php/U…

    Some parts of the Facebook platform, like Facebook Connect, aren't licensed for others to use (yet?), so Google didn't have a choice on that one. Actually, it's not quite clear whether or not Facebook wants other people to clone all of their platform, or if they will ever allow for it, so we're all waiting to see what happens with that. (Personally, I think it would be great if they licensed the whole thing, but that's up to them of course.)

    My guess is that it will be a little bit of a lot of protocols, with all of us working together. The Atom+AtomPub+Activity Streams+OAuth+OpenID+Media RSS+PSHB approach is the one that everyone seems be converging on—those parts aren't controversial, everyone from Microsoft to Facebook to Yahoo to MySpace to Google to Status.net to Cliqset seem to agree there.

    There might be some details that differ between the implementations, but it is wrong to paint this as a divergence. On the contrary, we're all working together on these protocols. If anyone says otherwise, feel free to ask them where they'd like to see further alignment, and please point them my way.

    Like

    Reply

Leave a comment