I spent Tuesday night, Wednesday and most of Thursday at MSN's Search Champs V4. The event is a forum for Microsoft to get feedback on various search related initiatives before they come to market. I did not apply to participate in the event, and I was surprised when Brady Forrest called to invite me, especially since I'm not a Windows user.

I debated with myself over whether or not to attend. I imagined all the flak that I was going to take from open source people for going to a Microsoft sponsored event. I pondered the prospect of actually helping Microsoft improve their products, which could be a double edged sword. And I disliked the requirement of an NDA. So why did I decide to go?

It basically came down to this: if we want the world to be a better place, then people have to start to talk to each other, listen to each other and learn to trust each other. The folks at Microsoft extended a very generous invitation to me (and the other Search Champs). I've been impressed with the degree of openness that I've seen in the post blogging Microsoft, and with the people at Microsoft that I know personally. So I took this opportunity to try and take a step toward the world that I want to live in. Part of the problem with the old Microsoft era was the monopoly situation. In search and many ares of web / internet innovation, Microsoft is the trailer (they are #3 in search). So fostering competition for Google seems like the thing to do unless I want to live under a different company's monopoly, especially in light of Yahoo essentially dropping out of the search race.

As far as the technical content of what I saw, there's a lot that was under NDA, and I think that the public stuff has already been outed by some of the other search champs. I've given up trying to win the first to report on X race. Other people are more motivated to break the news and get the traffic and accompanying ad revenue (still no ads here).

There are two things that I did want to comment on.

First:

Due to the recent DOJ subpoena of search engine logs, there was a discussion on this at the event. For more details and background, read Joshua Porter and some of the blogs that he links. The Microsoft folks were very credible when it came to the issue of whether they had done anything bad for users/consumers as far as releasing information that would allow people to be identified. Despite that fact, after last weeks media blitz, it appears to most of the world that Google is the company that will go to bat for users when it comes to privacy. The Microsoft folks talked about privacy policies and better ways of display privacy policies and so forth. But I didn't think they overcame the perception that they are kind of late on this issue. Even though I believe that Microsoft did the right thing in the recent case, after the conversation, I didn't feel supremely confident that they would go to the mat for users privacy. And that's the perception that they need in the market. For the record, though, I don't feel any better about Google or Yahoo on this score either.

Second:

Gary Flake, a Microsoft Technical fellow, gave a talk (ppt) predicting an Internet singularity. All the major points and many of the minor points have been well discussed in the various corners of the blogosphere that I hang out in, but the talk is worthwhile because it ties a whole lot of things together, and because it represents MSN's official vision for the Internet. He also announced a new unit at Microsoft, Live Labs, to be co-founded by MSN and Microsoft Research (MSR). While drawing from those two organizations, there are approximately 130 open positions for Live Labs. The Live Labs idea, mixing research and fast moving product teams seems very similar to Google. Google has a much smaller research group, but many people who would normally be in research groups are intermixed with product groups. It's interesting to me that Microsoft felt it necessary to have a new entity in order to accomplish the same kind of skill/role mix. Also, the Live Labs Manifesto emphasizes collaboration with the outside world, although I'm a little concerned that this will be weighted towards academic collaboration. I was particularly interested to note that Eric Horvitz who has done a lot of work related to the attention problem, is part of the Live Labs staff. Microsoft needs to kick it up a notch, and Live Labs is clearly one effort at making that happen.

I heard (and gave) some pretty blunt feedback on things that we were shown, and I have to say that the Microsoft folks really listened. It's not easy to hear someone say something negative about your work, but I heard many hallway conversations between the champs that said the same thing -- people really felt that they were being listened to. Of course, we'll all have to see if the feedback affects the products, but there was a real earnestness on the part of the Microsoft folks to hear what we had to say. I liked it.

I wasn't really sure what to expect as far as the other champs were concerned. I recognized a few names, but most of the other champs were folks that I was unfamiliar with. Because of that, I had no idea whether or not the majority of people were going to be hardcore Microsoft fans or something like that. But looked to me like there was a very broad distribution of people across the spectrum of positions, and I didn't really hear any sucking up to the people at Microsoft. It looked to me that Microsoft achieved their objective of getting tough feedback on the stuff that they wanted to show us. I definitely met some cool people - both champs and Microsoft employees.

As with most trips, I put up a few photos on Flickr.

The Foxmarks team now has a blog ...

There are lots of things going on in the building that houses OSAF. Now there's one more. Mitch Kapor and Todd Agulnick have been working on a Firefox extension to syncronize Firefox bookmarks between multiple computers. Foxmarks just went into beta.

I finally got around to watching a Ruby on Rails movie I waited so long that I got to see the new improved one. The demo is pretty impressive, especially compared to my web app experience, which involved either JSP (pre struts), Struts, and Python CGI (pyblosxom). The net result is that I'm now more motivated to look at Django, to see if it offers a similar kind of experience. Cool as Rails is, I'm not quite ready to learn Ruby (although lots of people that I respect like it). The parts that look perlish make me break out in a cold sweat. On the other hand Ruby has continuations and Python probably never will, so if I want to play with a continuation based web framework (and yes, I know about Seaside and Cocoon Flow), maybe Ruby will end up in my language pile.

I also have to say that it looked like TextMate has some cool moves. I wonder if those moves translate well to Python.

[via Dare Obasanjo aka Carnage4Life ]:

The fun with Greasemonkey has only begun. Dare reports on changes to Gmail that broke Stephen O'Grady's Greasemonkey scripts. Dare's response is:

I find this hilarious. Greasemonkey scripts work by effectively screen scrapping the website and inserting changes into the HTML. Stephen and others who are upset by Google's change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts. Yeah, right.

Repeat after me, a web page is not an API or a platform.

I pointed out the same in the comments to this post.

My friend David Temkin is the CTO at Laszlo Systems, and he's just started up his blog. His first post explains the difference between Laszlo and Macromedia's new Flex server.

I'm not as lucky as Sam, who's on a first name basis with luck, but I suppose that a last name basis isn't that bad, especially considering how many people in the world have my last name...

Gay and Troy don't live on Bainbridge Island, but they do live on Vashon Island, which makes them fellow islanders...

Go check out their web based aggregator MyWireService. Gzip enabled too.

Writing this blog has been a great way to find old friends and colleagues, or perhaps more correctly, for them to find me. Today's reconnection was David Temkin who was the manager of the NewtonScript toolbox and apps group when I worked on the Newton team at Apple. The connection with David actually goes back further than that. Julie knew David from our days at Brown -- they were both involved with the Brown Daily Herald.

These days, David is a co-founder and CTO of Laszlo Systems, which some of you may have seen on Marc Canter's blog. I think that Lazlo is a pretty interesting technology -- if it had been around when I was a CTO in 2000, we definitely would have used it with some of our customers.

Anyway, David is a smart guy, and it's good to see that he's taking another shot at changing the world.

Bill de Hora has a really good post on why is RDF useful, based in the context of quantifying the RDF Tax on Atom. Sometimes its not the knowing of a story, it's the telling of it, and I think that Bill's telling of the RDF story is helpful (at least it was to me). Aside from some enlightenment on RDF, I found this quote:

We'll start with a standard device for any technology that is not widely adopted - draw a spurious analogy to it and Lisp.

We'll always be the whipping boys...

I finally got around to picking up the concluding articles from Nathan Ashby-Kuhman's Article URLs Week series.

Here are his recommendations from Saturday, and a post on Nouns and verbs today.

The recommendations are sensible, and I want to adjust pyblosxom to put the categories before the dates if they occur. Makes more sense that way (at least to me).

Bill deHora and Don Park each posted suggetions for how to clean up the Atom Wiki. Leaving the issues with Atom aside, it was instructive to hear a little bit about how Wiki's can be used effectively.

Here are some wiki related posts from today's version of the blogosphere.

Bill de Hora describes how to do faceted classification with a Wiki.

Nick Lothian invents the Fiki: a Wiki that automatically figures out where links should be created

Sam picked up on Elizabeth Lane Lawley's post on Wiki backlash, and a flow of comments ensued. The major issue that's come out of this for me is the ahistoricism of Wikis, or put another way, the non-traceability of a Wiki. If people are working intensely with each other, then a Wiki is fine, but as the process runs out over time, and more people join the conversation, it's nice to have a way to trace how you got there. Some Wikis let you see all the changes, but its kind of like reading CVS diffs. You can do it, but it's not always the best way to trace the flow of discussion and decision. We've been using a Wiki at the ASF, which is my first real use of one, and it's been successfull for small documents that don't link to each other that much. But for big documents or multi-multi page layouts like the pie/atom/necho wiki, it's tough unless you can devote attention to watching the changes every day. I've found the same difficulty with the OSAF Wiki. The OSAF Wiki is easier, because there are far fewer small edits. It tends to be (relatively) infrequent big updates of large sections. It's like you need an out of band channel to hold the rationale and traceability of what's happening on the wiki. What that out of band channel is, I'm not sure. But then you need a way to link them to achieve traceability.

It's Article URLs week at Nathan Ashby-Kuhlman's blog. I'm just finding it at the end, but this is a good series of posts critiquing URLs at various sites. It's good food for thought for weblog and microcontent software developers.

Mark posted in response to my suggestion to merge Subversion with his client side WebDAV cache. I totally agree that the cache should be a general DAV+DeltaV cache. I just think that some of the Subversion / DeltaV stuff may help in resolving merge conflicts when you try to sync the cache after being disconnected for a while.

Mark Nottingham thinks that using WebDAV and a client cache in front of the WebDAV server could solve some of the offline/synchronization problems posed by mobile computers. He notes that the problems that arise in this approach have to do with versioning and items changing underneath. I think that if you combine the client cache with something like Subversion, which is already based on WebDAV and DeltaV, you might have an interesting solution. The problem of resources changing behind your back when you also have changes is what Subversion is all about. So "all we have to do" is build an offline aware client side cache for Subversion...

Panelists Tim O'Reilly, Jeff Barr, Jeffrey McManus, Sam Ruby

This panel had some disappointing moments. Sam Ruby didn't arrive in Portland in time for the panel. I think that the key point came up when someone in the audience said "You guys are platform vendors, and over the years, all of us have been screwed by platform vendors". A lot of discussion focused on the value of the data as opposed to the value of the software. The other theme that was repeated was that developers want these new platform vendors to guarantee that they won't take access to their service away, or to provide a service level agreement (SLA). Both of these would be bad recommendations for a corporate attorney to make. I still feel kind of fuzzy about exactly what the appproriate areas are here.

Some time into the talk I realized that the person sitting in front of me was Dave Winer. It seems to me that Dave was disagreeing with the positions of the panelists, and was agreeing with the challenges being presented by the audience. Since I've never met Dave in person, I introduced myself and we had a pleasant conversation.

Time to start another "bad RSS aggregator list". Today's list is a list of aggregators that don't follow the conventions for User Agent Strings, especially regarding the use of '/' to separate the user agent name from the version number. Following the convention makes it easier to track usage.

• Aggie
• BottomFeeder
• ChannelBuddy
• FeedReader
• RSS Bandit
• Straw
• nntp//rss
• vw-http

Jon Udell's OSCOM keynote slides are up. There are a few interesting items in there:

1. A section on titles in RSS and HTML versions of blog pages (I need to fix this in my blog).
2. The use of HTML doc titles and URI's to affect search engine results.
3. His argument for the use of xhtml:body in blog entries.
4. A nice series of XPath examples, and his repetition of what Joshua Allen and Dare Obasanjo already know about XPath based programming models for XML

Tim Bray wonders if home pages are going away. I think of it this way. A home page is like a brochure or advertisement that is used to get someone's attention -- as a starting point for a relationship. An RSS feed is what you use if you want to keep the relationship going.