Positioning real-time web platforms

Like many people, I’ve been thinking a lot about the live nature of the web more and more recently.

The startup world has gone mad for it. And though I think Microsoft’s Chief Software Architect Ray Ozzie played down the depth of Microsoft’s commitment to it in his recent interview with Steve Gillmor, it’s apparent that it’s at the very least a top-of-mind subject for the people at the highest levels of the biggest companies in the Internet world. As it should be.

The live web started to feel more tangible in shape and clearer for me to see because of Google Wave. Two of the Guardian developers here, Lisa van Gelder and Martyn Inglis, recently shared the results of a DevLab they did on Wave.

My brain has been spinning on the idea ever since.

(A DevLab is an internal research project where an individual or team pull out of the development cycle for a week and study an idea or a technology. There’s a grant associated with the study. They then share their findings with the entire team, and they share the grant with the individual who writes the most insightful peer review of the research.)

Many before me have noted the ambition and tremendous scale of the Wave effort. But I also find it fascinating how Google is approaching the development of the platform as a service.

The tendency when designing a platform is to create the rules and restrictions that prevent worst-case scenario behavior from ruining everything for you and your key partners. You release capability gradually as you understand its impact.

You then have to manage the constant demand from customers to release more and more capability.

Google turned this upside down and enabled a wide breadth of capability with no apologies for the unknowns. Developers won’t complain about lack of functionality. Instead it will probably have the opposite effect and invite the developers to tell Google how to close down the risks so their work won’t get damaged by the lawlessness of the ecosystem.

That’s a very exciting proposition, as if new land has been found where gold might be discovered.

But on the other hand, is it also a bit lazy or even irresponsible to put the task of creating the rules of the world that your service defines on the customers of your service? And do those partners then get a false sense of security because of that, as if they could influence the evolution of the platform in their favor when really it’s all about Google?

Google takes no responsibility for the bad things that may happen in the world they’ve created, yet they have retained full authority on their own for decisions about the service.

They’ve mitigated much of their risk by releasing the code as “open source” and allowing Wave to run in your own hosted environment as you choose. It’s a good PR move, but it may not have the effect they want it to have if they aren’t also sharing the way contributions to the code are managed and sharing in the governance.

They list the principles for the project on the site:

  • Wave is an open network: anyone should be able to become a wave provider and interoperate with the public network
  • Wave is a distributed network model: traffic is routed peer-to-peer, not through a central server
  • Make rapid progress, together: a shared commitment to contribute to the evolution and timely deployment of protocol improvements
  • Community contributions are fundamental: everyone is invited to participate in the public development process
  • Decisions are made in public: all protocol specification discussions are recorded in a public archive

Those are definitions, not principles. Interestingly, there’s no commitment to opening decision-making itself, only sharing the results of decisions. Contrast that with Apache Foundation projects which have different layers of engagement and specific responsibilities for the different roles in a project. For example,

“a Project Management Committee member is a developer or a committer that was elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, an apache.org mail address, the right to vote for the community-related decisions and the right to propose an active user for committership.”

That model may be too open for Google, but it would help a lot to have a team of self-interested supporters when things go wrong, particularly as there are so many security risks with Wave. If they are still the sole sponsor of the platform when the first damage appears then they will have to take responsibility for the problem. They can only use the “we don’t control the apps, only the platform” excuse for so long before it starts to look like a cop out.

Maybe they should’ve chosen a market they thought would run with it and offer it in preview exclusively for key partners in that market until Google understood how to position it. With a team of launch partners they would have seemed less autocratic and more trustworthy.

Shared ownership of the launch might also have resulted in a better first use-case app than the Wave client they invented for the platform. The Google Wave client may take a long time to catch on, if ever.

As Ray Ozzie noted,

“When you create something that people don’t know what it is, when they can’t describe it exactly, and you have to teach them, it’s hard…all of the systems, as long as I’ve been working in this area, the picture that I’ve always had in my mind is kind of three overlapping circles of technology, social dynamics, and organizational dynamics. And any two of those is relatively straightforward and understandable.”

I might even argue that perhaps Google actually made a very bad decision to offer a client at all. This was likely the result of failing to have a home for OpenSocial when it launched. Plus, it’s never a good idea to launch a platform without a principle customer app that can drive the initial requirements.

In my opinion, open conference-style IM and email or live collaborative editing within docs is just not groundbreaking enough as an end-user offering.

But the live web is fractionally about the client app.

The live web that matters, in my mind, harnesses real-time message interplay via multiple open networks between people and machines.

There’s not one app that runs on top of it. I can imagine there could be millions of client apps.

The Wave idea, whether it’s most potent incarnation is Wave itself or some combination of a Twitter/RabbitMQ mesh or an open XML P2P server or some other new approach to sharing data, is going to blow open the Internet for people once again.

I remember trying very hard to convince people that RSS was going to change the Internet and how publishing works several years ago. But the killer RSS app never happened.

It’s obvious why it feels like RSS didn’t take off. RSS is fabric. Most people won’t get that, nor should they have to.

In hindsight, I think I overvalued RSS but undervalued the importance of the idea…lubricating the path for data to get wherever it is needed.

I suspect Wave will suffer from many of the same issues.

Wave is fabric, too.

When people and things create data on a network that machines can do stuff with, the world gets really interesting. It gets particularly interesting when those machines unlock connections between people.

And while the race is on to come up with the next Twitter-like service, I just hope that the frantic Silicon Valley Internet platform architects don’t forget that it’s about people in the end.

One of the things many technology innovators forget to do is to talk to people. More developers should ask people about their day and watch them work. You may be able to breakthrough by solving real problems that real people have.

That’s a much better place to start than by inventing strategic points of leverage in order to challenge your real and perceived competitors.

Data dynamics: How the rules of sharing are changing

Today it’s easy to store and share my pictures, my favorite URLs, my thoughts and lots of other things online. There are a range of data repositories that allow me to do this kind of thing in different ways.

What still needs work is how I give trusted services access to much more private data — things like my current location, my spending behavior, access to my friends and family, etc.

To date, most services follow the premise that the looser the controls, the more fluidly data will travel. And that’s all that mattered when it was still hard to get data flowing.

Data flow is no longer an issue. Perhaps data flow has actually become too easy now. And therein lies the problem.

Clearly, blogging, RSS and feed readers drove a lot of the early thinking about syndication. Blogging enabled people to post content in a publicly accessible data repository somewhere for anyone to pull out without any privacy or permissioning controls. The further your content then syndicated, the better.

Wikis and community sites like Slashdot created a slightly more complex read/write dynamic against the central content repository that lots of people could access together. The permissioning model was essentially hierarchical where controls were kept in the hands of a smaller community.

Then Flickr broke ground with a new approach. They applied a user-centric friends and family relationship model to permissioning access to personal photos. Flickr opened up what was once considered private data and defaulted it to a public read-only permission status. But each individual still has a great deal of control over the data he or she contributes.

Similarly, del.icio.us made it possible to store and publicly address what had previously been private data. The nice twist here was the easy-to-understand URLs that allowed machines to consume, interpret and redistribute data stored in del.icio.us.

Where services like Facebook and Wesabe are now breaking ground again is in identifying a security model around highly sensitive data. Contact lists are very personal, but there aren’t many data sets more personal than my purchases and spending patterns.

Neat things can happen when I give machines access to my data, both the things I explicitly ‘own’ and my implicit behaviors. I want machines to act on my behalf and make my data more useful to me in a range of different contexts.

For example, I like the fact that Facebook slurps up my Twitter activity and shares it with my friends in the Facebook network. I don’t want to change my ‘status’ on every service that shows status messages. Similarly, I like that Last.fm captures my listening behavior from iTunes and then uses that data to give back personal recommendations on a badge posted to my blog.

Allowing machines to automatically act on personal data on my bahalf is the right direction for things to go. But important questions need to be resolved.

For example, what happens to my data in all the places I’ve allowed it to appear when I change it? How do permissions pass from one service to another? How do I guarantee that a permission type I grant in one service means the same thing in another service? How do changes propagate? How does consent get revoked?

And even trickier than all that will be the methods for enforcing protection of privacy and penalties for breaking those permissions.

Until trust is measurable with explicit consentual triggers, loosely coupled networks that act on the data I wish to protect are going to struggle to talk to each other. Standards need to enable common sharing tactics. Responsibility needs to be clearly defined. And policies need to be enforceable.

Empowering a person to invest in storing and sharing the more sensitive data he or she owns is going to require a lot more than traditional read/write controls. But given the pace of change right now I suspect the answers will happen as the people behind these services work things out together before the industry taskforces, legal entities and blogosphere sort it out for them.

Media As A Service

Much like print and tv are becoming marketing vehicles to drive people online, the domain name for an online media service is becoming sort of an abstract utility or maybe just a brand address for media services rather than the real estate upon which the core activity occurs. The service a media vehicle provides matters more than the vehicle itself.

And this isn’t only happening in the content space. Every aspect of the media business is pointing to a services model. Here’s what the key pieces look like, in my mind:

  1. Data is infinitely distributable. All data…not just editorialized words. The RSS standard opened the doors for vast distribution networks, and services like Yahoo! Pipes and Feedburner figured out how to make the distribution methods meaningful. There’s an endless supply of microchunks flying around the Internet, most of them unattached to any domain or URL except as a handy reference point.
  2. Data can be visualized in meaningful ways. AJAX and the many freely available widget kits and javascript libraries such as YUI are rendering these microchunks in the right place at the right time in the right way for people which, again, is not always on a web site. The Internet user experience is no longer held back by the limitations of HTML and the packaging a site owner predefines for their media.
  3. Media is created by everyone. Whether written in long form by a reporter or researcher, captured as video by a mobile phone owner, or simply clicked by a casual web site visitor, expressions of interest are shared, measured and interpreted in many different ways. This results in a seemingly neverending stream of media flowing in and out of every corner of the digital universe.
  4. Distribution technologies are increasingly efficient and inexpensive. Personal media services like instant messaging, blog tools, podcasting and collaborative media services like Wikipedia, del.icio.us, Flickr, etc. are easy to use and often free. Web services and open source software enable people and companies to scale distribution and production functionality for large audiences or groups of users with negligeable costs. Most importantly, these tools enable people to be influential without ever owning a domain.
  5. The distance between buyer and seller is shrinking. There are more and more ways for buyers to find sellers and sellers to find buyers from search engines to recommendation tools to coupon rss feeds, etc. Distributed ad markets like Right Media are enabling marketers and service providers to negotiate both the methods and the value of a marketing message. Advertising can operate as a service, too.

After re-reading this description myself, it looks like I’ve just echoed much of the whole Web 2.0 thing yet again. That makes me think I didn’t articulate the concept properly, as I believe there’s a very different way to visualize how data get created, packaged, distributed and remixed and how the various parts of a media business can be coupled both within the organization and across the wider network. Maybe that’s Web 2.0. Maybe it’s edge economics. SOA. Whatever.

The important thing is to think of how your media business can create for yourself or leverage how others offer Marketing As A Service, Sales As A Service, Operations As A Service, in addition to your editorial and community building efforts. Here’s a quick chart of how a media business might look that hopefully gets the point across:

Staffing Model Source Data Coopted Data Distribution Services
EDITORIAL Reporters, Community Managers, Assemblers (formerly known as ‘Producers’) Original News, Analysis, Columns News Wires, Paid Data Feeds, Free RSS Feeds, Links, Comments, Votes, Ratings, Clicks RSS Feeds, Content API (Read and Write)
MARKETING Customer Service, Evangelists, Event Organizers SEO, SEM, Paid Inclusion, Sponsorships, Staff Blogs Partner Promotion, Customer Evangelist Blogs Customer Help, Usage Policies, SLAs, Traffic/Referrals to favored partners
SALES Sales Engineers, Business Development Customer Data, On-site Inventory Partner Inventory, OEM Partner Services Ad Service API (Read and Write)

We’ve seen Journalism As A Service evolve with a little more clarity, particularly recently. Mark Glaser provides a step-by-step guide on how to structure a community-driven news organization:

“Reach out to the community for bloggers, muckrakers and go-to experts. Each topic area would require more than just reacting to news. The Topic Chief would be sure to enlist as many experts as possible not only to be sources but to also be contributors, commenters, and word-of-mouth marketers. Anyone who possesses the skills that go beyond basic participation can be hired on as freelancers or even full-time staff.”

Similarly, Doc Searls’ “How To Save Newspapers” post also lays out what needs to happen on the editorial side. Here’s step #5 in his list:

“Start looking toward the best of those bloggers as potential stringers. Or at least as partners in shared job of informing the community about What’s Going On and What Matters Around Here. The blogosphere is thick with obsessives who write (often with more authority than anybody inside the paper) on topics like water quality, politics, road improvement, historical preservation, performing artisty and a zillion other topics. These people, these writers, are potentially huge resources for you. They are not competitors. The whole “bloggers vs. journalism” thing is a red herring, and a rotten one at that. There’s a symbiosis that needs to happen, and it’s barely beginning. Get in front of it, and everybody will benefit.”

There is lots of guidance for the newsroom, but all parts of a media business can become services.

For example, the ultimate in Marketing As A Service is the customer evangelist. It’s not about branded banners, as Valleywag points out,

“When paid-for banner ads lead to another site that’s supported by banner ads, you know that something’s wrong. Anyone who relies on that circular spending is asking for trouble.”

Marketing should be about enabling customer evangelists whether your customer is simply promoting your stuff for you or actually distributing and reselling it. Fred Wilson thinks of this in terms of “Superdistribution“:

“Superdistribution means turning every consumer into a distribution partner. Every person who buys a record, a movie, reads a newspaper, a book, every person who buys a Sonos or a Vespa becomes a retailer of that item. It’s word of mouth marketing, referral marketing, but with one important difference. The consumer is the retailer.”

None of this needs to happen on a single domain. The domain chain in any of these actions probably should be invisible to people, anyhow, except maybe to ground the events in trusted relationships.

Now, there are many domains that can create wonderfully useful and valuable destinations once they reach a certain critical mass. Invoking another over-used dotcom jargon word, this is what happens at the head of the long tail. And there are obviously lots of nice advantages of being in that position.

Most media companies want to be in that position and fight tooth and nail for it even if it just means being at the head of a niche curve. But instead of or maybe in addition to competing for position on the curve, most media companies need to think about how they provide relevant services outside of their domains that do something useful or valuable in meaningful ways across the entire spectrum.

Posting articles on your domain isn’t good enough any more. The constant fight for page views should be positive proof of that. There’s a bigger, deeper, longer term position out there as a critical part of a network. Sun Microsystems’ mantra “The Network is the Computer” is still meaningful in this context. What is your role if “The Network is the Media”?

Similarly, is Marshall Mcluhan’s widely adopted view that “The Medium Is The Message” still true? Or, like many have asked about the IT market, does the medium matter anymore?

If we are moving to an intention economy, then those who best enable and capture intention will win. And that doesn’t have to happen on a domain any more.

Admin: My feed’s gone spastic

Big apology to everyone who subscribes to my feed. I should have tested things out more thoroughly before peppering your feed reader with hundreds of posts. If I haven’t lost you already, please hang on. I think it’s stable now. And if I already lost you, please consider either coming back or subscribing to my blog-only feed or my bookmarks feed. Thanks for your patience.

Testing ways to splice my feeds

I started playing around with Pipes a bit more the other day and then found this handy tip via Lifehacker for nicer looking ways to link splice in your blog feed.


You can already splice del.icio.us and flickr directly into any Feedburner feed, but Pipes allows you to do things like isolating the saved bookmarks from tags and groups of tags. You can also prepend each item in your feed with things like “link”, “blog post”, and “photo”. You could also splice in other feeds that Feedburner doesn’t support like your Last.fm tracks, for example. I thought I would try offering foreign language versions of all this, too.

I apologize if my feed here gets squirrely on you as I work this out. Coincidentally, I saw this post yesterday that pointed out the number 1 reason people unsubscribe from a particular feed is information overload. I’m definitely becoming an overload offender here. Sorry.

If you want to be sure you’re only subscribed to my blog posts, then here is the blog-only feed.

UPDATE: As I suspected, it was a snap to create foreign language versions of my feeds. I’ve added several translations using the BabelFish operator. I can’t vouch for the accuracy or quality of the translations, but there are now Spanish, French, German, and Japanese language versions of my feed. More on the way.

A start page on my own domain

With a quick copy and paste job using Kent Brewster’s Pipes Badger and a few widgets from services I use, I now have what is a mostly sufficient start page on my own domain that displays my various forms of online expression. Really interesting stuff here.

For my wishlist: a start page that learns

I had the pleasure of joining Rex Hammock for drinks last night in Potrero Hill while he was here for Macworld Expo.

Rex is tuned in to some interesting aspects of the online world, particularly through his site SmallBusiness.com which is becoming a useful and increasingly powerful wiki. I was amazed to hear that the contributions are no longer coming from his team. The community is making the site work and building it into a resource that matters.

We also talked about RSS and start pages. Rex shares my frustration that start pages are so dependent on custom configurations that the majority of the world will never do. Machine learning and recommendations technology is not new, and it seems like such an obvious direction for the start page to go…

Show me what the world looks like through a global lens, my networks' lenses and my own personal lens. Learn from both my explicit and implicit behaviors and then adjust.

Amazon knows how to use my shopping behavior to create compelling shopping experiences. Why can’t my news reading behavior be interpreted to create a better start page experience?

The Onion understands this, too:

Amazon Recommendations Understand Area Woman Better Than Husband

Pamela Meyers said that her husband, whose gift choices have never reflected any outward recognition of her desire to learn Spanish, nor of the fact that she looks terrible in orange, rarely, if ever, communicates with Meyers while away on any of his frequent business trips.

“I was having some tea from that Nebraska Cornhuskers mug Dean got me for Valentine’s Day, when a little emai from Amazon popped up out of the blue,” Meyer said. “Just completely out of the blue.”

“It was nice to know that on my birthday, someone or something was out there thinking about me, and what boxsed sets I wanted.”

How to offer simple RSS badges for your users

The key breakthrough that made it possible for YouTube to ride on MySpace’s heavy traffic coattails into its current state as a mass media service is the concept of widgets, often called badges in related contexts. Although offering widgets or badges may seem like a far off idea for most web site owners to internalize yet, there are a few tools that can make this a snap to offer your users if you’re ready for it.

(I’ll assume here that you already know what widgets and badges are. If you don’t, I’ve been tagging articles addressing the topic of widgets that may be helpful.)

In the case of YouTube, they allowed users to post the YouTube video player to any web page with a simple copy and paste operation. Since most web site owners are dealing mostly with text, the equvilent would likely be a feed of RSS content that people could display on a web page. It would clearly be best to allow your users to display a feed of the things they are contributing to your web site, but if you don’t have user-contributed data to give back to your users it’s still worth trying to offer this functionality using your own content to see what happens.

Here’s a really cool tool I recently found that made it possible for me to offer badges to users on the FlipBait web site. It’s an open source service called Feed2JS, and it appears to be developed by Alan Levine. It requires another open source service called MagpieRSS to operate, but MagpieRSS takes maybe 10 minutes at most to download and install.

After you download and install these scripts you can point to a feed you want to display nicely and get the code back that you can include on any web site to show that feed.

In other words, you now have a badge platform to offer your uses.

I tried this out on the FlipBait web site, and it worked out of the gate. In fact, you can now see on my blog sidebar here the posts I’ve submitted to FlipBait. Each user on the site has access to his badge via his profile page. Now everyone can take their contributions with them wherever their “Internet startup news” identity gets expressed.

It couldn’t have been much easier to setup either. I’m hoping, actually, that the Pligg team incorporates something like this into the source code.

There are also some nice formatting capabilites in Feed2JS that would make people happy, I’m sure. But that adds some complexity I’ll address at a later date. The important thing is to push out a feature like this, watch for uptake, and then evolve it.

I’d be interested to know if other people have tried any other similar solutions or used tools from some of the recent startups in this space and what their experiences have been. Please comment or blog about it if you’ve found another way to accomplish this without having to write the code yourself.

Recommending RSS feeds on My Yahoo!

Former Yahoo! colleague Don Loeb (now at Feedburner) called out the recent addition of RSS feed recommendations to the My Yahoo! product. This module automatically bubbles up sources that you might want to add to your page so that you don’t have to hunt and peck so much to find stuff that matters to you.


It’s cool to see a technology work as it was intended…but then there are the surprises that aren’t intended that are even better than seeing something go as planned.

One interesting unintended outcome is that I’m actually discovering new blog posts to read that I would never otherwise find amongst my current list of feeds. And I don’t have to subscribe to the feeds to see these posts.

For example, Niall Kennedy’s blog was recommended to me in this new module and I learned that he’d just left Microsoft after a short stay with the Live.com team. I don’t currently subscribe to Niall’s blog and none of my feeds seemed to reference this news. Very impressive.

This is another example of the “Interestingness” concept Tim O’Reilly and Bradley Horowitz have written about this week.

You can get access to the recommendations module by clicking on the small promotional link in the “Inside My Yahoo!” module that comes as a default when you sign up for an account. The reason we’re not making more noise about this pilot is because we’re in test mode to see if it works and if people like it. Plus, it feels like the kind of feature you just expect from a personalized start page anyhow.