Richard MacManus has a blog post entitled Netscape Community Backlash where he writes

I've been tracking the release of the new Digg-style community news site Netscape.com, because there is a lot of backlash within the Netscape community about it. A story called Netscape's Blunder!!! was number 1 on Netscape.com for a while and the latest post on the homepage is entitled A Request by the Netscape Community to Bring Back Our Netscape.com. There's another Netscape story currently on the homepage called Netscape Reborn: Why? Why? Why?. The backlash has presumably led to this message currently on the right of the homepage, from the Netscape team:

"Attention Netscape users Your Netscape mail hasn't gone anywhere, you can find it right here! Also, My.Netscape and your Stock Quotes are still online as well."

There appears to be a genuine feeling of betrayal by the (very large) set of users who have had Netscape.com as their homepage for some time. Indeed I've been getting comments on my own posts and even emails from Netscape users, upset about the change to the Digg style.

All of this shows how passionate people can get about their Web homepage - and they're just as much a 'community' as the Digg.com users are. It's just that they like the old-school Web homepage, not the new Digg style. Also what this tells me is that while a lot of us geeks and 2.0 types are addicted to our own technology (and our own voices, to be honest), it's pretty darn obvious that A LOT of people want to stick with the status quo.

This is one of those reasons why I believe that Danah Boyd's essays should be required reading for anyone interested in building social software. I disagree with Richard MacManus that the problem is that a lot of people want to stick with the status quo. I agree that it plays a part but the real problem is that AOL made a drastic change to software that was an integral part of their users lives in such a draconian manner.

People grow attached to the software they use and the online community that exists around that software. Heck, I've been using My Yahoo! for the past five or six years and have only partially switched to Live.com even though I made a conscious decision to switch*. I'd personally be pretty irritated if one day Yahoo! radically switched things around in a desperate attempt to jump on the Web 2.0 bandwagon and I'm a tech geek.

AOL should have engaged with their community of users before launching the revamped Digg-like version of Netscape. At the very least, the company should have considered using an alternate URL for the site and not the valuable Netscape.com domain or done some A/B testing to see if users liked the switch over or not. It may be that the people complaining are a vocal minority but something tells me that they aren't given how drastic the change to the site has been. Perhaps making Live.com and MSN.com separate sites wasn't such a bad idea after all. :)

* I use Live.com at work and My Yahoo! at home.

 

Last week I attended the Kenny Chesney concert with my girlfriend and we even took some photos before the concert. A couple of coworkers answered my call for country duds and I got some hats, shirts and a pair of cowboy boots contributed to the cause. I probably should write a review of the concert but its hard for me to judge the musical quality of a concert that had people singing songs like She Thinks My Tractor is Sexy and Save a Horse, Ride a Cowboy. However here are a few observations from the concert There were supposedly over 40,000 tickets sold and it looked like there were tens of thousands of people there. However the crowd wasn't very diverse, it was almost all white guys and white gals. I was the only black person I saw the entire 5.5 hours we were there. Besides Kenny Chesney there was also Gretchen Wilson, Dierks Bentley's, Big & Rich, and a surprise appearance by Uncle Kracker. The crowd seemed to get into all the performances although it was hard for me to since I didn't know most of the songs. I think I saw someone with the worst job in America. One of the concert goers vomited and it seems there were no safety cones available so one of the stadium employees stood over the vomit so that concert goers wouldn't step on it. Unlike hip hop concerts this one started on time. We got there at 5:30PM and we had already missed half of Dierks Bentley's set. Not only did it start early, it ran until 11 PM which means we got our money's worth. This was the largest gathering of people wearing cowboy hats I'd ever seen. This was doubly a surprise given how rarely one encounters cowboy hats in Seattle.

 

Cory Doctorow has a blog post up on Boing Boing entitled Mark Pilgrim's list of Ubuntu essentials for ex-Mac users where he writes

Mac guru and software developer Mark Pilgrim recently switched to Ubuntu Linux after becoming fed up with proprietary Mac file-formats and the increasing use of DRM technologies in the MacOS. I've been a Mac user since 1984, and have a Mac tattooed on my right bicep. I've probably personally owned 50 Macs, and I've purchased several hundred while working as an IT manager over the years. I'm about to make the same switch, for much the same reasons.

You could probably write an entire Ph.D dissertation on what would motivate someone to tattoo a corporate logo on their arm. Maybe I should buy a Mac just so I can figure out what all the hype is about.

 

It seems the Web API authentication discussion has been sparked up all over the Web by the various announcements of Windows Live ID and the Google Account Authentication for Web apps . In his blog post Google's authentication vs. Microsoft's Live ID Eric Norlin writes

Recent announcements of Google's authentication service have prompted comparisons to Passport, and even gotten to Dick Hardt (of "Identity 2.0" fame) to call it the, "deepening of the identity silo." I'd like to contrast Google's work with Microsoft's recent work around Live ID.

Microsoft's Live ID *is* the old Passport — with a few key changes. Kim Cameron's work around the identity metasystem has driven the concept of InfoCards (now called CardSpace) deep inside of Microsoft. In essence, Kim's idea is that there is a "metasystem" which utilizes WS-Trust to translate tokens, so that all identity systems can interact with each other.

Of extreme importance is the fact that Windows Live ID will support WS-Trust, WS-Federation, CardSpace and ADFS (active directory federation server). This means that A) Windows Live ID can interact with other identity metasystem implementations (Open Source versions, for example); B) that your corporate active directory environment can be federated into Windows Live ID; and C) the closed system that was Passport has now effectively been transformed into an open (standards-based) and transparent system that is Live ID.

Contrast all of this with Google's announcement: create Google account, store user information at Google, get authentication from Google — are we sensing a trend? While Microsoft is now making it easy to interact with other (competing) identity systems, Google is making it nearly impossible. All of which leads one to ask - why?

Perhaps it's because there are now so many old-school Microsoft people at Google? ;)

On a more serious note, I suspect that the Google folks simply didn't think about the federation angle when designing the authentication model for their APIs as opposed to this being some 'evil plot' by Google to create an identity silo.

 

Julien Couvreur has a blog post entitled Web API authentication for mashups where he talks about authentication and Web APIs. This is a topic that is near and dear to my heart since getting this right is very important for the Windows Live developer platform. Julien writes

Authorization techniques:

A number of techniques for controlling access to web APIs are generally used: user authentication cookies, API keys and crossdomain policy files. The problem is that API keys and crossdomain policy files are too restrictive because the service needs to decide which third-parties to let in.

On the other end, access control based on the user authentication cookies are very open to un-planned integration, but also create a huge phishing risk. This is a classic example of the confused deputy problems that appear in principal-based security models.

As a result, most web APIs today don't involve any user data (search, maps, ...) or non sensitive user data.

Yahoo APIs:

Yahoo appears to be tackling the challenge with its announced "browser-based authentication". From the little information I could gather so far, it seems less of an authentication than an authorization system. Unlike cookie based approaches, which give access to any agent presenting user credentials (principal-based security), it appears to follow a capability-based security model, which only grants access if the agent uses the proper "secure handle" or "capability" to call the service. Such capabilities are sufficient to gain access to the service and don't need any additional authentication, they are communicable tokens of authority.

The devil is in the details when talking about authentication, authorization and Web APIs. When I first heard about the Yahoo's proposed authentication model for Web APIs at their ETech 2006 talk entitled Building a Participation Platform: Yahoo! Web Services Past, Present, and Future, I thought it sounded similar to the model used by Passport Windows Live ID. In both approaches instead of applications prompting users for their credentials (username/password combo), the user signs in to the primary service which then returns an opaque token to the target application that identifies the user and gives the application permission to access the user's data. However, having a fine grained access that can give applications access only specific services and can revoke permission given to specific applications seems to be richer than what I've seen offered by  Passport Windows Live ID. This is nice but it's to be seen how easy this will be for users to understand or for applications to manage.

From my perspective there are two primary goals an authentication model for a family of Web APIs must satisfy

1. User credentials are sacred and must be protected at all costs: A security mechanism is only as strong as its weakest link. This means that it is extremely unwise to build an authentication model that has applications built on your APIs to request username/passwords or other credentials from users directly. The last thing you want is for anyone with a copy of Javascript for Dummies to be able to legitimately ask your users for their credentials then store them insecurely. In addition, if users get comfortable with entering their credentials in all sorts of random places then it makes them more susceptible to phishing attacks. This is one of the reasons services like Meebo are worrying to me.

   It should be noted that in certain cases, the information hosted in the service may not be very valuable in which case this tennet can be waived. For example, the NewsGator API expects applications to prompt users for their credentials and then pass those along when interacting with the service. Since the user information hosted in the service is primarily a list of RSS/Atom feeds and their read/unread state, the value to attackers is extremely low and there is little need to build a sophisticated authentication model for this service.

2. Do not discriminate against any platform or any device: In todays world, end users interact with online services using a variety of devices and platforms. Each device and platform has different strengths and limitations but is important in its own right. Online services like email or instant messaging have witnessed the rise of multiple access models from desktop applications running on PCs to applications running on mobile devices, from JavaScript code running clientside in a browser to web service calls being made from one server to another. In many cases, the average user may go back and forth between all these access modes within the course of their normal usage of the service. For example, I check my email using Outlook Web Access, Microsoft Outlook and my Audiovox SMT 5600 during the normal course of my work day. 

Thus far I have not seen any Web API authentication model satisfy both goals. Based on my understanding from the ETech talk, the model proposed by Yahoo! fails to meet the second goal above because it is browser based. Before being accused of bias, I'll also point out that from reading the initial documentation for the Windows Live ID service it also fails to satisfy the second goal because Microsoft has only announced SDKs for server-to-server calls and desktop clients [both of which I assume will only target servers or PCs running varieties of Windows]. 

Providing a comprehensive authentication story for a suite of Web APIs is a hard problem.

 

The Windows Live Custom Domains team has a post on their blog entitled Bye bye beta….Custom Domains v1 has launched which states

We’re leaving the “Beta tag” blanket at home.  That’s right…thanks to your beta testing and feedback; we’ve now officially launched Windows Live Custom Domains.  Our colleagues over in Messenger kicked off the Windows Live launch season last week.  Along with the launch of OneCare and Live Favorites, we're excited to continue the momentum.  Windows Live is about the Web, the way you want it.  Personalization is a key piece here, and let's face it...your identity online is central to that.  Custom Domains enables people to use all of the Windows Live and MSN services they want with an ID that's as unique to them as they want it to be.

For those who aren’t familiar with Custom Domains, we provide free hosted e-mail for your domain.  Let’s say you own the domain name, “wingtiptoys.com.”   With Custom Domains, you get unlimited, free e-mail accounts at that domain.  You can open accounts for sales@wingtiptoys.com, owner@wingtiptoys.com, etc.  Oh wait, did we mention that it’s free?  This isn’t one of those “free during beta” trial offers.  This is free for life. 

New Feature: Open Membership

We’re jazzed about a new feature we’ve added called Open Membership.  How does this work?  Let’s say you run a website called “soccerfan.com.”  Your users love your site and want an e-mail address @soccerfan.com.  Prior to this launch, each user would have to request an e-mail account from the administrator.  Then, the admin would manually approve and create each account.  We’ve made things much easier all around with this launch...With the Open Membership featured enabled, we provide URL links so users can automatically sign-up for an e-mail account @soccerfan.com.  Admins no longer have to burden with the manual creation of email accounts, and users get accounts immediately.

Congratulations to the team, it's good to see more Windows Live services coming out of beta. I really like this service but I'd love to see it expand to cover other Windows Live properties. For example, will I be able to ever use my own custom domain for my Windows Live Space?

 

The Windows Live Local/Virtual Earth team has a blog post entitled Free Phone calls at WLL which states

A new release of Live Local went out over the weekend. Mostly minor bug fixes, but a few new features made it in as well. One of the more interesting is the ability to phone any business for free. Using it is easy - do a business search by name or category and in the result panel will be a 'Call for Free' link next to each business listing. Each pushpin popup on the map will also have the Call for free link. When you click it you specify your phone number  -the system will dial both you and the business and connect you. Once you've made your first call, you can rapid dial businesses without having to re-enter your phone number.

Windows Live Local is definitely my favorite online mapping service today and probably the only Windows Live service I can say is head and shoulders above the competition. Kudos to everyone on the team who have built such a killer service in such a short time.

 

Quentin Clark has posted a new entry entitled Update to the Update on the WinFS team blog that answers some of the questions that have been raised since his post on Friday about the status of WinFS. He writes

Is WinFS dead?
Yes and No. Yes, we are not going to ship WinFS as a separate, monolithic software component. But the answer is also No - the vision remains alive and we are moving the technology forward. A lot of the technology really was database stuff – and we’re putting that into SQL and ADO. But some of the technology, especially the end user value points, are not ready, and we’re going to continue to work on that in incubation. Some or all of these technologies may be used by other Microsoft products going forward.

Does your plan for WinFS have any impact on Windows Vista?
There is no impact on Windows Vista. We announced back in August 2004 that WinFS would not be in Windows Vista.

Will the "Relational Filesystem" ever be in Windows?
Hey – we are very busy finishing Vista, and just aren’t ready to talk about what comes next. The vision for a richer storage in Windows is very much alive.  With the new tools for searching and organizing information in Windows Vista, we are taking a good step towards that vision.  

Why are parts of WinFS going into SQL Server?
We have a vision around data that guides us we call the "Data Platform Vision". We’ve been talking with customers about this for some time, and we have heard consistent positive feedback. It was clear that the integrated storage and automation features of WinFS will help SQL Server deliver on the "Beyond Relational" and "Continuous Availability and Automation" promises of that vision. We decided to focus resources on delivering these technologies to our customers as part of the Data Platform Vision in the near term.

Why did Microsoft announce this now after talking about WinFS at TechEd so recently?
When we were at TechEd, we had not made the decision. Sure, it was under discussion, but we did not have all the information we needed and we had not made the call yet. We did share the news as soon as we had the final word. We could have waited longer to disclose the information and made the change in plans less of a contrast, but we chose to notify people as soon as we could. This is why we used the blog and didn’t fire-up the big MS PR machinery – that takes time.

I commented internally that the response to Quentin's original blog post shows that there has been a discrepancy between what the WinFS team has been working on and what the developer community believes they were delivering. I got to read a draft of this blog post before it went up and it does a better job of stating what has happened with WinFS and even seems to have incorporated some of my feedback. I hope Charles Miller doesn't think this post is also un-blog-like. :)

 

I was reading Charles Miller's post entitled We Come to Bury WinFS... where he wrote

The first thing to strike me about the blog post announcing the end of WinFS as a Vista feature is how totally un-blog-like it is.

Every comment (bar one) got the point. WinFS is dead. Its carcass is being split between SQL Server and ADO.NET, and the relational filesystem that was going to change the way we use computers is no longer just postponed to be shipped after Vista, it’s gone.

The blog post itself, however, is written entirely in marketing-speak. The engineer talks about how super-excited the team is about this "new direction", how encouraging this news is, and leaves the fate of Vista for a final, particularly obfuscatory paragraph. Nary a word is allowed to suggest that the last nail in the coffin for Vista’s most eagerly anticipated feature might be a huge let-down to those people who have been watching it slip further and further down the schedule since its fanfare announcement as a part of Longhorn three years ago.

Did Microsoft forget everything Scoble was supposed to be teaching them, so quickly?

Every now and then, you’ve got to put out a mea culpa. You’ve promised something that turned into something else, or that you changed your mind about, or that you just can’t deliver. In the mass-media world, you do this by spinning the story as positively as you can. The message will be filtered by intermediaries before it reaches the public, and it’s expected the journalists in the middle will get the point, pulling quotes from the positive spin to offset the otherwise negative message.

I agree 100% with Charles Miller's sentiments about the blog posting on WinFS. This seems to be another example a case where Microsoft overpromised and underdelivered failed to deliver but even worse instead of owning up to this, the blog post spins this as being what customers want. From reading the hundred or so comments and trackbacks to Quentin Clark's post it doesn't seem that there are many people who are excited or encouraged that what once was touted as a pillar of Longhorn is now just another checkbox feature in SQL Server. This makes Microsoft look bad to developers because it means that we are either insulting our developer customers by thinking we can pull the wool over their eyes in such a blatant way or even worse that we are completely out of touch with them. Either way, it sucks and I feel like we should apologise to developers and perhaps even the software industry as a whole. Microsoft did offer a mea culpa to developers for the delay between Internet Explorer versions and I think this is another one of those cases where we should do the same.

I feel like I should probably throw in some last thoughts about WinFS, the technology, especially since in my previous post I claim that this decision should have been made a few years ago. Below is a random collection of my thoughts WinFS which can also be gleaned from my various blog posts on the technology over the last few years

1. There was a divergence of opinion in what the team was building and what the people thought the team was building. A common misconception was that WinFS would somehow make search "better" on the desktop in the same way that desktop search tools like Lookout do. I addressed this misconception further in my post Killing the "WinFS is About Making Search Better" Myth from almost two years ago.

2. The project had the biggest example of scope creep I'd ever seen at Microsoft. When WinFS swallowed ObjectSpaces the team decided that instead of just tackling the hard problem of building an object/relational file system for Windows that they also wanted to tackle the hard problem of  building an enterprise-class object to relational mapping technology with the same product in a single release. It also didn't help that key ObjectSpaces folks like Matt Warren, Dinesh Kulkarni and Luca Bolognese ended up joining the C# team to work on LINQ which meant WinFS inherited all of the problems of ObjectSpaces but not necessarily all the folks who had been working on those problems.
   

3. The chicken and the egg problem. One of the key ideas in the WinFS type system for the Windows desktop was that we'd have common file system level types for high level concepts like people/contacts, email messages or photos instead of just opaque bits on disk with some file format specific metadata. To take advantage of this, existing applications would have to be rewritten or new [backwards incompatible] applications would have to be written targetting WinFS. The primary benefits of making this change [besides the improved programming model] were the network effects if lots of applications used these types (e.g. Outlook stored mail identified by a WinFS contact, RSS Bandit stored RSS feeds from that WinFS contact, AOL Instant Messenger stored IM conversation logs using that contact, etc). Even if you got these network effects you then had to deal with the Windows registry problem (i.e. apps stomping over each others data which is one of the main problems with the Windows registry today).
   

4. I never saw good answers to the questions Jon Udell asked in his blog posts Questions about Longhorn, part 1: WinFS and Questions about Longhorn, part 2: WinFS and semantics. Specifically, the world is betting big on open file formats such as XML including parts of Microsoft (e.g. Microsoft Office) so why would anyone want to build aplications targetting a proprietary Windows-only file system that didn't have a good XML story for getting data out of the platform?

I should probably stop now. Even though all the information above is freely available to anyone who reads blogs and can put two and two together, some may object to the above collection of thoughts.
 

Quentin Clark has a blog post entitled WinFS Update where he writes

There are many great technical innovations the WinFS project has created – innovations that go beyond just the WinFS vision but are part of a broader Data Platform Vision the company is pursuing.  The most visible example of this today is the work we are now doing in the next version of ADO.NET for Orcas.  The Entities features we are now building in ADO.NET started as things we were building for the WinFS API.  We got far enough along and were pushed on the general applicability of the work that we made the choice to not have it be just about WinFS but make it more general purpose (as an aside – this stuff is really coming together – super cool). 

Other technical work in the WinFS project is at a similar point – specifically the integration of unstructured data into the relational database, and automation innovations that make the database "just work" with no DBAs – "richer store" work.  It's these storage innovations that have matured to the point where we are ready to start working on including them in our broader database product.  We are choosing now to take the unstructured data support and auto-admin work and deliver it in the next release of MS SQL Server, codenamed Katmai.  This really is a big deal – productizing these innovations into the mainline data products makes a big contribution toward the Data Platform Vision we have been talking about.  Doing this also gives us the right data platform for further innovations. 

These changes do mean that we are not pursuing a separate delivery of WinFS, including the previously planned Beta 2 release.  With most of our effort now working towards productizing mature aspects of the WinFS project into SQL and ADO.NET, we do not need to deliver a separate WinFS offering. 

So that's it, no more WinFS. This is the right decision, albeit two years too late but better late than never. It's sad to think about the projects that got killed or disrupted because of WinFS only for this to happen. In a recent column entitled Taking One for the Team Robert X. Cringley has a quote from Management By Baseball by Jeff Angus which reads "When I worked for a few years at Microsoft Corporation in the early '80s,...no one cared to track and codify past failures as a way to help managers create guidelines of paths to follow and avoid". I hope this doesn't end up happening with the lessons from the WinFS project.