[okfn-discuss] Fw: The equivalent of free software for online services

Tue Oct 24 17:31:13 BST 2006

Kragen Javier Sitaker wrote:
> Sorry to take so long to reply --- I've been traveling in Ecuador and
> Perú, and now I'm on a bus in Venezuela after the Foro Mundial de
> Conocimiento Libre.
> 
> I mostly agree with what Rufus and Francis wrote, but I've quoted the
> few parts with which I disagree below.
> 
> Rufus and Francis, may I copy your comments to the kragen-discuss
> mailing list?

Of course. There is also an associated blog post which has similar, but 
slightly different content:

http://blog.okfn.org/2006/09/04/open-apis-dont-equal-open-knowledge/

> On Sat, 29 Jul 2006 11:59:48 +0100, Rufus Pollock wrote:
> 
>>Kragen suggests how we could address these problems by 'build[ing] these 
>>services as decentralized free-software peer-to-peer applications'. I 
>>certainly think this is an interesting suggestion and would concur with 
>>many of the items on his wish-list of tools and systems but I think a) 
>>we need to distinguish between different kinds of  service (and the 
>>associated data) b) distinguish between services and data.
>>
>>For example it seems to me that a todolist service (highly personalized 
>>data, little reuse, little sharing, privacy issues etc) is substantially 
>>different from a map-tile provider (common data, massive reuse, large 
>>datasets etc) and that must influence the approach taken in providing 
>>that service in a truly free/open manner.
> 
> 
> It may be that you are right, in which case we will need two (or more)
> different protocols, sets of servers, security models, etc., to
> provide these different kinds of services in a decentralized manner;
> the associated network effects will be correspondingly less
> compelling.  

Sure though it means that if one had to prioritize one would focus on 
the system for the map-tile provider before the one for the todo-list.

> We know this is possible in a somewhat centralized system; the WWW is
> a compelling way to build both to-do lists and map-tile providers
> today.  I am hoping that we can find a way to design a decentralized
> system that supports at least as wide a range of applications as the
> WWW, and takes advantage of the WWW's network effects by fitting into
> it as little more than another URL scheme and security model.

Good point.

> But I am not actually building that at the moment, because I have too
> many other projects to do.
> 
> 
>>Second, and relatedly, I believe it is primarily the *data* and
>>*not* the *service* that we need to manage in the
>>highly-decentralized, collaborative (versioned), componentized[^2]
>>fashion which Kragen describes.
>>
>>In essence we need a *knowledge-centric* approach rather than 
>>*service-centric* one.
> 
> 
> I agree with this in part.  The data is more important than the
> service; if I had to have one or the other, I'd pick the data.  But I
> don't think it's a good idea to divide the task this way, for two
> reasons.
> 
> First, data isn't very useful without *some* code, and if you don't
> have the code that makes it useful, you may underestimate how hard it
> is to write it yourself.  It may be that for some apps, with a
> reasonable data representation, you'd be happy just reading the data
> in its native format rather than using other code to view and modify
> it, but I think that the advantages of having a UI are very large.

In one sense I completely agree with you: data on its own, that is 
without an API of some kind is useless. In many ways the distinction 
between code and data here is artificial:

CSV file:

"Date", "Population"
1800,1000000
1801,1001000
...

Python file:

data = [
     1800,1000000
     1801,1001000
     ]

Furthermore, one always need to ship some kind of metadata with the data 
and this metadata is usually expressly designed for (or results in the 
development of) code that can access, and therefore process that data.

I do agree that a distinction can be drawn between data + api and data + 
  api code + service code where the service includes all the items that 
making a working 'Service' such as UI, load-support, (charging?) etc etc.

I take your point that the service part is valuable but I do think for 
the 'openness' aspect the crucial part is data. As long as the data is 
rich enough and open you can always leave. Perhaps that takes us some 
way towards defining an open service:

   * Its data (+ api) is open (and where there are privacy issues that 
means available to that user).
   * That data can be accessed in an automated manner.
   * (?) Its source code is F/OSS

> Second, code is a kind of data.  If you can store and version data in
> a collaborative and componentized way that works for a wide range of
> different kinds of data, you can store and version code that way too.
> For many applications, that's almost enough --- you just need a
> security sandbox that lets you run that code safely.  That's a
> difficult problem, but not an unsolvable one.

Absolutely, in fact I'd say it was a lot easier to store and version 
code than to store and version data (this is something we've been 
discussing at the OKF for a while).

> There are some applications, such as full-text search of the whole
> web, that require access to too much data to make it practical to run
> the code in one place and move all the data to it, or have a spiky
> temporal load distribution and therefore benefit from distributed
> time-sharing.  My second reason doesn't apply to such applications,
> since they require more than just storage from the underlying
> platform, but I think they're still worthwhile to support.

Sure and these are things which, as you point out, will require some 
kind of decentralization to work.

[snip]

Regards,

Rufus