This season, Mitch Kapor is delivering a trilogy of lectures on “Disruptive Innovations I Have Known and Loved” at the UC Berkeley School of Information. I missed number one, which covered Kapor’s role in the early years of the PC (podcast audio is here). Wednesday evening I made it to the second lecture, which focused on the rise of the Internet, and particularly the early, pre-Web Net era — the time when the Internet was considered a hopelessly geeky backwater for Unix heads and the golden road to the future lay with outfits like Prodigy and Compuserve and AOL. (The third lecture, on virtual worlds, is on Nov. 28.)

I first heard Kapor speak on this topic in the summer of 1993, at the Digital World conference in Beverly Hills, where, amid a throng of cable executives and Hollywood honchos and telco bureaucrats, he was the only speaker to make the then-fringe-y claim that the Internet offered a better model for the networked future than the “Information Highway” then being touted as an inevitability. His concern — one that resonated with me at the time — was that we try to create something better than “500 channels with the same crap that’s now on 50,” some system that would not only be open to corporate entertainment and commerce but would offer “a migration path for the weirdos and the outsiders to get into the system, mature and blossom.”

Kapor’s espousal of the Internet in those days was part of a wider activist portfolio; he’d cofounded the Electronic Frontier Foundation only a few years before. But it also stands as one of the more accurate acts of long-shot prophecy in technology history. At his talk Wednesday, Kapor looked back on that time and filled in some of the details of his own role.

He’d joined The Well early on, in the late ’80s (a year or two before I did), and “lost the next two weeks of my life” absorbed in the online conversation. A bit later the Well gave its members Internet access, making it one of the only ways that members of the general public could connect to that network. Around then the National Science Foundation began an aggressive project to open the Internet out to the public and to private businesses. In 1992 Kapor was spending a lot of time in Washington doing EFF work and got to know the founders of UUNet, which was one of the first firms to resell Internet connections to other companies.

“Why,” Kapor asked, “wasn’t this an obvious investment?” He tried to interest John Doerr at Kleiner Perkins, but Doerr “wouldn’t take the meeting.” Kapor himself ended up putting some of his own money into the company. He provided no details, but it must have been a lucrative move: UUNet went public in 1995, shortly before Netscape, and was gobbled up in an accelerating series of acquisitions that made it part of Worldcom, in the days when people thought Worldcom was taking over the known universe. (Today what’s left of Worldcom — after a storied detour through the courts and various name changes — is part of Verizon. Full timeline here.)

My recollection of those days — when I was a recent immigrant to technology journalism from the arts — was that, much as I rooted for the Internet-style future as a healthier one for our culture, it was awfully hard to see how anyone was likely to make money via such a system. Kapor said he looked at the open network’s advantage in generating innovation and encouraging participation and concluded, “I think this is the one that’s going to win.” He was right.

It’s incredibly useful to keep that era in mind today, I think, because it provides not just a heartening saga of the triumph of free expression and open participation, but also a clear case in which those ideals were more practical, too.

The Internet’s victory over the services we now derisively dismiss as “walled gardens” was an instance, within recent memory, when the idealists weren’t hopelessly outgunned by the cynics — when, in fact, the idealists turned out to be the realists, and the cynics took a bath. That’s worth keeping in mind as today’s tech industry — powered by Google’s success and enthralled by innovators like Facebook — races through yet another cycle of debate over what “open” really means.

I’ve been laying low this week completing a draft of a new book proposal. More on that as we get closer to the finish line. This is the first year I’ve not attended the Web 2.0 conference, but, you know, I need to focus — and I think I wasn’t that eager to hear Rupert Murdoch, anyway.

In the meantime, I’m happy to report that I have successfully managed to get Ecco Pro running on a Mac via Parallels. I actually achieved this goal a decade ago using Virtual PC, but boy was it slow! The Parallels set up, by contrast, is snappy and, so far, foolproof. Thanks to all of you who advised me on this dilemma. Very exciting. (The “coherence” mode of Parallels is remarkable — its puts the Windows taskbar and WinXP program windows on an equal footing on the Mac screen with the OSX stuff, turning your display into a sort of operating-system hermaphrodite.)

As I close in on my next book-project goal, I would also like to draw your attention to this quotation from William Gibson (in a Washington Post interview from last month), musing on the persistence of the book:

It’s the oldest and the first mass medium. And it’s the one that requires the most training to access. Novels, particularly, require serious cultural training. But it’s still the same thing — I make black marks on a white surface and someone else in another location looks at them and interprets them and sees a spaceship or whatever. It’s magic. It’s a magical thing. It’s very old magic, but it’s very thorough. The book is very well worked out, somewhat in the way that the wheel is very well worked out.

From the earliest days of the Web to the present, there’s been a fundamental split between people who get the value of “human-readable URLs” and people who don’t. A human-readable URL is a Web address that tells you a lot of useful information about the page it represents. For instance, Salon URLs always tell you the date an article was posted, the section of the site the article appeared in, and a few words describing the subject matter of the article. By comparison, the typical URL at, say, CNET, looks like this: http://reviews.cnet.com/4520-10895_7-6782817-1.html. It is, essentially, human-unreadable.

In the old days, writers and editors who actually knew and used HTML always appreciated a good human-readable URL; and typically, for the ugly gibberish URLs, we had to thank (some) software architects and (some) publication managers who’d never hand-coded a link themselves. At Salon, we editors knew we’d be typing (and proofing) a zillion of those URLs ourselves; we insisted on something we could work with. (Our developers “got it” too.)

The cause of human-readable URLs got a great shot in the arm when sites began trying to optimize themselves for Google, because Google gives a little extra weight to text hints in URLs. So a lot of sites (like the New York Times) that had a history of human-unfriendly page addresses began to do better.

Today, though, we’re taking a step backwards, or at least sideways, in the cause of human readability, thanks to the growing popularity of the “tinyurl.”

When the tinyurl first crossed my radar I understood it to be a convenient way to tame unmanageably long Web addresses. (The Tinyurl site focuses in particular on how long Web addresses break in email messages.)

That’s all fine. But the tinyurl giveth and the tinyurl taketh away. When you encode a Web address as a tinyurl you’re hiding its target. Normally, when I read an article on the Web that has a link, I’ll hover my cursor over the link to see where it points. Even on a site with human-unfriendly URLs like CNETs, at least I can see that the link points to CNET.

With a tinyurl, I know nothing about the link except what the author chose to say about it. I can’t tell if it’s a reference to an article I’ve already read. If I want to find out, I have no choice but to click.

My sense is that tinyurls have grown in popularity with the rise of Twitter (where the strict character limit of messages means you don’t want to fill up a whole message with an URL), as well as the growing use of mobile devices for Web-posting activities. These are perfectly understandable reasons. But still, each time I see a tinyurl I think, there goes another tiny piece of the Web’s transparency.

Jeff Jarvis reminds us that Moore’s Law is not: “Chips double in speed every 18 months.” Gordon Moore first predicted that the power of microprocessors (as measured by the number of transistors you could cram into a particular space on a chip) would double once every year; later he revised it to once every two years. Somehow — most likely, thanks to careless popular journalism — in the popular imagination this has become set in stone as an every-18-month prediction about chip speed.

Jeff asks:

So I raise again the question of how we can better map content and corrections. How does Moore assure there is a definitive statement of his law? How do we know it comes from him? Once it’s acknowledged as correct, how do we notify those who got it wrong so the can correct it and start spreading the right meme? Truth is a game of wack-a-mole.

I’ve been playing that game for a decade. Here’s a Salon column from October 1997 that addresses it. Here’s a post from just this past spring.
Here’s two pointers for good reference information on Moore’s Law: one from Greg Papadopoulos at Sun and the other from ExtremeTech.

If we all keep repeatedly linking to the good information maybe we can demonstrate that Gresham’s Law does not apply to information, and that good info can drive out bad.

But, you know, I won’t hold my breath.

A brief note to express my support for the Alameda County Computer Resource Center, an outfit not far from my home that has done creative work over the years in restoring and finding new homes for donated or broken electronic equipment that would otherwise be headed to landfill. I’ve donated my share of stuff to the ACCRC over the years. Now it seems that the center has been targeted by a government inspector for technical infractions of the regulations regarding recycling centers.

I’m no expert in that area of the law. But I know a good organization when I see it. ACCRC is such an outfit. If there are issues or problems with how ACCRC does its thing the government should be helping it achieve compliance, not threatening to shut it down.

Dale Dougherty of O’Reilly has the scoop. You can also read ACCRC founder James Burgett’s version of the saga. I’ve already written to the state agency involved; Burgett’s blog has more info.

Apologies for slow blogging. Been working in parallel on a number of important tracks. Some interesting stuff coming up shortly. In the meantime, I will trouble you with this rant on a trivial annoyance.

If you use a Windows computer for any period of time, your system tray — the little box next to your clock on your task bar — will get clogged up with a million and one icons you don’t need or care about. The tray is useful for stuff like “safely remove hardware”, but it’s stupid as a location for applications. That’s what the “quick launch” icons are for; that’s what your “start” menu is for; that’s what any number of other utilities are for. When an application pushes its icon into the system tray it’s almost always redundant — a case of corporate overreach.

So when renegade applications insist on putting their icons in the system tray anyway, in a sort of desktop manifest destiny policy, I get peeved, and I try to figure out how to banish them. Usually, though not always, it’s possible.

I hate to think of something as routine and plumbing-like as Quicktime as a renegade application, but in this way, at least, it is. I went through the “get this thing out of my tray” routine with Quicktime a long time ago; I found the “preferences/advanced” dialogue that let me express my wishes; I did so and thought that was the end of it.

Today, suddenly, it turned up again. I soon realized I’d recently allowed Apple’s auto-update install a new version of Quicktime. OK, I’m willing to turn this sort of routine patching and maintenance over to the software companies — I’d rather they worry about it than have to worry about it myself.

But how rude is it to overwrite a user’s preferences and force the reappearance of an annoying icon that you’ve already ordered the program to suppress? Why does Apple do this stuff? To me this is just one tiny but telling instance of the company’s perpetual dance between delivering useful innovations and behaving as a desktop Big Brother that pretends to know better than you do what you really want.

Me? I just want Apple to keep its fingers out of my system tray.

Longtime readers here know of my interest in the subject of outliners and in particular my dedication to an old program called Ecco Pro. I used it as my main organizer for my first book, and now, as I begin work on a new one, I find myself turning to it once again. (If you want to understand why, Andrew Brown’s recent piece in the Guardian offers a thorough explanation.)

Ecco devotees long hoped the program might be open-sourced, but the hopes never materialized. Nonetheless, in one of those twists and turns that keep the software world interesting, there has been much movement in the Ecco world in recent months — and, even without the code being open-sourced, there’s the first significant new work on the program in years.

Here, as far as I can tell, is what happened: A programmer who goes by the handle “slangmgh” posted a message to the Yahoo Group “ecco_pro” on April 16th: “I write little utility, have upload to the files directory! It’s only work for EccoPro v4.01.”

The file was called “EccoPro extension.” It included a half-dozen significant fixes and upgrades to the program. A day later, he’d uploaded a 1.1 version of his “little utility.” Today, he is on 3.6 or so. His furious pace of development has involved, if I understand correctly, the incorporation of the Lua scripting language into the extension. It’s all made possible by the essential solidity of the original program and the API hooks its creators provided — so that, even though the original Ecco code can’t be changed, it can still be built upon.

The only downside to the whole thing is that “slangmgh” is plainly not a native English speaker and so his explanations of the changes and features are sometimes difficult to follow. In recent weeks, other members of the Ecco support group have stepped forward to provide better documentation.

There you have it: an orphaned program that hasn’t been touched in a decade but that still has a devoted community of users suddenly starts evolving again in the hands of an energetic programmer. I don’t know where the Ecco story will ultimately lead but I’m delighted to see it still unfolding.

As David Bowie once sang:

We’ve got five years — my brain hurts a lot
We’ve got five years — that’s all we’ve got

One of the arguments I often hear raised against Dreaming in Code’s contention that “software is hard” is what I call the “Web apps solve all our problems” stance. In this view, the Web 2.0 wave is not just about user convenience and nimble companies — it represents the final triumph over the beast of software-project delays and headaches, thanks to the ease of prototyping, the fast upgrade cycle and the tight feedback loop of user input characteristic of this approach.

No sane observer denies the importance of this trend. But I’m always a little skeptical of the pollyanna-ish view that moving our software onto the network and into the browser puts all of our old problems out to pasture.

Tonight as I caught up on my feeds I noticed two items from TechCrunch that resonated. First, Yahoo has taken its revised Web-mail interface out of beta, after years of development. (Farhad Manjoo at Salon’s Machinist has a good review.) Yahoo’s new mail system is based around that of Oddpost — a small startup that pioneered the “Ajax”-style Web interface back in 2002 before being acquired by Yahoo. I remember looking at it then and thinking, wow, this is a big deal. And it was, as the concept of updating data within a browser window without refreshing the entire page quickly spread over the next several years. But it took Oddpost from 2002 to 2007 to mature into Yahoo Mail.

Meanwhile, another key Web application that started up only a little after Oddpost, Bloglines, has introduced the first major upgrade to its interface since — well, since it began. Bloglines got acquired by Ask Jeeves years ago, and has had some problems keeping up with its masses of users and data. Even now, its new design — which looks very nice on first glance — is just entering a beta phase.

Put this together and it sounds like, after the phase of “gee whiz, we got a great idea, let’s buy a domain name and put it out there” — once reality kicks in — major Web applications have an upgrade cycle of once every five years or so. Small startups get acquired and face organizational integration challenges; small applications face the uphill struggle to scale for masses of users; and services sit through long “beta” periods to test interface choices, iron out bugs and see how they can handle running under load.

I’m not knocking Yahoo Mail or Bloglines here. But this is sobering data for those who argue that the advent of Web-based apps and services drives a silver bullet through the heart of software’s problems. Five years is no sprint. Funnily enough, it’s roughly the timespan of Windows Longhorn/Vista — or Chandler, the program I wrote about in Dreaming in Code.

I love the convenience of RSS, but one of the problems of life inside the feed reader is that once you find a few dozen feeds you want to follow, the cost of adding a new feed becomes too high. When you find a site you like, you think, “Gee, I want to subscribe — but do I really want to add another feed? I can’t keep up with the ones I have!” (I know that the casual “River of News” approach, where you just let the stuff stream by you, would mean no guilt over not keeping up, but I haven’t achieved that level of Taoism detachment yet.) So over time we stop adding new feeds to our RSS diet. This perpetuates the “first-mover advantage” and makes it harder for newcomers to gain subscribers. (They still can, and do, of course.)

Here, as I mentioned in my BarCamp post, is my idea for a feature that RSS readers should but don’t (as far as I know) have: a sort of “New Feed Probation” or “Test Drive” zone. New feeds you subscribe to are automatically placed here (unless you deliberately put them somewhere else). They remain here for a preset time period (a week, a month, whatever you choose). At the end of that period, your reader flags the feed for you, tells you how much you’ve read it, and asks whether you want to keep it or not. You can see whether you actually ended up reading much of it during the “trial period,” and make an informed choice.

Sure, you could do all this yourself, manually. (I do, sometimes!) But wouldn’t it be nice if the reader helped you with this clerical task — and, in the process, encouraged you to explore new information sources and blogs?

BarCamp Block was extraordinary — I spent Saturday morning and afternoon there. (Family commitments kept me from the Saturday evening and Sunday events or I’d have stayed all the way through.) This “unconference” was a free event, with “programming” supplied ad hoc by the attendees themselves, and a schedule devised on the fly at the start of the weekend.

Sounds like chaos? “Cult of the Amateur” mediocrity? No way. Think instead of the energy, ideas and conviviality that can flow from a crowd of smart people when they’re given a chance to make things up as they go along.

The event was huge — hundreds of people gathered primarily around one block in downtown Palo Alto centered on the SocialText offices. No one could possibly have attended more than a fraction of the sessions. Three highlights for me were:

• A discussion among about a dozen people at the Institute for the Future office about coping with RSS overload. This was started by someone who works at a company that’s producing a sort of personal (or collaborative) filter for your RSS feeds (so you can train your feed reader to only show you posts on a set of topics that you’re interested in). I have no use for such a product; when I subscribe to a feed I’m happy if the blogger surprises me with interesting stuff that I didn’t know I was interested in (and that I’d never see with a feed filtered by preset criteria). But the idea led to a good exchange in the room, and helped crystallize my thinking on a feed-reader feature that would make a big difference (for me, anyway!). I’ll post separately on that.

• Tantek Celik led an open discussion about the state of microformats, a subject I’m increasingly interested in. This is one of those Web-technology phenomena that at the moment is intelligible almost exclusively to geeks, but I think that — like blogs or RSS — it will become much more widely useful and adopted in the next few years. I’ll also be writing more on the subject later.

• Finally, Brad Fitzpatrick, David Recordon and Joseph Smarr led a session on “Opening the Social Graph.” They were talking about a pragmatic, we-could-build-it-now solution to the much-discussed problem on the “social web” of proliferating networks. Who wants to join another social networking site when, each time you do that, you have to painstakingly rebuild your list of “friends” or relationships? Isn’t there a way to make this information portable? LiveJournal founder Fitzpatrick’s recent paper on this subject proposed one approach. At BarCamp Fitzpatrick and his collaborators talked about setting up a nonprofit organization that would serve as the hub for the backend data services his solution would require. Another fascinating subject worth more future in-depth posting. (No one seems to have posted notes on the session, so I’ll try to add mine to the conference wiki soon.)

So there you have it: I spent less than a full day and came away with my head buzzing and three major areas of material to pursue more deeply. I don’t think any of the old-fashioned, CEOs-on-stage conferences I’ve been to match that record.