On Web Services and Free Data

Posted: Thu, 6 October 2005 | permalink | No comments

Jamie Wilkinson's search for XML-RPC interfaces for bug trackers reminds me of the heady days when I was looking for automated interfaces for SourceForge's various services. I am an incredibly lazy person, willing to expend enormous effort to avoid small, trivial tasks (hey, it's why I learnt to program, after all).

The end-result I wanted to achieve was a script to automatically upload, announce, and do the file release for new versions of IRM. Unfortunately, I (like Jamie) could find no automatable means of doing this, so I settled for a screen-scraping app called releaseforge, which isn't nearly as automated as I'd like, but is at least marginally less hideous than sf.net's direct interface.

All of my searching got me thinking (as I am wont to do when I've work that needs doing) about the need for Web Services[1] interfaces for various things. I've heard (although not played with) the wonderful things that you can do with the APIs that Google provides, and there seems to be a small but interesting number of other places out there that provide a means to sensibly access their services via code (no, screen scraping doesn't count as "sensible").

But, most sites have no handy interface for a program to get at it and do stuff. This is bad. For OSS developer support sites (sf.net, I'm looking at you!) it's downright frigging criminal. Here you have a site which is explicitly for people who know how to code[2], in the main. They're busy people. It would, I think, make sense to minimise the pain they have to go through to use the site, and not have them use a hideously slow[3] web interface for operations which you might be doing multiple times a day. The cynic in me (and that's a big part of a big me) has concluded that the reason that there's no WS interface is to push more ads past our eyeballs. If that's the case, though, I will happily and gladly sign up for a paid sf.net membership for access to the WS interface. Seriously -- that is a feature I'd see as financially worthwhile.

Of course, though, my thoughts didn't stop there. There's a bit more story to tell, a few more miles along this road.

Sites like SourceForge demonstrate a fairly big gap in the world of Free Software -- Free Software doesn't mean Free Data. What's the point in having the ability and right to modify the code, if your modified version can't actually work on the real, useful data?

I can hack on the sf.net code all I want (actually, I can't, but let's say I can) but that's of zero use to me unless I can run my code against my data. But my data is stuck up on sf.net, and they're not about to upload my changes to the site for the hell of it. I can apparently retrieve list archives and tracker data if I'm a project admin, but that doesn't really help me if I'm a random user, and it's not very real-time or interactive, which really limits it's utility to migrating away from SourceForge.

Basically, if my data is stored somewhere else, I'm restricted to whatever method the gatekeeper of that data deigns to give me. If hosted apps ever seriously get off the ground, Microsoft will be able to piss themselves laughing as they throw the source to Office 15 at me, safe in the knowledge that it's effectively useless without all of the documents I've written, which are safely and securely stored in a server somewhere I can't get at them.

A few weeks ago I was reading a blog entry from Colin Walters about why he isn't going to run his own server any more. At the time, I had a vague disquiet about his reasoning; at the time I put it down to my control-freak nature and left it at that. But I've realised that it's more than that: if I have my own server, I have the power over the data on it. I can host my own FOSS projects on it, my own blog, my own e-mail. Relying on a third-party provider (sourceforge, livejournal, gmail) I have no real say (other than with my feet) what happens to my data on that service. As it turns out, that's something that really sits poorly with me.

[1] I'm loathe to utter either the words XML-RPC or SOAP, lest I am labelled as a supporter of either. They both suck, as does all software, but for very different reasons.

[2] Or at least lay claim to some skill in that area. Actual skill level may vary, from virtuoso to virtual faeces flinger.

[3] It's even slower since falkag.net started serving their ads. Make it faster or f**k off, ktkxbye


Post a comment

All comments are held for moderation; markdown formatting accepted.

This is a honeypot form. Do not use this form unless you want to get your IP address blacklisted. Use the second form below for comments.
Name: (required)
E-mail: (required, not published)
Website: (optional)
Name: (required)
E-mail: (required, not published)
Website: (optional)