There is no doubt that social networks are on the rise. No Web2.0 site is actually not having their own community. No wonder, is Web2.0 about two things: people (and their relationships) and content.
But there is another phenomenon: Conversations. The authors of Cluetrain Manifesto described it quite well and while Doc Searls and others might not be that eager to talk about it anymore (Doc once said on IRC that he wants to talk about new things such as VRM instead) the topic is still hot and I think more and more companies will go that way and start talking to their customers on a more personal basis again. One means of doing this is blogging. Others are of course forums or even virtual worlds. The main point here is to let customers leave their opinion which means that comments should be enabled because otherwise conversations cannot start.
But all these things taken together also mean that Content Management Systems have to change. I won’t be the one-way communication any longer which it has been for quite a while. It is bidirectional and this means some challenges.
What are example use cases?
One mentioned already are blogs. Another one might be forums. Then depending on the site it might as well be media upload or even live chat/video/audio. If we look into the realm of portable social networks then we will also have things like activity streams, contact management, profile data and so on. All these things should be supported in the future. I will post more on how this might look from overview level later.
CMS vs. CDS
In some systems there has been a distinction between the Content Management System (CMS) and the Content Delivery System (CDS). While the first one is located on the intranet where the whole company can work on new content, the CDS is located in the internet realm and is more or less a dumb system which’s only means is to deliver content (e.g. the CMS can spit out PHP code which then gets copied to a standard LAMP setup). For that it does not need to know about permissions, workflows, member management and so on. Of course this is not completely true as also in the public server of your company you might have some areas which are restricted. But in general a CDS can be much less complicated than the CMS and therefore also faster in execution.
In the world of Plone (the open source CMS of my choice) sometimes there seems to be the answer to use a CDS in front of Plone if the question is about performance but of course this is more easily said than done as there are no really complete solutions to the problem out there. This might actually also be true for most of the other CMS out there. And in fact the mostly used CDS is probably simply Squid.
So in the end it might come down to have a clever caching strategy. This is the more true the more dynamic your website will grow. With social networking components it will certainly be more dynamic. It will also be about how costly it is to create content (unfortunately in Plone it is relatively expensive today due to things like Archetypes, missing addforms and more but there is also work being done in this area to hopefully solve this).
Not only will performance/caching be important but also interoperability. We see a big move into this direction with lots of discussion and some projects moving forward. All this is build on already existing protocols, like:
- Microformats (hCard, hCalendar, XFN and maybe some more).
- FOAF (an RDF format for defining contacts, groups and profile data)
- OpenID (for identity management)
- OAuth (for authorization management)
- XMPP for contact updates
and maybe some more. In Plone we already have OpenID implemented (although maybe it could be enhanced here and there in the course of implementing a social networking layer. But more about this in a future post), Microformats should not be too hard to be done aswell as FOAF. And for OAuth we probably simply need a good plan on how to do it, a Python library is already there (done by Leah Culver). For other CMS it looks similar, libraries are out there for most languages and some have implemented these things already (like Drupal and WordPress have OpenID support, too).
The general challenge here is how to combine these things to make sense and another challenge is which policies for it’s use are needed. As the Soble/Facebook incident showed there is definitely a lot of room for discussion.
In the end it would be great to hook up a CMS to a worldwide social network based on open standards.
The Attention Profile Markup Language might also be one of the key parts of tomorrow’s social networks and thus CMS. It’s intention is to format your attention profile (which links you clicked, which videos you saw and so on) in a standardized way so that it can be read by other tools and applications. One usage for this is the activity stream in which a site can show parts of this data to other users (privacy settings are apparently needed). This also means for a CMS (or a CDS if you implement it that way), that you need a means for recording it without putting a performance bottleneck on your system. Eventually it makes sense to record this with an external tool. Some ideas might be needed here.
You can find a great writeup by Michael Pick here.
For some of the mentioned standards it might make sense to have a way to collect information asynchronously (which means not triggering other http activity when the user clicks a link but instead to do this e.g. with a queue and a cronjob). This might esp. be important for collecting XFN/hCard information after submitting some URLs.
Such a mechanism would not be that easy to implement with Zope/Plone though (at least if you want to use the ZODB) because you cannot easily access the database structure directly as you could e.g. do with SQL bases systems.
If you do social network like stuff you might need to implement some APIs. These days it seems to go the RESTful route which is probably a good route. Of course it depends on what functionality you want to expose and what makes sense but I would say at least OpenSocial support might be important in the future.
One part of the social networking experience in the future will also be virtual worlds. These are on the rise and I expect to see quite some new virtual worlds pop up this year. The leading company, Linden Lab (Second Life), also thinks about opening up their world and make it interoperable by trying to create an open standard in an open way (more coverage on my old SL blog). You only need to think a little step further to know that it would make sense to make this part of your social network, too. With the architecture envisioned by Linden Lab it would indeed make quite a lot of sense because their concept of an agent domain is more or less a social network (with groups, friends, profile information, identity management and so on) only that it also stores assets used for the virtual worlds. But part of these assets, like photos (which become textures) are not so far off from use within a virtual world.
And thus it makes sense to prepare a CMS today for tomorrows use of virtual world which should be a more or less trivial step though if the above mentioned standards are implemented
I definitely want to explore this area further and thus here’s what I want to do:
- Explain the underlying standards better. I started already with an OAuth presentation
- Create a vision for what we actually want to do (or me at least)
- Write down use cases of sample scenarios of what might be possible and how it might look like
- Create a prototype social networking layer for Plone in order to understand problems better
- Then plan further
One project I am trying to get involved with in the future is probably DiSo which stands for Distributed Social Networks and is very much going in the aboce described direction. They are using WordPress as a platform right now but interoperability is planned. They already have some code and lots of discussion going on and participants in that project are good connected which hopefully helps to get these ideas more into the big companies like Google or Yahoo.