From the Windows Live QnA team blog post entitled Welcome to the public beta for Qna.live.com! we learn

It’s with great pleasure, a lot of late nights, and barrels of caffeine, that our team launches the public Windows Live QnA beta.

For all you thousands of beta testers who took a chance on us, nagged us, mocked us, and made us better – we thank you. Keep doing it. Enjoy. Obey the code of conduct. We see you getting hooked.

The site is now available to all at http://qna.live.com/. Try it out and let the team know what you think.

Update: There is an interview with Betsy Aoki about Windows Live Qna on On10.net. If you look closely, you'll also notice a cameo by RSS Bandit.

I was surprised by the contents of two blog posts I read over the weekend on the same topic. In his post Web 2 bubble ain’t popped yet: Kiko sells for $258,100 Robert Scoble writes

How many employees did Kiko have again? Three, right? Well, they just sold their “failure” for $258,100. Not too shabby!

On the same topic, Om Malik writes in his post Kiko Sells for $258,100

The company recently became talk of the blogs, when the founders decided to cut their losses, and put the company on sale on eBay. Niall and I devoted a big portion of our latest podcast, Snakes on a Business Plan to the Kiko affair. Well, the auction just closed and brought in $258,100. A tidy sum! This explains why Paul was smiling today at The FOO Camp " src="http://gigaom.com/wp-includes/images/smilies/icon_wink.gif"> Apparently, Kiko’s angel round was $50,000 in convertible debt, and this sale should cover that. Graham’s YCombinator which did the seed round could come out ahead as well.

I'm confused as to how anyone can define this as good. After you take out however much the investors get back after investing $50,000 there really isn't much left for the three employees to split especially when you remember that one of the things you do as the founder of a startup is not pay yourself that much. At best I can see this coming out as a wash (i.e. the money made from the sale of Kiko is about the same as if the founders had spent the time getting paid working for Google or Yahoo! as full time employees) but I could be wrong. I'd be surprised if it was otherwise.

One of the biggest surprises for me over the past year is how instead of Sun or IBM, it's Amazon that looks set to become the defining face of utility computing in the new millenium. Of course, the other shoe dropped when I read about Amazon Elastic Compute Cloud (Amazon EC2) which is described below

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.

Just as Amazon Simple Storage Service (Amazon S3) enables storage in the cloud, Amazon EC2 enables "compute" in the cloud. Amazon EC2's simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon's proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.

All Amazon needs to do is to add some SQL-like capabilities on top of Amazon S3 and I can't see any reason why any self respecting startup would want to host their own datacenters with the high bandwidth, staff, server, space and power costs that it entails. Anecdotes such as the fact that SmugMug is now storing 300 terabytes of data on Amazon's servers for cheaper than they could themselves will only fuel this trend. I definitely didn't see this one coming but now that it is here, it seems pretty obvious. Companies like IBM and Sun, simply don't have the expertise at building something that has to handle traffic/capacitye at mega-service scale yet be as cheap as possible. Companies like Yahoo!, MSN/Windows Live and Google have this expertise but these are competitive advantages that they likely won't or can't give away for a variety of reasons. However Amazon does have he expertise at building a mega-scale service as cheaply as possible as well as the experience of opening it up as a platform for other companies to build businesses on. With the flood of startups looking to build out services cheaply due to the "Web 2.0" hype, this is a logical extension of Amazon's business of enabling companies to build eCommerce businesses on their platform.

With a few more high profile customers like SmugMug, Amazon could easily become the "dot in dotcomm Web 2.0". Of course, this means that like Sun was during the 90s they'll be pretty vulnerable once the bubble pops.

It looks like the big news this morning is that Google just announed Google Apps for your Domain. From the press release Google Launches Hosted Communications Services we learn

Google Apps for Your Domain, an expansion of the Gmail for Your Domain service that launched in February 2006, currently includes Gmail web email, the Google Talk instant messaging and voice calling service, collaborative calendaring through Google Calendar, and web page design, publishing and hosting via Google Page Creator. Domain administrators use a simple web-based control panel to manage their user account list, set up aliases and distribution lists, and enable the services they want for their domain. End users with accounts that have been set up by their administrator simply browse to customized login pages on any web-connected computer. The service scales easily to accommodate growing user bases and storage needs while drastically reducing maintenance costs.

Google will provide organizations with two choices of service.

• A standard edition of Google Apps for Your Domain is available today as a beta product without cost to domain administrators or end users. Key features include 2 gigabytes of email storage for each user, easy to use customization tools, and help for administrators via email or an online help center. Furthermore, organizations that sign up during the beta period will not ever have to pay for users accepted during that period (provided Google continues to offer the service).
• A premium version of the product is being developed for organizations with more advanced needs. More information, including details on pricing, will be available soon.

If this sounds familiar to you, that's because it is. This is pretty much the same sales pitch as Microsoft's Office Live. Right down to having tiered versions that range from free (i.e. Office Live Basics) to paid SKUs for businesses with more 'advanced' needs (i.e. Office Live Essentials). With Google officially entering this space, I expect that the Office Live team will now have some pressure on their pricing model as well as an incentive to reduce or remove some of the limitations in the services they offer (e.g. the fairly low limits on the amount of email addresses one can create per domain).

As usual, the technology blogs are full of the Microsoft vs. Google double standard. When Microsoft announced Office Live earlier this year, the response was either muted or downright disappointed because it wasn't a Web-based version of Microsoft Office. An example of such responses is Mike Arrington's post entitled Microsoft Office Live goes into Beta. On the flip side, the announcement of Google Apps for your Domain which is basically a "me too" offering from Google is heralded by Mike Arrington in his post Google Makes Its Move: Office 2.0 as the second coming of the office suite. The difference in the responses to what are almost identical product announcements is an obvious indication at how both companies are perceived by the technology press and punditry.

I personally prefer Om Malik's take in his post Web Office Vs Microsoft Office where he states

"Web Office should not be about replacing the old, but inventing the new web apps that solve some specific problems".

This is pretty much the same thing I heard Ray Ozzie and Sergey Brin say at last years Web 2.0 conference when they were both asked [on different occassions] about the possibility of replacing desktop office suites with Web-based software. Enabling people in disparate locations to collaborate and communicate is the next major step for office productivity suites. One approach could be replacing everything we have today with Web-based alternatives, the other could be making the desktop software we have today more Web savvy (or "live" if you prefer the Microsoft lingo). I know which one I think is more realistic and more likely to be acceptable to businesses today. What do you think?

My next question is whether Google is going to ship consumer targetted offerings as Microsoft has done with Windows Live Custom Domains or is the free version of Google Apps for your Domain expected to be the consumer version?

Disclaimer: The above statements are my opinions and do not in any way reflect the plans, thoughts, intentions or strategies of my employer.

Recently I asked one of the Javascript devs on the Windows Live Spaces team to review the code for some of my gadgets to see if he could point out areas for improvement. One thing he mentioned was that there were a ton of memory leaks in my gadgets. This took me by surprise since the thought of a memory leak in some AJAX code running in a browser sounded like a throwback to the days of writing apps in C/C++. So I went back and took a look at the Windows Live gadget SDK, and sure as hell there was a section of the documentation entitled Avoiding Memory Leaks which states

Memory leaks are the number one contributor to poor performance for AJAX-style websites. Often code that appears to be written correctly will turn out to be the source of a massive memory leak, and these leaks can be very difficult to track down. Luckily, there are a few simple guidelines which can help you avoid most memory leaks. The Live.com developers follow these rules religiously, and recommend that you do the same when implementing Gadgets.

• Make sure you null any references to DOM elements (and other bindings for good measure) in dispose().
• Call the base dispose method at the end of your dispose method. (conversely, call the base initialize at the beginning of your initialize method)
• Detach all events that you attach.
• For any temp DOM element vars created while constructing the DOM, null the temp var before exiting the method.
• Any function parameters that are DOM elements coming in should be nulled before returning from the method.

There are a number of websites and blog entries that document approaches for identifying and fixing memory leaks in AJAX applications. One such helpful site can be found here.

A great way to see whether your Gadget is leaking memory is to use the following URL to load your Gadget: http://gadgets.start.com/gadget.aspx?manifestUrl=gadgetManifestUrl. Open Task Manager in Windows and monitor the memory usage of the Internet Explorer window. Keep reloading the Gadget in Internet Explorer to see if the memory usage increases over time. If the memory usage increases, it is indicative that your Gadget is leaking memory.

This is the entirety of the documentation on avoiding memory leaks in Windows Live gadgets. Granted there is some useful information in the blog post referenced from the SDK. The post implies that memory leaks in AJAX code are an Internet Explorer problem as opposed to a general browser issue. 

Most of the guidelines in the above excerpt were pretty straightforward except for the one about detaching all events you attach. I wasn't sure how event handling differed between Firefox and IE (the only browsers I test gadgets on) so I started down the path of doing some research. and this led me to a number of informative posts on Quirksmode. They include

1. Traditional event registration model
   
2. Advanced event registration models
   
3. addEvent() considered harmful
   

The information in the above pages is worth its weight in gold if you're a Javascript developer. I can't believe I spent all this time without ever reading Quirksmode. The Windows Live gadgets team would be doing gadgets developers a lot of favors by including the above links to their documentation.

There is also an interesting observation about the end user perceptions about who's to blame for badly written gadgets. The comment about memory leaks in my gadgets answered the question of why Internet Explorer uses as much as 200MB of memory when running my Live.com start page. At first, I assumed the problem was with Live.com and then after switching browsers to Firefox I saw some improvement and then assumed the problem was with IE. It never crossed my mind that the problem was the poor coding in the gadgets on my page. This may just be because I was the author of many of the gadgets on my page but I suspect that when the average end user hits problems with poorly written gadgets causing issues with Live.com or Windows Live Spaces pages, Microsoft is the entity that gets the blame not the gadget developers.

Just like with Windows®, poorly written applications often reflect badly on the platform and not just the application. Interesting food for thought if you are interested in building Web platforms. 

The Windows Live Wifi team has an introductory blog post entitled Hello World... which is excerpted below

I’m Stefan Weitz, director of planning for Windows Live WiFi. The team has been developing Windows Live WiFi Center over the past few months and it’s now time to let others experiment with it. The beta is currently limited to 5,000 people but will open up more broadly in the coming months.  If you are interested in participating please email your Windows Live ID (ex. JaneDoe@hotmail.com) to BellBeta@microsoft.com and we’ll get you on the list of interested parties.

Getting online in a WiFi world
Windows Live is all about unifying our customer’s online experience.  Well, let’s face it – you need to be connected (in one way or another) to have that world unified :).  The Windows Live WiFi Center is all about helping people get connected in a secure way – it’s essentially our first step at creating an integrated software solution that helps people find and securely connect to wireless networks around the world.  The Windows Live WiFi Center has a number of great features in this beta version (hint: beta = more features are coming soon…).

 ·         Hotspot locator:  Provides you with the ability to search for free and fee-based wireless networks in countries around the world.  The locator shows you the address, description, available amenities, service providers and shows you a map of the location.

 ·         Network Management: Helps you see what networks are available and makes it easy to get technical information about them, including their security configuration, signal strength, etc.  In addition, you can tag networks as ‘favorites’ for future connections, track connection history, and manage network preferences. 

 ·         Security: Our built-in security, using VPN technology, allows you to secure a wireless Internet connection on unsecured networks like those in hotels and coffee shops.  This security feature comes free with the Windows Live WiFi Center product. 

Sounds pretty sweet. I've known this product was coming but hadn't tried it out yet. Looks like I need to get hooked up with the beta. The HotSpot Locator sounds particularly interesting to me.

Nick Gall has a blog post entitled What were we thinking? where he writes

It just struck me, after 5+ years of analyzing the ins and outs of SOAP, how little need there has turned out to be for the SOAP binding model (i.e., binding SOAP onto various "transport" protocols). If some endpoint is going to go to all the trouble of enabling processing of URIs and XML (a prerequisite for processing the SOAP envelope), what are the chances that said endpoint would not go ahead and enable HTTP processing? The scenario of a mainframe endpoint that is able to process a SOAP envelope, but is unable to process HTTP to receive the envelope strikes me as ludicrous.
...
So who really cares that SOAP is able to be bound to MQ or IIOP or SMTP, today? Apparently, very few--since there has been virtually no progress towards standardizing any SOAP binding other than to HTTP for years.
...
Accordingly, it seems to me that the WS-* stack could be made a lot less complex for the average developer if the SOAP and WSDL binding models were simply deprecated and replaced with simpler "native HTTP" binding

This is one of those blog posts where I simultaneously agree and disagree with the author. I agree that a lot of the complexity in WS-*/SOAP/WSDL/etc has to do with the notion of "protocol independence". As I mentioned in a previous post entitled Protocol Independence is a Leaky Abstraction, the way SOAP and the various WS-* technologies achieve protocol independence is by basically ignoring the capabilities of the Web (i.e. HTTP and URIs) and re-inventing them in various WS-* specifications. This leads to a lot of unnecessary complexity and layering when you are already using HTTP as the transport protocol (i.e. the most common usage of SOAP).

On the flip side, there is something to be said for being able to use one distributed application model and support multiple protocols. For example, if you read the Windows Communication Foundation whitepaper you'll see it mentioned that WCF supports sending messages via HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ). I've actually been working on using this functionality in some of our internal Windows Live platform services since the performance benefits of using TCP for communications over SOAP/HTTP are considerable. However we'll still have SOAP/HTTP end points since that is the lowest common denominator that SOAP-based services that interact with our services understand. In addition, I'd like to see some straight up PlainOldXml/HTTP or RESTful end points as well.

One of the main problems we've faced in our evaluation of moving to multiprotocol SOAP services is how much of a leaky abstraction the "protocol independent" nature of SOAP tends to be in real life. My favorite issue thus far is that we actually use HTTP redirects in our current SOAP web services. Guess what? There is no "protocol independent" WS-Redirect specification. So we have to roll our own solution for non-HTTP protocols.

We've hit a couple of other minor issues but in general the support we've gotten from Omri, Doug Purdy and others on the WCF team has been great. In fact, I've started to lose some of my skepticism about the WS-* family of technologies. I still think they are overkill for the Web though. ;)

It looks like I'm now writing a Windows Live gadget every week. My latest gadget is a port of the Flickr badge to a Windows Live gadget. It's in the approval pipeline and should show up under the list of gadgets I've written in the next day or so. To get the gadget working, I had to use the Flickr API. Specifically, I used the flickr.people.findByUsername method to convert a username to an internal Flickr ID. Ironically Coincidentally, I had recently read something by Alex Bosworth criticizing this very aspect of the Flickr API in his post How To Provide A Web API where he wrote

Simple also means don’t be too abstract. Flickr for example chooses in its API to require the use of its internal ids for all API calls. This means for example that every call to find information about a user requires a call first to find the internal id of the user. Del.icio.us on the other hand just requires visible names, in fact internal ids are hidden everywhere.

Actually, it's much worse than this. It seems that Flickr is inconsistent in how it maps user names back to internal IDs. For example, take Mike Torres who has 'mtorres' as his Flickr ID. I can access his Flickr photos by going to http://flickr.com/photos/mtorres. When I use the Flickr API explorer for flickr.people.findByUsername and pass in 'mtorres' as the username I get back the following ID; 25553748@N00. When I go to http://flickr.com/photos/25553748@N00 I end up going to some other person's page who seems to be named 'mtorres' as well.

However when I plug "Mike Torres" into the flickr.people.findByUsername method instead of 'mtorres' I get '37996581086@N01' which turns out to be the right ID since going to http://www.flickr.com/photos/37996581086@N01 takes me to the same page as http://flickr.com/photos/mtorres. Weird.

Perhaps this is a naming collision caused by the merging of Flickr & Yahoo! IDs?

Over the weekend I blogged that Kiko was an example of sprinkling AJAX on old ideas that had failed in the 1990s. I found an even better example from a blog post by Richard MacManus entitled Ex-Googler starts Webwag, new personalized start page where he writes

"According to Poisson, Webwag’s revenue streams will include affiliate marketing – something Netvibes is doing via Kelkoo - and B2B deals, an as yet unexplored area. Chris previously suggested that white labelling this technology is one key revenue opportunity for these firms to consider.

Poisson said: "As Web 2.0 develops over the next three three to five years, two things will remain. Firstly, everyone will have their own blog, and over 75% of people will have their own personalised start pages.

"My belief is the big search portals (My Yahoo etc) will get 50% of that market, and 50% will be taken by three to four independents.”"

Personally I think that 50% figure for independents is too ambitious. I also question his claim that 75% of people will have a start page in 3-5 years, unless you count the likes of Yahoo.com as a 'personalized start page' (actually I suspect the distinction will be moot in 5 years time).

If someone would have told me that AJAX versions of My Yahoo! (i.e. a portal homepage) except with none of the integration with a family of websites that a portal provides would be a hot startup idea I'd have laughed them out of my office. This market was saturated five years ago. The thought that adding drag & drop to a portal homepage and not having any rich integration with a family of sites is a viable business seems pretty absurd to me. The barrier to entry is pretty much zero, all you need to do is grab the Yahoo! Javascript UI library and write some code to parse RSS feeds to get started. That's besides the fact that the portal homepage is primarily a means to an end since they are there to encourage people to stick on the site and use other services (i.e. search) and not the core product in itself.

The quote that 75% of people will have a personalized start page is the best part though. As if the lack of AJAX and drag & drop is the reason that 75% of the population don't have My Yahoo!, My MSN or My AOL pages. Yeah, right. 

This reminds me of a conversation I was having with Eric Fleischman about blogging and RSS becoming mainstream yesterday. We agreed that blogging is already mainstream because everyone has a MySpace from politicians and school teachers to movie stars and DJs. On the other hand, I didn't think subscribing to feeds in a conventional aggregator would ever become used by a widespread percentage of the population. Subscribing to feeds seems cool to geeks because it solves a geek problem; having too many sources of information to keep track of and optimizing how this is done. The average person doesn't think it's cool to be able to keep track of 10 - 20 websites a day using a some tool because they aren't interested in 10 - 20 websites on a daily basis in the first place. I'm sure a light sprinkling of AJAX can solve that problem as well.

*sprinkle* *sprinkle* *sprinkle*

Matt Mullenweg has a blog post entitled MSN Spaces Numbers where he writes

Scoble has been questioning the claimed numbers of MSN Spaces and somehow the conversation got sidetracked in the technicalities of “what’s a blog?” I’m not sure what Microsoft hopes to gain by inflating their numbers so much, now claiming 70 million “blogs”, but it’s interesting to note back in March they were claiming 123 million blogs at SxSW (Flickr photo of their booth). Of course that was like 2 name changes and reorgs ago. Maybe 50 million people left the service?

I wasn't planning to blog about the recent round of player hating on Windows Live spaces certain bloggers but the above claim by Matt Mullenweg that we are 'inflating' our numbers really got my goat.

First of all, the two numbers quoted above by Matt are unrelated metrics. The count of 123 million users is explained in the press release MSN Spaces Now Largest Blogging Service Worldwide which states that comScore Media Metrix has measured the service's reach as being 100 million unique vistors a month and this number is in addition to 20 million unique visitors from using the chinese version of MSN Spaces. The 70 million number is the number of blogs spaces that have been created since inception. This number isn't particularly interesting since it doesn't correlate to how many people are actually getting value out of the service.

For example, according to the LiveJournal statistics page their current statistics are

How many users, and how many of those are active?

• Total accounts: 10945719
• ... active in some way: 1870731
• ... that have ever updated: 7278240
• ... updating in last 30 days: 1164416
• ... updating in last 7 days: 679693
• ... updating in past 24 hours: 204465

According to those statistics only 1 out of 5 LiveJournal accounts is actually active. Of course, it would sound impressive to tout 11 million LiveJournal accounts even though the number of active accounts is much less. For that reason, the number of spaces on Windows Live Spaces isn't a particularly interesting metric to me nor is it to anyone I know who works on the product. We are more interested in the number of people who actually use our service and get value added to their lives by being able to share, discuss and communicate with their friends, families and total strangers.