I stumbled across this create resource and immediately had to replace my old HTML based Twitter widget with a much nice Silverlight one.  You can see it in the right sidebar of my homepage.  Though I am not sure if something that splatters my face even more on my site is a good idea.  I may have to grab the source and hack a more viewer friendly version...

Sam Chenaur has an interesting post and video on some proof of concept working going on with Silverlight Mobile.  Very cool stuff of what will be available to Silverlight developers in the mobile space in the not to distant future.

What has been a rumor forever has finally come to fruition - subscribers to both NetFlix and XBox Live Gold can stream movies to their XBOX 360 - intro details and caveats here.  This is something I have been waiting for for a very long time.  I was doing the Blockbuster Online DVD thing by mail for a while because I liked the option of going to the Blockbuster on the corner and swapping movies.  The challenge recently, however, has been that I've been so busy with family and work things the past few months I was never watching what came by mail and just rolled over to swap DVDs for something more recent when I had time to watch a movie.  I've thought the idea of getting movies via XBox would be great - but then again, I don't do much pay-per-view either so maybe not.  Regardless, this is a cool announcement and a nice first step.  Hopefully, it won't be long before the entire NetFlix catalog is available.  When it is, maybe that will be the time to watch all of the Babylon 5 episodes again! ;-)

Ryan Stewart over on ZDNet has some interesting thoughts on this area... nothing earth-shattering but one of the few times I have seen this thought put together so succinctly.

Tim Barcz posted today about how he and his team will be transitioning from an ASP.NET 1.1 app to ASP.NET MVC.  Tim plans on posting how it goes, problems, tips, etc.  I'm really excited about the opportunity to "watch over his shoulder" as Tim gets to work on the transition.  There hasn't been much said out there about actually making this kind of transition.  Quite a bit about why you might want to make the transition (and Tim covers some of that in his post) but not much about real world "how I got here from there" information.  I'll keep my fingers crossed that Tim will have the time to post often and in detail about how things are going.

Tim Barcz blogged about attending a session at the recent ALT.NET conference that centered around why people choose a first gen Microsoft product (but you can apply this to any vendor really) over a more mature open source project.  You can read Tim's thoughts here.  Tim gives a good example of one of the big benefits of open source and that is being able to fix the source when you encounter an issue, but I'm not sure it really tackles the original question though - "why some (many) developers, managers, and executives feel comfortable choosing a brand-new Microsoft product when a far more mature open source alternative exists?"

Tim demonstrated one great aspect of having open source - being able to fix bugs on your own or modify the code to suit your particular application or scenario.  But the reason Tim talks about for not wanting to go open source in the first place (lack of known viability and a desire to NOT have to support that code base) still exists.  Yes, you were able to fix an issue, but you are still responsible for maintaining and versioning that code from now on.  Now, if you submit the bug fix back to the project and it gets rolled into the code base, life is good. 

Yes, having the source is nice in the scenario Tim paints - fixing bugs, extending, whatever.  But it does not alleviate the original problem of "I don't want to support that code."  Now for larger open source projects, that is probably not a valid reason to not choose open source since they have become so large and popular that they have a high probability of being around for a long time.  For small to medium projects, however, the long term viability may be a bit more dicey.  If I have a "big vendor" solution where I have a higher degree of confidence that it will be around for a while (yes, vendor solutions sometimes "disappear" as well), then I have mitigated the support risk out of the equation.  Yes, I give up a lot in exchange for that, but it is a trade off that makes business sense in a lot of cases.

Now some will say, "but if vendor A discontinues that project" or "if Vendor B goes belly up" you are much worse off because you don't have the source.  I don't agree because what I am really faced with is a migration effort to another supported platform or taking on support of someone else's code.  If my desire is to mitigate the amount of code I have to support, having a particular closed source solution basically needs I would need to migrate as opposed to take on a software support activity.  That is a valid goal for organizations where software development is not their core competency. (because I have the source does not mean I have the time, resources and/or technical expertise to support it or even take advantage of it). I shudder at having to think of having a large code base that I am now responsible for making sure runs on the next version of x dev platform or y operating system.  I think this stems from a lot of open source advocates of not realizing that if your business is making widgets, your really don't want to get in the habit of directly supporting any more code than you absolutely have to.  If I have limited on staff dev resources, I can see a lot of scenarios where I would rather bite the bullet and migrate than take on support.

Another way to look at it is the exploding interest in SaaS applications.  Companies today do not want to even support applications on premise if they can avoid it.  They would much rather let someone else support certain applications since it is cheaper and a better utilization of the company's core competency assets.  But for some reason being able to bring large amounts of source into my organization with the idea that I may some day have to support it and say that that is always a good thing doesn't make a lot of sense.  That is a very broad brush to use and by no means am  I saying that open source is bad, shouldn't be used, etc.  There are a ton of great open source solutions out there, but there are a ton of good reasons to go with vendor solutions (even less capable ones) if you look at things through a different lens.  I don't think its a slam dunk either way and both sides can be right depending on the solution, the vendor, and the company.

This is worth a look see - cool watch.  That is done all in XAML!  Micheal used an image of the actual watch to create its XAML representation using Expression Blend, maybe a little Expression Design?  You can some of the details from Micheal's blog here.

This article on InfoWorld raises the idea that SaaS may be "throw away" software and as such, its long term viability is questionable.  Simon Jacobson, an AMR analyst, is paraphrased in the article as saying..

According to Jacobson, some companies are using SaaS as an interim solution. Try it for a year, two, maybe three, and when the time is right, dump it for something better.  That something better could be another SaaS application, yes, which in turn could be thrown away when it gets replaced by the new, more innovative solution that comes along.

Ephraim Schwartz, the article's author, continues on with that notion and concludes there is a high likelihood that SaaS could very well end up being another flash in the pan.  His conclusion stems mainly from the idea that a company can bypass initial up front investments in traditional software, ERP is the example used in the article, for two or three years of SaaS "goodness" and then dump their SaaS commitment and move on to something bigger and better.  To be correct, this idea relies heavily on the notion that a SaaS "commitment" easy to break off, with time and dollars being the two primary dimensions used to illustrate the lower commitment threshold.

But that really is not accurate.  From a pure IT perspective, yes, SaaS typically has lower startup costs and a much faster time to deployment model than traditional solutions.  But Schwartz misses out on two key things when he looks at short SaaS "flings".  First, after two years, there is going to be a significant amount of time invested in training employees and shaping business process around that short term SaaS solution.  When I look at the massive amount of time and energy that was spent on getting Microsoft employees and processes up to speed with our Siebel deployment (shudder, groan... run to bathroom) I laugh at the idea that a company would want to go through that type of pain every two years.  Yes, smaller companies would experience less angst, but the long term ramifications of switching major business applications would have a big impact on the bottom line regardless of the size of the company.

Secondly, and I would argue more importantly, think of the important data that would have to be moved from the choice du yesterday to the choice du jour.  After two years, a company is going to have a lot of customer data, business data, you name the data, invested in a given platform.  There is absolutely no incentive for a SaaS provider to make it easy to extract or migrate that data in any meaningful way.  It enables the very scenario that Schwartz describes so any SaaS vendor that has the mantra of "we make it easy for you to leave" is just asking to go out of business.  No one is going to do that.  The whole idea with the "try before you buy" model that many SaaS vendors have is based on the notion that a) you will find there offering acceptable and b) once you actually invest time/resources (not necessarily dollars) it won't be easy for you to leave.  Even if you are able to pull the data out of a particular SaaS vendor, you still have to get it into some other solution.  That is not going to be an easy proposition either.  Vendors may start to make such tools, but rest assured their competition will continue to try and make it hard for you.  The SaaS model actually makes it very easy to do just that.  If Vendor A comes up with a solution to migrate Vendor Bs data, all Vendor B has to do is change their data formats ever so slightly.  The end user will never see the changes (the beauty of an application in the cloud), but Vendor A's migration tool will suddenly be SOL.

SaaS and it's cousin S+S are long term directions IMHO. There are still issues to be resolved on a variety of fronts before they are truly "universal" and even then, there will remain many valid reasons to run applications on premise.  Maybe some of those reasons will limit SaaS success, but to say SaaS is "throw away" and doomed to failure ignores a lot of the "real world" realities that business face today.

Some folks may have been having some problems accessing some of the podcasts I have uploaded to the site.  My ISP enabled a feature that seemed to have an adverse impact on some folks.  I think I have the situation corrected.

I wanted to call your attention to a series of articles that a co-worker and friend, Hanu Kommalapati's will be writing.  He just posted his first entry on "Fundamentals" and will continue on to cover things like security, architecture, deployment, and more.  Hanu is one of those people that falls into my "wicked smart" category.  Hanu does a great job of looking at things through a customer's eyes and then articulating technical information in an approachable way.  I just wish he would post more!!!