Toward federated services

Federation is not exactly a household word in free-software advocacy. However, a small but growing number of projects are using the term to describe de-centralized web applications based on open protocols. Such an approach, they maintain, is necessary to counter the lock-in created by centralized, proprietary sites such as Facebook and Instagram.

Although such centralized sites are sometimes applauded for running on top of free software, the challenges they create for free-software advocates are far from new. As early as 2008, Tim O'Reilly asked: "What good are free and open source licenses, all based on the act of software distribution, when software is no longer distributed but merely performed on the global network stage?".

Yet the Free Software Foundation has continued its license-based approach, promoting the GNU Affero General Public License (AGPL) as a way to bring free software to cloud services. However, the fact that less than one percent of projects were using the AGPL in 2013 (according to Black Duck Software) indicates that the AGPL is too little-used to be influential, even assuming that it might actually provide an alternative.

The identification and popularization of the concept of federation is usually credited to Evan Prodromou of StatusNet and Identi.ca. In searching for an alternative to centralized web services, Prodromou and projects like GNU MediaGoblin looked back to services like email and IRC, in which anybody can run their own servers, and users can run the software of their choice while still being able to communicate with each other. By contrast, on centralized sites, users can do neither. The closest the users of centralized sites can come to federation is to use tools such as Friendi.ca to post to multiple sites simultaneously; even then, proprietary or constantly changing APIs are frequent problems.

The problem with centralized services

Although centralized sites are often convenient, the trouble is that they contradict the ideals of free software for both developers and end-users. As Kenton Varda of Sandstorm explained:

At best, the only changes will be ones that the centralized site finds convenient in the short-term.

For end-users, centralized services raise both technical and privacy concerns. Technically, centralized services create a series of walled gardens that connect poorly, if at all — if, for instance, you have a Flickr account, you are unable to share photos directly with Instagram. Moreover, as GNU MediaGoblin's fundraising video explains, centralized services also mean centralized control. Users communicate through the service, instead of directly with each other, and become subject to whatever terms of service the service enforces. For example, content may be limited, or, as happened in the early days of Google+, anonymity may be prohibited. Should the service develop technical problems, it becomes unavailable to everyone, while in a federated network, if one node goes down, only those working with that node are affected.

However, perhaps the most important concerns about centralized sites is that their users lose control of their data. According to Prodromou:

In these situations, the idea of federation is seen by its advocates as being just as important as the code quality. The nodes of federated networks, their advocates maintain, should, in theory, be more respectful of user choice and privacy. Moreover, should one federated node prove unduly bureaucratic, users can always migrate to another one to continue receiving service.

Putting the theory into practice

Federation is far from a new concept. Prodromou suggested that the blogging networks that sprung up just after the turn of the millennium could be considered the first deliberate efforts to create federated networks. One or two efforts at federation, such as Diaspora*, have even received widespread media attention. To date, however, no implementation of federation has come anywhere close to achieving the success of centralized sites like Google+ or Twitter.

Part of the problem is that breaking monopolies by direct competition is difficult in any circumstances. Prodromou suggested that "it's a chicken and egg problem" to gain popular acceptance. Federated services need a large user base, but they are unlikely to attract users unless they already have a large base. Even dedicated free-software advocates are as likely to use Twitter as Identi.ca — not because they approve of Twitter's practices or privacy policies, but because their friends are using it.

Another problem is that projects that promote federation are not intended primarily for average users. Their main appeal is to the minority who want to run their own servers and perhaps fork the code. As Varda noted:

For example, MediaGoblin's project lead Chris Webber observed: "we have a lot of people say that they want to deploy their own MediaGoblin server, but they don't have the time" for either the initial configuration or the ongoing maintenance.

Moreover, user-friendly design is difficult to implement when a project is still in rapid development and is struggling to reach its first general release. As a result, efforts at federation have yet to reach their full potential. According to Prodromou:

Efforts to develop common protocols such as pump.io are being made, but attracting early adopters without full functionality is difficult. Although those working on common protocols include representatives from IBM and Mozilla, the majority are from smaller and more obscure projects, many of which are still in the early stages of development.

Yet even without these problems, federation is a a hard sell. The truth is, security and privacy are unappealing to many users. As Prodromou observed, promoting federation goes against the truism that, if developers want success, they need to:

All the same, those who are promoting federation remain optimistic. Because federation encourages code innovation, they hope that federated networks will eventually be able to offer features that centralized networks cannot. "End-users aren't going to be attracted to federated networks just because they're federated," Webber said, "but because there's software available that isn't available elsewhere." Prodromou agreed, suggesting that "the more we include games and rich content and [have] lots of interesting things happening, the more people come back, and the more that they invite their friends."

Even the dryness of federation as a subject may be less of an obstacle than anticipated — after all, Webber noted, if a subject as arcane as the HTML5 standard can attract widespread interest, so, too, might federation some day.

Whether federation can gain acceptance, much less counter the ills of centralized services, is still anybody's guess. For now, however, its potential is becoming as much a concern in some free software projects as the code itself. Federation may, in fact, be the long-delayed answer to the challenges offered from web applications, but whether it can be implemented widely enough to make a difference remains uncertain.