Joachim Breitner's Homepage

For software, the question whether some software can be considered “free“ is relatively easy to decide: Check the license of the code against the list of free licenses of your trust (the OSI list, the FSF list or the judgement applied by debian-legal) and that’s (mostly) it. When it comes to web services in the broader sense, including hosters, communication providers, social networks etc., this are not so clear. In this blog entry, I’ll try to list the various requirements that a service should fulfill and which I usually consider before deciding to use a service.

The Requirements

A) Availability of source code

Coming from the Free Software movement, this is the first requirement that comes to mind. If a web service claims to be free, then I want to be able to inspect how it is working, suggest and implement improvements and set up my own instance. For example, Canonical’s software housing setup Launchpad was itself not Free Software until very recently. Having access to the source code is also the reason why I prefer gitorious over github for git hosting.

B) Access to my data

Depending on the kind of service, it might hold data from me or about me that are important, such as my emails on a webmail service. If I won’t have a way to easily retrieve my data to back it up or to move to a competitor, I’ll think twice before trusting my data to this service.

C) Free data formats

If there is accessible data, it should be in a format that I can easily get and use with a choice of (Free) software. Not sure if such a service exists, but an online office suite only supporting its own proprietary file format (possibly with its own proprietary offline office suit) would be no option for me.

D) An API

For an extensively used service, I will want to have the possibility to optimize my user experience by automation. This requires that I can use the service not only in person, but also from tools I write. A very good example for this is Twitter: Besides registration, there is no need to use their web site at all and still use all the features, using the tools I find most fit for a task.

E) Choice of providers

Competition is good. If a service is only provided by a single company, and I become dependent on the service, I become dependent on the company. A few years ago, SourceForge was mostly the only provider of gratis, comprehensive software project hosting. By now, there are a few alternatives, such as alioth, savannah or google code, which is appreciated. Note that when it comes to the proprietary instant messaging services (ICQ, yahoo messenger, MSN messenger), there is no choice of providers: To talk to my buddies on a certain network, I am bound to that provider. The same applies to social networks (Facebook, StudiVZ, XING), and is one of the reasons why I shun these yet.

F) Federation between providers

If there is  a choice of providers, and the service in question provides some kind of communication, it is very desirable if I can interact with users of the service on other providers. A very good example for this is e-mail: People @gmx.net can send mails to people @aol.com, and I can have @joachim-breitner.de and still communicate with everyone. This was not always the matter of course: Before Internet e-mail was common, people on AOL could not get in touch with people at CompuServe. These days, the problem persists with instant messaging (Jabber a.k.a. XMPP being the notable exception) and social networks. Also sites like gitorious or github could support federation if they would allow to create branches of repositories that are hosted elsewhere, allowing their users to use the familiar interface with all repositories they work with.

Analysis of a few services

So far the theory. Let’s see how various services fare.

e-mail

Being from the old times of the Internet, when everything was better, it does not surprise that this passes all requirements: There is a large amount of Free e-mail servers and clients to choose from, my data is easily moved via well-known protocols such as POP or IMAP and save in standardized format. There is an abundance of service providers, and they all talk to each other. One could argue that the openness of email causes problems like spam, but I’d say that this might be a design issue, but not inherent to the above criteria.

Pretty much the same analysis applies to Jabber/XMPP.

ICQ

I joined when I was young and unwise. Now I am stuck to AOL to keep in touch with a relevent part of my online correspondence. To use it on the operating system of my choice, other people had to reverse engineer the protocol and any time, AOL could change how its servers work and I’ll be locked out. I can not get in touch with people on other networks, my buddy roster is not easily backed up and restored, and no, we can not see the source of the ICQ servers. I’d wish I could switch over to Jabber completely, but there are always a few important people who do not use that yet.

Github/Gitorious

Although gitorious is slightly older, github managed to become more famous. These web sites allow developers to publish their source code and other contributors to easily branch, work on their changes, and propose them for merging in the main code. They are based on git, so I can get my data. There is a choice of providers. I am not sure how well I can access their functionality (merge requests etc.) programmatically. As said before, they do not interact well, and only gitorious has published its code.

Facebook/StudiVZ

Very disappointing. I have heard that Facebook offers you a rich API, but otherwise, they fail every category. This is one of the reasons why I am not to be found on these networks yet.

Twitter/identi.ca

Twitter, similar to Facebook, excels in the category “API”, but fails in the others. A better alternative is identi.ca: The software behind it is free, I can download contact data etc. It even supports federation via OpenMicroBlogging, although that did not break through yet it, it seems.

OpenID

Another very good example for what I want is OpenID, a service that allows websites to accept a user’s credentials from another site. This saves the user from having to create accounts everywhere. There are free implementations, multiple providers, I can easily switch between them. A great feature of OpenID that goes a bit beyond federation is delegation: On the start page of my homepage http://www.joachim-breitner.de/, I saved who my OpenID provider is. Now I can use http://www.joachim-breitner.de/ as my OpenID, and even if I change my provider, this stays valid! This is a feature that not even XMPP easily provides.

Conclusion

Whether a web service is really free is a complicated question and has a graded answer. One has to balance the benefits of using a web service against the freedoms it is missing. I hope that in the long run, services fulfilling most or all of these requirements will prevail, so that I’ll be networking socially and blogging microly with a good conscience.