We were planning to ship a bugfix release of RSS Bandit before Christmas which fixed all the major issues reported in the recently Nightcrawler edition of RSS Bandit.

Unfortunately, it seems that either due to complexity or buginess I simply can't get the NewsGator API to perform the straightforward task of marking something as read in NewsGator Online which was viewed in RSS Bandit. I spent all of yesterday afternoon plus a couple of hours this morning working on it and I've finally given up. This feature simply won't work in the bugfix release shipping later this week. Maybe I'll have better luck when we ship the Jubilee release.

To make myself feel better, I'll work on fixing some of the Atom parsing bugs reported by Phil Ringnalda and the issues with password protected newsgroups. Nothing like having your self-worth defined by how many bugs you close in a database on SourceForge.

Update: So not only have I already fixed the newsgroup issues and the problems with parsing Atom feeds pointed out by Phil Ringnalda but I just got pinged by Gordon Weakliem who is the developer of the NewsGator API. Perhaps my Christmas can be salvaged after all.

I've seen a number of interesting posts today in response to the news that Microsoft will end support for Internet Explorer for the Mac ths year. The best posts have been from people who used to work on the product.

Jorg Brown has a comment on Slashdot entitled I was on the MacIE 6 team when it got canned... which contains the following excerpt

MacIE had one of the strangest and saddest histories I've seen, of any product.

MacIE 5 was an awesome release, critically aclaimed and everything, with a good development team and a strong testing team, that included daily performance measurement.

And yet, almost immediately after 5.0 was released, the MacIE team was redeployed to work on a set-top DVR box. The notion at the time was that the team would continue to do MacIE work in their spare time, since IE 5 was the leader among Mac browsers and no longer needed a full-time team.

The problem with that notion was that WebTV, the team's new bosses, had no reason to actually schedule any time for real IE work. So later, when that particular set-top box got cancelled, the IE team got redployed for other WebTV work, and since this was now out of MacBU's control, nothing could really be done.

3 or 4 years went by before enough people in the Mac division wanted to resume work on IE, and when it looked like we might actually need the technology, as a base for MSN-for-Mac, the IE 6 team was formed. It got a firm OS X-only foundation, a new even more complient browser base, and then suddenly it became apparent that Apple was doing their own browser, because, well, there were lots of small clues, but the big clues was that Apple had started calling the old Mac IE team offering them jobs.

By that time the Mac division had formally committed to MSN-for-Mac-OSX, so it's not like we were completely going to stop work. But a meeting was held internally, the outcome of which was that it didn't make sense to build our own browser if Apple was going to bundle one, because the marketshare and mindshare of the distant-second-place browser, on the distant-second-place platform, wasn't worth pursuing. A week later we had a meeting with high-up people at Apple, where they told us they were doing a browser. And the week after that, after confirming it with Bill Gates, who was reportedly sad but understanding of the decision, MacIE was officially shut down.

MSN-for-MacOSX went ahead, and was also critically acclaimed, but once released, indications were that the number of users was about the same as the number of developers. After that, MacBU concentrated once again on the next Office release, and MacIE has been well and truly and permanently dead ever since.

Over the whole sad journey, the single most surprising thing I ever discovered was from a small conversation that went:

Me: "Look, if it makes sense to devote dozens of people to WinIE, then surely it makes sense to devote half a dozen to MacIE!"

Higher-up: <confused look> "There aren't dozens of people on WinIE. WinIE had some great people on it! We need those great people on products that make money!"

Me: "Then why on earth did we pursue IE in the first place? Just so that the DOJ would sue us?"

Higher-up: <confused look>

Some day I hope to get a proper answer on our motivation to do WinIE and MacIE in the first place. It seems to be that we were scared of not having control of the HTML standard. And indeed, now that Firefox is gaining traction, Microsoft has added more people to WinIE again.

Jimmy Grewal also has a blog post about this entitled End of an era: Mac Internet Explorer where he writes

This announcement has sparked some debate on Slashdot, which was inevitable. Omar pointed me to a comment to this by our former co-worker Jorg Brown, who now works for Google, which I’ll quote below:
... [see above excerpt]
A lot of what he says is true; but the story is more complex than this and there were many other factors that came into play. Issues which he doesn’t cover…primarily because he wasn’t working on the product much until the last few months of development:

• - Mac IE was the first real browser running on Mac OS X. We had it running on Developer Preview 2 and it shipped on the Public Beta CD-ROM. That was a great engineering achievement but it came at a very high price. Developing for OS X in those early days was a nightmare and we spent so much time struggling with OS bugs and changing APIs that precious time that could have been used to improve the product was wasted just trying to maintain compatibility with each new beta release of OS X.

• - Apple was a pain in the ass sometimes. For a company with such great PR, they really were very unprofessional and treated developers poorly. I know that the OS X transition was tough, but there are so many stories I could tell of stupidity at Apple and policies which made no sense…but I won’t. I’ll just say that Apple had a lot more involvement in the development of Mac IE and it’s eventual end than Jorg gives them credit for. There were times during the last two years of working at Microsoft that I really hated Apple’s management…which was very difficult for me being such a loyal fan of their products and having so many friends who worked there.

• - No clear direction from our management was the last major factor which Jorg touched upon but is important to mention again. Towards the end, we had some major changes in management at the MacBU and the new team was inexperienced both with the products they were managing and how to deal with Apple. They were further handicapped by lack of clear direction by our execs who were too busy worrying about AOL, the DOJ, and our stock price.

The common thread in both perspectives is that management at Microsoft didn't see much value in continuing with IE on the Mac. Jorg doesn't seem to understand why but the reason seems clearer to me.Microsoft is a platform company. We have built the most popular software platforms on the planet; Microsoft Windows and Microsoft Office. In the 1990s, two technologies/products attempted to take the place of Windows as the world's #1 developer platform. These technologies/products were the Java platform produced by Sun Microsystems and the Netscape Navigator web browser produced by Netscape. Microsoft met both challenges in a variety of ways including making sure that Windows  (a) was the best platform to run Java applications and (b) had the best Web browser on any platform. The goal was simple if Java or the web browser became the platform, then that platform would at the end still be a Windows platform. Of course, some other decisions Microsoft made with regards to competing with Sun and Netscape landed the company in court with billions of dollars in fines and settlements. 

Fast forward to the early 2000s, the browser wars are over and IE is the world's dominant Web browser. In an almost text book example of how monopolies work, Microsoft abandoned innovation in IE in a move that showed that at this point IE was considered a cost center not a revenue generator. It simply doesn't make business sense for Microsoft to invest in a technology that dintermediates it's most popular platform, the Windows operating system. This should sound familiar to you if you've read The Innovators Dilemma.

It's now the mid-2000s and the Web browser landscape has changed. Technologies such as DHTML and IXMLHttpRequest which were invented by Microsoft to make IE the best developer platform on the Web have been adopted by competitors like Google and rival Web browsers like Mozilla. Despite our best efforts, the Windows platform is being routed around and even worse it is by technologies we invented. In this case Microsoft has been hoisted by its own petard. 

These developments have caused renewed interest in IE [at least on Windows] by Microsoft which is why I went from two years of being a Microsoft employee and not believing an IE team existed to reading the IE blog which makes it seem that there is now a veritable army of developers working on IE. The only problem is that I expect that history will repeat itself. What happens when IE reaches feature parity with Mozilla? Will we have to wait until Windows Blackcomb until we see Internet Explorer 8? Given how Microsoft [and specifically the Windows division] works this isn't as crazy an idea as it sounds. 

I can think of two ways to prevent history from repeating itself. The first is that Microsoft officially disbands the IE team after IE 7. The second is that Microsoft transfers the IE team to a product group that actually depends on browser innovative to make money such as MSN Windows Live. We haven't innovated in the browser for almost a decade. IE 5 was the last truly innovative release. Ex-IE team members like Scott Berkun who wrote the classic How to build a better web browser show exactly stagnant the world of Web browser innovation has been this century. Given that Microsoft views IE as a defensive option to make Windows an enticing product, there is less incentive to make it the ultimate browsing experience as products whose bread and butter is the Web browser. Why do you think there are so many Google employees working on Mozilla?

Microsoft should either cede innovation in the Web browser to Mozilla/Google or make IE more than just "icing on the Windows user experience cake"by transfering the product to a team whose bottom line depends on browser innovation. Of course, I doubt that my words will be taken seriously by folks at Microsoft [except as a reason to send my boss or his boss angry mail] but this needs to be said.

Robert Scoble has a post entitled Riya not recognized by Google where he recommends that Microsoft look into purchasing Riya.com. He writes

I’ve heard many rumors about Riya over the past few weeks. One strong rumor, reported by Om Malik, among others, was that Riya was getting purchased by Google.

I know our M&A guys had met with Riya too and had passed on the deal after negotiations got too expensive (translation someone else had bid more than we were willing to pay). So, I was suprised that during the past few days I had heard that Riya’s deal with Google wasn’t going to happen.

Today Munjal, Riya’s CEO, said on his blog that they were going to continue on as an independent firm and that the rumors are incorrect.

This is actually very good for Microsoft and Yahoo. Why? Cause this team is high quality and the technology is great (I’ve been using the alpha recently and like it a lot).

Now, why doesn’t Microsoft purchase them? Well, I’ve been in contact with our M&A folks. We have a lot of NIH syndrome here cause we have similar technology that our research teams have developed. I’ve seen our photo/face recognition capabilities and they are pretty cool too and, indeed, are better in some areas and not as good in others.

I have a couple of opinions here but mostly it is advice to Robert given that I've been recently involved in acquisition related discussions as part of my day job. My main thought about Google passing on Riya is that I expected this given that they demoed their in-house image recognition software at the Web 2.0 conference. Thus purchasing Riya would primarily be about augmenting their internal development team which reduces the value of the deal to Google.

From a Microsoft perspective, I'd expect to see a bunch of NIH as well. We have folks who are doing quite a lot in the area of improving digital photograph at Microsoft Research. You can read about some of the work in articles like MSR's Life of a Digital Photo or view demos about interesting work in Object class recognition from the Cambridge arm of Microsoft Research. I don't think I've seen anything as cool as the stuff demoed by Riya and Google but we do have some interesting stuff cooking at Microsoft Research nonetheless. 

The problem for Scoble is finding a product team that actually thinks what Riya is doing is valuable enough to make it worth however many tens of millions of dollars the VCs think the company is worth. Simply saying "What they are doing is cool" isn't enough. The folks at MSR face the same problems and the fact that there aren't lots of transitions from cool research demo to Microsoft product shows just how difficult this process can be. 

A friend of mine called me yesterday to ask for my opinions on the fact that Meebo just got a few million dollars in funding. For those not in the know, Meebo is an AJAX version of Trillian. And what is Trillian? It's an instant messaging client that supports AIM, ICQ, MSN, Yahoo Messenger, and IRC.

In his post How Much Did Meebo Get? Om Malik asks

Here is the rub: Since the company basically aggregates all four major IM networks in a browser, all the four major IM owners - AMYG are out of the acquisition game. One of them buys the company, the others shut down access to their respective networks. The very quality that makes Meebo attractive to end-users will make it difficult for them to be acquired. But there is one option: eBay. When all fails, you know who to call. Skype did. Interactive Corp is another long shot, but they are bargain hunters not premium payers.

Regarding acquisitions, there are three reasons why one of the major players would buy a company; users, technology and people. Unless the start up is in a brand new market that the major player isn't playing in, buying a company for its users is usually not the case. This is because big players like Google, Yahoo! and Microsoft usually either have orders of magnitude more users than the average 'popular' startup or could get just as many or more users when they ship a rival service. The more common reason for a big player like Microsoft or Yahoo! buying a company is for exclusive technology/IP and for the development team. Yahoo! buying del.icio.us or Flickr isn't about getting access to the 250,000 - 300,000 users of these services given that they have less users than the least popular services on Yahoo!'s network. Instead it's about getting people like Joshua Schachter, Caterina Fake and Stewart Butterfield building the next generation of Yahoo!'s products. Don Dodge covers this in slightly more detail in his post Microsoft will acquire my company.

Let's talk about Meebo specifically. The user base is too small to be a factor so the interesting things are the technology and the people. First we should look at the technology. An AJAX instant messaging client isn't novel and companies like Microsoft have been providing one for years. A framework built on reverse engineering IM protocols is cool but not useful. As Om Malik points out, the major players tolerate activities like companies like Meebo & Trillian because it is counterproductive for [example] AOL suing a tiny company like Trillian for misusing its network. On the other hand, they wouldn't tolerate it from a major player like Microsoft primarily because that becomes a significant amount of traffic on their network and licensing access becomes a valid revenue generating scenario. Thus, the technology is probably not worth a great deal to one of the big players. That leaves the people,  according to the Meebo team page there are three people; a server dev, a DHTML/AJAX dev and a business guy (likely to be useless overhead in an acquisition). The question then is how many million dollars would Google, Yahoo! or Microsoft think is worth for the skills of both [most likely excellent] developers? Then you have to factor in the markup because the company got VC funding...

You can probably tell that I agree with Om Malik that it is unlikely that this company would be of interest to any of the four major IM players.

If you are building a Web startup with the intention of flipping it to one of the majors, only three things matter; technology/IP, users and
the quality of your technical team. Repeatedly ask yourself: would Microsoft want our users? would Google want our technology? would Yahoo! want our people?

It's as simple as that.

Clemens Vasters has written two interesting atricles on building RESTful services using Indigo Windows Communication Foundation entitled Teaching Indigo to do REST/POX, Part 1 and Teaching Indigo to do REST/POX, Part 2. His first articles begins

A little bit more than half a year ago I got invited to a meeting at Microsoft in Redmond and discussed with Steve Swartz, Yasser Shohoud and Eugene Osovetsky how to implement POX and REST support for Indigo. ... I witnessed the definition a special capability for the HTTP transport that I am exploiting with a set of Indigo extensions that I’ll present in this series of blog posts. The consensus in the meeting was that the requirements for building POX/REST support into the product weren’t generally clear enough in the sense that when you ask 100 people in the community you get 154 ever-changing opinions about how to write such apps. As a consequence it would not really be possible to define a complete programming model surface that everyone would be happy with, but that a simple set of hooks could be put into the product that people could use to build programming models rather easily.

And so they did, and so I did. This new capability of the HTTP transport first appeared in the September CTP of Indigo/WCF and surfaces to the developer as properties in the Message class Properties collection or the OperationContext.Incoming/OutgoingMessageProperties.

If you are using the Indigo HTTP transport on the server, the transport will always stick a HttpRequestMessageProperty instance into the incoming message properties, which provides access to the HTTP headers, the HTTP method (GET, POST, PUT, etc.) and the full query string. On the client, you can create an instance of this property class yourself and stick it into any outbound message’s properties collection  and, with that, control how the transport performs the request. For sending replies from the server, you can put a HttpResponseMessageProperty into the message properties (or, again, into the OperationContext) and set the HTTP status code and description and of course the HTTP reply headers.  

And since I have nothing better to do, I wanted to know whether this rather simple control feature for the HTTP transport would indeed be enough to build a POX/REST programming model and application when combined with the rest of the Indigo extensibility features. Executive Summary: Yes.

One of the first work items I got assigned when I joined my current team at MSN Windows Live was responsibility for our Indigo migration. This was pretty ambiguous and it turned out this was a place holder work item for "Figure out why we should move to Indigo and when". So I talked to our devs for a while and after thinking about where I saw our services evolving it seemed there were two main things we wanted from Indigo; better performance and support for a more diverse view of what it meant to be a Web service. 

Why we need better performance is pretty straightforward. We provide services that are depended on by hundreds of millions of users across a variety of MSN properties including Hotmail, MSN Messenger, and MSN Spaces as well as newer Windows Live properties like Windows Live Favorites and Windows Live Fremont. The more performance we can squeeze out of our services stack, the better things look on our bottom line. 

Then there is support for a broader view of what it means to be a Web service. When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world's best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn't jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren't the only Web service on the planet. Technically they aren't even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk  SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0. I remember sending mail to a number of folks on the Indigo team about this disconnect including Doug Purdy, Don Box, Steve Swartz and Omri Gazitt. I remember there being some initial resistance to my feedback but eventually opinions started to thaw and today I'm glad to read posts where Doug Purdy calls himself one of the original REST-heads in the big house.

Anyway, the point is that there is more than one way to build services on the Web. Services frameworks like Indigo Windows Communication Foundation need to support this diverse world instead of trying to shove one solution down the throats of their customers. We at Microsoft now understand this, I hope eventually the rest of the industry does as well. 

Alan Kleymeyer has a post entitled NewsGator Online where he writes

I've switched my online news aggregator from Bloglines to Newsgator.  First, I wanted to try it out and compare it to Bloglines.  I like the interface better, especially in how you mark things as read.  I've swithched for good.  I mainly switched so that I can continue using RSS Bandit and get the benefit of syncing between it and an online news aggregator (supported in latest RSS Bandit 1.3.0.38 release)

Alan's post describes exactly why creating APIs for your online service and treating it as a Web platform and not just a web site is important. What would you rather use, a web-based aggregator which provides limited integration with a few desktop aggregators (i.e.Bloglines) OR a web-based aggregator which provides full integration with a variety of free and payware aggregators including RSS Bandit, NetNewsWire and FeedDemon? Building out a Web platform is about giving users choice which is what the NewsGator guys have done by providing the NewsGator API.

The canonical example of the power of Web APIs and Web platforms is RSS. Providing an RSS feed liberates your readers from the limitations of using one application (the Web browser) and one user interface (your HTML website) to view your content. They can consume it on their own terms using the applications that best fit their needs. Blogging wouldn't be as popular as it is today if not for this most fundamental of web services.

The topic of my ThinkWeek paper was turning Web sites into Web platforms and I was hoping to get to give a presentation about it at next year's O'Reilly Emerging Technology Conference but it got rejected. I guess I'll just have to keep shopping it around. Perhaps I can get it into Gnomedex or Mix '06. :)

Don Demsak has a post entitled XSLT 2.0, Microsoft, and the future of System.Xml which has some insightful perspectives on the future of XML in the .NET Framework

Oleg accidentally restarted the XSLT 2.0 on .Net firestorm by trying to startup an informal survey.  Dare chimed in with his view of how to get XSLT 2.0 in .Net.  M. David (the guy behind Saxon.Net which let .Net developers use Saxon on .Net) jumped in with his opinion.
...

One of the things that I’ve struggled with in System.Xml is how hard it is sometimes to extend the core library.  The XML MVPs have done a good job with some things, but other things (like implementing XSLT 2.0 on top of the XSLT 1.0 stuff) are impossible because so much of the library is buried in internal classes.  When building a complex library like System.Xml, there are 2 competing schools of thought:

1. Make the library easy to use and create a very small public facing surface area.
2. Make the library more of a core library with most classes and attributes public, and let others build easy (and very specific) object models on top of it.

The upside of the first methodology is that it is much easier to test, and the library just works out of the box.  The downside is that it very hard to extend the library, so it can only be used in very specific ways.

The upside of the second methodology is that you don’t have to trying to envision all the ways the library should be used.  Over time others will extend it to accomplish things that the original developers never thought of.  The downside is that you have a much larger surface area to test, and you are totally reliant on other projects to make your library useful.  This goes for both projects internal to Microsoft and external projects like the Mvp.Xml lib.

The System.Xml team has tended to use the first methodology, where the ASP.Net team tends to build their core stuff according to the second methodology, and then have a sub-team create another library using the first methodology, so developers have something to use right out of the box (think of System.Web.UI.HtmlControls as the low level API and System.Web.UI.WebControls as the higher level API).  The ASP.Net team builds their API this way because, from the beginning, they have always envisioned 3rd parties extending their library.  At the moment, this is not the case for the System.Xml library.  But the question is, should System.Xml be revamped and become a lower level API, and then rely on 3rd parties (like the Mvp.Xml project) to create more specific and easier to use APIs?  Obviously this is not something to be taken lightly.  It will be more costly to expose more of the internals of System.Xml.  But, if only the lower level API was part of the core .Net framework, it may then be possible to roll out newer, higher level, APIs on a release schedule different then the .Net framework schedule.  This way projects like XSLT 2.0 could be released without having to what for the next version of the framework.

 I’ve always been of the opinion that XSLT 2.0 does not need to be part of the core .Net framework.  Oleg doesn’t believe that the .Net open source community is as passionate as some of the other communities, so he would like to see Microsoft build XSLT 2.0.  I’d rather see the transformation of the System.Xml team into more of an ASP.Net like team.  If .Net is the future of development on the Windows platform, and XML is the future of Microsoft, then the System.Xml team needs to grow beyond its legacy as just an offshoot of the SQL Server team.  The System.Xml team still resides in the SQL Server building.  Back before .Net, the System.Xml was known as the SQL Web Data team, and unfortunately, still carries some of that mentality.  Folks like Joshua Allen and Dare (who are both not on the team anymore) fought to bring the team out from the shadows of SQL Server.  With new XML related groups, like XLinq and Windows Communication Framework, popping up within the company the System.Xml group is at a major crossroads.  They will either grow (in status and budget) and become more like the ASP.Net or they will get absorbed into one of the new groups.

 I’d prefer to see the System.Xml team grow and become full partners with teams like ASP.Net and the CLR team.  I’d like to see the XML based languages become first class programming languages within the Visual Studio IDE.  That means not only using things like XSLT and XML Schema as dynamic languages, but also be able to compile them down to IL and compiled with the other .Net languages.  I want to be able to create projects that contain not only VB or C#, but also XSLT and XML Schema (to name a couple), and have them compile into one executable.  Then developers can use things like XSLT 2.0, or the next in vogue XML based language, and take advantage of that language’s unique benefits, without having to choose between a compiled procedural language (like C# or VB) and dynamic functional languages like XSLT.  Linq is starting to bring in more of the functional programming style to the average procedural programmer, so I can start to see the rise public awareness of functional programming.  It is only a matter of time before the average programmer feels as comfortable with functional programming as they do with procedural programming, so we need to look towards including these languages within the Visual Studio IDE (which then leads into my discussion about evolving Visual Studio into more of an IDE Framework, and extended with add-ins.)

There is a lot of stuff which I agree with in Don's post which is why I forwarded it to some of the folks on the XML team. I'll be having lunch over there today to talk about some of the topics it raised

Don does gloss over something when it comes to the decision between whether Microsoft should implement a technology like XSLT 2.0 or whether we should just make it easy for third parties to do so. The truth is that Microsoft now has a large number of products which utilize XML-related technologies. For example, implementing something like XSLT 2.0 isn't just about providing a new version of the System.Xml.Xsl.XslCompiledTransform Class in the .NET Framework. It's also about deciding whether to update the XSLT engine used by Internet Explorer to support XSLT 2.0 (which is an entirely different code base), it's about adding support to the XSLT debugger in Visual Studio to support XSLT 2.0, and maybe even updating the Biztalk Mapper. Users of Microsoft products expect a cohesive and comprehensive experience. In many cases, only Microsoft can provide that experience (e.g. supporting XSLT 2.0 across our entire breadth of technologies and products that use XSLT). It was a really tough balance deciding what we should make extensible and what was too expensive to make extensible since we'd probably be the only ones who could take proper advantage of it when I was on the XML team. I'm glad to see that some of our MVPs understand how delicate of a balancing act shipping platform technologies can be.

I'm a day late to blog this but it looks like we announced releases in both the consumer and business instant messaging space yesterday.

From the InfoWorld article Microsoft uses Ajax to Web-enable corporate IM we learn

Microsoft Corp. Tuesday released a Web-based version of its corporate instant-messaging software that gives users access when they are working remotely or from non-Windows computers. Gurdeep Singh Pall, a Microsoft corporate vice president, unveiled the product, Office Communicator Web Access, in a keynote at the Interop New York 2005 show.

Office Communicator Web Access includes support for Ajax (Asynchronous Javascript and XML), a programming technology that enables developers to build applications that can be altered dynamically on a browser page without changing what happens on the server. The product provides a Web front end to Microsoft's Office Communicator desktop application, and is available to customers of Live Communications Server 2005 for immediate download at www.microsoft.com/rtc, said Paul Duffy, a senior product manager at Microsoft.

I'm confused as to why InfoWorld feels the need to mention AJAX in their story. It's not like when other products are announced they trumpet the fact that they are built using C++ or ASP.NET. The AJAX hype is definitely getting ridiculous.

From the blog post Windows Live Messenger Beta - Released from the Windows Live Messenger team's blog we learn

 Windows Live Messenger Beta is now available for use and testing to a limited set of users in the US, UK, Japan, Australia, Canada, China, France, Germany, Brazil, Korea, Netherlands, and Spain. More and more of you will be invited to join over the coming weeks/months.

They also have a blog post on the Official Feature List for Windows Live Messenger. Unfortunately, none of the features I'm working on are in this release. I can't wait until the features I'm working on finally get out to the public. :)

An artist's transition from gangsta rapper to pop star is always a weird one for fans. For example, there was a joke on this week's episode of the Boondocks about how Ice Cube "the guy who makes family movies" used to be a hard core gangsta rapper. I've personally been amused by how the subject matter of their songs changes as they realize that their fan base is dominated by prepubescent and teenage suburbanites as opposed to hip hop heads from the 'hood. 

On the album Blueprint 2: The Gift & The Curse Jay-Z has a song called Poppin' Tags which is about going to the mall and shopping. The subject matter of the song is the kind of thing you'd expect from Hilary Duff not Jigga. 

However 50 Cent has Jay-Z beat when it comes to songs targetted at the teenage mallrat crowd. On the soundtrack to his movie Get Rich or Die Tryin' 50 has two songs that belie his status as a gangsta rapper. There's the poorly crooned Window Shopper about how 50 Cent gets to go to the mall to buy stuff you can't afford. Then there's Best Friend where he begs to be some girl's "best friend" if the other guy in her life is "just a friend". 

But it gets worse.

Mike Torres sent me a link to a post entitled 50 Cent Caught Red Handed which is excerpted below

Remember that story about 50 Cent performing at some little girl's bat mitzvah? Yeah, you wish it didn't really happen. Nothing says hardcore gangster rapper like a teenie-bop white girl dancing to your music with two hundred of her closest white teenie-bop friends.

More pictures from the $500,000 bat mitzvah after the jump.

UPDATE: You can see all the photos from the bat mitzvah here.

Keep it real, Fiddy.