Some good pieces about using weblogs in business have appeared recently. But I was irritated by the glib assertion in an otherwise excellent article that Radio Userland is "poised to become the weblog tool for businesses." As so often happens, a mainstream journalist unfamilar with blogging has prematurely leapt to an unsustainable conclusion (tsk, tsk).
My view is that, for all its good points and for its many contributions to the spread of blogging, as in the newly announced deal with Salon.com nevertheless Radio has some serious flaws as a platform for business blogging. Blogger Pro has its flaws too, but as I've explained in a Diary posting today, I explicitly chose it for its advantages over Radio as a business weblog publishing tool.
I think the big mistake that the designers of Radio are making albeit with the best of motives is that they're trying to make Userland into the BigCo of blogging. They're pursuing the same strategy as all the companies that got big and made money in the last wave of computing they're trying to become the default platform in their field.
Unfortunately, that's going to be the wrong strategy this time round, which I think is something the creators of Blogger intuitively understand. But I suspect they too have not fully realized all the implications. They already have an impossibly long feature wishlist, which is one of the tell-tale signs of platform thinking.
Attempting to be the platform that everyone runs on is missing the point, because the platform already exists, and it's called the Web. Success in this new era of computing will depend not on how many users you capture, but on how many you connect to. In this new era, if your feature wishlist is too long, it's because you're not doing enough to encourage and support third parties. If you're losing customers, it's because you're trying too hard to hold onto them, and not doing enough to help them make connections.
The same message applies equally well to online media like Salon.com, and to anyone else who thinks of weblogs as just another mechanism for drawing people to your site. A published weblog is merely a single instantiation of the content stream produced by the user of a weblog publishing tool. Smart weblog authors will publish their content streams to multiple websites, and smart weblog publishers will selectively aggregate content streams from multiple sources.
The best weblogs on Salon.com will also want to be published on other sites, and if Salon.com doesn't accommodate that syndication then those authors will publish their content streams elsewhere. Instead of trying to be the home of those weblogs, Salon.com should aim to be their enabler, making it easier for them to publish in the arenas and formats that suits them best.
In a nutshell, the recipe for web services success is this. Don't try to own your users; strive to set them free.
PS: [added Monday, July 29] It occurs to me that it would take a much longer article to really explain the thinkig behind this posting, and in the absence of those explanations maybe it comes across too harshly. It's not intended to be an anti-Userland rant. Dave and his colleagues have pioneered technologies that make much of what I'm talking about possible. But I do believe the Userland product is flawed by being too much of a self-contained packaged platform, and I see many other web services designers falling into the same trap. Fortunately, yesterday I added a comments capability to this blog, so if you want to put a follow-up question or comment, feel free.
posted by Phil Wainewright 6:49 AM (GMT) | comments | link
Thursday, July 25, 2002
Gates admits .Net shortcomings
In a laudably frank appraisal of Microsoft's progress to date with its .Net strategy, company chairman Bill Gates yesterday spelt out how the software giant plans to move forward with its web services architecture. There's a good write-up by Wylie Wong on CNet. Here are some of the key points:
Globally rebranding Microsoft products under the .Net label had been a mistake, Gates admitted: "Maybe the .Net Enterprise servers [were] prematurely called .Net."
Although Microsoft has made a big contribution to focussing attention on web services, Gates admitted there had been little substantive progress on deliverables: "He gave Microsoft a grade of 'C' for developing what he termed 'building-block services' and for making the software-as-a-service concept a reality."
The most important achievement so far has been the release of the Visual Studio.Net development tool in February this year, he said.
Microsoft remains 100% committed to investing in the development of .Net, which Gates said was always seen as needing five to six years to complete.
"Gates said that Microsoft is doing 'a bit of a reset' and over next 12 months or so will be moving .Net forward on several fronts." I thought that was an interesting choice of metaphor, since when Bill Gates says 'reset,' it is with the explicit meaning of pressing the reset button when the PC has crashed so that you can debug the program and re-run it.
For an alternative, digital identity-centric account of the same analyst briefing, read Eric Norlin:
"Calling the problem Microsoft was attempting to solve 'one of the toughest ever' and comparable to 'getting to the moon' ... Gates went on to suggest that the solution to the problem could be found in 'people-centric' computing."
No doubt there will be much more analysis of this briefing (attended by some 150 media, industry and financial analysts) in the next few days, so I may return to the theme in further writing once I've seen what others have to say. Find links to a selection of articles I've written about Microsoft and web services over the past few years here.
posted by Phil Wainewright 3:21 AM (GMT) | comments | link
Wednesday, July 24, 2002
Quote of the day
Dave Winer, commenting on a posting in Paolo Valdemarin's weblog: "If one were to write a definition of the Web, loose coupling would be part of it." To which Paolo replied: "I like the term 'loosely coupled'." Nice to see such consensus. I like the term too :-)
The debate is around the question of whether weblog authors should be free to go back and change their entries. Well that's up to them, of course. If I were writing a weblog whose role was to challenge perceptions, then it would be a legitimate part of that artwork to go back and change previous posts. Dave's Scripting News weblog is a fascinating collection of links and observations made in real time, and sometimes errors or hasty judgements need correcting.
However if the main role of a weblog is to act as a repository of referenceable information, then I don't believe it's a good idea to substantially rewrite published posts. For this weblog, my policy is to allow minor changes within the first day or so especially if they're necessary to correct facts or add important afterthoughts but nothing beyond that, because then you run the risk of people or search engines quoting something you no longer said.
The real point here is one that applies to applications as well as to content, and thus has some relevance to other debates about the mechanics of web services. Loose coupling only works within a defined context. Sometimes the context will imply transience (eg DayPop ranking), and sometimes it will imply permanence (eg 'permalink'). The coupling works when the context is understood but falls down if it has been poorly communicated and/or incorrectly interpreted.
posted by Phil Wainewright 1:49 AM (GMT) | comments | link
Tuesday, July 23, 2002
Money makes the world go round
Web services architectures include no practical mechanisms for collecting revenues, which is going to become a major brake on the development of commercial web services as time goes on. For now, Google and Amazon are happy enough to let developers experiment for free with their web services APIs, but what happens if a 'killer app' suddenly arises that requires an effective metering, billing and settlement infrastructure? There are one or two vendors that might be able to help out (such as Metratech, Teleknowledge or Apogee Networks), but nobody's established any best practice.
This is the theme of my column this week on ASPnews, where I elaborate the point at much greater length. Here's my conclusion:
"Virtually no meaningful work has been done to develop the technology to accurately measure usage, raise bills, collect payments and distribute settlements for multi-tiered component service delivery ... Without the means to bill for service consumption and make a fair distribution of the proceeds to participants, the next generation of Web service providers could rapidly become as bankrupt as the last."
WorldWideWeb creator Tim Berners-Lee cites two historically significant aspects of the current move towards web services in a short interview with Eric Parizo of searchWebServices.com:
"What you're seeing in IT with Web services is about angling to solve existing problems with existing solutions like XML and HTTP, the building blocks of the Web."
"... what's most important is that there're royalty-free [standards] ... I hope all the technology will be free."
I think he's absolutely right that if we get these two factors right, then we will have achieved something of historical importance. And so it troubles me that I just do not get the Semantic Web, which he is also very keen on. "People are realizing the [important] issue is about automating communications between two companies," he says which is fine, but it seems to me that the Semantic Web misses the point. We're not automating communications so that we can take humans out of the picture and let the machines get on with the job. We're automating them so that the humans in those companies can have more time to interact without the machines getting in the way.
This will be the final and historically most significant achievement of web services the global enablement of communication, trade and knowledge exchange in a way that brings humanity closer together than ever before. If that's what the Semantic Web is really about, then I'm all for it. In the meantime, the other two factors that Tim cites will get us a big part of the way there.
A detailed essay by the influential Sam Ruby makes it clear that both SOAP and REST have roles to play in the web services environment, and sets out guidelines for making the most of each of their strengths when designing an application. It doesn't really do justice to the scope of the piece to abridge it as brutally as I'm about to, but I felt there were two succinct phrases that summed up the key merits of each:
REST: "The key point here is that applications that desire to be broadly accessible should be designed with this in mind in other words, to maximize their visible surface area."
SOAP: "Sometimes, one truly wants to have an atomic 'transfer funds from savings to checking' transaction instead of simply a series of discrete GET and PUT's."
So there you have it in a nutshell. The XML-over-HTTP openness of REST works best when you want to reach as wide a universe as possible. On the other hand, you're going to need the encapsulation of SOAP when performing operations with a high level of contractual commitment. Most applications will need to use some of each.