“There’s only two industries that refer to their customers as users - the drug industry and the high-tech industry.”
It’s really no surprise that high-tech companies have long tried to lock-in users into their platforms - incredibly profitable companies have been built this way (The Microsoft of the ’90s with its software lock-in; Apple of today with its hardware lock-in).
The recent growth of social Internet sites like YouTube and MySpace are predicated on the concept of information lock-in. Once a member of either YouTube or MySpace contribute information to the site, that data is locked into those sites - there is no way to export the contents of those sites in any meaningful way back to the user. If anything, the second coming of the Internet Gold Rush has seen a boom of sites whose sole purpose is to capture information about its users, with no intent on ever allowing anybody else access to that information. Once users start contributing content to any of these social sites, they become more entrenched due to the difficulty of retrieving their own data - in essence, they become dependent on these sites as content providers.
Why is this important? As we spend more and more time on these sites, gathering value from the personal networks that are created, we are going to want to be able to port our data from one of these information silos to another. Otherwise, we will have to continue to spend time recreating all the relationships on every new site that comes along.
This is the goal of the “Open Web” initiative - to promote the portability of data between information silos on the web. The Open Web initiative shares the same kindred spirit as the open source community - while the OSS community unlocks value in software, the Open Web initiative unlocks value in the data generated from software sprayed across the web.
With the Atom Publishing Protocol going gold, developers are starting to agree on how completely separate pieces of software will transfer information.
A rich API can be a daunting engineering task (We spent 7 months getting our API done for Deki Wiki!). (Un)fortunately, languages such as PHP and Ruby on Rails has allowed non-programmers to participate in the growth of the social software movement. For these hobbyists who lack a deep technical background, a rich API is not necessarily the proper solution.
Micro-formats have been offered as another solution - these basically extend the concepts of XHTML and allow for machine readability. Instead of forcing new features to be built, micro-formats allow for extensibility within the familiar framework of XHTML.
Accessibility and machine-readability go hand-in-hand; the more accessible content is, the easier it is for machines to read it. It’s really no surprise that we are just now starting to realize why the web standards movement (for the past 4 years or so) is so important. The adherence to light, semantically rigorous mark-up has laid the groundwork for many of these micro-formats, as well as the explosion of Javascript frameworks which powers many of the rich applications today (Gmail would not have been possible during the first dot.com boom).
I believe the most exciting times for development are just up the road - Facebook was the first good example where tons of people started “getting” it. As more and more people start understanding the value in an API, they’ll demand more and more from their software.
As developers, where do we go from here? We already:
- Give users the tools (open-source)
- Allow users access to their data generated from these tools (open web)
- Allow the broadest group of people to use those tools (accessibility)
- Make it easy to use those tools (rich UI tools derived from disciplined XHTML markup)
The next step has to be allowing those tools to be run on every platform possible, as easy as possible.
At MindTouch, we don’t think it’s enough to simply provide an API. We want to take things up a notch by offering tools in front of the API.
Our PHP component of Deki Wiki is nothing more than a series of scripts which interface with our API - in theory, it becomes possible to set-up your PHP scripts anywhere and still have access to Deki Wiki’s rich functionality.
If there’s one thing that projects like Wordpress and phpBB have taught us, is that simple installation, coupled with rich functionality is the Holy Grail of software. Nobody wants to spend hours setting up a server and configuring everything to get a wiki running. Most people want to run through one PHP install script and be done with it.
And that’s where we’re going. As we continue to move forward with Deki Wiki development, we will continue to rip out functionality from the PHP components and move them into the C# side (don’t worry, Deki Wiki is GPL open source, so you can download and run our whole app on Windows XP *or* any Linux distribution with some elbow grease!). This, in essence, turns PHP into nothing more than a piece of software which talks to the API and outputs the data in a pretty, usable format.
Imagine 6 months from now, downloading a small PHP application, uploading it to your server, writing in a few configuration keys, and having a full-featured wiki? No databases to set-up, no NFS or disk storage to set-up, no need to acquisition a whole specific type of server to get the thing running … just PHP.
How awesome would that be?
It will be interesting to see how these companies have progressed. 
