Free Newsletters
Technology & Business Daily

InfoWorld
Log-in | Register

  Tuesday, August 06, 2002 

Ray Ozzie: Why?

From a remarkable essay by Ray Ozzie today, entitled simply "Why?":

We spent years and years at Lotus trying to convince people of the "higher order" value of collaborative processes, sharing, and KM. And I learned the hard way that fighting what appear to be natural organizational and social dynamics is very tough. Which is why eMail is the most popular collaboration tool on the planet: it works the way that people naturally want to work. And which is why Groove is built upon a client-side, personally empowering "email model" than an "app server" model. Mobile, instant, ad hoc, private. Effective collaboration tools strike a balance between personal need/behavior and collective/organizational need.

And so here I sit, typing into Radio. The personally-empowering client-side online/offline UI of Radio, in my view, like Groove, offers us a glimpse at a new model of interaction that may indeed make it more natural to post into a public space. Or maybe post into "semi-public" spaces, more naturally. Which is why I've been fascinated by what lies at the juncture between the eMail model, the Groove model, and the blog model.

I've spent many fewer years than Ray, but still a goodly number, trying to convey that "higher order" value. And I also learned the hard way that you can't swim upstream against what people naturally want to do. What is remarkable about the present moment is that the current may be shifting. Public or semi-public communication that once would have seemed odd or pointless can now (under the right circumstances) begin to be seen as normal and useful.

First, what kind of technology can be used to achieve a balance between "working in a virtual fishbowl" and "working in a virtual SCIF"? (Secured Compartmentalized Information Facility, for those not familiar with government lingo.) What are the useful points on the gradient between authentication and trust, and pseudonymity? What are the human interface mechanisms that might be employed in trust-centric environments such as Groove that might adequately communicate -- not just to the individual, but to the group -- that a certain set of shared information or activity is being shared outward? And how can this be done while still maintaining the OHIO principle? (Only Handle Information Once) - that is, if information must be entered in two places, it won't be.

These are all the right questions. To answer them, I think we have to do the experiment. When some of us tried one recently, it was illuminating all around, for Groovers and for bloggers. Effective communication always has required the ability to compartmentalize, to empathize with and belong to different groups, to manage multiple layers of meaning, to project a range of identities. Now that we have so many modes of communication to choose from, balancing the interplay of public and private modes has gotten trickier. For what it's worth, my gut tells me that we need to have a set of flexible frameworks in place, to get people using them in a variety of boundary-crossing scenarios, and then to adapt the technology as needs and opportunities arise.

 

 

Lawyers, bugs, and money

A couple of articles on the "why software sucks" theme came my way recently. First this one in Wired:

Buggy software is creeping into systems where failure can't be dismissed with curses and a sigh. Consider: Darpa is using wearable computers designed to beam tactical information to the "data visors" of combat troops. The devices run Windows 2000, an OS so flawed that its bug-cleansing "service packs" run to 100 Mbytes.

I'm no Microsoft apologist, but that's hardly fair. Win2K is in my experience the stablest NT since 3.51. The fact that its components are coarse-grained, and that service packs are therefore large, says nothing in itself about quality. But in any event, here's the punch line:

There's always the American way: Unleash the lawyers. At the moment, shrink-wrap licenses and clickthrough agreements shield software makers from damage claims - even if they broke it, you bought it. Just as the legal fallout from exploding Pintos shamed Detroit, exposing software to class-action lawsuits might induce Silicon Valley to code more cautiously.

The same theme appears in a Technology Review story by Charles C. Mann. (Incidentally, the Tech Review site asks $4.50 for the piece, but MSNBC doesn't.)

The real problems lie in software’s basic design, according to R. A. Downes of Radsoft, a software consulting firm. Or rather, its lack of design.

Really? I've seen intensive design lead to great success but also spectacular failure. Here, again, comes the appeal to the lawyers:

The lawsuits will eventually come. And when the costs of litigation go up enough, companies will be motivated to bulletproof their code.

I have no doubt that we need, and will get, more accountability, and that litigation will play a role. Likewise, I have no doubt that Bruce Schneier is right when he says that insurance will play a growing role in the security business.

For better and worse, though, we're entering the age of distributed software services. Accountability is becoming more diffuse. If we've done a bad job with the software that we fully control, how do we deal with the emergent behavior of software that we don't fully control -- that's just a piece of a larger puzzle? It's not wrong to demand as much accountability as we can get. We call software interfaces "contracts" and they might literally come to mean that in a legal sense. But lawyers can't solve the whole problem. We really are going to need some new tools and techniques for managing distributed complexity. The folks who are approaching this problem from the biological perspective are, I suspect, on the right track.

 

 

New home for this blog

Tonight I'm cutting over to the InfoWorld server. I regenerated the old verson of this site with pointers to the new location (above the navlinks). There will be some glitchiness I'm sure. In particular, I have to go over to the new place now and see about getting the RSS channels and items to link to the right place.

OK, done. Here are some observations:

- When you go back and forth between Radio's native xmlstoragesystem and an external FTP site -- as I've done several times during this exercise -- you have to apply the fix Lawrence documented each time you revert to the native mode.

- Each time you switch Radio does a complete upload.

- The <%headlinks%> macro failed when I went to the new location, producing:

<link rel="alternate" type="application/rss+xml" title="RSS" href="http://localhost:8080/rss.xml">

instead of the expected:

<link rel="alternate" type="application/rss+xml" title="RSS" href="http://weblog.infoworld.com/udell/rss.xml">

No big deal. It only occurs once, so I can just hardcode it if need be.

PS: Seems to have fixed itself. I would say you should plan to upload fully at least twice before concluding that something has not worked.

- It's cool that the rankings and referrals, both keyed to my usernum, continue working right through the transition.

- If you change the main template and regenerate your old site with a message pointing to the new site, remember to change it back when you regenerate the new site.

- I wish I could insert into UserLand's Apache the one mod_rewrite directive that would redirect everything to the new site :-)

- If you hardcode your site address anywhere, you'll get burned. I did this in a few places. For example, I had:

http://radio.weblogs.com/0100887/stories/2002/03/16/storylist.html

instead of:

<%radio.weblog.getUrl()%>stories/2002/03/16/storylist.html

- If you use GoogleBox, it'll recompute for every regenerated page. This was a bit of a drag, because I like to have each day's GoogleBox relate uniquely to something on that page. That'll be true going forward, but I've lost the historical searches. I might want to try a variant of GoogleBox that only recalcs recent pages.

- The channel and item links in my RSS files were pointing to the old site from the new site's feeds. That was because the RSS files aren't rewritten until you post something new. Once you do, they'll catch up.

PS: It seems theory was wrong. This category RSS file, for example, was updated even though no new postings were made to the category. So now I'm not sure what went wrong initially, and what it went right subsequently.

PPS: But look at this one, and this one! Go figure.

- I seem to have screwed up the old RSS file along the way. I really wish there were a way to replace its contents with:

<meta http-equiv="refresh" content="0;url=http://weblog.infoworld.com/udell/rss.xml">

As it stands, this might be the most disruptive part of the whole operation. Subscribers to the feed (evidently there are a goodly number) will need to resubscribe at the new address (standard version with short descriptions, alternate version with long ones). Come to think of it, there might be a way to make Radio upload an RSS file containing the redirect. But I can't face doing the experiment at 2:30AM...

- On the bright side, anyone who watches weblogs.com will pick up on the new location immediately. In fact, to avoid confusion while switching back and forth, I probably should have turned it off and then back on again.

- The local search isn't wired up to the new site yet. There's a robots.txt file on the infoworld server that blocks the spider. Hopefully, it can be modified.

 

 


Recent Entries


















































Sponsored Technology Links

 
 
 HOME  NEWS  BLOGS  PODCASTS  VIDEOS  TECHNOLOGIES  TEST CENTER  EVENTS  CAREERS   About | Advertise | Awards | RSS | Contact Us 

Copyright © 2008, Reprints, Permissions, Licensing, IDG Network, Privacy Policy, Terms of Service.
All Rights reserved. InfoWorld is a leading publisher of technology information and product reviews on topics including viruses,
phishing, worms, firewalls, security, servers, storage, networking, wireless, databases, and web services.

CIO :: ComputerWorld :: CSO :: Demo :: GamePro :: Games.net :: IDG Connect :: IDG World Expo
Industry Standard :: IT World :: JavaWorld :: LinuxWorld :: MacUser :: Macworld :: Network World :: PC World :: Playlist