Provoking: The blog of Filip Dousek

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?

I have been writing a novel for so long that my friends think it’s just a chat-up line. My first notes are about 8 years old, so when the book gets mentioned, laughter often follows.

I am comfortable as long as people just laugh, but once in a while I am asked what it is about. Then comes trouble – I can dodge the answer and look pretentious, or attempt to answer and look like an idiot. Why? Because I don’t remember what my own book is about.

So what is the book about? This happened again during one breakfast chat with Tom Papirnik in Brighton, in a cafe that seemed to stand on a vortex of paradoxes. Even the cafe itself could not be described consistently (we couldn’t agree if it was that good or that bad), and then I hit on the idea that the book’s content is an incommunicable idea. We laughed, but the thought stuck. It’s actually true for the time being, because the book has not been written yet, so it cannot be communicated. But it also captures fairly well how I struggle every time I try to summarize. I have a feel for what I am writing, but it does not summarize well. The book is quite long now (before edit!) – 400 pages + 1000 unsorted notes. I get a feeling that the text is like a hard drive, and I seek here or there, load some chunks into my work area, work on them, save, and move to another cluster. The book is a network of individual nodes (chapters, paragraphs), and I work on individual nodes without needing to remember the rest.

There is the moralizing point of view: If you cannot summarize your book into a few sentences, you don’t know what you are writing about, and it will be crap. I heard of this as one of the standard publishers’ tests. The traditional story contains a meaning, a point, a three sentence bonsai. Why? On the last page of a book, the reader’s brain, having already forgotten most of the text, asks – okay, so what do you want me to remember? What was this about? He would like to remember the experience, possibly draw a lesson for the future, but he can only do it through a line that fits within the limits of consciousness (point, lesson, theme). And if this final need is not catered for, the reader might finish the book unsatisfied, which is not good for the business. But the story already is a bonsai, so its point is a bonsai of a bonsai. I am skeptical towards book summaries, points and messages. What can be simplified should be said in its simpler form. I like ambiguity, paradoxes, double meanings, diversions, networks of interconnected ideas, thought fertilization. I enjoy novels, but am bored by most summaries. Raison d’être, IMO.

Getting to the point: It is not possible to ‘know’ the whole book for the writer just as for the reader. Now returning to writing after several months on other projects, I forgot even more. And I found myself with over a 1000 notes that need to be merged into main text. Which notes are important? Which themes are important? Which notes are related? Could I get an eagle-eye view of the chaos within too many ideas to remember? Visualization.

I spent two weeks tagging each note with multiple tags, assigning priorities (weights) and also scenes, where possible. Then I loaded the Excel files into TouchGraph Navigator to get a picture of my novel, the bonsai of a bonsai:

I didn’t know beforehand if the result would be worth the time. And I am really surprised how much more I can see in the network images. The TouchGraph UI is simple, but the output is great. I can display all individual notes or just the network of tags, with links weighted by co-ocurrence. I can output a list of tag co-occurrences, with relative importance (much more telling than absolute importance). This tells me which tags are related, and I can now go through the lists and draw out significant clusters of tags: Uncertainty – Romantic – Photos – Prague – Revolution. Madness – Meaning of Words. Story – Point – Death – Life. Humour – Fear. Woohoo! Several topics (identity, the perception of time), which I considered to be on the sidelines of my thoughts (and I thought about saving them for some other book), are actually among the most integrated tags. I can also select only certain topics and see the notes that relate to them, and notes under related tags…

This is TouchGraph (by the way, they also have visualization apps for Facebook, Amazon and Google). I am planning to upload the data to Tinderbox next to include theme development and scenes.

So, what’s my book about? You tell me! Click on the images to see full versions and leave a bonsai in the comments :)

Three companies have caught my eye in the last few months thanks to their innovations in business models coupled with a focus on the developer community: Force.com, 3scale and CloudMade. I will use them as examples in this three-piece discussion of the good things that are lately happening to the developer. The trio are a diverse bunch, but I will write about them together to try and show from different angles that the refocus from the end customer to the developer is not trivial, and cannot be boxed simply as ‘infrastructure’.

Something else is emerging from the fog of clouds, platforms, APIs, business models and crowd-sourcing: A next layer of aggregation with prefabricated sets of infrastructure, services and customers, luring the developer. Think iPhone. Playgrounds, ecosystems, complex live platforms. They are now starting to provide a ready-made business environment, thus adding yet another layer of leverage to the already nicely leveraged and scalable method of problem-solving that is software.

The choice of platform defines the starting point of every project. If I want to win the marathon, I might consider starting on mile 2. Or mile 12. In business, this isn’t cheating. No one starts at mile 0, we all utilize platforms. For example, the electricity grid. Who would start their next big idea by producing electricity, soldering own laptop and hacking an operating system? We now consider these elementary platforms a given (without even feeling blessed). The real advantage is then made (or missed) by using convenient languages, ‘cross-platform’ platforms (Adobe Air/Flex, Google Gears), open-source building blocks, elementary cloud services (Google App Engine, Amazon Web Services) and recently complex platforms. I like the ones that come with a business model, so let’s look at one.

One Free Lunch, Please
Salesforce is a trailblazer. Some years ago, they have built Salesforce.com, a CRM software that has become the largest SaaS application on the market. It is the flagship experiment in SaaS, prominently discussed all over the web. A large part of the discussion revolves around costs to customers, due to the subscription pricing that has become synonymous with SaaS. But there are far more interesting innovations inside Salesforce.com than customer pricing.
Technically, Salesforce.com is more than CRM software. The underlying architecture has received a lot more thought than is needed to build CRM. It was developed with a strict multi-tenant approach (which is the proposed solution to a number of inefficiencies in traditional software delivery, and therefore of great interest to many developers). Both the database and the code have added layers of abstraction that allow deep individual customization within a shared system. For example, there is no Customer Account table, no Sales Event table. Instead, there is a set of meta tables such as Data, Objects, Fields, Indexes and Relationships. The same meta tables will hold both Customer Accounts and Sales Events. Cars. Mileage. Alien Sightings. The same tables will track Cars for one tenant, and Alien Sightings for another. Similar abstraction is applied to the code and UI. So architecturally, Salesforce.com is not a CRM system, it’s the largest running solution to multi-tenant platform software.

Salesforce then took the next step: They have turned the architecture of Salesforce.com into a service – a (relatively) blank platform that can be used to build applications very different from the original CRM. The Force.com platform offers the resolved, functioning approach as a development starting point to everyone. With zero upfront costs (except the cost of mind porting – learning the architecture, the Java-based Apex language and Force.com specifics and limitations), every developer can write a multi-tenant app on a proven platform and reap instant benefits:

• Fast deployment to first customer (the number of technical features, and development business process know-how that come with the platform)
• Fast deployment to further customers (scalability of hardware, software, deployment model, upgrades, customization)
• Instant customer base (55 000 customers accustomed to the technology, using the platform, used to paying for service, able to test drive and install the next application in a few clicks)
• Rapid innovation (fast deployment + crowd-sourced ideas from customers = evolution lab for good software. Salesforce claims that this is a key ingredient behind the success of Salesforce.com.)

Now Show Me The Money
OK, so having a multi-tenant platform for free is nice, but how do you make money with it? Ta da, on the AppExchange. Force.com with AppExchange is a similar combo to iPhone with App Store. Both are development platforms that come with an efficient marketplace. Yes, one is mobile and the other a web platform, which might sound like comparing Apples to oranges. But consider this: Many developers (companies, startups) don’t just choose a platform to suit their project; they are increasingly choosing a project to suit a good platform. iPhone app, Facebook app, Force app? In that moment, all platforms compete against each other for the developer. So what does AppExchange offer, compared to App Store?

• Customers: In place of several million consumers, here are 55 000 business customers prepared to try out the product.
• Pricing: Business customers are used to paying for a service, and these ones are accustomed to monthly or yearly service fee (per user). This creates a more sustainable long-term relationship than the essentially pyramid scheme of App Store.
• Distribution: Download and installation is almost as easy as on the AppStore. Trial period is automatically available and Salesforce customers seem happy to try new apps (280 000 trials recorded).
• Business: This does not mean only access to the marketplace. Marketing, customer support, technical support, communication, ongoing development, upgrades, and related business processes are common to all AppExchange suppliers, and the synergy is well supported by Salesforce. By this I don’t mean email support, I mean your own business process tools that come with Force.com. See an example of the depth of the platform here: Managing ideas.

The end result (or rather the starting point) is a prefabricated generic business. It is like coming to a shop and saying ‘Hello, I would like a business, about this size, no colour, please, and I want it with zero deposit. I’ll just pay you a commission if I make some money.’ And Salesforce goes – ‘Yea, here you go. Next please!”
Isn’t this called franchising? I see franchise platforms.

The developer can now start at mile 16, launch fast (fast enough to forget about funding!) and focus on his product. Faster development -> more apps -> more happy customers -> more money -> more developers. More Salesforce, more iPhone. More platforms with business models. And more fractals.

[to be continued]

Small print:
Force.com will not suit every project, and a good start for considering the specifics is to check the documentation and governing limits.
I am not connected to any of the companies mentioned.

Oh yes, what will I write about? I will write about that.