The Social Graph Portability Act Doesn’t Take Tech Seriously, and That’s Worrying
This week, James Pethokoukis at AEI convened an online symposium on a regulatory proposal that has been floating around, the “Social Graph Portability Act.” The idea comes from an op-ed by University of Chicago’s Luigi Zingales and Guy Rolnik as a response to the “increasing monopolization of the technology industry.” Here is a taste of that recommendation from the original piece:
For a 21st-century problem, we suggest a 21st-century solution: a reallocation of property rights via legislation to provide more incentives to compete. In fact, the idea is not new. Patent law, for example, attributes the right to an invention to the company a scientist works for, to motivate companies to invest in research and development. Similarly, in the mobile industry, most countries have established that a cellphone number belongs to a customer, not the mobile phone provider. This redefinition of property rights (in jargon called “number portability”) makes it easier to switch carriers, fostering competition by other carriers and reducing prices for consumers.
The same is possible in the social network space. It is sufficient to reassign to each customer the ownership of all the digital connections that she creates — what is known as a “social graph.” If we owned our own social graph, we could sign into a Facebook competitor — call it MyBook — and, through that network, instantly reroute all our Facebook friends’ messages to MyBook, as we reroute a phone call.
If I can reach my Facebook friends through a different social network and vice versa, I am more likely to try new social networks. Knowing they can attract existing Facebook customers, new social networks will emerge, restoring the benefit of competition.
There are some astute comments from Mark Jamison, Joshua Gans, Daniel Lyons, Hal Singer, Bret Swanson, and Gus Hurwitz. I cannot recommend their comments enough, and indeed, at some point soon I will review them at greater length.
The Zingales and Rolnik piece irks me, and not just for the reasons that other commenters laid out. For one, their Social Graph Portability Act primarily focuses on making switchover costs lower. As they explain, “If I can reach my Facebook friends through a different social network and vice versa, I am more likely to try new social networks.” Underlying this statement is the belief that “the data” is the key to Facebook’s ubiquity. But that misses the content for the form. It isn’t data that gives Facebook oomph, but structured and processed data.
Second, and related to the first, Zingales and Rolnik confuse the Graph API for the social graph. They aren’t the same.
Here is one exercise. Start looking for mentions of scalability in the work of Zingales, Rolnik, and others. It doesn’t play an especially prominent role. But everywhere else in tech, the idea is ever present. And for good reason. One survey a couple of years back suggested that nearly 3 out of 4 tech startup failures could be explained by premature scaling, where one side of the business grows before the other. Social network scalability problems often happen early in the life cycle of these companies when off the shelf technologies hit their technical limits.
MySpace is one exemplar, and nearly decade on, the lessons are still not well understood. I’m old enough to remember just how buggy the site was. Error rates were as high as 30 or 40 percent at times. In contrast, commercial operations like Yahoo! or Salesforce had at most 1 percent at the time. Simply put, MySpace wasn’t created with the kind of systematic approach to computer engineering that went into Yahoo, eBay, Google, and Facebook. Instead, the site slogged through upgrades to implement flexible data caching and the distributed architecture needed to scale. As one article explained it at the time:
Every profile page view on MySpace has to be created dynamically — that is, stitched together from database lookups. In fact, because each profile page includes links to those of the user’s friends, the Web site software has to pull together information from multiple tables in multiple databases on multiple servers. The database workload can be mitigated somewhat by caching data in memory, but this scheme has to account for constant changes to the underlying data…
And although the systems architecture has been relatively stable since the Web site crossed the 7 million account mark in early 2005, MySpace continues to knock up against limits such as the number of simultaneous connections supported by SQL Server, Benedetto says: “We’ve maxed out pretty much everything.”
For those that haven’t designed a system to freely scale, and indeed many commentators in the tech regulatory space haven’t, it’s hard to impress just how difficult of a problem engineers face. This is what unites the biggest players in the space, the ability to innovate to solve problems at scale without interruptions. How each site has done it serves as a case study in its own right. Todd Hoff’s site High Scalability collects these solutions. For example, here is how Twitter solved its issues with scaling. Here is how Facebook did it. Here is how eBay did it. As for Google, well, the company’s solutions are legendary in the computing world. Structuring data creates value.
To be sure, Facebook has made countless missteps and should be rightly criticized for them. However, when you start looking at where the value rests in Facebook, it isn’t just in the data, but in how that data is structured and processed. Facebook’s technology stack clearly shows this, as much of the architecture was developed in-house. Facebook created BigPipe to dynamically serve pages faster, Haystack to efficiently store billions of photos, Unicorn for searching the social graph, TAO for storing graph information, Peregrine for querying, and MysteryMachine to help with end-to-end performance analysis. Nearly all of this design is open for others to use, and has been a significant boon to programmers in the ecosystem. The company also invested billions in CDNs to quickly deliver video and split the cost of an undersea cable with Microsoft to speed up information travel.
With this in mind, consider again Zingales and Rolnik’s reasoning behind the Social Graph Portability Act:
Today Facebook provides developers with application-program interfaces that give them access to its customers’ social graph, Facebook Connect and Graph A.P.I. Facebook controls these gates, retaining the right to cut off any developer who poses a competitive threat.
As noted in the official documentation, the Graph API is “a low-level HTTP-based API.” APIs are software-to-software interfaces. To be very blunt, the API is not the graph. The social graph, the real social graph, is queried with TAO and Unicorn. Facebook’s Graph API simply allows for an external querying of this internal Facebook stack. This is what worries me about the proposal. It lacks in the specifics that are so important. An actual competitor to Facebook would compete at the level of TAO and Unicorn, not via an API. Perhaps a follow up paper will deal with these issues, but it is unclear to me if the authors understand how Facebook’s architecture is integrated.
The competitive edge of large social media sites isn’t based just in the data, but in how that data is organized and processed. Advocates and wonks pressing for regulation like social graph portability need to dive deeper, understand where value is located, and deal with the specifics. As it stands, the Social Graph Portability Act doesn’t take this subject seriously, and that is worrying.
