DIY Web Services

Monday, February 4, 2002 by Dave Winer.

Good morning! 

It's been almost a month since I had the time to write a DaveNet essay. I'm out of practice. Even now, I don't have much time because things are moving so quickly. The reason I'm so busy is that on January 11, we shipped a new product called Radio 8. It's a personal weblog tool and news aggregator, runs on the desktop, taking advantage of Moore's Law that's put such powerful but poorly utilized machines on our desktops. It's fast and easy. Yesterday the product was favorably reviewed in the Washington Post. Our company had a record sales month in January, thousands of new users. The list of firsts has been incredible. Not only have we survived, we're thriving. Business is good.

Web Services 

While Radio is doing well with users, it's also a developer's platform, at it's heart it's the Frontier database, scripting engine, debugger, outliner, verb set, HTTP, XML-RPC and SOAP stacks, etc. In a sense the weblog and news aggregator are just apps to seed the market, with luck, playing the same role that MacWrite and MacPaint played in starting up the Macintosh developer world. To be a strong platform you have to have users, and the users must have apps.

The core value of our development platform is the idea that you can build peer-to-peer apps that are easy to use. To make that work, we needed protocols, XML-RPC and SOAP, to connect machines to the community server and other users' machines. That's why we made the investment in these technologies, which are also known as Web Services.

While all the hooplah has been going on about Web Services I've been thinking to myself (and sometimes I've shared these thoughts on Scripting News) -- Couldn't this stuff be a lot simpler? I mean really, before most people even understand what we're talking about, they're thrown into an alphabet soup of confusing stuff that blows most peoples brains back to JavaScript and programming in the confined spaces of a Web browser, when the whole Internet is waiting for them.

I had to be patient. First we had to get Radio 8 out. Then we had to get some users. They needed to get to know each other and establish relationships (this is called blogrolling). Once all that had happened, then and only then could I begin to explain Web Services in a way that would make sense to people.

Well, all that has happened, and now we're ready..

But first a little story on how we got here.

Integrated software, APIs, networking 

As I wrote my Web Services tutorial, I realized I've been working on it not for a few days, but almost 20 years. (I don't even want to know the actual number.)

It began with a speech given by Microsoft's Bill Gates, in 1982. He was getting a lot of grief about Lotus 1-2-3, and in his brilliant and feisty way, he said that integrated software was a crock, what you really need are modules of functionality glued together by scripting languages.

I immediately recognized this as the spirit of Unix, but applied to user apps. Lotus was a spreadsheet. Its innovation, with the benefit of hindsight, was that it added a graph-drawing program to the spreadsheet idea pioneered by Visicalc.

Integration without an API. Gates was saying this is a crock. And he was right. (With a hat-tip to Mitch Kapor, Jon Sachs, Ray Ozzie, Bob Ramsdell, and all the early people at Lotus, it was a beautiful crock, a step on the path, a very important one.)

Then comes the Internet, and networking is easy. It takes a few years for this to settle in, then we swing back to the desktop, and Gates is still right, but instead of just thinking about integration on the desktop, we're now working on integration on the World Wide Web.

I've had as my goal, since starting UserLand, to turn the power of connecting apps over to the users. As a commercial developer, I learned that if a developer does the integration, users know that they're being steered into only one way of doing things, and the brightest and most interesting users, the people we like the most, want their minds to explode with infinite possibilities.

My goal was to give them those possibilities in such a way that the power could never be taken back. So inch by inch, we've built and rebuilt this idea, here's the latest incarnation.

At the top of a tall cliff 

So where are we now? Indulge me in an analogy.

You're standing at the top of a tall cliff looking down.

What do you see?

A bunch of little furry animals with parachutes giggling with glee?

Or a scene of carnage and drowning?

This tutorial linked to above, for many people, gets them to the point of having some very big questions about how this stuff will work. Me too. The Internet has the power, but how do we want to use it?

For people who are behind firewalls, you can create easy networks where your machines exchange information, and security will not be an issue because your firewall protects you.

For people who are full peers, your machines can have incredible new power on your behalf, and possibly for your friends and associates, but you must understand that power so you don't get hurt. A new culture of empowerment and awareness must go hand in hand. Security is the parachute. The height of the cliff is the fun. What a great ride we can have.

Anyway, a few facts have been established.

1. If you use Radio, you're accumulating information that you very likely want to share with some people.

2. There's nothing inherently hard about the technology. Creating and calling a Web Service is just like creating and calling a procedure in JavaScript or another scripting language like Python or Perl.

3. And the chicken and egg problem has been solved by the Radio community. It's not a question of who you would like to communicate with, for many, that question has been answered -- they're the people on your blogrolling list. Web communities, like the one that's forming around Radio, create the human associations that drive this kind of technology.

At the same time questions come up.

1. What role if any should UserLand play in helping the scripts find the Web Services of people you want to share information with? (We know how to do this, it's not hard to do, in fact we already have much of it working.)

2. What role should the Instant Messaging vendors play? They already have a big directory of users, we could tie into their networks, but would they like us to do this, or would they even let us?

3. How much of the work should be done by the local machine and how much by the cloud? Perhaps some users who are full peers would like to try being a community server for their friends? This is the most revolutionary approach of all.

Now, with this tutorial behind us, on the record, with people DIYing Web Services, we'll have the new community we wanted to work on this stuff. It's like the band Jake describes. Will you deny it, play along reluctantly, or support and build on the foundation?

As the Radio 8 community has formed in the last three weeks, I really have no doubt that the community will choose the last option, with gusto. ;->

Dave Winer

PS: DIY stands for Do It Yourself. It was a motto of the punk rockers. Later Nike offered a refinement. "Just Do It." I agree. It's time.