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.
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.
“We started the work on the Mono Project since we were frustrated with low-level languages to build large applications, and at the time, high-level languages were just too slow to power those applications. So C# and .NET were a good fit, a balance of performance and high-level features.” de Icaza went on to compliment .NET’s progress over the years.
“Luckily, the framework has evolved over time,” he said. “.NET is not the same beast that it was back in 2001. It has kept up very well with the new understanding about the world. .NET brought full generic programming sometime around 2003, then the C# language went through iterations that added, first, generics support, then functional programming constructs, then dynamic constructs, and most recently support for beautifully handling asynchronous programming.
“.NET was designed very much at a time when Windows was king, so every once in a while there is an API that is sadly designed with Windows in mind. Luckily, we have been able to replace those in many cases with cross-platform ones, or they have become deprecated. Although there are things that I would like to fix in the core, purely from a perfection perspective, they are livable. And the good things that have been built around it make up for the few mistakes here and there in the core.”
#
Microsoft’s handling of open source
At this point, there’s something of a truce, and even Microsoft is reaching out to the open-source community to a small extent. The Mono Project currently falls under the Microsoft Community Promise, which functions as an established covenant to not assert legal rights or action over certain Microsoft patents on implementations. As such, there exists some wiggle room within Microsoft’s patents, and Mono’s code, if found in violation of these patents, could be altered so as not to infringe upon Microsoft’s legal claims.
To date, Mono seems to exist in a gray area and has even been regarded askance within the Linux community. Back in 2009, it was unknown as to whether to include elements of the Mono Project within Fedora 12—Red Hat’s Linux distribution—given its legal status. Fedora project leader Paul Frields has stated that “We do have some serious concerns about Mono and we’ll continue to look at it with our legal counsel to see what if any steps are needed on our part,” yet that the Fedora Project has “yet to come to a legal conclusion that is pat enough for us to make the decision to take Mono out.”
“Microsoft has already moved libraries like Entity Framework into open source development,” said Brandon Bray, group program manager of Microsoft’s Managed Languages team. “Right now, Microsoft has no tooling for (non-Microsoft operating systems). It’s good to see Mono filling this space. In fact, C# is probably the most portable programming language on phone platforms today because of Mono,” he said.
“The downside of having such a large programming API and being on so many platforms is that developers have to spend a lot of time hunting for libraries or tutorials,” he said regarding the current scale of the .NET effort, and where Mono and open-source efforts fit into this.
Bray then went on to endorse the NuGet effort, which functions as an open-source package manager for the .NET Framework and is distributed as a Visual Studio extension.
“Mono has been around since the standardization effort for .NET began in ECMA,” Bray said. ECMA has created a standard that defines the Common Language Infrastructure (CLI), in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications. “The Mono Project has been a great example of cross-platform capability,” he added. “Microsoft has frequently collaborated with the Mono team.”
Where developers themselves were concerned, feelings toward .NET seemed somewhat ambivalent, albeit some wished for a wider support basis from Microsoft regarding the Mono Project.
“I haven’t used Mono for anything production-related, mostly just quick testing or trying to compile something needed for Linux,” said Tim Donaworth, a security engineer for Gemini Security Solutions. “But I honestly think it’s a great thing. I wish MS would further open the framework. I don’t know if they support Mono, but from what I’ve heard, they’re not trying to stop it.”
Donaworth went on to praise Microsoft’s support of additional libraries to .NET, which have helped him in his work. “I think the addition of LINQ was the biggest change for me though. Being able to take an object-oriented approach to databases, or even to use previous SQL experience on objects, now made managing data a breeze.”
#!
Building an F# bridge
If a grand compromise exists between Microsoft’s .NET Framework effort and the Mono Project community, it can be found in the F# programming language, which de Icaza called “currently one of my favorites.” The F# tools, which can be downloaded from the F# Software Foundation, function as an open-source, cross-platform CLI language that can also generate JavaScript and GPU code when necessary. The language, which was developed via a collaboration between the F# Software Foundation and Microsoft, is currently supported in Microsoft’s Visual Studio development along with Mono, MonoDevelop and SharpDevelop. It also functions on the Android, iOS, Linux, OS X and Windows operating systems.
Even if Mono has yet to completely break out and become the de facto programming standard for all, it’s presently finding its way into some useful tools. Per Bruce Morrison, producer at video game development company Man Up Time, Mono has had elements used in the Unity game development engine, which Morrison has come to know and love in his day-to-day work developing games for the iOS platform.
“Unity is extremely good,” said Morrison. “It has some technical limits, but the power and speed of development it brings can’t be beat.”
Morrison went on to add that he supports the idea of Mono helping .NET Framework capabilities reach more platforms, especially iOS. Still, he felt the integrated development environment in Mono Develop could stand to see some improvement in future versions.
Other developers sided with Microsoft’s .NET Framework architecture but still liked how the Mono Project was evolving as a development tool. “I’ve made a couple attempts at getting my game to compile with MonoGame, but I haven’t had any luck yet,” said Ian Stockton, a self-taught game designer and developer with experience in both .NET and Mono, with a preference for the C# programming language. “One of these days, I’ll need to sit down with someone who knows his way around the framework so I can get it working. In terms of being cross-platform between Xbox and PC, XNA is amazing. Aside from some resolution and file system things, it’s almost automatically cross platform.”
Stockton then detailed the changes he’d like to see made with the Mono Project, especially within the realm of getting new developers acclimated to the technology. “An easier installation process would be nice,” he said. “When I tried it last, I think I had to install about five different programs just to access the codebase. A walkthrough for getting the examples to compile would also be great.
“XNA has spoiled me. Now I feel entitled to zero-friction new projects and deployment. If only MonoGame were so simple!”
The relationship between Microsoft and Mono is and has always been a strange one (if not incendiary at times), complete with all the hesitancy, caution and fervor of a very large software company defending a key technology, and the open-source community doing what it can to bring .NET’s feature set to its operating systems of choice.
Even so, there seems to be a bridge slowly forming between the two camps. In eight years’ time, Microsoft has respected its Community Promise, left Mono alone and seems to be collaborating well with de Icaza’s brainchild, even if there are mutterings among developers that they’d like to see more tools from Microsoft available to the Mono side of the camp. The Mono Project, in turn, has thrived, created what tools it could to work directly with the .NET Framework architecture, and cranked out some amazing open-source tools with no signs of slowing down or stopping.
No, the relationship between the two sides isn’t perfect, nor will it ever be. The two efforts serve different needs and different creators, even if their goal of creating killer developer tools for their respective user bases is the same. The bridge between the .NET Framework and Mono architectures may never be complete, but it is gradually extending, with both sides offering a maturing set of tools to work with as well as collaborating with the other side’s tool set.
And that’s good news to any developer looking for a better means of finishing his or her project.
