Dave Winer vs. CNET, platforms of personal expression (PPEs), and why Grandma matters

A couple of days ago, I did Scoble vs. Ballmer. Now, it's Winer vs.

A couple of days ago, I did Scoble vs. Ballmer. Now, it's Winer vs. CNET. In their search for the creator of the first blog, News.com's Declan McCullaugh and Anne Broache refer to one of their candidates Dave Winer as irascible (a common misconception regarding Mets fans from Brooklyn or Queens, of which I'm one). Yankee fans? Well, they're irascible (reminder: I now live in the Boston area). The News.com piece gathers quotes from some of the other candidates like Jorn Barger. Dave was quick to respond from his blog:

That would be Tim Berners-Lee, whose first website was, in every way, a blog. .....I think the CNet article misses something important as they make light of my claim to having bootstrapped blogging. The first blogs were inspired by this blog, in fact many of them, including Barger's Robot Wisdom, used my software. If you go to BlogTree, a site that asks bloggers to say which sites inspired them, you'll see how many self-declare as originating from the Scripting News community. How you summarize that effect is up to you, I call it a bootstrap.

Call it what you want. Trying to compartmentalize Dave into the first blogger, or the Father of RSS or however else you want to compartmentalize him misses the totality of his contributions. Step back to see how those contributions hang together, and suddenly, not only is the whole far greater than the sum of its parts, you may begin to see each part a little bit differently.

Identifying Tim Berners-Lee as the first blogger is a patronization of people who can't see the big picture. It's the same patronization some media companies are doing to themselves when they refer to their downloadable audio as podcasts when they're no such thing. Sure, if posting text to a Web page is blogging and you figured out how to get BackWeb or twist Marimba or Internet Explorer's earliest "subscription" function into a notification mechanism, then maybe a Web page you monitored that was authored by Tim or someone else qualifies as the first blog.

But to me, "weblogs" and the subsequent derivative "blogger" was always a misnomer. The software Dave refers to when he said "my software" -- assuming he was referring to Userland Radio -- was so very much more than a way to digitize a logbook onto the Web. It was the first Web authoring software that made you forget your were authoring Web pages (never mind the fact you didn't have to be online to author them). RSS? Interesting technology by itself and the debate over Dave's role in that is as useless as trying to figure out whether he was the first blogger. Regardless of how RSS as we know it today came to be, Radio was a showcase for how it was not just a notification mechanism, but also a pipeline through which users could frictionlessly flow  content from one Web page to another. 

Podcasting is undeniably a description of a technical process. For something to qualify as a podcast, it unequivocally must be retrievable through an RSS feed that uses a special XML field known as an enclosure. It's easy to point at some audio on the Web that's only available via streaming or manual download and say, that's not a podcast (even though, in many cases it says it is). I'd posit that weblogs (blogs) are no different. Tim Berners-Lee may have been the first to chronologically log history on a Web page. But is that a blog? Or must RSS hang together with the content the way it did in Radio to qualify? If it's the latter, the debate over who the first blogger was takes a completely different dimension.

In his response, Dave also touched on inspiration. There's no question that Radio inspired many bloggers to blog. But going back to the whole being greater than the some of its parts, Radio inspired me in a completely different way.

My very first personal blog was built on Userland's Radio and the underlying architecture in that product was positively brilliant for its time and has deeply affected how I write about technology.

For example, take a look at the blog I posted just before this one about the Mozilla Desktop Environment. Had I not spent hours upon hours getting under the hood of Radio (and reading Rogers Cadenhead's book), I might not of processed Francois Orsini's demonstration of JavaDB (Sun's version of Apache Derby) in the same way. Nor might have James Governor encapsulated our subsequent discussions at JavaOne 2006 with the phrase "the synchronized Web." Architecturally speaking, Radio is an early MDE and the synchronized Web rolled up into one. Web pages are served locally into your browser. There's file system awareness (albeit awareness of the actual local filesystem). It's cross-platform (as MDE would have to be). And best of all, it solves on the on/offline problem through unattended synchronization. 

Technically speaking, those Web pages, which are Web forms, could be for anything. For example, they could be for a Google Document just as much as they are for a Radio weblog.  In fact, check out my writeup on Google's Writely and how its approach to the offline problem (when a Web form can't find its Web server due to missing connectivity) is a dot that can be connected directly back to Radio and Dave.

A browser with some sort of filesystem-capable plug-in would allow most of the operating system dependencies -- the hard work Dave had to do to make Radio work the same on both Windows and the Mac -- to be moved a layer up and away from the OS. Imagine for example Radio running the same way a Flash app would. Or a Java app. And imagine it not being specific to one application like Radio, but rather extensible to multiple applications. And then imagine all the data and "apps" (loosely defined since they're Web forms, probably Ajax driven) being stored on a USB key -- perhaps one that could be plugged into the USB port on the seat back tray in front of your airplane seat (flip the tray over and there's the keyboard, and up on the seat in front of you, a big LCD display). Goodbye notebooks.

Sound crazy? I don't think so. Even if it is, who cares? It's fun to think about and Dave's work on Radio is what inspired those thoughts.

But wait, Radio inspired something else just as fun to think about. By the time I got around to using Radio, Dave was no longer as involved with it or Userland (in fact, Dave just published the details of this history). In getting under its hood, I discovered how Radio was actually a Web development platform that was cleverly disguised as a blogging platform -- one that included canned integration widgets for personalizing your Web presence. 

In April of 2002, Dave announced that Radio would be supporting Google's newly introduced API to its search engine. In that announcement, Dave wrote "This is very leading edge stuff." He wasn't kidding. Not only was the unveiling of a SOAP-based API to something like Google search very leading edge, even more leading edge was what Dave did with it to make it easily deployable by any Radio user. Wrote Dave at the time:

You do not need to download the Google developer kit, although it contains documentation that you may find useful in understanding how the API works. We will release the parts you need to program Google from UserLand's environments.

For your typical blogger, accessing APIs is the stuff of rocket scientists. To ease their pain, Dave took all the rocket science in Google's SOAP API and tucked into one neat little statement that was so easy to add to a Radio page that a 10 year-old could do it.

<%google.macros.box ("text to search here")%>

When I first added this to my Radio-based blog (I searched the text "media transparency," see the resulting Google box on the lower right hand side of the page here) and saw the results, the light bulb immediately went off. I haven't been the same person since.

With the sudden of explosion of APIs taking place on the Internet, the same explosion that inspired Doug Gold and I to start Mashup Camp, it became clear to me that blogs weren't just places to express yourself in text and still images. They should be mashup platforms unto themselves that make it possible to express ourselves in both static and dynamic content (a.k.a. software). By tucking all the complexities of Google's SOAP API behind such a simple line of code, Dave was clearly onto something very big and so far, I still don't think the major blogging platform providers get it. Nor do many of today's API providers.

For example, when a new, useful API is released -- one that bloggers (or anybody publishing Web pages) could use to further their personal expressions -- who should be responsible for its widespread adoption? The API provider? On the flip side, if you're in charge of Radio, Typepad, Blogger, Wordpress, MySpace or one of the other platforms of personal expression (PPE), what's the best way to keep your existing users happy and draw new users in? 

Why then, as API providers release promising APIs that could play a great role in personal expression, are they (the PPE providers or PPEPs) not also releasing the "so easy a 10 year-old could deploy it" versions for each of their platforms? In the course of keeping their platforms the most vibrant and engaging places for personal expression, shouldn't the people who run those platforms be racing embrace those new APIs in a way that incorporating them onto a Web page is no more difficult than it is to pick a color from palette dialog?

Everyone seems to be violating the golden rule of ecosystem supremacy: He (or she) who turns Grandma into a software developer wins. Period. Have we not learned anything from Visicalc, Lotus 1-2-3 and Excel -- some of the first pieces of software to do this? Think about it? Those software packages did the same thing that Radio's google.macros.box command does. How many lines of assembler code do you think were hidden behind the first spreadsheet's (Visicalc) SUM command? According to Dan Bricklin, the co-author of Visicalc, thousands. OK, so today's APIs aren't nearly as complex to make use of. Unless, you're Grandma. In that case, they're impossible. Neither the API providers nor the personal platform providers are doing themselves any favors if the only people that can use the APIs are the same small population of rocket scientists around the world that think in XML, Javascript, PHP, C++, etc.  

Dave gave Radio a huge head-start by establishing an architecture through which the code for anything complex could, like a spreadsheet's SUM command, be tucked behind something that most mortals could use. OK, not Grandma. But mortals (better than rocket scientists). But after his departure, my sense is that the subsequent management team at Userland didn't realize how this should have been a priority.  I was the perfect example. Here I was, a Radio user, and one that wanted to take advantage of some of the newer APIs that were surfacing on the Web. Surely, someone at Radio would be releasing the equivalent of the aforementioned google.macros.box command for all these other cool APIs that were hitting the Web.

In May 2005, I wrote to Scott Young who is still CEO of the company and asked:

DB: Why doesn't Userland release like 10 new macros a day?

SY: Technically, we could and it has been a trait of UserLand in the past. However, all those separate little widgets then have to be rolled up into a release, an installer added, and tested to make sure there aren't any conflicts -- and that's always been the issue. It made it really difficult to keep track of things and it also tended to confuse people who were new to the game. Anyway, as we push deeper into the enterprise (and have more resources) we will start producing more widgets for release, Maybe not 20 per day, but definitely a few.

Back then, Radio ruled the blogging roost. Today, it doesn't. Not by a long shot. Most of the top bloggers, many of whom have since defected to other platforms like Wordpress, were using it.  Young's answer, particularly about the hard work it takes and the challenges in avoiding confusion -- that is the Holy Grail. That is what it takes to turn Grandma into a software developer without her knowing it (blogging tools already turned Grandma into a Web publisher without knowing it). That is why people like Grandma are drawn to a platform of personal expression. That is why people like Grandma will stay with or leave a PPE. 

Radio wasn't alone. In the search for a PPE that was embracing third party APIs as they were being released, none of Radio's competitors were paying attention either. They're still not.

Even more surprising is how the various API providers -- the ones who most want their APIs to be adopted by the masses -- are rather complacent about the situation as well. Back in 2005, I half-wondered why, when Flickr or Google or Yahoo released an API, they didn't also release the macro that could be plugged into Radio that would give all those non-technical Radio users like me google.macros.box-like access to that API. Today, if I was the one releasing APIs, then I'd also be making it dirt simple to plug it into the market-leading PPEs like Wordpress, MySpace, and FaceBook.

Eventful.com, provider of event related APIs (as well as a full-blown Web site that sits on top of those APIs) gets this concept. Even though it has APIs, one way it demystifies them for people who are handy with little more than HTML is that it embodies them in "stickers" that you can stick on a Web site like MySpace. Once such sticker, known as a "Demand It" sticker is a way for event promoters like Barack Obama's campaign manager to figure out where Obama should be making personal appearances based on voter demand. Obama's Demand It sticker (see image, left) is stuck on his MySpace site. Musicians can use the feature too to help them plot their next tour. Not only is the sticker easy to build, once it's built, it can be shared with others who are free to modify it the way Obama's sticker can have it's colors and size customized

Demonstrating to some extent that Eventful.com knows it has to make API access easier on platform-by-platform basis, clicking on the "Stick it" button in the lower left hand corner of a sticker like Obama's results in the display of instructions that are marginally specific to MySpace. It's still code (yuck) that has to be pasted onto a Web page (yuck), but the language refers specifically to MySpace users when it says "Copy the code below into your 'edit profile' page and save." 

Even though Eventful may get it, the demystified version of Eventful API access is still a snippet of code that must be cut and pasted somewhere. Eventful's sticker may qualify as a widget, but like Radio's google.macros.box command, it's still slightly out of the reach of Grandma. Even so, it's closer to what API providers must be doing in order to encourage adoption of their APIs within certain platforms of personal expression than most are doing. I asked Eventful's senior software engineer Chris Radcliff if the company had any intentions of doing something Wordpress-specific, like an Eventful plug-in. He said it's "on the long list."

Months ago, Radcliff was also the first ones to tip me off that MySpace was interfering with the implementation of certain widget types. According to Radcliff:

MySpace disabled support for some aspect of Flash on its site. Flash is one of things we used to make our widgets interactive. So when you click on the right button it does the right thing. We had to rewrite the widget so it wouldn't use that aspect of Flash.  

Compared to Userland which simply wasn't making new widgets (a.k.a. macros) a priority for Radio, MySpace, the world's leading PPE is deliberately heading in an antithetical direction. Yesterday, fellow ZDNet blogger Steve O'Hear offered more details of how MySpace's 3rd party widget policy could be upsetting users -- a complaint I'm hearing more and more about. The irony is that MySpace should actually be doing the complete opposite just the same way Userland should have with Radio. Somewhere on MySpace should be a library of widgets -- some MySpace authored, others from third parties -- that can simply be dragged and dropped right onto a MySpace profile. Or a desktop. Or, if you're viewing someone else's profile on MySpace and you see a widget you like, you should be able to right click on it and select a menu item that says "Add this widget to my profile."

MySpace is of course free to make whatever business decisions it wants to. But its hand will most definitely be forced by some other PPE that finally sees the light -- the one that finally understands what the possibilities are, and the loyalty you'll have, once you turn Grandma into a software developer.

In the meantime, while the majority of API providers simply publish APIs without making them easier for Grandma to use, and while the majority of PPEPs forget that it was the demystification of Web authoring that got non-technical users into expressing themselves on the Web in the first place (throwing software into the formula is simply the next evolutionary step), at least one innovative outfit seems to be filling the void by getting in the middle of those two constituencies and providing Grandma's glue.

I'm talking about yourminis.com which I witnessed for the first time when I recently attended Adobe's Engage event (small writeup by fellow blogger Ryan Stewart here). Much the same way Eventful's stickers are simply Grandma-friendly abstractions of the company's more complicated APIs, the idea behind yourminis is that anyone can build a similar Grandma-friendly widget that abstracts an API (or APIs) and share it with the other members of the yourminis community. In other words, to the extent that MySpace, Typepad, and other turnkey platforms for personal expression should be including a directory or palette of widgets from which to choose (and drag n drop), yourminis is now just such a palette, albeit a third-party one.

A great example of this can be seen in the stock market widget that's currently available through yourminis. Under the hood, it's powered by Yahoo Finance. But, unless you were looking, you might not know that, nor should you have to.  The widget, which was developed by yourminis (the company has seeded the site with some widgets of its own) is slick looking (good for personal expression), it's colors can be changed, and it can be modified using an idiot-proof edit widget button (modifiable elements are the ticker view (list or marquee), the stock symbols, and the chart (on/off). Look Grandma. No APIs.

Once you're done customizing the widget, it can be copied to a Web site (much the same way an Eventful sticker is copied to a site), your desktop (wow!, Web or desktop), or your own personal space on yourminis. Given the incredibly free form nature of a yourminis personal page, it's pretty much what a MySpace profile should be. Or, your MyYahoo page. It starts as an empty canvas, and goes from there. Widgets go where you want them. And, provided yourminis survives its startup ramp up, the likelihood that different sorts of stock widgets will show up, maybe one with piercings and tattoos, is good. In other words, there's no reason software can't or shouldn't be a form of personal expression. 

Likewise, whereas yourminis can essentially serve as a third party widget palette to PPEs, it's also encouraging others to do the dirty work that API providers should be doing for themselves in the first place -- wrapping their APIs into something that's a bit more Grandma-friendly.

In some ways, it's a sad statement that there's a need for something like yourminis. What yourminis is doing is what API providers and PPEPs should be doing for themselves. Then again, even if API providers were wrapping their APIs in Grandma-friendly widgets, or, if the PPEPs were embracing third party APIs by widgetizing them for their users, I wouldn't expect those widgets to be very imaginative. With yourminis, there's no telling what some artist will come up with.

The room that's left for yourminis to fill isn't filled by yourminis alone. Go to netvibes.com and start dragging widgets from the left side of the screen (there are more than I can count and you'll recognize many of them). Then check out what NetVibes correctly refers to as its ecoystem (to which anyone can contribute a widget). And there are others coming, each with their own unique spin on how to keep Grandma happy.

Clearly, looking at how Radio was originally architected, Dave Winer was grokking all of this long before anybody else saw the light. And even with Radio as the proof point (and the solutions like yourminis that eventually followed), I'm still not sure very many people are seeing the light just yet.

Irascible? Perhaps. Misunderstood? More likely. A couple of years ago, a friend in the Netherlands took me to see his favorite wine dealer. The building was ancient. So too was the wine on the shelves in its dark dingy cellar. As we pushed cobwebs out of the way, I looked at the dates scribbled onto the sides of decaying brown cardboard boxes on dilapidated shelving. Most years dating back to the early 1900's were there. And so too were the dusty bottles. 

After touring the cellar, my friend introduced me to the owner of the business. Knowing that some of France's finest vintages sat below us, I asked him what he thought the best wine in the building was. I was shocked when he pulled out a 2004 French Riesling. We tasted it together. It was excellent. And then I did something really stupid. I asked him how much it cost.  Here was this man with over 50 years of experience in the wine industry who was trying to teach me -- someone he didn't know from Adam -- something about appreciating wine.  And all I could do was ask the one question that mattered least.

Disclosure: I did not consult with Dave at any time during the writing of this story nor did I try to. His or other opinions may differ from mine. But this is mainly a story of how Radio has inspired a lot of my thinking over last few years. Perhaps I saw in it things that he never intended. I don't think it matters given the thoughts it provoked.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All