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.

It would seem there is not only safety in numbers, but there is also productivity. Anyone who has managed a team knows that this is somewhat contradictory, as the more developers there are, the more code must be evaluated, checked, tested and integrated.

The Linux kernel now sees contributions from more than 10,000 developers every year, and other projects like Gnome are considering getting on the release train bandwagon.

The key point to remember here is that most of what these projects are doing around coordination and scheduling was said to be impossible only 10 years ago. Now it would seem that it is also possible to get all of those bright developers to commit to an actual schedule. And, as anyone who has worked in software development should know, schedules are the hardest part.