Ecosystems and social software

Why do I get hung up about platform independence and vendor-neutral strategies, about avoiding layers of lock-in?

Not because it’s cool, I’m too old for that. Cool is not a word to use when you’re fighting to hold on to your teeth and your hair. My children blench every time I use the word.

Not because it’s easy to follow such a path, it isn’t. There’s a need to accept delayed gratification and for emotional intelligence a la Goleman.

Not because it’s faster than any other (it isn’t). Snake oil is always easier to buy than to make.

But because we pay too high a price any other way. The price is freedom. Freedom of movement, freedom to share, the ability to manoeuvre, to adapt, to adjust to unknown futures.

I tend to think that people who buy vendor-locked-in products are buying trains on tracks while thinking they’re buying cars. They don’t see the tracks. They don’t see the problems with manoeuvring. They don’t realise the track is there until they try to move off it. By which time it’s too late.

The guy who owns the tracks decides where the train goes. You, as train driver and crew and passenger, can only decide to stay in one place or go where the track takes you. And sometimes you can’t even elect to stay, you’re in the way.

I am of the opinion that social software can never come from a single vendor. Cannot be allowed to. Otherwise all we do is put off the next battle for breaking up Bells, the next net-neutrality-style debate, the next ICANN argument. And we really don’t need that.

So. If social software should not come from a single vendor, a “let the market decide” approach, then how do we decide what to use?

I don’t have the answers. But what I have been trying to do is to follow a few principles:

  1. Keep your mail and IM and blog and wiki and audio/video distinct and separate in terms of origin. But common in terms of vision and direction. And supported by an open community of developers who can extend and modify the product sets.
  2. Make sure that regardless of origin, the tools you select must let you implement your own version of single sign-on, of authentication and permissioning, of identity management. They have to make it easy for you, not the other way around. #
  3. Make sure the information that flows in each piece remains open; open to common ways of archiving and restoring, of recording and retrieving. Look out for train tracks that say “you can only search using tool X” “you can only share in manner A” “you can only archive in way Z”.
  4. Have some common way of naming things that are shared by the different pieces, so that 2 and 3 are achievable. We will need new upstream registries all the time.
  5. Plan for telephony becoming software, for mobility support and location-specific services and device agnosticism and related issues all the time. Their time is almost here.
  6. Plan to record everything. Archive everything. Search everything. Retrieve everything. Independent of device and location and time and language and connect style.

Those are my thoughts and experiences as we stand. And the only way I can see, to keep to all the principles, is to use products clearly and demonstrably based on opensource. Not vendor standards. Not industry standards (just vendors under a different name). Not market standards (biggest wins). But community standards.

No point having the only phone in town, or phones that only work between prime-pairs on Saturdays.

Social software is all about ecosystems. And open adaptive evolutionary ecosystems at that, able to respond to external stimuli. Not integrated-platform offers. Not Digital Wrongs Management.

I’d love to know what has worked for others. And as importantly what hasn’t worked.

Let me know what you think

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