Re: Tim's paradigm shift

I had difficulty in relating what-makes-Open-Source-great to the examples 
of network-centric business models in Tim's essay.  It's more than just 
about architectures of participation, network effects, and scale.  I think 
we need to think about the business value of the right to fork, and 
whether that still applies in a web services context.

The right to fork is, as I see it, the fundamental right inherent in any 
truly open source license.  It's the right to clone a creation *out* of 
the hands of its creator and continue its evolution *despite* where the 
original author(s) intend to take it.  It's how nearly every major Open 
Source project starts, it's what keeps the investment risk around 
collaboration low, and it's what keeps leaders of projects humble.  IBM 
doesn't have to trust Linus with the kernel - it knows it could fork at 
any time should their priorities and those of Linus differ.

To illustrate this in terms of Tim's paper, let's talk about CDDB and 
FreeDB.  I'd wager most of you are familiar with the basics: CDDB started 
out as a free service for mapping CD track layout signatures to metadata 
about the CD itself, making it possible for your CD playing or ripping 
application on your desktop to give you a nice interface to what's playing 
now (because, astonishingly, that metadata isn't usually on the CD 
itself).  The first real major end-user-level "web service" IMHO.  Most of 
the popular tools that consumed that data also produced it: if CDDB 
couldn't find a match when your player app hit the server, the app would 
open a small window where you could type in that information yourself, and 
with a click of a button submit that back to the database.  Most 
applications also allowed you to correct the data that was in there; 
meaning incorrect data usually didn't last long.  No one ever asked you to 
sign over your copyright for your effort, since it wasn't your content 
anyways, and it was always assumed (perhaps because that was the MO for 
things like this on the net back then) that your contribution would remain 
available to you in some way.

This was such a valuable tool that tens of thousands of titles were 
entered, with rich metadata.  The inevitable happened: servers got swamped 
(because it was centralized), donations didn't cover it, an angel stepped 
in to bail out the founders and become 'caretaker'.

What happened next is probably best said quoting the freedb.org web site:
http://www.freedb.org/modules.php?name=Sections&sop=viewarticle&artid=2

   As Escient has changed the terms of licence for accessing CDDB, some
   programmers complained that the new licence includes certain terms that
   threatens them in a way they cannot accept: If you want to access CDDB,
   you are not allowed to access any other CDDB-like database (this one,
   for example) and - while accessing the database - the programmer has to
   ensure, that a CDDB-logo is displayed (Funny sidenote: One programmer
   told me, that his cd-player will be banned if he is refusing to display
   the CDDB-logo. His software is a console-based program (it does not
   produce any graphical output) for blind people...).

   Update (March 2001): Gracenote (which is the new name of CDDB) has now
   banned all unlicensed applications from accessing their database. New
   licenses for CDDB1 are not available anymore, as they obviously want to
   force programmers to switch to CDDB2.

A totally valid position for Escient/Gracenote to take, if evaluated from 
the perspective of a business.  This was costing real money to run these 
servers, and bandwidth, and hey we've got a business here, how are we 
going to monetize this except by somehow charging for use?

I'll avoid any information-wants-to-be-free arguments, because that's 
debatable.  Let's say you're Apple, and used CDDB for iTunes.  Whether or 
not Gracenote's licensing fees were reasonable, the fact that your 
business was dependent in a *inavoidable way* on CDDB represents a 
business risk you didn't anticipate.  And even if the fees today are 
reasonable, what leverage do you have to keep them reasonable?  And 
shouldn't you get some credit for all the contributions your users made 
into the system?

In short, because there was no 'right to fork', using CDDB represented a 
business risk.  Replicating what they had would have been painful; if 
iTunes's track-display suddenly broke for everyone, yow!

Enter freedb.  It wasn't started for business reasons, as best I know; it 
was started more for info-libertarian reasons, the sense that what 
Gracenote did with CDDB was wrong, and the free software world needed a 
free CD metadata database.  But it might as well have been, especially had 
Gracenote tested the "what the market is willing to bear" line much more 
closely, and the other vendors felt that a truly "open service" was a 
better approach.

Freedb's architecture is significantly decentralized, as I understand it, 
save for its DNS.  One can grab the entire database at once, and if one so 
chooses, fork - realizing you give up the stream of updates flowing 
through the freedb.org system.  This is perfectly analogous to the risk of 
forking in an open source project, where the fork is only likely to 
"compete" with the project it forked from if you attain enough momentum 
behind it in terms users, developers, and patches.

If I knew more about Freedb I'd probably have more interesting things to 
say; I don't know its size (entries, # of mirrors, usage) in absolute 
terms or relative to CDDB.  Nor do I know whether the protocol between 
freedb clients and servers has any sort of "standards" momentum other than 
as a de facto standard.  But those would all be interesting things to look 
at.

What I think is self-evidently interesting about Freedb is the concept of 
an "open service" that Freedb represents.  Amazon's web services for 
getting metadata about a book based on its ISBN # is pretty interesting - 
but what about describing that protocol generically, so the Library of 
Congress could provide such a service as well?  Or Barnes n Noble?  That 
way the thousands of libraries using that functionality don't have to 
worry about it disappearing if Amazon ever has start cutting costs. 
Amazon's smart so they'll probably start charging for it, charging less or 
nothing for non-profits, etc; but only the existance of a viable 
alternative will guarantee that this model is stable.

Let me define an "open service" much more concretely: it's three things:
a) a document that describes the protocol (WSDL, for example)
b) a database of content, collaboratively built, inherently copyable
c) source code that implements it on common infrastructures

I think all three are essential.  Anything less is interesting, in the 
same way running MS Office on MS Windows is interesting.  But 
fundamentally different.


The reason we're talking about this here, rather than on some 
open-source-utopians list, is its relevancy to business.  Let me posit 
that any business whose operational struts are single-sourced at critical 
points runs with significant business risk, and is not a business any of 
us would invest in or run.  Since I assume with this move to a web-service 
world we want to see businesses consume web services as much as they 
provide them, to have tight loops and be multilayer and all that, we want 
to be thinking about the resiliency of such a system.  I think "open 
services" are key to that.  Building your business to be dependent 
functionally upon the web services provided by particular companies is no 
different than building applications that run on Windows.  There may be 
money to make there, no doubt about it... but in the long run I suspect it 
will cause the same kind of dynamics between supplier and consumer as you 
see today between Microsoft-the-platform-provider and Win32 ISVs.  Meet 
the new boss, same as the old boss.


Thoughts?

 	Brian