It all comes down to the tools and application programming interfaces you have to work with.

At the dawn of the 2000s, with boy bands ruling the day, people thinking nu-metal would last forever and no one quite knowing what the next decade might bring, Microsoft pulled away from the traditional architecture it had used for the Windows 95 and 98 operating systems and moved toward a wider consolidation of its file systems and libraries with the .NET Framework project. Such an architecture, which sought to encapsulate all the functions of security, memory handling, interoperability, virtual machine operation, exception handling, library management and support for assorted programming languages, became something of a leviathan, but one that controlled a good deal of how the Windows operating systems behaved and how to write for Microsoft’s platforms.

If there’s a problem to be had with .NET, it’s the same problem you’ll find with any technology that’s an instrumental part of any corporation: It tends to be available for that company’s products and not much else. And as terrific as .NET has become, it’s still largely tied down to the Microsoft family of operating systems with few, if any, expectations that Microsoft might one day release its golden geese for non-Microsoft operating systems to enjoy.

Mono and Microsoft

Into this breach stepped Miguel de Icaza, formerly of Novell and now with Xamarin, who’s been working for the past eight years to bring .NET to the masses via the Mono Project, a set of open-source development tools that work to ensure that developers are able to run .NET applications across a wider array of operating systems. (The current list includes Android, BSD, iOS, Linux, OS X, Solaris, Unix and Windows, as well as assorted game console such as PlayStation 3, Wii and Xbox 360).

The Mono Project has done what the open-source movement is great at doing: taking something that’s closed off, reverse-engineering it, and releasing it to as wide an audience as possible—in this case, with considerable success.

Similar to .NET in many ways, the Mono Project has stated that its current aim is to support the feature base found in .NET 4.5—except for the Windows Presentation Foundation, Windows Workflow Foundation and Windows Communication Foundation file formats. (Additional efforts to support these formats are under way via the Olive libraries.)

Over the past several years, Mono has begun to come into its own, with the current version incorporating many of the elements of the .NET Framework.
#!
Branches on Mono’s tree
Like .NET, the Mono Project has added support for a wide variety of programming languages, including C, C++, Python, Java and Vala. The runtime version also shipped with two garbage collectors that work together to appropriately free up resources between the application and operating system.

Other projects that have spun off from the Mono effort include open-source media players; Android OS builds for Droid handsets as well as Apple’s iOS devices; cross-compatible Cocoa and C# development tools for the OS X platform; game-creation tools; and cross-compatible plug-in developments between the Mono Project and Microsoft’s Visual Studio application (something of an informal alliance, but still readily available to those who want it).

Which brings about the most pertinent question for the development community: Where do Microsoft and the Mono Project stand in relation to each other, especially given that Mono somewhat exists to reverse-engineer a Microsoft property, thus bringing similar functionality to non-Microsoft operating systems and devices?

“In the last decade, we went from a monocultural world dominated by Windows to a multiplatform world,” said de Icaza. “I know that you might be thinking, ‘Well, the guy works on Mono,’ and it is a common reaction by those that are not familiar with .NET. But the framework and the ecosystem are a delight to use, and you soon realize that there is some top-notch engineering going on its design.

About Chris Barylick