Last week I was asked (at very short notice) to come up with a presentation on what a social networking operating system would be. This is in part why I felt it was necessary to spend time on social network modalities. In the end the presentation wasn’t formalised (or constrained) by being put into a document, so this blog post is the first written record (assuming that my white board scribblings were consigned to the bin shortly after the workshop ended).
The thesis is fairly simple. Over time we’ve seen operating systems develop to provide sets of basic functions and services so that applications don’t have to do this themselves. This achieves a number of key things:
- Applications can be simpler, because the operating system does the ‘heavy lifting’ for them.
- Applications can work together, because there are common interfaces provided by the operating system.
This makes me think that we’re still in some sort of pre-history with social networking applications, as since they aren’t built on a common operating system they necessarily have to provide their own essential functions and services, and these typically don’t work well together.
So what does a social networking operating system let me do? I think it’s like this – it will let you join together functional aspects from social networking applications, and do this in the context of the user. An example might be the feedback mechanism for directed social bookmarking. Lets suppose that the user wishes to provide feedback via microblog @name posts. Without a social network OS that user is forced to switch contexts from their RSS aggregator (where the social bookmark is consumed) to their microblogging application (where they can make the feedback post). Not only do they need to switch applications, but they might also have to deal with context mismatches between namespaces etc. With a social networking OS the user would be able to press a button to make that response in context – the reply by microblog post (or whatever else they wanted to do) would become a feature of the RSS aggregator.
More broadly a social networking OS allows a user to consume social web applications (in the context of their choice) and connect to other social web applications in the modality of their choice (and without having to change context).
This example makes me think that the social networking OS would therefore be a very client centric rather than server centric technology, as the user context is on the client. I therefore think that the environment for such an OS is almost certainly the browser, which means that the preferred language is almost certainly JavaScript. This would give us the following evolution:
- Internet
- Paradigm – distributed machines
- OS – Unix
- Language – C
- Protocol – TCP/IP
- Web
- Paradigm – application server
- OS – J2EE
- Language – Java
- Protocol – HTTP
- Social web
- Paradigm – social network
- OS – something in the browser?
- Language – JavaScript
- Protocol – stuff based on HTTP, but not really HTTP itself (could be replaced by AMQP?)
I suspect that the example I illustrate above could be pulled off with some ninja GreaseMonkey scripting, but that doesn’t mean that I see GreaseMonkey as the heart of a social networking OS.
It would be remiss of me to close without a hat tip to OpenSocial, which seems to have been an effort to create something like a social networking OS. I remain curious about what’s become of it? I’d also love to hear from any OpenSocial guru who can explain how it might be used to achieve the use case outlined above?
Pinboard.in bookmarks
Chris Swan's Weblog 
I’d make the case that the protocol of the social web is a settled issue. It’s XMPP. Twitter continues to use it for heavy duty repackagers of Twitter flow. Facebook has announced it will use an XMPP based solution to further link its users. Open Social is promoted by XMPP oriented Google. XMPP supports pub/sub.
Have a look at http://www.readwriteweb.com/archives/browzmi_new_firefox_extension.php
for another example of XMPP as the Social web glue.
What’s your take on “hyperlocalism” and sites like outside.in?
Joe, it’s interesting that you bring up XMPP as I ended up having a chat with an analyst yesterday about the pros and cons of XMPP vs AMQP. I think my own leaning is towards AMQP as it can do everything that XMPP does and more, though clearly XMPP is more mature, and already accepted (through the firewall) in many places. Of course you can have your cake and eat it with some AMQP-XMPP federation (e.g. https://dev.rabbitmq.com/wiki/RabbiterFederation)
Browzmi looks quite interesting. In some ways it confirms my sentiment that the browser is where the real social networking action is at. Unfortunately it’s an application rather than an OS. I guess doing an application with the functionality of Browzmi on a social network OS (SNOS) would be pretty trivial.
Hyperlocalism probably deserves a separate conversation. In some ways this reminds me of Gelertner’s ‘Mirror Worlds’ work, whilst in other ways it seems incongruent in the context of increasing virtualisation of our online persona (along the line’s of Cory Doctorow’s ‘Eastern Standard Tribe’). In some other work that I’ve been doing location as an identity attribute (and potentially an authentication/authorisation component) is becoming increasingly important; this is probably the key to broader adoption of hyperlocalism (which kind of assumes a meatspace [or should that be meetspace?] rather than virtual audience).
Does the concept of an OS make sense in the context of a social network?
It’s such a low-level concept compared to the human activities involved.
It’s interesting that the activities that have been most formalised (semantic web?) seem to attract a much smaller audience than those that have grown ad-hoc, in response to human demands (twitter? facebook?).
At this stage in the development of social networks, the focus should probably be more on the human factors, but that’s just the opinion of a jaundiced, cynical, pre-digital old fart :)
On-topic, I think that we will probably end up with a grab-bag of some very familiar old protocols, along with some like XMPP that have been adapted from other uses, and those such as AMQP that represent a new attempt at levelling the playing field. However, I am much more interested in what will pass for an API in the social space, rather than what goes on the wire. How do we represent the connexions and their value, rather than how do we ship the bits and bytes over the ether? Worrying about the OS for a social network is probably even less useful than worrying about the OS underlying a Javascript routine.
-hagrant
Hugh,
Sorry for the slow reply. JP’s post on ‘musing about the customer perspective’ at http://confusedofcalcutta.com/2008/12/29/musing-about-the-customer-perspective brought my attention back to this subject.
The point is that some low level plumbing stuff does need to be in place that will let users mash their stuff in their context. It looks like the existing social network platforms won’t do this for us, because they’re behaving like vendors (and taking the CRM view) – trying to lock us into their platforms. We need something that supports the inversion (to a VRM perspective) – that’s properly user/customer centric.
One of the key points here is that it’s only in the eyes of the user that a particular identity (or persona) comes together. For reasons as simple as name space collisions we all call ourselves different things on different services, so it’s only in our own aggregator that we have all of the pieces (or at least all of the authentication cookies).
May I offer the name snopsys if a social networking operating system comes into being?
I too arrived here via @jobsworth / JP Rangaswami
And, by the way, it makes a lot of sense. Is Adriana Lukas part of this conversation?
Thanks David, snopsys certainly sounds better than the geeky SNOS that I’d been using so far.
Hopefully a vanity search subscription will bring Adriana along shortly. The pointer to her stuff quickly led me to http://themineproject.org/, which looks like a good attempt to by a ‘snopsys’, though clearly it’s still early days.
Hey, Chris,
While I appreciate that you’re trying to promote something that would be useful, you’re really not talking about an Operating System. An OS is there to manage hardware resources and potentially provide a primary interface to the user. What you’re talking about is services to be consumed to make doing social applications easier.
http://kirkwylie.blogspot.com/2008/12/snos-quit-angering-andrew-tanenbaum.html
Thanks a lot,
Kirk
Thanks Kirk,
I realised from the outset that the operating system label was likely to cause offense. To be honest I don’t like it myself, and it wasn’t even my label as it came up in a workshop with one of our research partners (I won’t call out the guilty party by name). I used it anyway as I haven’t yet thought of a better label for ‘something in the browser’ that lets you do all this user side social network combination stuff.
Perhaps if we can agree to David’s ‘snopsys’ (even if it does have the broken term operating system buried in there) then we can move on from the symantics (which are always important in these early days) and on to a richer discussion on how this might be made to work (and who will write it)?
Alexis Richardson in a meatspace conversation today hit on an excellent name for this type of thing: Application Execution Environment. Hits on all of the points in your evolutionary discussion perfectly (UNIX, J2EE, and “Something In The Browser” all point to Application Execution Environment to me).
For those of us drilled into a rigorous CS background every time we see “Operating System” used wrongly (see: Cloud OS, Google OS, Social Network OS) we cringe. :-)
Alexis knows a lot about the background to this, as we’ve been talking for some months about the underlying issues before I got around to the blog post.
Once again I agree that OS is a clumsy term. I’m not however that convinced by application execution environment in this context, as it stretches my own interpretation of what an ‘application’ is.
My sense of what this would look like if it ever works properly is some point and click plumbing stuff over the top of some pretty fugly scripting. Clearly the average user won’t be creating their own social applications (= writing fugly scripts), they’ll be specifying how they want things to be joined together and configuring what’s important and what’s not (JP’s ‘graphic equaliser’). For that to happen firstly needs some standards for the interfaces, so that one piece of equivalent functionality can be swapped for another. I doubt that the existing service providers will be that inclined to break down the walls around their gardens, so somebody else will probably have to get involved in wrapping and mashing.
This is all starting to remind me of the enterprise service bus concept (not that I’ve ever really seen it work properly), though clearly stuff like OpenAdaptor was useful and successful.
The term I prefer is ‘micro-integration’ because we are talking about correlating streams of microcontent – eg. a blog comment, a tweet, a tag, an annotation to a document. An internet of ‘things about things’. As with normal integration the main operations are: route, transform and filter. Chris is right to mention ESB as involving the same aysnchronous integration patterns (see also Gregor Hohpe’s book).
In this context, ‘social’ means sharing updates on ‘social objects’ by multicast pubsub filtered by roster; now fashionably called ‘assymetric follow’. This is just messaging – so why not seek to reapply successful integration patterns from enterprise messaging, to social applications.
I think it is useful to then ask:
* what social utilities or shared services would enable the messaging for micro-integration between social applications – eg. relays, firehose services, stream query services …
* what standards are needed? http, xmpp, amqp, app, …
* what microcontent adaptors are needed at the endpoints and for transformations
* what is the pingback model (if any) and/or push pubsub model, for defining updates on web content, and subscriptions to ad hoc microcontent feeds
To address the problem Chris describes in his post above, all this needs to allow for (but not mandate) consumer driven feed creation (“tell me about updates to this microcontent given by this URI that only I care about”).
Oh – PS – it is really important that whatever technology is used for micro-integration, to achieve genuine social integration it has to be decentralised and not require submission to a single authority. This is why things like browzmi, friendfeed, gnip and twitter are intermediate solutions, however cool or useful they may otherwise be. Federated social networks have to be *federated*. XMPP is great for this because it has a workable model for federated identity, independent of physical addressing.
I’d pipe in here that perhaps another reason why XMPP has started to work here is because people have spent time working on the content problem (which is one of the things that kills ESBs in their Consultant-Driven form): in order to consume, you have to be able to consume everything that’s coming out; publishers all though seem to want to publish in their own form.
You very quickly get into the MxN problem: M consumer applications, N publishers. Each of them decides “I’m the best at modelling this problem for my particular domain” and does their data modelling, and then you end up with a whole bunch of individual point connections and some really REALLY fugly glue to get similar consumption.
You really need some people to sit down and hammer out what the content of these messages (no matter how they’re delivered) are going to look, and that’s pretty hard, because every system is slightly different. Some people have started to do a reasonable job at this, but I’d say that’s as big a problem as any of the technical challenges of getting the messages from A to B: getting general agreement on what precisely is supposed to go into them in the first place.
Also, Chris, are you imagining something like Yahoo Pipes writ large?