The OpenSocial API

OpenSocial is a standard API for applications in social networking platforms. It is sponsored by Google. The API exists to make applications portable between different social networks. On January 22 Patrick Chanezon, OpenSocial Evangelist at Google spoke to the SDForum Web Services SIG on the topic "OpenSocial Update: On the Slope of Enlightenment".

Social Networks have been a big part of Web 2.0 and thousands of them have sprung up. In the future Social Networks could become like wikis where businesses and organizations set up social networks to allow their employees and members to communicate with one another so there is the potential for millions of social networks. A standard API makes a social network that support the API more valuable because applications can be easily ported to it.

When first announced, there was great expectations for OpenSocial. Unfortunately, many people assumed that it was either an API for communicating between different social networks or an API for porting members data between social networks. OpenSocial is neither of these things. Social networks regard their member data as their crown jewels so allowing for data portability or interaction between networks is something that would not be welcomed easily. As Patrick explained, to get the API out quickly, it had to be something uncontroversial and as all social networks want applications, it is easy to draw them around a common API.

Because of the great expectation OpenSocial went through the hype cycle quickly. In a few weeks it hit the Peak of Inflated Expectations and then just as quickly descended into the Trough of Disillusionment. Now Patrick claims that they are on the Slope of Enlightenment and firmly headed towards the Plateau of Productivity. All this on an API that has reached version 0.6.

APIs are difficult to judge, but this one seems kinda nebulous. There are three parts to the OpenSocial API. The first part is configuration where the application can find out about its environment, the main issue seems to be coming to agreement on the names for common things in social networks. The second part of the API is a container for persisting the applications own data. Finally the API has features for handling event streams that seem to be a common feature of social networks. Ho-hum.

Some other interesting tit-bits came out of the talk. Security is a big issue with JavaScript and browsers. As I wrote previously, the Facebook approach is to have their APIs use their own language which is easy to sanitize. The response from the rest of the world seems to be an Open Source project that filters JavaScript programs to effectively sandbox them. Unfortunately, I was not quick enough to record the name of the project.

Music Business Models

So little time and so many things to write about. My February copy of Wired arrived before I had time to remark on the article in the January edition by Davis Byrne of Talking Heads on "The Fall and Rise of Music". In the article, Byrne describes 6 different business models for musicians in the new world on digital music. They range from the sell your soul to the record company at one end of the spectrum through to eschew any other organization so that you can create sell and distribute your music yourself. Moreover, Byrne gave examples of musicians who are using each of the business models to show that they are valid models that are used.

From his experience of record deals with big record companies, Byrne advises any young artist to avoid selling your soul to the man, or even taking the the standard record company deal where they just own everything that you do. Surprisingly, there many who hold the opposite position. In December Tech Crunch published their list of the 20 most popular posts of 2007. One of them was by Michael Arrington on "The Inevitable March of Recorded Music Towards Free". It is interesting to read the comments in response, particularly the many comments from people who live to sell their soul to the big record companies and their anger that the big record companies are becoming not so big.

I have laid out my opinion on the future of music in several previous posts. It is great to see Byrne explain the alternatives in such a dispassionate way. It is also great to know that there are forward looking people who are building next generation music businesses, for example RCRD LBL.

Tao of Software Engineering

Scott Rosenberg's latest book "Dreaming in Code" contains a very readable history of Software Engineering. I will review the book in another post. Here, I want to talk about a couple of papers that are not mentioned in Scott Rosenberg's history that are parts of my Tao of Software Engineering.

The first is Melvin Conway's paper from 1968 called "How do Committees Invent". Fred Brooks references the paper in "The Mythical Man Month" and gave it the name "Conway's Law", however, only recently that my good friend Roger Shepherd pointed me to the original. The thesis of the paper is: "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."

While Conway's paper gives examples from several different branches of engineering, it is more applicable to Software Engineering which is the most plastic of the engineering arts. After all, a building has to have a floor, walls and a roof; a semiconductor chip is laid out on a flat surface; most mechanical devices start with a rotary power source and after that it is a question of packaging. On the other hand, software can take on any structure so it is absolutely natural that it should take of the structure of the organization producing it, whatever unsightly skew the organization may place on the software's structure.

It is not only the structure of the organization that influences a software architecture, it is the way the project is put together. For example, I have recently been working on a software project that started as a GUI demonstration. Because the GUI came first, it defined the client-server API and the data structures that passed through the API which then defined the database storage structure. We recently had to make significant changes to the API and data structures which has been extremely painful at such a late stage in the project.

This brings me to the second paper, Butler Lampson's "Hints for Computer System Design" from 1983. Like Conway's paper, it is not a difficult read. The paper is a collection of simple aphorisms on computer system design and examples to back up those aphorisms. While the aphorisms are still relevant to this day, some of the examples are creaky. For example, who remembers PL/1 or the SDS 940?

I reread this paper every few years and compare with my recent experience to see what I have done right and what could be done better next time. For example, one aphorism is "Keep basic interfaces stable". Several years ago, my very first act in a project to add a significant new feature to a large system was to go through the entire code base and change some basic APIs for the new feature. In my most recent project we have gone through months of pain because we decided to change the API just as the project was coming together.

DRM Discordance

Read this article from someone who bought a new high definition monitor for their Windows Vista Media Center PC and found out that they could no longer use the Netflix Watch Now streaming video facility. In the past I have argued that if we have to put up with DRM, it is better system engineering to put the DRM decoding in a separate box rather than try to bundle it into a general purpose PC as Microsoft is trying to do with Windows Vista Media Center.

By coincidence the article appears on the same day that Netflix and LG announced their partnership to integrate Netflix Watch Now streaming video into a future LG device. The TechCrunch take on the Netflix set top box is that it will be a hard sell, but if the alternative is the flaky behavior that we see in Microsoft Vista, maybe the masses will buy the box.

42

We know that 42 is the answer to the question, you know about life, the Universe and everything. Also, 42 is the number of posts that I have made in this blog in each of the last 3 years. I have always intended to write more posts, there are many subjects that I want to write about, but for one reason or another, they never get written or never get finished.

This year I did manage to write some more as I started the Developer Notebook blog to cover specific technical programming topics. The Developer Notebook also has less posts than intended. I have several posts in my head that are just waiting for me to find the time and energy to write them down. We will try to do better in 2008.

So as they say in my birthplace "Awrra best furra New Year".