Over the past year or so I've seen a good number of beta or pre-beta systems, all in a space which could be said to go beyond expectations for Web 2.0 (I'm not altogether comfortable with these versioning labels, but they'll do for present purposes). These systems have generally had Web of Data aspects, some have been fairly by-the-book Semantic Web setups, most have had significant proprietary parts. The word "platform" often appeared in the blurb. Without exception these have been impressive on technical grounds, but again without exception the success of these systems is by no means guaranteed.
Whether or not it's possible to list Best Practices in this space, I think it most definitely is possible to identify ways in which developers of such systems can maximise their impact on release. Whatever the particular business model or target audience, getting mindshare is a goal.
At this stage in the game it isn't really possible to truly draw on past experience, all there is to go on is guesswork. But by looking at the environment and considering how pieces of the Web can fit together, I believe there's plenty of material around to inform that guesswork. Nothing of what follows is remotely new - it's essentially a collection of cliches. But I'm reasonably confident they're the right cliches.
I'd suggest there are two initial aims for most Web 3.0 systems: maximising visibility on release by getting as many people on-side and enthusiastic as possible; maximising utility on release by having ready-to-use applications in place. These two aims complement each other - more enthusiasm means a bigger pool of 3rd party developers to create cool applications, more utility means there's likely to be more enthusiasm.
As a rule of thumb for any decisions, favour what's best for the Web. The success of a Web 3.0 system will be dependent on the progress of the Web. While there may be features in your system which provide the exact same functionality for the exact same market as features of competing systems, at this point in time, cooperation is the best strategy. It's pioneering time, there's a huge amount of land available, no need to grab. By colonising the new territory together it'll be possible to minimise the cost of facilities everyone needs. Ok, that's getting way to metaphorical. Put it this way - by opening people's eyes to the potential for new ways of working on the Web, everyone benefits. Sure, emphasise unique selling points, but with a backdrop of building the New World together. While this next statement sounds purely antisocial, it isn't: exploit the Commons. There's a huge amount of Open Source software and Open Data which could offer leverage for your system at very low cost. Existing communities contain a lot of expertise and social cohesion which can act to your advantage, if you make your approaches following respectful netiquette. If all goes well, a community all of your own will emerge.
While Web 2.0 has encouraged a move away from walled gardens, there's still a tendency to visualise systems from a local perspective, with a bit of chain-link fencing to keep the chickens in. But to get mindshare and market penetration you want to maximise your surface area. This means being prepared to work away from home, going out and connecting existing systems to your own. Your system may look like an elegant modernist construction from your point of view, but there's a good chance that from other people's perspective it looks like a big black monolith. Work on other people's platforms is good for your vision.
Because you've got this powerful application/platform, the temptation to build a universe of applications of it will be great. But although you may have shifted up a few layers of abstraction the old NotInventedHere antipattern still holds. Sure, build a bunch of standard kit (Wiki, blog tool, feed aggregator...) to demonstrate how easily it can be done. But unless you have really compelling novel features planned, every hour spent on such stuff is an hour that would be better spent on making something more interesting. Ask people for interesting use cases - be a part of the LazyWeb.
Allocate a proportion of your resources to creating material to put back into the Commons - open source/open data. While this sounds purely philanthropic, it isn't. Not only is giving stuff back good PR, every thing you expose to which you can connect is exposing your surface area. Work for other people and they'll work for you.
Your imagination is limited. There's no way you can envisage all the different possible permutations people can come up with in the application/service space. An application may require component X connected to component Y connected to component Z, where X & Z are your pieces and Y is that of another party. Don't fret it, this is a good scenario from which yourself, the other party and the end users are all benefitting. Get over to ProgrammableWeb, pick a handful of nice services, integrate them through your system.
Which would appeal most to the developer:
Hand in hand with this goes the accessibility of any constructed applications to the end user. If it doesn't do something useful when visited with Lynx, you've lost half your potential audience before you start.
Standards are the conventions that allow this stuff to work. Ignore them and you're doomed. There's nothing inherently wrong with proprietary formats and protocols, but the ROI is at best linear. Think of the bean counters. Follow established specs and your beans turn into magic beanstalks.
No matter what the internals of your system looks like, what matters to the Web is what you expose over HTTP. Remember, Web APIs are just Web Sites.
No matter what your target domain(s), ideally you will support all these:
Hopefully most of those should be self-explanatory. Mark Woodman queried my suggestion of SPARQL as a must-have. I can't deny it's on the fringe of this list. But I'd suggest that's only because it's relatively immature and not widely deployed. It certainly is possible to get a long way based on HTTP and link-following along. But if we're talking Web of Data, a database really needs a query language, and SPARQL's web-native. Simple search (a la GData) just doesn't cut the mustard.
If you really must go beyond existing specifications, provide mappings to standards where there is overlap.
You need a Wiki, blog (with comments enabled), podcasts, maybe a mailing list.
---
Comments appreciated
status: first draft
Danny Ayers 2007-04-20