Let .NET be .NET

There exist not one, but myriad developer communities in the world. Scores exist in academia. Scores more can be found in business. Literally thousands are found in the private and individual worlds. To the uninitiated, these communities may look alike, but they are not.

Even down to the hive from which the codebase originates, these communities are grossly different. By the time we are initiated into a community, we know the difference (or do we) between assembly and C and C++ and C#. We are reminded (incessantly) of the superiority of our own platform and the inferiority of the competing equivalent.

Political and religious factions arise from our community passions: the Big-Endians are superior for this reason; the Little-Endians are superior for that. I am constantly entertained by each side -- but never so much as I am by the constant attempts by one or two of the non-Microsoft religions who attempt to both become and overcome Microsoft.

Mono appears to me to be one such siege for the throne. Other than an assault on the primacy of the platform, for what reason does it exist?

Those behind the Mono project seem to have blurred the difference between these divergent communities. If they achieve acclaim in one development community for appearing to duplicate the .NET framework, they should not expect to find the same acclaim in the most critical and fiercest developer communities: business automation development.

Microsoft's .NET platform is highly successful. Whether or not anyone in the non-Microsoft religions will admit it, it has a deep and wide following and fuels an astonishingly vibrant number of business and personal development communities. It is mature, complete, and thousands of small to large third-party tools are available for it.

It was built by Microsoft to work in the Microsoft operating systems. In its native environment, there exists no possible reason to mimic the .NET platform -- except to knock-off the intellectual property of an industry giant.

Microsoft's .NET platform was not built to work in other environments. This, apparently, is the open-source-community's invitation to copy the product (in whatever form and quality) for use on platforms for which it was not originally made. While an incompetent analogy, this is akin to copying the Chevy 442 engine block such that it could be dropped into a Ford. Chevy never intended for that to happen. If a driver wanted the Chevy 442 engine, they should buy Chevy. And, among the countless other reasons this is a bad idea, the company who built the hybrid cannot be expected to be there next week or next year for maintenance or support.

This point completes the logical circle. Considering the full-spectrum of developers, there must exist some community of rogues who neither care that their tools and platforms are supported, nor work in projects for which such risks are relevant. There must be very few of those communities in business.

JBoss is a haven of support and maintenance for the risk-averse in businesses running on the Linux and Java platforms. But it is not limited to the mere presence of the product that JBoss is a God-send to business. While Marc Fleury must be complimented for his vision, it was not until a full-bodied company, Red Hat, took JBoss under its corporate umbrella that such a product could be trusted by the business community.

Before that, those using JBoss had to be content with the anticipation that JBoss would be there tomorrow, or that it would be maintainable. Businesses who used JBoss before Red Hat's acquisition must have slept uneasily, wondering what additional programmer costs would occur should they lose the JBoss company while having its source embedded so deeply in the corporate automation.

And what, exactly, does Red Hat add to the JBoss code? Nothing. But it adds everything to its business stability. And does Red Hat give away its product? Yes. And No. At the business level, risk-averse businesses are more than willing to "buy" annual support contracts wherein Red Hat promises to support the implementations in which its products reside by promising to support and maintain its products.

In exactly the same way, unless and until a "Red Hat" comes along and renders Mono a marketplace product, Mono will remain on the cusp of respectability. Even so, considering that the ideas and structure of Mono is a direct copycat of products by one of the world's largest and most aggressively-protective companies, it would have to be a blatant, arrogant, and wealthy company who would bring such a product to direct competition in the marketplace.

While rendering an unsupported and divergent platform on which students, the technically curious, and the religiously competitive may experiment, Mono seems, in the short run at least, to be a mirage for businesses. Business, lest anyone forget, is the fortress in which most programmers earn their livings. Programmers, therefore, should see very little Mono at work. Unless it is the virus. Especially so, let us hope then that it is quite rare.

Nonetheless, the allure of the .NET framework is strong. But wait! Do not despair! There already exists a platform on which .NET exists, is supported, is backed by a multi-billion-dollar company, and can be expected to exist in this or larger form for decades. That platform is the Microsoft Operating System platform. That platform is Windows.

For the price of an affordable server, affordable workstations, licensed, maintained, and supported operating systems, licensed, maintained, and supported office productivity tools, licensed, maintained, and supported business ERP products, and the acquisition of reasonably-priced development resources, any business can install, extend, and maintain a custom implementation of their business automation using the Microsoft operating systems platforms and their tools (which nicely integrate and work with each other without so much as a small sacrifice to the gods of interoperability). Business can use .NET!

And if the business has not chosen the Microsoft pathway, for what possible business-friendly reason should the executives insert such a risky unknown in their architecture? And who among the programming communities would advise any business to engage in such risky decisions?

Let .NET be .NET.

Paris, because nobody else could be Paris; or want to be.