Dare's recent post: Fire & Motion: The Trouble with Competing with Google
reminded me of one of the more difficult truths of working at Microsoft. As an industry gorilla, every move Microsoft makes leaves a wake that shares more in common with a tsunami than the poetic ripples of a pebble in a pond. Working at Microsoft on the XML team starting just after the publishing of the original W3C XML spec
and staying with that team until relatively recently, I became acutely aware of the difficulties of working at a large company. I had meant to write a post about this when Oleg wrote about XSLT 2.0
and Dare responded with his comments
. I was involved in some of the discussions about shipping XSLT 2.0 and/or XQuery. Just as Dare calls out how expensive it is for Microsoft to compete with Google's GMail, it is surprisingly expensive for Microsoft to implement XSLT 2.0 (or XQuery). An implementation of XSLT 2.0 would require man-years of implementation effort, as well as a few more man-years of QA, and then there is the long term cost of support/documentation/maintenance of such a complicated product. One might counter that Microsoft is huge and can easily afford a few man-years here or there, but the only team likely to ship such a product is the XML team, and the XML team is actually a relatively small team that already has its hands full supporting MSXML, existing System.Xml features, SQLXML, while still trying to innovate on the core XML programming experience (a-la XLinq
This is one of the reasons I decided to leave Microsoft. Everything Microsoft does, it does in a big way. It isn't realistically possible to 'just try out an idea'. Even back 8 years ago, when I first joined Microsoft, they released a technology preview of some of the ideas that lead to XSLT. They had people designing companies based on that single tech-preview, with the assumption that Microsoft would ship something based on it. Unless it is a research group, it is virtually impossible to explore a new idea and release a tech-preview type release that is not directly tied to a product. In some ways, this is good. It forces people to be focused on profits and costs and not waste time and money. On the other hand, it means that innovation that isn't immediately tied to millions in revenue is discouraged. In a coffee conversation with someone else who left Microsoft, they mentioned that someone at Microsoft specifically mentioned that it is now openly talked about how some Microsoft divisions encourage innovators to leave to a start-up, with the potential for Microsoft to purchase the start-up if it pans out.
What this means is that Microsoft is a great place to start your career (because there are some excellent opportunities to work with experienced people who know what they are doing) or end your career (because you either want to sit on your arse and collect a safe salary, or are like Don Box or Anders Heilsjberg and are out to change the world). If you live in the middle, Microsoft can be a tough place.
What this means for XSLT 2.0, is that it is a non-priority. At least when I was on the team, we would have been happy to encourage a small team outside of Microsoft to build a .Net XSLT 2.0 engine. If it was good enough, there might be a chance that Microsoft would someday purchase the company or at least the IP. In the short term, the cost of implementing XSLT 2.0 is extremely high relative to the return. Getting back to Dare's original post, the economics of Michael Kay
implementing XSLT 2.0 are flipped compared to Microsoft. As a 'small-time-player' his investment on the bleeding edge will garner him customers. This is similar to the phenomenon that Dare was discussion with GMail vs HotMail vs Yahoo Mail. The more entrenched in that domain, the harder it is to innovate. Usually. Clayton M. Christensen's Innovator's Dilemma
series discusses this at length and provides some suggestions for how to avoid these pitfalls. More of Microsoft's management would do well to study how to apply some of the lessons mentioned in those books to its current business.