Jon Udell follows Jeremy Zawodny in thinking del.icio.us and flickr might be best examples of Next-generation infoware ... because both of them let you quit:

From the user's perspective, del.icio.us and Flickr support near-optimal entry and exit strategies. You can deeply and automatically mesh your own information with them. And you can undo that meshing. Participation in the services is thus an "at will" arrangement. If you maintain well-structured information, you can as easily mesh it with another comparably-equipped service.

So the switching cost is low and the risk is minimized because you can always take your bat and ball elsewhere. And as Jon points out it is your bat and ball to do with as you please ...

You can't delete reviews you write for Amazon, which is why I've never written one there. (Instead I write about books on my own blog where services such as All Consuming can find them.)

I have written reviews on Amazon, but admittedly not many, only it's not because I can't delete them -- the Internet Archive already assures me the impossibility of any real retractions -- but the reason I don't play on Amazon's site is also related to All Consuming: It is because it's my review and it belongs on my website. If Amazon wants it, I have no qualms with that, they can slurp up my RSS and post my words to my hearts content, but if they want it they'll have to come and get it, which is what All Consuming does. Ditto with my profile, my friends lists, and all my metadata; for larger things like MP3s and photos, there's good practical reason for these files to live on those hosting service sites, but I'd want the content apparent in my pages.

I do praise Flickr for the value add of their photo gallery, for the use of their bandwidth (and being nice enough to allow direct image linking!) and I do appreciate the exit clause, but the best perk I find with both services is how they play a network computing game by providing albeit highly limited but nonetheless functional webservices that let me control my own distribution; anyone trying to make their money off my content by strictly controlling distribution channels should know that we already know may be a profitable, but its a questionable idea, and kudos to both FlickR and del.icio.us for not only providing the backchannel pathways around this problem, but to be thoughtful enough to provide them within a simple, portable and scaleable REST style that doesn't lock anyone into tenuous transport methods.

Jon I think touches this idea, but backs off short of the point:

... I'd love to see competition based on the value that's wrapped around the portable data we choose to mesh with infoware services, rather than on data lock-in.

and an amen to that last one because, for my money, the next generation infoware must converge on a network computer that will be exactly this -- Flickr and whoever else should do what they do best inside the infrastructure, but I want my property on my side of the fence, served to my audience.

And I'll go a little farther: returning the control back to the content creators through network computing is one aspect of a next generation, but the real network computing will

1. use the network to provide services we can't provide on our own
2. provide services transparently, behind the scenes and in a commodified way where we can switch or gang service providers
3. fashion content distribution in a decentralized model where there is only our data and the access we grant to that data, and where the actual locations are irrelevent.

sharing the load

These points form my essence of the next-generation network computer: webservices should vanish, become transparent, infrastructure plumbing, interchangeable or used in consort. Webservices should let me extend my own meagre computing environment, picking up bits of utility a little here, a little there, woven into a whole fabric, and as Jon notes, history teaches that I need to do so reservedly, staying in control and retaining my ownership, able to shift vendors at will and not become tied to any set of partner connections.

Sharing the load should extend in any shape of a data pipeline, perhaps taking my images from one source, passing them through another before delivering them, for example, why not let one site host all my videos in convenient AVI and then use some third-party specialist site to serve alternative formats or stream the content?

'harambe' means 'working together'

I might have my photos on FlickR today but move to another tomorrow, maybe even subscribe to both if the value-adds are complimentary. We can do this when we build our railroads to the same gage. We already have RSS and Atom as frameworks for metadata exchange, all we really need to complete this component is the will to allow symmetric data access with service API models, for example, if FlickR lets me upload images via some XML path, there should be a complimentary backchannel download path -- in OOD terms, symmetric access methods should be a knee-jerk reflex of all webservice designers.

Of course, it's early now and history tells us that the early market-share owners tend to have a large say in the eventual standards, but history also tells us we don't get far with divide-and-conquer market strategies. Whether it's Skype or FlickR, Amazon reviews, FOAF files or bookmarks, I've said it before and I say it again, the better strategy is to make the pond as large as possible lest you become the fat fish in a shot-glass.

my friend flickR

I'm still playing with del.icio.us, who already gets points for a memorable domain name -- on the surface, and especially if they allow me some fine-grain access to my sifted tags, it looks like it's way ahead of Furl's game in terms of efficiency, but miles behind in terms of actual utility. No matter, it's still early.

As for FlickR, I'd like to think I'd misjudged them back when I thought they were headed into being just another singles bar. Having now accepted Jon's comment, taken a subscription and played with it a bit by folding photos into the sidebar here and in the footnote of Just Us I think I'll soften that -- perhaps they are playing a symbiosis webservice game where my little blog can become more than it is through our sharing the load.

I still don't know exactly what they might do with my profile and the pictures I make public, but in the interim I have a decent gallery where they get what they get from me in exchange for much needed bandwidth and, so far, it's a fair trade. If I have any complaint at all, it's just to ask why I can't sift my random pics with a tag when I show my FlickR badge, and closely related to that, why there's no obvious way to ask them that directly.

Still, there's a nagging usefulness lacking in both of these services, and it was hard to put my finger on it at first, being caught up in the fun of posting a few megs of pictures. Something was missing ...

and then it struck me: Where should I post about the WOAA tournement?

or my best beach sunset shot? Or my buddy list? Or ... Do I really have time to maintain multiple photo galleries? Especially when, superficially, from the perspective of the naive user of the service, all of these galleries exist for the same purpose, ie, "A fun way to share your photos with friends."

I don't know about the others on FlickR, but I have photos on YahooGroups, photos on my blog, photos on iNeighbor, photos on 0Catch, photos on FreeFind, photos on ...

Frankly, I've lost track of all the places where I've uploaded photos for this subset group of friends or that. There's even more places where I've left more or less the same bios, bios that would have been identical had they given me that option ...

going decentralized

But tell me again how we're getting into next generation infowares toward network computing? True, there's a transaction possible between my website and FlickR (or Furl or whatever) but -- and dig this -- who really does 'own my data' when I roll up on i-Neighbor.org and get asked yet again to gallery my photos in the service of a social cause, only, see here, they want I should upload them all? Again?

Does this only sound off-key to me?

It must be just me because there are so many of these sites, and all of them are offering the same or at least partially overlapping services and you'd think, given that the name of this game is said to be 'sharing the load' through distributed computing while 'sharing our photos with friends and family', you'd think FlickR would be delighted if I could hand them an RSS of my i-Neighbor or Yahoo or Apple or Whatever photo-album and have these same photos be hosted only once yet do dual service, reach twice the audience. Why not have MIT paying the actual bandwidth cost for serving them out to my FlickR friends?

That's the thing, that's the stuff we gotta watch. In all these services queuing up for our webservices attention, we need to ask why the topology of their network computer is de facto a star shape ... with each of us on the points, and them at the centre.

This is the fat fish in the shot-glass, in the error of a divide and conquer webservices mindset: The big pond will belong to the fish that learn to co-operate and extend beyond what any one of them can do, and the big market will go to those who can grasp synergy, who know that, together, we add to more than just the sum of our parts.

Photos, events, bios, friend-lists, soundbytes, stories ... we will scale the heights of a new infoware when all our content is location agnostic, able to reach any audience we choose through being not duplicated, but syndicated throughout the network computer.

we should be moving only the meta-bits

Syndicated news (and blogs) succeed because they only trade in meta-data and thus are fully shareable; it matters not one iota to anyone if you read that BBC story off a weblog sidebar, inline on a portal page or on the actual BBC. No matter who hosts the bytes you read, the Beeb gets the credit and the credibility and the Beeb gets the attention next time news happens, and all the Beeb-hosting portals and weblogs will catch some of that next big wave. Sharing metadata lets us spread the largest possible sail for the least investment of actual bits.

So too our shared photos, events and reviews should be syndicated such that FlickR and iNeighbor and every Drupal site is just another venue for the meta-data about that syndicated work. That one of them happens to be the actual host of the physical bits is inconsequential: word gets around about the photographer, and they can all catch a share in a wave of attention far bigger than any that might have happened in their old closed-circuit walled-garden shot-glass.

closing the loop

Most of these items are syndicated already, or usually are, almost -- FlickR for a very typical example, tags almost every cross-sectional pageview of your data with an RSS/Atom feed of that content, so technically I'm set with that ready instant list of my photos ready to hand to ...

and there's the problem. Who?

The smoking hole in the topology: nobody seems willing to accept this syndicated content, they only want the original. Not one of them accepts a URL to a competitor's RSS; the only one I ever heard to plan such as service intended to crawl the links to abscond with the bits, to ease your migration into their fold.

Why is that? Why would any sentient being given the choice voluntarily choose the burden of serving the bits over the easy lightweight role of simply posing as proxy for the data? Doesn't it make more sense to take credit (and gain, um, 'eyeballs') for the content you don't host? Certainly there are oodles of top blogs that do exactly this, snip what they find on the syndicated channels, coallate and distill for a new audience and serve it up.

So why wouldn't a FlickR or iNeighbor want to host content where the bits-bill is shouldered by the competition?

the answer: they would.

or they will. It's inevitable and I'll bet the real reason we don't see it is only because they just hadn't really thought about it, because they really hadn't stepped into their own game to ask how would I use such a thing.

The moment they do, the moment they churn the spreadsheets on the market scale data, the economics of distributed co-operation will be so compelling, I'm willing to go out on a limb and predict that future webservices will follow the lead we've already seen in the amateur blog-item networks. After a brief and (to the users) frustrating fling with wanting to be all things to all people, all these services will see this light, give up on trying to own the shot-glass, open their fingers and let the universe spill through, and all of us will open our services in all directions.

In that future information space there is no 'infoware', only information awareness. In that future space, you will never read my blog and none of you will subscribe to my RSS ... not _directly. In that future info-awareness the likes of me would never dream of affording the full infrastructure to accommodate the pressures of a billion readers (I wish) but you will still (I hope) read what I write because you'll connect to my words in the frame of your own neighbourhoods, in the context of your own tribes, picking up my signal across a network of enthusiastic relays each aggregating, reformating and rebundling in their bid for your membership attention.

And that's when we will really see the next-generation.