|Development Advisory: Continuing Hold on .NET Development
Like investment advisories providing buy, sell, or hold signals to stock investors, theOpenSourcery continues a Hold on Microsoft .NET development work. The rational is fourfold. First,the .NET Framework has not come to complete fruition. This is partially due to external delays in standards groups such as W3C, OASIS, WS-I in producing a complete set of Web Services standards in important areas as such security, transaction processing, and robust inter operation. But also Redmond is remiss in delivering promised .NET relief from old problems such as reliability and security breakdowns, banishment of .DLL Hell, the Registry Black Hole, plus better and faster development. Microsoft's CSA has recently acknowledged that current development is too complicated. In fact Redmond is not eating its own dog food as recently released software such as InfoPath 2003, Office 2003, Project 2003 and Visio 2003 are not written in .NET Framework. Even for programs written in .NET code, Redmond will not say what % of the code is .NET Unmanaged(easier to write and/or more performant but less secure/reliable) and what % is .NET Managed(the real deal).
The second .NET downside is that many problems have been deferred to Longhorn for solution. For example, on the UI side, Microsoft developers have to work with 5 different and mutually incompatible forms: WinForms and VBAForms and InfoPath Forms on Windows, WebForms in the Browser and .NET Compact Framework for Mobile and PDAs. Longhorn's Avalon and XAML will help to address this issue. But also .NET is the cause of a proliferation of scripting languages – JScript, WSH, VBScript, VBA, VB.NET, VSA among others that hold official sanction in the Redmond world of development. Hopefully, Redmond will start to rationalize this surfeit of languages. But not in a Draconian manner as was done in the case of VBx to VB.NET where the conversion was all VBx manually converted to VB6 then automated VB6 to VB.NET(but the conversion utility worked for only 70-80% of the code). Redmond needs to make a new Longhorn scripting tool not only attractive but adequately supported by robustly automated conversion utilities. Ditto for COM and database access tools where conversion utilities to the latest ADO.NET are "not plentifull".
The third downside for .NET is the timing. If you as developers begin a .NET project and deliver in 8-14 months time you will barely get a year's operation before the code is obsoleted by Longhorn. And Longhorn represents a major code change-over for Microsoft. The Windows SDK is a complete re-write. This includes the Avalon UI layer, the WinFS file system (not available in the first version of Longhorn but "coming")which will now be based on the Yukon relational database engine, and Indigo which will carry forward networking on a full XML+Web Services foundation. These changes imply some potentially very attractive IT features and services; but the price is old programs and even current .NET coding becomes obsolete. But the question arises what will Microsoft do for developers that have to make the large-scale transition/conversion to the new Longhorn and its profoundly changed underlying SDK and the inevitable programming changes. As we have seen above, the VB, ASP and ADO precedents are not encouraging.
The fourth downside is Redmond's increasingly laissez-faire bordering on an almost abusive attitude to developers. We have already seen how a $40B dollars in cash company could not find the resources to deliver an adequate conversion utility from earlier versions of VB to VB.NET (VC, ASP, ADO, RDO, COM developers could only wish). And developers supporting old but still heavily used software such as NT, Windows 9x, Exchange, and SQL Server 6.x or earlier now face no-support cutoff dates with few aids to make the transition to newer tools and systems.
So for these four reasons, developers are advised to hold on .NET developments.
Do expect Microsoft to hit their 2006 target for intro of Longhorn – although it may be at the year end and after a debilitating “death march”. But Bill Gates has indicated he wants his troops to meet the 2006 introductory deadline – and so there is already cutting back in Longhorn features to meet that date. Likely the first features to go will be the conversion and transition tools that will help developers get from here to the very different Longhorn there. And Microsoft cannot drop too many of Longhorn's unique features because it is no longer the lowest cost software provider. In fact Redmond needs to match a range of vendors like Adobe, BEA, IBM, Oracle, Peoplesoft, SAP, Sybase and others whose prices more nearly match Microsoft's and who are able to advance their products faster than Microsoft since they have less security/reliability/scalability problems to contend with than Redmond.
Finally, there is more evidence that Longhorn will become a Gated community where the point of entry is strictly XML and Web Services. Everything from Microsoft is designed to interoperate and run best within an almost strictly Redmond family of products with a very few selected external apps like IBM or Oracle or SAP allowed directly in. One can already see this Gated, Windows-best Community taking shape with the discontinuance of updates to IE which will be re-introduced in Longhorn as part of the operating system; by the low level of interoperability offered in Microsoft applications; the new Longhorn security apparatus; and the moves to become more self sufficient in basic apps. For example, Redmond markets a complete set of business systems with Great Plains, Navision, and Solomon products; is broadening its content management and collaboration software, and is rounding out its BPM, EAI, and BI lines.
But the Gates of Longhorn is a very risky proposition. It is not just the hurried release of Longhorn but the widespread changes it envisions. Bill Gates has already announced that there will be a new version of Office using Longhorn features to appear closely if not at the same time as Longhorn. As we have seen there is the large amount of unfinished .NET programming work to be done. And the scope and scale of changes with Avalon, Yukon/WinFS, and Indigo – the Longhorn OS alone is a daunting task. Now add one more ingredient – the newest lowest cost producers, Open Source Software. They are starting to technically challenge not just Microsoft but all the major vendors. Part of the low price for Oracle 10g is designed to stave off the new cluster capable MySQL as much to take market share from IBM or Microsoft. Likewise, JBoss is doing well at roughly 30% market share in the intensely competitive application server market. Plus Apache with a consistent 66% share of web servers– all are proving that Open Source is no fluke but in fact a very attractive software business model, especially with some of the new licensing modes. Open Source is being adopted not just for its price but its technical features and also Open Source's better rules of support plus future changes while respecting past legacy systems. Now in respones to OSS, what if Microsoft has to divert resources to better support – will it raise prices ? In fact for many lines of fundamental inquiry on the future direction of Microsoft, queries like this raise even more critical questions than answers. So this is an easy call. Hold on .NET development until Microsoft has more major .NET apps under its own belt like SQL Server 2005 and Whidby or Visual Studio 2005. Also wait for greater clarity on when and what Longhorn will bring. And most importantly wait and demand much greater clarity and committment from Microsoft on how it plans to support the tough programming transition from WinXP/Win2000/Win9x and their apps to the new and very different Longhorn world.