Ubiquity, Gorillas and the vServer

My field is Ubiquity – helping people and communities to enable themselves with effective and universally available knowledge, collaboration and online presence.

Ubiquity is a broad field, and one that tends to headline on the functionality and geek-chic of the endpoint devices and the ever-expanding notion of “invisible” technologies – from PDAs and mobile phones, through wearable computers and so on, to smart buildings and intelligent shoelaces.

I consider that holy grail of ‘invisible’ technology to be slightly spurious, finding the concept of ‘casual’ technology to be rather more useful. Here, people are able to extend the utility of the tools they already have available and are comfortable with using, rather than having to continually adopt new technologies and their infrastructures. My focus however is less on the endpoint technologies than on the knowledge architectures, models and processes which give people a reason to use the their technological tools, new or old, to seamlessly integrate their physical and virtual existences. The enabler for this is access to knowledge and association that is timely, contextualised, personalised and relevant to who they are, where they are and what they’re doing.

I’m the architect of a variety of more and less complex collaboration and content delivery systems and applications and regard the whole concept of individual and group empowerment for knowing, for interaction an collaboration as key to the emergence of a truly enabled society – I can bore for England on the subject.

I also work in some rather remote corners of the world. Which is to say that they’re remote only to us “Western” technorati – the people who live there find them usefully local. The remoteness is simply that of external perception, local infrastructure and access to the tools that access, create and present the connecting knowledge that breaks the barriers of medium, geography and culture. This is the true digital divide, where the affluent connected find it easier and cheaper to become more affluent and connected and, in being connected, lose contact with those societies that don’t form part of the infosphere and thereby tend to fall off the edge of our perceptual world. And so it goes. But what if people had that casual access to communication, presentation and collaborative knowledge? What if their voices, achievements, needs and aspirations could be heard, directly and immediately, across the world?

Digital Gorillas

Case in point: I’ve spent a lot of time working to provide information systems to help with Mountain Gorilla conservation in Central Africa. Contextual aside: the last 700 or so of these fabled beasts live on the slopes of the Virunga Mountains, a range of active volcanoes that straddle the border between Uganda, Rwanda and DR Congo. This is a region that is politically, militarily, geologically and ecologically unstable, and the gorillas wisely choose to hang around in one of the remoter areas, for the most part avoiding direct contact with their noisy and numerous neighbours. The greatest single threat to the future of these closest relatives of ours is human encroachment on their habitat, so the focus of the conservation projects are on the development of the human societies of the area, helping both to directly improve the quality and sustainability of local life and helping to turn the gorillas into a positive asset to the region, rather than being perceived as an obstacle to the short-term exploitation of scarce land.

Individual projects, which range from an agricultural college to art training for local orphans, are locally-run, with seed funding coming from individual and corporate donations, and from a variety of government and NGO sources. The shared need is to facilitate and promote the feedback between the field projects and donors, communication and knowledge sharing between the projects themselves and to create a global community of perception about what is being done and being achieved. In traditional models, all such information is mediated through a central management and editorial process, which both kills the directness of communication and engagement and creates an organisational overhead, which isn’t good news for a lean-operating charity in a rather fluid environment.


(I do use the word ‘fluid’ advisedly here – when I arrived in Goma, it was to find the local Resource Centre under about 5m of freshly-cooling lava, along with its computers. Which had all been very diligently backed up to CD, and the CDs then placed in a fire safe. In the same building. Apart from the lesson in off-site backups, there’s some interest there for future archaeologists – a melted iMac under a lava flow…)

So how then to provide the projects with the means to tell their story, be it in the context of formal reporting or in a direct engagement with the wider world? The first step is to look at what technologies and infrastructure are already available across the region and see how we can build on them: although we’ve provided key projects with computers and training in their use, it’s still to a relatively small subset of those involved, although they do provide useful staging and editorial noes for coordination and reporting. Communication is then a problem – landlines are not always reliable for data comms, mobile data services are not well-established or economical and, while the core infrastructures are actually modern and data-capable, it will take considerable time to bring local Telcos through the act-of-faith stage to the point where broadband provision hits the threshold of sustainable uptake.

So it’s time to turn the question around and, rather than see what new technologies we can introduce (with all the attendant issues of supply and support), look at just what is available to people as part of their daily lives. Here, above all, it’s the cellphone: I’m not overstating the case to say that most of the developing world’s economies now run on the cellphone: people using basic voice and SMS services to organise, collaborate, deal and inform. So that’s a good start. Then there are the widespread and well-equipped Internet cafés – in Rwanda and Congo, these tend to be satellite-linked to the wider Net, and provide a generally good and reliable service. So here’s the emerging model: individuals on projects already use SMS and voice to communicate directly with each other, albeit without being able to store that knowledge or share it more widely. By casually adding that persistence and public or private sharing of the information we immediately take a huge step forward in the ability of these projects to tell their stories to each other and to the world at large. The internet Cafes and the specific ICT equipment that we’ve put in place then provide access to external feedback, to e-mail and to the creation of an editorial and feedback process. After that, it’s a question of providing a platform that enables all of this. Which is where the vServer comes in.

Jigsaws and Standards

And if by now you’re thinking that this sounds like an ideal application of blogging and moblogging and their attendant zeitgeist, you’re exactly right, and that’s the genesis of the vServer platform, the system that runs this web site. At it’s simplest, the vServer is a blogging and content publishing platform that is specifically configured to support publishing and feedback by nearly any technological means – you can publish by email, SMS, voice or even fax, and from any device you care to carry – mobile phones, PDAs or computers. And pick the buzzword of choice and it’s supported: moblogging, voblogging, podcasting and any combination thereof.

It starts with a basic set of principles, themselves driven by the frustration of seeing organisations struggle with the cost, complexity and functional railroading of proprietary knowledge systems and of delivery mechanisms that are assumptive, and thus exclusive, in their presentation for particular browsers and/or devices.

  • The system must put control over content and update in the hands of its users.
  • The system should be simple and ‘casual’ in use, working with whatever means of communication people have and are familiar with using and with their preferred way of working.
  • Each core element and the underlying OS should be supported by the widest possibility community of expertise.
  • Delivery and presentation should be to open standards.
  • Any core element should be based on either Open Source or open architecture tools, source and knowledge.

After that, there are two alternatives: the all-in-one package and the modular, ‘best-of-breed’ approach. Both have their advantages, and there are many applications where I’ll cheerfully recommend products like Zope/Plone or WebCrossing, but for the maximum degree of flexibility, integration with existing infrastructure and distributed support, we went for the modular option, tying together more or less tightly (at need) a range of function-specific products, any or all of which can be substituted at need.

Moving on a level, it’s a modular architecture based on open standards and a combination of ‘best-of-breed’ open source and open architecture packages, designed to be rapidly, flexibly and reliably deployable. At it’s broadest, most arm-waving level of conceptualisation, it can work as a platform for casual collaboration and sharing, applicable to the creation of any virtual or hybrid knowledge space, particularly those where that casual integration with the way people already work is essential.

What you see in the diagram above is the complementary jigsaw of products which comprise the vServer, any or all of which can be combined to enhance and extend an organisation’s existing ICT infrastructure to effectively integrate with existing systems and expertise, without repetition, hesitation or deviation – if there’s a standard around, we’ll probably be able to work with it. For more on the technology and standards behind the jigsaw, you’re then invited to carry on with some of the more technical documentation over here…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.