Terry Jones is building *something* that got the tech community talking and thinking (@scobleizer, @solso, @timoreilly, @tweetipFH, @ericflo, hacker news…). Some say he is building the new web, some don’t think he is making any sense at all, and rumors outnumber facts. I was intrigued by the possible connections to the platform revolution enough to spend a weekend reading everything I could find on the net ((@terrycojones, his blog, notable articles by Gerry Campbell, Paul Erb and the original firestarter) and exchange a few long emails with Terry. Interest growing, I hopped on a flight to Barcelona to meet the maker himself.
The events of the trip would be worth a post of their own: Guitarists and step-dancers in Barcelona parks, the legendary night of tapas and wine that carried us to a secret bar with candleholders, greek, gothic and baroque statues and a medieval black globe guarded by bar staff who thought to be bar staff, the door that could be a movie, the three metal screws into my head, the sampling of Terry’s fine library over three rooms and the football I played in pajamas. But here I will only write about the nine hour non-stop discussion about FluidDB, and what I think the Fluidinfo team is up to.
Nuts and Bolts
To clarify the basic concept and uses, let’s first suspend the frameworks in which FluidDB was so far mentioned: Semantic web, read write web, a wiki database, web search and the next everything, and start with fundamentals. Let’s also abstract from Terry’s and Esteve’s execution (which I find pretty good), and see FluidDB as a concept.
FluidDB fits into the platform landscape and can be initially compared to Amazon SimpleDB or Google’s BigTable. It is a database platform with several architectural twists: All objects in FluidDB are shared. Anyone can add objects and add attributes to existing objects. Attributes are owned by their creator (user), can be of several basic types, can be shared or private, and can be nested into a hierarchy. A program built on FluidDB could store some data in FluidDB, and other data elsewhere. All data in FluidDB is readable and writable via a single API that supports a native query language, opening FluidDB data to internet services, iPhone apps, Firefox extensions, dashboard widgets, you name it.
So what does all this mean? We may speculate about the collaborative and evolutionary dynamics brought by object sharing in the long term, but I am primarily interested in the first few applications that might emerge. Both a litmus test and a driver for adoption, if these turn out interesting, then the long term should as well. I imagine them like this:
App 1: Bookmarks
Social Bookmarking: I dived in recently again to seek visibility for my blog (bad boy!). I signed up to three popular ones, and now have around twenty pages bookmarked in each of them. Probably different pages. I feel there is *something* I would like to do with the bookmarks (visualize? remember? link to my documents via tags?), but none of the bookmarking services managed to satisfy the mind that doesn’t know what it wants.
Enter FluidDB: Someone develops a social bookmarking app that saves bookmarks and tags to FluidDB. This is one of the easiest and most obvious FluidDB apps, so it will come out shortly after FluidDB release. It might be an alpha test project or an opensource port (perhaps of Markaboo or anyone struggling to differentiate). The data collected from me (and other users) is now freely accessible to any developer. So a second developer thinks about a better way to visualize my bookmarks, and writes another app that uses and enriches the same data. Great. A few months or years later, I still have only one set of bookmarks (a gentle simplification here), they are online, accessible, mashable, reusable, and I also have many applications to view them through. I can play with a few new apps in several windows and instantly see which one does a better job with my data. And I know that new apps will be coming knowing where to find everyone’s bookmarks, tags, likes and favourites.
App 2: Books
I browse books on Amazon, on AbeBooks and sometimes elsewhere. I have an Amazon wishlist and purchase history that has value only on Amazon. I bet that a few weeks after FluidDB release, a Firefox bookmarklet will start saving my purchases, wishlist, browsed books and liked books into FluidDB. The bookmarklet will work independently of Amazon and AbeBooks, and will collect all books I browse in all book stores, and make them available in FluidDB as ‘my books’. I hope I will only need to wait a short while until the quickest of the big players realizes the FluidDB data is useful and accessible, and starts using my FluidDB book data in his recommendation engine (in effect, start using purchase and preference data from competitors). Others will follow.
Result: I have reclaimed my data; I can come to any bookseller and let them do their magic on my data; I am not locked in by any of them, and they will need to try harder to impress me during every purchase. But they also can do a better job, because they know more about me. (Bonus: They even know my bookmarks and tags created by App 1, and maybe they can make use of them. But let’s ignore that for now.)
What happened? I am thinking about a few shifts:
Shift in the platform / app divide
The data is unlocked from the application, and the two layers can be optimized independently. The data layer is shared, so the applications optimize it together. The benefits of collaboration are shared. Hmmm. Why not? Sharing that unlocks synergy is the essence of platforms, and differentiation is sought elsewhere. In the process, data has become part of the platform, an interesting part – a fluid platform…
Shift in data ownership
Locking users to an app by locking in their data will get even more difficult. Just like every app/startup today needs to keep an eye on open-source competition, they will start thinking about open data. Threat or opportunity – everyone’s choice. We see this trend today in data portability – applications already assure users that they won’t get locked in. It is the users’ data, after all. But FluidDB is not about data portability: Why port when you can share? Data portability comes to play often as a creative afterthought when the lock-in strategy fails, and does not substantially affect application design. FluidDB, on the other hand, aims to be a service that any developer can use as a starting point – for an application, a mashup, an iPhone app using Firefox-produced data mixed with a news feed. Plus, all objects are essentially ‘social’, collaborative – both between users and between objects.
Shift in value perception
Del.icio.us sold for $30m, Stumbleupon for $75m. If they could not claim the value of my locked bookmarks, how much would they be worth? Where will the value of applications be after they start sharing data? How much of it is monetizable? And where did the original value go? Twitter is a good model of the benefits and challenges: One API over a lot of data, and applications mushrooming all around it. Except Twitter only half want this – they also want a business. It is an example worth spending a few sleepless nights over, and I would suggest that Google buying Twitter is not a solution (for anyone besides Twitter and Google). The Twitter business model challenge might be approaching other businesses.
Shift in application focus
If applications collaborate in creating more useful shared data, where will they compete? I don’t believe that FluidDB / open data / data-as-a-platform destroys apps or value. Data ownership will just move out of the app value equation just like infrastructure did, changing the approach to application building. Developers will have more time to be creative with good algorithms and good UI. Applications can be valuable even without own data layer. Algorithm example: Google does not own the pages their algorithm so successfully presents. UI example: I just bought a licence for Path Finder, a file system explorer, to view my files in a more comfortable way.
Shift in innovation speed
If anyone told you five years ago they were building a database that would hold blah blahs about people, and that they hope developers would start writing applications on top it, would you have laughed? And perhaps that was the chance to see the early Facebook. From one angle, Facebook is a specific version of FluidDB, and the concept of shared data and individual applications has worked incredibly well for them. Similarly, Twitter opened its data through an API, and applications mushroom all around it. I see FluidDB as a generalized version of this approach, and expect it to accelerate innovation wherever it finds its use.
Which apps will start porting first, which will have the rug pulled from under their feet, which ones will attack before getting attacked? What will eventually grow on top of the pool of data? Now we might return to the suspended frameworks and think again about mashups, personalization, search, semantics, apps dissolving into protocols, data publishing. And about the efficiency and synergy of collaboration. If FluidDB manages to unlock another layer of this power, manages to make us collaborate more, it might eventually create a paradigm shift similar to those caused by open source, bittorrent, wikis, blogs, VoIP and APIs. To finish in style with a little mashup, Nick Taylor’s recent quote is spot on: “It’s hierarchy vs. network again – the defining conflict of the era.” The video that made him say it is Mike Wesh’s Anthropology of YouTube.
If you don’t have an hour to watch it and see how much people enjoy sharing, see the warp version of his Machine is Us/ing Us video and how it hit #1 video spot on Technorati. And have a laugh here …do you think it’s unrelated?
Powered by Facebook Comments