First prize: Book Chirpa

Mark
McSpadden gets first prize for Book Chirpa. Mark
wins an OSCON package that
includes a full conference pass, coach airfare from within the US, and 4
nights hotel accommodation. Book Chirpa was
“built to explore what
people on Twitter are saying about O’Reilly books.” It can show you
the stream of O’Reilly book mentions, trending books, or a virtual library
of all O’Reilly books mentioned on Twitter.

Second prize: Skillshelves

Jonas Neubert gets second prize for Skillshelves. Jonas wins his choice
of either an iPad 2 or
a Xoom
tablet. Skillshelves lets
you “Show the world what tech topics you are an expert in — simply
by making a list of O’Reilly books in your bookshelf.”

Third prize: FluidCV

Eric Seidel gets third prize for
FluidCV. Eric wins his choice
of $500 worth of O’Reilly ebooks and/or videos. FluidCV pulls
together information for your CV from tags in Fluidinfo, allowing the
dynamic construction of a CV just by tagging relevant objects in
Fluidinfo. Tag an O’Reilly book in Fluidinfo and the book cover and
associated skill automatically appears in your CV. Eric’s own
FluidCV can be seen
here.

Congratulations to the winners and many thanks to all who entered.

[Disclosure: Tim O'Reilly is an investor in Fluidinfo.]

Related:

• A writable API competition
• A writable API for O’Reilly
• 3 ways APIs can benefit publishers

Contest Information

• Judges
• Prizes
• Deadline
• Restrictions (US only)
• How to enter
• Contest rules

In conjunction with the Fluidinfo writable API for O’Reilly books and authors that was announced today, we’re holding a developer competition.

Note: The competition has been extended to 4/17/11.

[Disclosure: Tim O'Reilly is an investor in Fluidinfo.]

Unlike a normal API that provides access to read-only data, a “writable API” is a shorthand for one whose underlying data is openly writable. That’s the fundamental property of Fluidinfo’s data model. We’re very curious to see what developers make of it. In other words, instead of the usual case in which a read-only API is released and programmers are encouraged to simply consume its data or contribute only in anticipated ways, the new API allows programmers to add additional data to the exact same objects that are holding the O’Reilly data, and the new data can be anything at all. There’s no need to stop to ask permission, and there’s no need for anyone to have anticipated what an application writer might want to do.

The writable nature of Fluidinfo-based APIs opens the door to a richer world of data and applications. A single application could add new data and combine it with the existing data. A second application could further enhance and mash up the O’Reilly data and that of the first application, and so on.

To give very simple examples, an application could tag book objects to indicate that a user owns them or is reading them, could add users’ current page numbers, add links to the book elsewhere, or add any other metadata it pleases. Applications can also add tags (with values) to the author objects. These could indicate things like the author’s Twitter name, a link to their profile on LinkedIn, a measure of influence, a tag to show that the author is known by a user or is someone the user would like to meet, etc.

Competition details

While we want you to develop an application however you see fit, we imagine entries will fall into three rough classes. None of these are required in an entry and they are independent of the judging criteria:

1. Uses of the basic O’Reilly book and author data, such as building a different UI to books and authors.
2. Interesting data added to the Fluidinfo book and/or author objects. Entries in this class would not build applications.
3. Mashups of original and new data: add to the original data, and write an application that combines both in a provocative way.

Judges

Entries will be judged by Tim O’Reilly, O’Reilly editor Mike Loukides, and O’Reilly GM Joe Wikert.

Prizes

In total, three prizes will be awarded:

• 1st prize: An OSCON package that includes a full conference pass, coach airfare from within the US, and 4 nights hotel accommodation.
• 2nd prize: Choice of either one 3G iPad 2 64GB or one Xoom tablet 32GB (second prize includes device only, no wireless service is included).
• 3rd prize: $500 worth of O’Reilly ebooks and/or videos; selection to be at third prize winner’s discretion.

Deadline

The competition opens today (12:01 a.m. Pacific, March 21, 2011) and runs until 11:59 p.m. (Pacific) April 17, 2011. Winners will be announced on Radar on or around May 1, 2011.

Restrictions

Employees of O’Reilly Media and Fluidinfo are not eligible to enter the competition.

Huge apologies to our international friends, but this contest is OPEN ONLY TO DEVELOPERS WHO ARE LEGAL RESIDENTS OF THE 50 UNITED STATES AND DISTRICT OF COLUMBIA. Our legal folks worked valiantly to include everyone, but rules governing contests in each of your countries have to be followed. In the end they could not conjure up the legal magic necessary to draft rules for each of them; things are sticky enough between the boundaries within the United States. We’re really sorry on this one!

How to enter and get going

Get a Fluidinfo account

You’ll need to create a Fluidinfo account for your application and use its credentials to make calls to the API. If you build an application hosted on its own domain, you can use your domain name as your username in Fluidinfo.

Let the world know you’re entering

As a warm-up exercise in using the Fluidinfo API, we’re going to get you to tag a Fluidinfo object to indicate that you’re entering the competition.

Here’s what you need to do: Suppose your application’s username in Fluidinfo is “myapp.com.” You create a tag named “myapp.com/entry” and put an instance of it onto the Fluidinfo object whose about value is “O’Reilly Fluidinfo API competition.” The value of the tag should be the URL of the home page of your contest entry. If you are just adding book and/or author data to Fluidinfo, the URL you provide should describe the data you’ve added.

The tag therefore serves two purposes: its existence indicates that you’ve entered, and its value points to your entry. Note that your tag must be on the object when the contest closes in order to enter. If it is not, we won’t know you have entered.

The O’Reilly data in Fluidinfo

The details of the Fluidinfo objects holding the O’Reilly book and author data, and the tags on them, are described in a post on the Fluidinfo blog. On the blog you’ll also find a post showing example queries against the O’Reilly API.

You can also take a look at the O’Reilly namespace in the Fluidinfo Explorer (click on the oreilly.com namespace in the left panel to see our top-level tags and the sub-namespaces), and can also look at individual book and author objects. For example here’s the Fluidinfo object for Python in a Nutshell, Second Edition and the object for its author Alex Martelli.

Other tags on O’Reilly book data in Fluidinfo

The O’Reilly book objects also have other tags on them to give you some extra initial material to work with, and also to give you ideas. If you look at the object for Python in a Nutshell mentioned above, you’ll see that as well as lots of oreilly.com tags, it also has tags from Amazon, Google Books, LibraryThing, and Goodreads.

A simple example Chrome extension

There’s also a simple Chrome extension for O’Reilly books. This is intended to illustrate how a browser extension can pull additional information about a book from Fluidinfo and show it to the reader. If you’d like to build a browser extension, you can grab the code from Github and take it from there. If you’re using Chrome, you can install the extension by following these instructions. The Fluidinfo blog has details on how to use it.

Fluidinfo object model and API

You can find out more about the Fluidinfo object model and its API on the developer’s page. You can also often get help in real time by joining the #fluidinfo channel on irc.freenode.net (in fact you can even join the channel with a web-based client right from this web page).

Contest rules

Here’s the fine print.

Related:

• A writable API for O’Reilly
• 3 ways APIs can benefit publishers
• The future of publishing is writable

[Disclosure: Tim O'Reilly is an investor in Fluidinfo.]

We’ve added information to Fluidinfo for about 2,300 O’Reilly books (or books they have rights to), and about 2,000 authors. The objects in Fluidinfo are tagged with O’Reilly information, using the oreilly.com domain in their tag names.

For any O’Reilly book you can use the Fluidinfo API (description, details) to obtain any of 30 tags containing information you’d expect from a regular book API: author name(s), title, price, page count, homepage, cover image, etc. For each author there are tags with details of name, works, author page on the O’Reilly site, photo, areas of expertise, etc.

The Fluidinfo query language lets developers obtain book and author information using different combinations of these tags.

Beyond read-only APIs

O’Reilly already has an API (based on RDF), so why would we bother making another one?

One answer is that with Fluidinfo it’s simple to make APIs, so we did it because it’s a nice example and it was easy. Another is that accessing a book via the RDF API pulls back all its metadata, so that API is not fine grained. By splitting the metadata into tags on Fluidinfo objects, it becomes easier for programs to do queries based on individual tags or to obtain particular pieces of information about books or authors.

But there’s a much more important reason. Because Fluidinfo objects don’t have owners (the tags on them do, however), anyone can add information to the book and author objects that hold the O’Reilly information.

To illustrate, we added information from Amazon, Google Books, LibraryThing, and Goodreads onto the exact same objects that hold the O’Reilly information. That means you can trivially query across data from different sources. Plus, when you look at a Fluidinfo object, such as the one for “Programming Python”, you’ll see information from all these places, with tags that contain corresponding domain names.

This screenshot shows some of the tags associated with the O’Reilly book “Programming Python.” Click here for the full view.

Having tags from these well-known book sites is not the end of the story. Regular people get to have a voice, too. For example, the Fluidinfo object shown above includes tags for several people who have marked “Programming Python” as a book they own.

In Fluidinfo, objects can always be added to by anyone or any application. If you’re a developer you can sign up for a Fluidinfo account and easily write applications that not only fetch information but also augment the tags on the book and author objects. You don’t have to stop to ask permission to do something creative, and you don’t have to put your data elsewhere as you’d need to do if the O’Reilly information was only available via a read-only API. There are plenty of open source client-side libraries to help you.

Because the O’Reilly API provides access to openly writable data, we describe it as a writable API. It’s an example of how we’re trying to make the world more writable.

To explain the details of the API, we’ve written two companion posts. The first explains the structure of the O’Reilly data in Fluidinfo, i.e., the oreilly.com book and author tags you’ll find on objects in Fluidinfo. The second shows example O’Reilly API queries to give you a flavor for the ways you can access the data.

We hope you’ll find this as exciting and full of potential as we do, and that you’ll join us in collectively marking up the world.

Related:

• A writable API competition
• 3 ways APIs can benefit publishers
• The future of publishing is writable

From a biological
point of view, publishing can expand to encompass all of human
social signaling — both verbal and non-verbal — and include the myriad
little acts of information production and consumption we all engage in.

Even seen from this outer limit of generality, it’s clear that
digital is ushering in a
rapid convergence in publishing. While some forms are born
digital and online, others are being reinvented there as technological
advance sets old media free. There is massive disruption — both behind
and ahead of us — as the convergence continues.

Three convergence trends: smaller, easier, more personal

There are three convergence trends in publishing that are already
apparent.

One clear long-term trend is that smaller pieces of
information are being published. Considering just modern digital forms
of publishing, there is a roughly chronological progression toward smaller
publications: emails, Usenet postings, web pages, blog posts, blog
comments, tweets, tags.

Traditional media are also being fractured into smaller pieces,
particularly where the media packaging existed only to address
physical quirks of the media or the act of publishing. To give one
example: Popular music publishing centered on delivering albums. This
was a by-product of physical equipment — LPs, CDs, and their
players — which did not align particularly well with the more natural
unit of popular musical output, the song. Given low-cost flexible
alternatives, it’s no wonder that these forms of content are now jumping
the packaging ship and going directly digital in pieces that make more
sense. This leaves traditional publishers scratching their heads and
clinging to increasingly irrelevant and anachronistic packaging
methodologies — newspapers being another example — with attendant
declining advertising possibilities. Clay Shirky has written and spoken
with insight and eloquence on these changes (see here
and here).

A second trend is a reduction in
friction. As access to easy-to-use and inexpensive publishing
technology increases, it becomes economically feasible to publish
smaller and less valuable pieces of content. We have reached the point
where anyone with
access to the Internet can easily and cheaply publish trivial, tiny pieces
of information –
even
single words.

The third trend is the rise of publishing
personal information. Our inescapable sociability is driving us to
shape the Internet into a mechanism for publishing information about
ourselves.

These three trends — smaller, easier, more personal — provide a
framework to examine the development of online information publishing.

The three trends and the future of books

Over the last few months, interesting discussion has arisen about the
future of books and publishing. One provocative example is Hugh McGuire’s
post “The
line between book and Internet will disappear.”
Let’s consider what the trends of smaller, easier, and more personal might
tell us about Hugh’s topic: the future of books.

First, these trends reinforce Hugh’s claim that the line between book
and Internet will disappear. The forces of convergence in publishing
are surely strong enough to drag the book across that line. But more
specifically, which of these trends will books succumb to? Which will
books resist?

Books typically have an internal coherence that may prevent their
traditional packaging from fracturing along more natural fault lines the
way it does with newspapers, magazines and albums. But as the difficulties
and costs of publishing continue to fall, and as methods for online billing
evolve, publishers or authors may themselves opt to fracture book packaging
for economic reasons. It was not long ago that novels were routinely
published in serialized form. If it’s all digital, why not?

Because modern forms of publishing are giving
end users a voice, it seems a safe bet that books will become living
digital objects and that the traditional distinctions between author and
reader, and between publisher and consumer, will blur considerably.

Conceptually, though perhaps not technologically, there’s a
long way to go. Even the most avant-garde online services are only now
contemplating this kind of future. I’m willing to bet that Hugh
is also right that publishers’ products will have APIs. The API,
provided that it allows users and applications to write, can be
the vehicle by which a book is alive on the Internet, in the sense that it
will allow the contribution of information to books,
and make that information actionable.

Terry Jones will discuss the writable future of publishing at the next Tools of Change for Publishing Conference (Feb. 14-16, 2011). Save 15% on registration with the code TOC11RAD.

A world of writable containers

Looking at publishing from the broad perspective outlined above, with
its clear general convergence and specific trends, I consider it inevitable
that books and their publishers will be drawn into a digital future along
the lines that Hugh predicts.

You can look at this more widely, though. Publishing will converge
on the usage of underlying information storage that provides for a
world of openly writable containers. You could, for example, build a
Twitter-like system on such a basis, providing seamlessly for user
annotations. At the other end of the spectrum, you could use this type
of writable system to publish customizable living digital objects –
writable containers — representing
books (or anything else). VC Fred Wilson lends weight to the claim of convergence toward
a more openly writable world in his blog post, “Giving every person a voice“:

If I look back at my core investment thesis over the past five years, it is this single idea, that everyone has a voice on the Internet, that is central to it. And as Ev [Williams] said, society has not fully realized what this means. But it’s getting there, quickly.

As Brian O’Leary noted in “Context first“, mental models and mindset changes are required.
Shifting people from read-only thinking to imagining a computational world
that is by-default writable is something I’ve been trying to pull off for years. (FluidDB, a database we’re building at Fluidinfo, is meant to explicitly prepare for the type of future Hugh envisions. Everything in FluidDB can be added to — tagged — by anyone or any application. )

Read-only containers of content are an
inherently limiting form of media, whether physical or digital. APIs that provide controlled access to information are similarly
limited. They prevent the accumulation of
unanticipated or personalized contextual information.

From one perspective, arguing that this kind of convergence is
inevitable may seem like a radical oversimplification or wishful thinking,
but from another it seems deadly simple and obvious. In plainest terms, I
believe the future of publishing is a writable one. One in which
we step beyond the default of read-only publishing via traditional
containers and APIs, to something that’s both natural and empowering: a
world in which data itself becomes social, and in which we can personalize
arbitrarily. In other words, a world in which we always have write
permission.

Related:

• The
  line between book and Internet will disappear
• Context
  First (Magellan Media Partners)
• Dancing
  out of time: Thoughts on asynchronous communication
• Getting
  closer to the Web 2.0 address book

This specific problem is just one example of a wider issue. Given that so
much diverse and overlapping information about each of us is spread between
many applications, why are seemingly simple things based on combinations of
information — like automatically reacting to known friend requests — still
not possible?

Tim summarizes this by asking “Where is the web 2.0 address book?“

The traditional reaction to Tim’s need would be to begin work on the design
of a new application to provide the suggested features. This might give
rise to an online social address book incorporating his specific
suggestions, along with anything else the application designers might dream
up to provide additional functionality.

While such an application might be cool and work well in the short term, I
believe that approach is doomed to failure. The main reason is that we
can’t anticipate the future. Baking decisions about what to support or not
into applications is almost certain to leave us wanting
and needing more. At that point we’re beholden to application designers’
willingness, priorities, and ability to further adapt.

What happens when Tim comes up with another idea, or when you or I do? While an application might be designed to be open — for example, by providing an API or a plugin
system — at the end of the day it’s just another application sitting in
front of its collection of data. This problem is particularly severe in our
specific case: Tim would ideally like the incorporation not just of his
phone’s data and his email, but specific information from the O’Reilly org
chart and from Amazon. That level of specificity — or personalization, if
you prefer — is well beyond the interests of anyone writing a general phone book application.

For these reasons, among others, I believe the traditional “let’s build a
cool new app” reaction to Tim’s dilemma is the wrong approach.

The other answer

An alternate answer begins with a sharp departure from this thinking. I
suggest that the Web 2.0 address book need not take the familiar shape of
an application. Instead, like a physical address book, it might be mainly
about the data. That is, centered in a common data store through which a
variety of loosely coupled applications interact with users and with one
another.

In such a world, a friend request to Tim would be added to a shared online
data store. There it would be noticed by an application running on a mobile
phone, a periodic script that scans Tim’s inbox, or an internal O’Reilly
script with access to the company’s staff list. Any application recognizing
the requesting user’s details could add information to the request object
to indicate recognition. The initiating application could detect this and
act on it.

Several aspects of this idealized scenario are worth close consideration:

1. Such a system would require an underlying storage — a “data fabric”
   as Tim has called it — that was shared not just for reading, but also for writing. The shared writable data fabric would be open to future applications. They could contribute or consume information as they saw fit, without requiring the permission of existing applications, possibly without knowing or caring about each other’s existence. Future applications would interact seamlessly with existing ones by simply following established data conventions.
2. While any application should able to join the fun and contribute, a permissions system would be needed to protect existing information and to selectively share it among authorized applications. For example, Tim might authorize an application on his phone to add information about numbers he has dialed or email addresses he has been in contact
   with. He could authorize another application — in our case an automatic friend request resolver — to read that information and to create more information on his behalf to indicate existing friendships.
3. This data-centric answer to the “Where is the web 2.0 address book?” question points to a wide class of future applications which cooperate and interact not through synchronous pre-ordained API calls, but via asynchronous data protocols which follow open-ended conventions. This is in strong contrast to applications which hold information in databases with relatively inflexible structure behind APIs that strictly delimit possible interactions. Applications using a shared writable data storage can adopt conventions and data protocols by which they cooperate to achieve joint actions. Applications that operate in this way leave the door open for new conventions, for additional unanticipated data, and for future applications that adopt the existing conventions, or introduce new ones.

At Fluidinfo we’re building a shared online “cloud” data system, called FluidDB, with the characteristics outlined above. FluidDB aims to usher in a new class of applications, as described above, in which data can be
thought of as being social. The data allows diverse
applications to interoperate and communicate asynchronously using shared
conventions. [Disclosure: Tim O'Reilly is an investor in FluidInfo.]

In FluidDB, all objects may have information added to them by anyone or any application at any time — with no questions asked. Whereas a more traditional approach locks down entire database objects, FluidDB has a simple and flexible permissions system that operates at the level of the tags that comprise objects. Objects are always writable, including by future applications and by idiosyncratic applications that know, for
example, how to access the O’Reilly staff list.

To put things in a more general light, Tim’s “How ridiculous is this?” complaint (see image, below) is symptomatic of a wider problem. It highlights the awkwardness of a computational world in which applications keep their data behind UIs and APIs that are designed for specific purposes. These prevent augmentation, sharing and search, and they ultimately prove inflexible. It is ridiculous that even simple operations combining information in obvious ways are still beyond our reach.

Relief does not lie in the direction of more applications holding more data behind more APIs. It lies instead in allowing related data to coexist in the same place. Both Google and Wikipedia have demonstrated, in very different ways, the massive value that accrues from co-locating related data. There’s a real need for a Wikipedia for data. Writable and with an
object for everything, like a wiki, but also with permissions, typed data, and a query language to make it more suitable for applications. Such a store can hold the data, the metadata, support search across these, and provide a locus for applications to communicate.

The Web 2.0 address book then becomes a ball of data, not an application. Something we access as we please, using a collection of tools that individually suit us, and without any application having the final word on what’s possible.

Related:

• Dancing out of time: Thoughts on asynchronous communication
• Social network fatigue and the missing Web 2.0 address book
• The state of the Internet operating system
• Personal data stores and pub/sub networks
• The laws of information chemistry
• Goodreads vs Twitter: The Benefits of Asymmetric Follow

This post is the first of a two-part series. Below, I take a look at the core differences between synchronous and asynchronous techniques, and I suggest an alternative to traditional synchronous API-based communication between applications. Part two addresses Tim O’Reilly’s question: “Where is the Web 2.0 address book?“

Synchronous and asynchronous communication

Synchronous communication requires that the participating parties — information producers and consumers — are simultaneously involved. Examples abound: telephone calls, in-person meetings, a parent teaching a child a song, an audience listening to a public lecture or a live concert, buyers and sellers negotiating prices at a market, the broadcasting and simultaneous consumption of live events, Morse code flashed between ships at sea, and the Gotham City bat signal.

Communication can also be asynchronous. In this case, information is
somehow — broadly speaking — published and is only later consumed.

The history of technology has many examples of the tremendous impact that
can result when a form of synchronous communication is replaced with
something asynchronous. The most obvious example is the invention of
writing, which allowed information to be written and consumed later.
There are many familiar examples, such as CDs and DVDs, the VCR (and its
modern derivatives like the TiVo and Boxee), voicemail, etc.

There are many other less obvious examples, too. Post-it Notes are
asynchronous: they let us publish information in physical locations that
we choose carefully so the intended recipient will likely encounter them
later. Blog posts, including this one, are asynchronous. There are also plenty of
non-human examples, such as dogs urinating on lamp posts.

Communication doesn’t always divide cleanly into synchronous or
asynchronous. Many forms of communication have some elements of both. How
would you classify the Pony Express, smoke signals, sky writing, and
telegrams? Susan
Boyle’s performance on “Britain’s Got Talent” was experienced
synchronously by a few thousand people, and asynchronously by 50
million. And when Charlie bit his brother’s finger (again) in the back seat
of the car, the event was experienced synchronously by just three people,
but later, asynchronously, in 233 million online viewings.

The requirements of asynchronous communication

The main requirement for asynchronous communication is a mechanism for
interim information storage. This can take many forms: wet concrete, the
soft bark of a tree, a wall, or one’s own skin. Along with storage, one
must also have a means by which to deposit information. In our previous examples that would be a finger, a pen-knife, spray paint, and a tattoo needle.

It’s difficult to overstate the impact of technology on our ability to
communicate asynchronously. Modern digital systems provide us with
virtually unlimited amounts of cheap storage, along with the means to
efficiently deposit/retrieve information into/from this storage. Consider Slideshare as an example: You can post presentation slides and have them read asynchronously
by thousands or even millions, rather than just seen by the dozens who might attend a presentation in person.

The other requirement is a set of conventions about the communication.
These may be high-level and taken for granted. For example, the language of
communication. Conventions are often more explicit, and can become
specialized over time, like apartment ads: lg 3br apt, d/w & a/c, hdwd
flrs. Conventions can also take the form of protocols, in which parties
exchange information using the shared storage. Examples include quoting conventions in
email threads, and people using @name to address others and check for
mentions in Twitter.

Asynchronous communication lends itself to scale

Asynchronous communication almost always scales better than
synchronous. Synchronization is usually centralized, complicated, and
expensive because participants are often forced to waste time waiting.

The main requirements for asynchronous communication are things that
modern technology is providing in abundance. Experiences that were formerly limited to a small set of synchronous participants are now regularly experienced asynchronously by a significant fraction of the people on the planet.

At smaller scales, there are many familiar examples — including
non-digital ones — of how asynchronous communications scale so easily and
cheaply. Putting up a billboard beside a busy highway is a cheap and easy
way of delivering a message to many. Using “Wanted” posters is better than
having the sheriff stand on the corner describing a fugitive to passers
by. Having a mailbox in front of your house provides temporary mail
storage, which ironically can be faster and more convenient than a
synchronous meeting with a courier service who will put your package back
in their truck if you’re not home to sign for it. Higher tech examples are
abundant, as mentioned above.

Because asynchronous systems scale so much better than synchronous ones,
coming up with ways to replace the latter with the former can result in the
creation of extraordinary value. For example, consider Twitter and YouTube.

APIs, data protocols, and FluidDB

My main interest in thinking about the possibilities of asynchronous
communications is in the area of how applications communicate (and might
come to communicate). This is often done via APIs that applications
provide, and in much of the computational world communication between
applications takes the form of synchronous calls to these API methods. I
believe this presents an opportunity for an asynchronous alternative, and
that the alternative can have an impact similar to those we’ve seen
historically when synchronous systems are replaced by asynchronous ones.

In particular, I’m currently involved in building FluidDB, a new kind of
database under development at Fluidinfo. Among other things, FluidDB aims
to provide shared always-writable storage that applications can use to
exchange information. [Disclosure: Tim O'Reilly is an investor in FluidInfo.] I believe that predefined API calls between applications are generally
less flexible and powerful than asynchronous communications.

In the second part of this series, I’ll give an example of asynchronous flexibility by offering an answer to Tim O’Reilly’s question “Where is the Web 2.0 address book?” His question arises from a frustration with the
lack of communication between applications. Application-independent shared
writable storage and simple conventions for communication look to me like
the best way forward.

Related:

• Getting closer to the Web 2.0 address book
• Social network fatigue and the missing Web 2.0 address book
• The state of the Internet operating system
• Personal data stores and pub/sub networks
• The laws of information chemistry
• Goodreads vs Twitter: The Benefits of Asymmetric Follow