On Freedom and Network Services

I’ve been on app.net for two weeks now. In the excitement about it, people raised the rather legitimate question about why people are excited about it when identi.ca and, more generally, StatusNet have been doing it for years. And there has been general questioning of why people are jumping from one closed service to another. And how only open source services are are real solutions.

I’ll table the questions of relative energy for now. I think that app.net is more likely to succeed than identi.ca has, especially since they’ve already gotten a lot of the types of people that made Twitter fun early on, but that is mostly irrelevant to my primary point here.

In general, I insist upon free/libre software for as much of my computing, especially day-to-day, as possible. Why, then, am I excited about app.net, and do I willingly embrace other services, such as Pinboard, to which I do not have access to the source code?

Many, in their zeal for free software, think that not only software they run, but software they interact with on other servers, needs to have source available, modifiable, and redistributable. This results in things such as the Affero GPL, which requires that administrators who deploy covered software as a user-facing network service make source code available.

If you believe that free/libre or open source software is an intrinsic good, and that software without source available is universally bad for all, even if the software code itself is never distributed (eg. Pinboard, app.net, the server-side components of Google’s product line), then I see how you can get there. Coming from this perspective, some see Software as a Service as a loophole in free software (which, in some ways, it is).

But I see free/libre software more as a means to a broad vision of computing freedom than as an end in itself. Certain of the aspects of computing freedom seem only obtainable with free software; the freedom to continue running software of my choosing as I upgrade hardware, independent of the whims of software and hardware developers, is difficult to achieve without source. And I like being able to dive into the sources and fix nagging bugs if I so choose.

But what freedom, for me, does having the source code to app.net or Pinboard achieve? As I see it, there are two big computing freedom issues for web services, both related to vendor lock-in:

The first requires only a data export facility that saves data in an accessible, documented (or self-documenting) format. No source code is required. For most data, reasonably-designed JSON or XML is fully adequate. While source can be useful for processing the data, in the worst case I can write code myself to analyze the data or move it to a different tool, so access to server source is a matter of convenience rather than freedom.

The second issue is primarily facilitated by federation protocols, however, and not source code. Many protocols, such as SMTP and XMPP, are built for a world with multiple interoperating service providers.

There are two other things to note about interoperability issue. First, while it does not depend on having source code available, it is aided by it — it is far easier to deploy your own node if you can get the source rather than having to write it yourself. Second, it is somewhat less important than data portability, particularly depending on the nature of the data stored on the service. My e-mail and IM, I want self-hosted. Public data, however - tweets, blog posts, etc. - are not as important for me to be able to host myself or migrate between providers. I am more willing to move my data to where the community is.

While my ideal world would have a federated microblogging system (and I have an identi.ca account), I find centralized microblogging an acceptable compromise to participate in an interesting ecosystem, especially if I can back up my content. And I think that the user-supported model of App.net has the potential to mitigate many of the pressing issues facing services like Twitter, while being far more approachable and easier to market than identi.ca.