Microsoft should be more conservative about changing fundamental technologies in .NET, especially when its changes require substantial developer rework and reverse previously stated directions.
The company’s recent decision to shift from LINQ to SQL on the ADO.NET Entity Framework was unsettling to some developers, and it contributed to the confusion regarding .NET libraries and consistency. Uncertainty is anathema to developers who might be considering .NET and who don’t want to be programming for a moving target.
Developers do not welcome breaking changes and do not want to be stuck using technologies that are initially encouraged by Microsoft, but then suddenly are rendered obsolete. The fact that Microsoft has committed to a 10-year support cycle for LINQ to SQL does not inspire confidence in the enterprise, where it is not uncommon for many applications to be decades old.
Since the .NET Framework’s introduction less than a decade ago, Microsoft has rapidly evolved it into a popular and productive platform for developers. The company deserves credit for its stewardship of the platform, but it needs to put the brakes on introducing new features that fragment the platform’s existing technologies.
We hear accounts from developers and partners alike that struggle to keep up with the pace of change to those technologies. Continuing down that path is the wrong thing to do for customers and for .NET.
While it is true that the core of .NET has changed very little from .NET 2.0, few developers work with the base class libraries alone. The foundations that were added with .NET 3.0, along with features such as LINQ, are at the heart of many enterprise applications.
By its own admission, Microsoft would have saved itself a year of effort had it realized that developers wanted synergies between its various technologies. It took a year to right that wrong in .NET 3.5.
Businesses are betting that .NET will be a viable long-term platform, and Microsoft’s partners have built businesses around it. While .NET is good, Microsoft’s inconsistency about APIs and supported technologies is not.
Hitch a ride on the release train
In 2008, there were two Ruby communities: one formed around Ruby on Rails, the other around Merb, a competing framework. When the two groups merged at the start of 2009, the Ruby world was made whole. Other Rails support projects merged into Rails, and with the upcoming Rails 3.0 release, the platform has matured considerably.
Coming together is a strength all over the open-source world. Consider the Eclipse model, where hundreds of developers working on dozens of projects are tasked with hitting milestones and release dates. Some would say it’d be like herding cats, particularly because Eclipse’s many contributors are distributed around the globe and work for different companies. And yet the release trains have been successful and have insured that the IDE remains on the cutting edge of software development.