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

Rufus Pollock rufus.pollock at okfn.org
Mon Oct 23 10:37:03 BST 2006


Forwarding for Kragen as he isn't yet subcribed to the list.

~rufus

-------- Original Message --------
Subject: Re: [okfn-discuss] Fw: The equivalent of free software for 
online services
Date: Sun, 22 Oct 2006 07:01:15 -0400 (EDT)
From: Kragen Javier Sitaker <kragen at pobox.com>
To: Rufus Pollock <rufus.pollock at okfn.org>,	Francis Irving 
<francis at flourish.org>
CC: Jo Walsh <jo at frot.org>, Kragen Sitaker <kragen at pobox.com>, 
okfn-discuss at lists.okfn.org

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?

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.

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.

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.

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.

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.

On Sun, 30 Jul 2006 20:36:50 +0100, Francis Irving wrote:
> Mike Linksvayer gives a few more interesting points:
> http://gondwanaland.com/mlog/2006/07/06/constitutionally-open-services/

Thanks very much for that reference --- I keep forgetting to read
Mike's weblog :)

> And it is worse than just knowledge - for example when a private
> organisation like eBay owns a major marketplace. I guess, that is the
> knowledge of who has what for sale at what price.

Also what sold for what price in the past, which I find more valuable,
as well as who's looking at which auctions.  Usually I get the first
by bookmarking a bunch of auctions about to close, then reloading them
the next day.


-- 
Director, Open Knowledge Foundation
m: +44 (0)7795 176 976
www: http://www.okfn.org/ | blog: http://blog.okfn.org/



More information about the okfn-discuss mailing list