The Facebook social graph is just the tip of the iceberg

There has been a lot of well deserved talk recently about the Facebook social graph. The social graph is very important because it helps establish the relationships between people and now between people and the world around them.

But the concept of the graph is much more important that the framework that Facebook has established. The concept of the graph is important because of what I call context. What we, as humans, really want is to be able to contextualize everything in our world. We define people by who they know, what they do, what they like, etc. But this concept of contexualizing goes much further. Every fact and every piece of information has a context.

Context is really nothing more than everything we know or can know about any given “thing” in the world. And any “thing” in the world can have a relationship to anything else. If you have a glass sitting on a table then the relationship between the glass and the table is “sitting on”. But they might also be related to a common person with the relationship “purchased by”.

If you think about our world, every object has an almost infinite amount of context, so if we went overboard with this it could quickly become uselessly broad. But there is an important middle ground here. It is critically important that we as individuals be able to capture the context that *we think* is important, and it is critically important that we be able to browse the context that those close to us think is important.

For example I may want to capture that a given person has a “married to” relationship to someone. For others that may or not be important. But I should be able to capture that. Its also important that I be able to explore all of the relationship that can be captured through the everyday software I use. Obviously lots of interesting relationships can be captured from email, calendars, documents, and I want to see *all* of those relationships when I need to.

The key to having useful context is being able to access it when you need it. For example, shouldnt you be able to see, whenever you look at a contact in your address book, all the emails you have received from that person, and when you have them in your calendar. For context, user interface is clearly is as important as storage and protocols.

Now its true that there are products that do small pieces of this for you like perhaps Xobni, or Gist. But my point is a larger one. What we really want is a system that provides context for *all* of the information objects that matter to us. This is not a niche problem. Existing tools are purpose built. They are finished recipes when what we really need are ingredients. I don't want any guard rails preventing me from capturing information and creating relationship between objects.

The point in all of this is that what we are constantly looking for is context. The social graph is just one relatively narrow facility for providing us that context. Part of the reason I am excited about this discussion around graphs and the emergence of graph databases is that I think we really need a universal platform for storing context. Facebook is but one use case of what is clearly a *much* larger opportunity.

Do graph databases have a special connection to Christ?

Because my company is based around and develops graph database technology, I track the term #graphdb on Twitter. My primary Twitter client is TweetDeck. But I found an interesting anomaly. It appears, on TweetDeck, when I search for the #graphdb hashtag, what I get, along with actual graphdb references, are references to, well, Christ.

I am not sure if there is any deeper meaning to this. But for someone who is in the graph database business, I can't decide whether I should be inspired... or something else.

In any case, here's a look.

Open Letter To Twitter. My suggestion for how to Kick-Ass (Facebook ass that is)

Twitter needs to get in touch with its inner Kool Moe Dee.

Dear Team Twitter,


Last week at Facebook’s f8 developers conference, Facebook got a lot of attention for launching the ability to mark anything on the Web as something that you like, creating a kind of Facebook owned overlay on top of the entire Web. They have taken a lot of heat about this because the perception is that this new system will allow Facebook to create a massive database of knowledge about essentially every Internet user, that is only accessible to Facebook. This idea scares people, as I think it should.

The week before last, at your own Chirp developers conference, you announced the idea of “annotations”, whereby additional pieces of data can be attached to a tweet outside the 140 character limit. Unlike Facebook’s announcement, the annotations concept was not received with as much excitement or fanfare because without specific supported annotations, it's not clear to people yet how useful the feature will actually be.

In light of Facebook’s announcement, What I suggest is that you put some meat on them annotation bones and quick. Specifically, I think you should create a “like” annotation. The way it would work is simple. A “like” would just indicate that you “liked” whatever URL was in the body of the tweet.

A Twitter “like” annotation would allow people to indicate that they liked a particular page just as Facebook’s system does. Any developer, using the Twitter API or firehose, could then leverage publicly accessible “likes”. Because many sites will mark up their pages with Facebook's new Open Graph Protocol for describing what restaurant, or person, or place, or event the page is about, it will be easy to tabulate and analyze what “likes” mean. So if, for example, a page is marked as being a restaurant, analytics software that analyzes the Twitter data space would know who liked that restaurant, and in fact that it is a restaurant. This would have the effect of making Twitter’s data infinitely more valuable, while not being viewed by the commentariat as being a "closed" system.

As you know, the reason this “like” thing is such a big deal is because the Holy Grail on the Internet is helping people buy stuff (or helping marketers sell stuff to people) by knowing as much about a given consumer’s likes and interests as possible. This would make the act of targeting ad-based “promoted tweets” much more effective. But you would also be empowering the marketplace as a whole. Imagine if any site that wanted to provide personalization information could ask a visitor for her Twitter address and then instantly customize the experience based on the indicated likes and dislikes in her history.

More interestingly, Twitter could also support other types of annotations. Perhaps “agree” and “disagree” annotations. Perhaps “just visited”, for supporting a kind of checkin ability. I am sure all kinds of sentiments and adjectives could be applied to URLs.

In fact, specialized apps or websites could provide interfaces for providing vertical-market-specific sentiments. This would allow the creation of tools for “liking” everything from vacation spots, to clothing, to consumer electronics, and on and on. A Twitter based liking system would be a much more open eco-system for allowing people to express and share leverageable opinions. Apps like Seesmic and TweetDeck could get much more interesting. It could also provide interesting opportunities for a company like bit.ly that is already in the URL analytics business albeit currently working a different angle.

The beauty of this plan is that you could probably implement this in a few days of work. Overnight it could blunt Facebook's potentially over aggressive plans, and cast you as the good guys. In the last week you have been portrayed in the press as being a day late and a dollar short when being compared to Facebook. Chirp was described by many as boring while the announcements at f8 were generally characterized, though fearfully, as game changing.

This is your opportunity to reverse that meme. It is your Kool Moe Dee moment. Its an opportunity, in the face of some believing you to be not fully up to the competition, to engage in a bit of strategic haiku, to pop your collar, and to ask the question, "How ya like me now?"

I fear facebook owning my relationships, not my identity

There has been a lot of talk by Dave Winer and others about the idea that with the f8 Facebook release that Facebook wants to own my identity on the web.

In thinking about this overnight, I realized that Facebook, with its latest release has actually clarified to me that they no longer want to own my identity. They have essentially gotten rid of all of the restrictions on how I import and export the data about me from Facebook. There are no more rules that say I can't, for example, export my pictures or other data to another application.

The one thing that the rules still prohibit me from doing is moving my friend list to another application. Essentially, they own my address book.

What I realized about this is that this is a much bigger deal. I really don't care that much if they keep my pictures. But by encouraging me to build up my social network in Facebook, and then saying I can't export it, they are really positioning Facebook as the unbreakable center of my online universe. If they succeed in making me use Facebook for real productive uses, as is signaled by their Microsoft Docs partnership, then I will really be locked into them. Then I have to think, can I trust them. Will they be evil in a Googley "don't be evil" sort of way? They haven't made any such pledge, and even if they had, Mark Zuckerberg just doesn't feel like the touchy feely do-gooder type.

In a certain sense, this is not news. They have always wanted to own my relationships. But by eliminating all of the other restrictions, and by making Facebook much more broadly useful, they have brought this issue into full relief, and made clear what they really think is important. And I, for one, am quite worried about fully turning over my relationships to them.

Unfortunately, as a developer I am not sure I have much choice but to support it. In fact, I am quite sure we will support it. And that fact, and the fact that most of us in the developer community will do so for our own selfish, short term reasons, may be our collective undoing.

Google Docs vs MS Docs. Wondering why Google Docs still sucks?

Presumably one of the most important initiatives at Google outside of search has got to be Google Docs. Having a platform for people to create and edit documents on the web has to have been seen as a critical feature. Why then, has Google Docs sucked so badly for so long? It really has borne no resemblance to a real word processor since inception. Yes, its had sharing, its lone competitive advantage. And yes that sharing has recently gotten better with its live multi-person editing that almost no one needs. But fundamentally Google Docs just sucks.

Where are style sheets, outline structure, type handling, etc. Yes they have supposedly added a bunch of stuff with a supposed new HTML5 based version. But it isn't live yet. At least not for me. And even what they announced, from what I remember, is not enough.

Yes, I am comparing Google Docs to Microsoft Word. But why not. That is what everyone else who uses Word or its similar competitor in Open Office does. It seems fair to me.

One of the often trotted out arguments about disruptive technologies is that they often start out looking like toys, but they serve some constituency really well, and they grow into something serious while no one is watching. As the argument goes, that is what is happening with Google Docs.

But with the launch of the new version of Facebook and Microsoft's near launch of its own "Docs" platform, I think its over for Google Docs. Presumably Microsoft Docs, tied into Facebook's social network, will have great sharing. And clearly Microsoft will have better editing features.

Google Docs started out as a toy and never graduated. And in taking so long to make it good, they have apparently given Microsoft all of the time it needed to catch up to Google, and it would seem, to lap it. The idea, as it has been explained, has been that Google Docs would be sold into the corporate environment. But at this point that seems like a ludicrous notion. I guess Google could just give Docs away, and at least try to hurt Microsoft by applying price pressure. But Google's efforts with Docs seems like such a competitive joke that I am not even sure free will be enough to make even a mildly noticeable impact.

Lesson learned: You snooze you lose.

Apple Outlaws All Animation Tools

It just occurred to me that if you are an artist who wants to make animation for the iPhone, Apple's new rules mean you can't. Not only is Flash, the best frame-by-frame animation creation tool out there, made illegal, but so is any other tool, past or future, that is designed for this purpose.

Is this getting crazy or what?

So now Steve has this new iAds platform. How does he expect artists and designers to create content. Perhaps art school graduates all now need course work in Objective-C?

Twitter isn't a platform. Yet.

A platform is traditionally considered to be something on top of which you can build other applications. Last week Fred Wilson lamented that people really aren't making new applications on top of Twitter. There’s been a bit of uproar over Fred’s post, and then Twitter's aquisition of Tweetie including an article in today's New York Times and last week in Business Insider.

But being upset over Twitter’s desire to control more of the Twitter ecosystem misses the point a bit. The reason that, after several years and tens of millions of registered users that people are not building new app categories on top of twitter is that Twitter is not really a platform.

Let me explain.

Fred correctly pointed out most of the apps that people are making are not new apps. What you do with the current generation of twitter apps is essentially what you could always do with Twitter which is to share bite size bits of content with others that are interested.

The key question is whether Twitter is plumbing, like a new kind of communications protocol like TCP/IP, or whether it is really an application like instant messaging. The talk about building new classes of applications on top of Twitter would suggest it is the former, when it is really the latter.

Twitter is an app.

Twitter is not a protocol, and it is not really suitable for building new classes of apps. This is plainly obvious in that with all of the developers out there, someone would have done *something* fundamentally new if they could have. It's not a coincidence that all of the apps out there are, as Fred describes "hole fillers."

In order for apps built on top of Twitter to really do substantively new things, they need to work with Twitter as a *protocol* where Twitter is carrying app specific payloads. This, of course, is problematic when a user's followers start seeing data that is not human readable, or not intended to be read outside of the context of a particular application.

The bottom line is that for Twitter to be a platform, applications must create payloads that are designed to be read only in that new application's ecosystem. But if that became popular it would ruin the experience for people using Twitter in it's traditional context. No one wants an unreadable stream of bytes in their Twitter stream.

Of course this problem could be fixed by adding what I will call "protocol channels". Protocol channels would be designed to carry application-to-application traffic. Only applications subscribed to a users protocol channel could see traffic on it. If Twitter had something like protocol channels, all kinds of applications could be created that would leverage the viral nature of Twitter and a users existing social network.

The potential applications for this type of channel are boundless. Everything from bingo games to Google Wave type applications would be possible. It would be a way to allow wide scale apps that would otherwise require sophisticated server software. And it would allow apps to be freely built across a user's existing social network.

Of course there is the question of how to monetize such in this model. It could be free, but I think it would be reasonable to charge developers for access. Such a channel might also provide an opportunity to provide an optional advertising system.

The bottom line is that if Twitter really wants developers to get creative with the tools, they have to get a little more creative with the platform. Once they do, I think there is an opportunity to make an ecosystem that, because of it's openness, could be far larger and more interesting than Facebook's much more restricted universe.

Honestly, up until now, I have not really been that excited about Twitter. But if they really opened up in this kind of way, I would see Twitter as a game changer. Twitter's developer conference, Chirp, is coming up this week, and it would be great to hear that Twitter has been thinking along these lines.

Apple Uses App Store to Enforce Non-Existent Trademark

Apple seems to be on a roll here.

This morning I read that apple is rejecting apps that have the word "pad" in them.

Clearly Apple does not own the trademark on the word "pad", certainly not as part of another word whether a real word like "notepad" or as a made up word like "contactPad", which is the name of the app they rejected. So their backdoor strategy is to use the App Store rejection process as a tool for enforcing non-existent trademark rights. This seems to me to be another blatant example of restraint of trade, similar to what I discuss about their new rules requiring apps to be written in C.

Amusingly, many years ago I ran a company that made a PIM for the Mac called DayMaker. When the Newton MessagePad came out, we were working on a contact manager, which we never ended up launching, called ContactPad. Apple was going to distribute the software, and had no problem with the "pad" in the name. But obviously times have changed.

Jobs Bans Non C Libraries. Insane Restraint of Trade

Last night I wrote about Steve Jobs insane 3.3.1 section in the new iPhone developers license which Jon Gruber discovered here, and I just want to clarify something.

People are writing that this is a ban on Flash, and cross platform tools. It is, but that is not what I am concerned about.

3.3.1 not only bans cross platform *tools*, it bans *everything* that is written in other languages and are ported to C. This, obviously, includes libraries.

By defining the rule as being about what language something is "originally" written in, we now must be supposedly concerned about the *provenance* of our code, and not just what it does. If a math library, or a physics engine, or a string package, or whatever, was *originally* written in some other language, and ported, then it violates this rule. This concept of what language something is written in is an insidious concept and strikes at the core of product development and of computer science in general. Everything is built on other stuff, the language provenance of which is often unclear. This language is fundamentally unreasonable, and un-enforceable.

Trying to control where something is originally done is attempting to control the thought process that yields a given result. Because if you thought of it in Java, and wrote it in java, and then, whether by hand or by tool, converted it to C, you are now outside the bounds of 3.3.1.

Some may say my interpretation is too pedantic. But the point is that in order for Apple to limit people in the way that they want to, i.e. to prevent the use of a given tool, they are inflicting collateral damage. I do not think there is a way to achieve their goal without such ridiculous restrictions. I have not done my legal homework here, but this seems to be a clear example of restraint of trade, a basic tenet of contract law.

I have no question that this will be tested in court. I don't think there has ever been a case like this because only Apple could make such a ridiculous attempt to control how developers work. But what is interesting here is that allowing this provision to go to trial may put the entire App Store concept under a legal microscope. Because it seems to me there is a reasonable risk that not only is 3.3.1 restraint of trade, but that the entire "you can only sell apps on iPhones and iPod touches that we approve" thing is found to be restraint of trade. Wouldn't that be tasty. Adobe, and/or class action lawyers start your engines!

Steve Jobs Has Just Gone Mad

Today Apple announced a version 4 their iPhone OS. It seems to answer most of the open issues relating to the platform. All sounded good.

But then, John Gruber over at Daring Fireball discovered a "hidden gem" in the new developer terms.

here they are:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

I am sure most of you know that Apple is trying to kill Adobe's Flash, so I won't go into that here. But the point of this rule is clearly to prevent Adobe from selling their new Flash development tool that compiles Flash apps into native code for the iPhone. What Apple is saying here is that the only tool you can use to write iPhone apps is theirs. This, it seems to me, is bad enough. I don't believe I have ever seen any company prescribe what tools you could use to compile on their hardware. But what Apple is saying here is even worse than that.

The key is where they say "Applications must be originally written in Objective-C, C, C++."

Take a pause and think about what that "originally" really means.

Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not "originally" written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is *INSANE*.

Steve does not want to allow Adobe's tools to be able to generate compiled code for the iPhone. But with this additional twist he doesn't even want Adobe to be able to generate objective-C which is then compiled by *Apple's* tools. The ridiculousness of specifying the manner in which one writes their code is hard to overstate.

My point is simple. It is perhaps reasonable to specify the nature of the programs that can be sold in the AppStore. It is not reasonable to specify how developers create those programs so long as the end result meets the specified end result criteria.

If you need to "originally" write your code in Swahili, while listening to Milli Vanilli, while reclining in a patch of mud, and then you need fifty oompa loompas to translate the Swahili into C, that is none of Steve Jobs fucking business. And the idea, which I am sure is actually the plan, that he will inspect application code to figure out what the "original" language is that the code was written in is just plain pathological.