It's been slated as one of the most significant Linux projects in years, but can Mono really succeed in providing an open source equivalent to Microsoft's much-hyped .NET?
David Braue separates fact from fiction.
This article is featured in APC November 2004
If imitation is the sincerest form of flattery, Microsoft has a lot to be happy about. Although sceptics panned the .NET framework as the company's way of owning the emerging field of Web services, years of developer hand-holding and executive "education" have helped it become well accepted.
In fact, developers like .NET so much that several hundred of them have spent much of the past three years cloning it. Called to action by the initiative of developer Miguel de Icaza in 2001, their efforts to replicate .NET's functionality became reality this year with the 1.0 launch of Mono. Promising cross-platform compatibility with .NET, Mono is a comprehensive application framework that could, if its proponents play their cards right, become Microsoft's worst nightmare.
Microsoft's .NET strategy has always been based on customer lock-in. By supporting the technology only in its Windows environments, Microsoft has successfully positioned .NET — and its intimate links with open Web services standards including SOAP, XML and UDDI — as a Windows value-add. Microsoft's only concession to other operating systems has been its support for those Web services standards as a way of standardising information exchange between applications and platforms.
Although broad approval of .NET technologies such as the Common Language Infrastructure (CLI) helped Microsoft paint itself as contributing to the global development community, it also opened the company up to imitation. Microsoft was effectively asking for Mono to happen, and de Icaza's team wasted no time in taking up the challenge.
The final product could redefine the way apps are built in alternative environments. While Microsoft's legacy of successful Integrated Development Environments (IDEs) has helped it retain the mantle of development tools leader for years, these tools have only been available on Windows. This is a major reason why even Microsoft's critics continue to use tools like Visual Basic and Visual Studio.NET. Mono, on the other hand, offers its own open source IDE, debugger and documentation browser — all tools that mirror Microsoft tools' functionality in an open design.
Mono isn't a product, it's a technology toolkit for developers. Like .NET (and Sun Microsystems' competing J2EE), Mono incorporates a compiler that converts source code into bytecode, which is then run on a virtual machine called the Common Language Runtime (CLR). This is complemented by a growing set of libraries offering common functions such as GUI interfaces and data handling routines as well as .NET-specific features like ASP.NET and ADO.NET.
The primary development language for Mono is C#, which Microsoft developed specifically for .NET, but compilers for everything from C and Visual Basic to Python are already at various stages of development.
There's one big difference between Mono and .NET, however. While .NET is only available on servers running Windows, Mono is an open source project that can be implemented on any type of server environment. That means applications written using Mono can run seamlessly on Linux, Sun Solaris, Mac OS X and even OS/390-compatible mainframes. Developers can enjoy the strengths of C# — hailed as more productive and straightforward than languages like C++ and Visual Basic — while building apps that run smoothly in all sorts of environments.
"C# is pretty quick to develop in," says Edd Dumbill, a UK-based developer who recently co-wrote Mono: A Developer's Notebook, one of the first books to discuss the ins and outs of Mono. "It provides the benefits of a statically typed language and the constructs for organising source code, and provides a lot more for free, especially in terms of its object model."
Dumbill began using Mono two years ago and found it quite easy to transfer his earlier expertise into the new environment. More telling, however, was the fact that he and co-author Niel Bornstein — an experienced .NET programmer — had no trouble relating their experiences and writing Mono-compatible code for the book. This fact both reinforced Dumbill's belief in C#'s value and confirmed the viability of Mono as a vehicle for .NET compatibility.
Because it has been built under open source, Mono is naturally being positioned as a complement to Linux, which has become the de facto alternative to Windows in both the corporate and developer environments. It features functions such as the Gtk# toolkit — a series of .NET bindings included in Mono — as well as libraries for GNOME to allow development of customised interfaces.
As with any attempt to duplicate the functionality of a commercial product, Mono's success will depend on its ability to keep up with new developments in .NET. Mono 1.0 claims feature parity with the .NET Framework 1.1, although features such as Windows.Forms, Directory.Services, Enterprise Services and JScript are still less mature than the core framework components.
A potential spanner in the works will be Microsoft's upcoming release of Whidbey (see review on page 38), which will next year emerge as version 2.0 of .NET. Whidbey will include upgrades to ASP.NET, changes to compiler and class libraries, the debut of standards such as XQuery and XPath, new controls on Windows.Forms and the ObjectSpaces API to simplify database access.
Whidbey offers the Mono team a new target to work towards, with many of these features already planned for incorporation into Mono 1.2, an interim update due out by the end of the year. Full compatibility with Whidbey is expected with the release of Mono 2.0 around the second quarter of 2005.
But Whidbey isn't the only challenge that Mono faces. By 2006, WinFX — Longhorn's .NET stack — is due and is set to include a broad palette of features such as the WinFS file system, Indigo communications stack and Avalon GUI. Just how WinFX technologies will be implemented in Mono is still being decided; inevitably, the programmers will add features as they're revealed in the lead up to Longhorn's release.
Although the battle to compete with Whidbey is the Mono team's next big technical challenge, the project's ongoing support and growing technical acumen raises a very important long-term question: will Mono continue tagging along behind .NET, or will its developers begin taking the initiative to push Mono in new directions that Microsoft has yet to explore?
Who's using Mono?
Whether Mono eventually becomes a popular player in the .NET space will largely depend on its success among the business community, where support for its capabilities will be essential to its long-term viability. As with many open source projects, visibility will be a serious issue: even supremely elegant technical solutions will need strong support to offset the momentum of Microsoft's marketing machine, which has spent more than US$250 million promoting Windows Server 2003 alone.
By contrast, it took years of effort and the support of legitimate companies like IBM and HP to build distros such as Red Hat and Debian into brands that business customers trust. In this respect, Mono has found a surprisingly strong ally in Novell, which last year purchased Ximian, the company that, through de Icaza, had maintained initial stewardship over the Mono project. Earlier this year, Novell strengthened its move into open source with the purchase of Linux mindshare leader SuSE Linux.
A Novell Idea
Although Novell doesn't actually own Mono, it has taken stewardship of the project and will be using Mono technologies extensively within its product line. The company's first deliverable is iFolder 3, an open source file sharing and synchronisation tool written entirely in Mono. An enterprise version will add better security.
Mono's highest profile gig, however, will be its integration as a core element of Novell's Linux Desktop, due before the end of this year. By incorporating Mono elements into the rejigged SuSE desktop, Novell will be providing developers with a complete Linux-based, .NET 1.1-compatible environment that will permit developers to write C# enterprise applications that are hosted on a broad range of operating systems. This will be a significant differentiator for developers, many of whom will consider Novell's "development platform in a box" to be a welcome improvement over Microsoft's all-or-nothing Windows proposition.
Easy access to cross-platform capabilities remains an ideal within the development community, says Bill Tinker, immediate past president of the Australian Developers Network. Tinker, who now develops applications for corporate customers through his Melbourne company Aries Software, has yet to use Mono, but says he likes the idea — as long as compatibility proves up to scratch.
"On the one hand, I'm pleased alternative .NET runtime engines are being built," he says. "Microsoft isn't interested in porting its applications onto other platforms, so if someone else can do that, it's a win-win situation. The more platforms there are to move source code across, the more development there will be. But I've seen things in the past that claimed to be 100% compatible [and weren't]. It should be a zero effort transition, but there are such vast differences between platforms that it's very hard to imagine how one runtime environment can [embody] all the options available."
Developers on the Macintosh platform would benefit significantly from Mono, since Mac OS X has struggled to attract commercial developers.
Mono, an extremely popular download through Apple's Web site, should allow Windows-built .NET apps to be run on Mac OS X virtually unchanged. An independent project, Cocoa#, is building a two-way bridge between Mono and Mac OS X's Cocoa library of object-oriented development components to produce a two-way interface that tightly integrates them both. This will allow Mono-based applications to have a Mac look and feel, further strengthening Mono's credentials.
Other commercial software companies are watching Mono with interest. Longtime desktop publishing giant Quark, for instance, is rumoured to be among the companies eyeing Mono. A favourite on both Windows and Macintosh, its flagship package will be maintained in two completely separate versions. A Mono port would let the company — and others facing similar issues — support both platforms from a single code base.
Similar benefits have attracted the attention of Computer Associates (CA), whose broad portfolio of software includes a growing proportion of open source code. CA made a significant contribution to the open source community with its Ingres database, and has recently taken an interest in open source tools.
CA's developers have borrowed code from the projects to integrate into its own products as well. For instance, CA's BrightStor document management project incorporates code from the open source Zope content management system and the open source Plone portal framework. CA is also embedding parts of the JBoss open source Java application server.
Interest is increasing in Mono within CA, says David Cook, product manager for the company's AllFusion development tools range. Part of Cook's job involves evaluation of open source tools. He's generally bullish about the prospects for a system like Mono, but says it could face an uphill battle gaining support within brand-sensitive businesses.
"We see Mono as being not another runner in the J2EE-.NET race, but an extension [for cross-platform capabilities]. If our customers ask for it, we will absolutely support it."
A Mono future?
Although it presents a significant threat to Microsoft's Windows.NET lock-in, Mono isn't all bad news for the company. Mono actually supports the .NET message: by enabling the creation of a .NET-compatible environment on alternative OSes, Mono will help .NET compete against J2EE in Unix environments where the latter environment has enjoyed free reign.
Companies recognise Windows as an inevitable part of the enterprise environment, and few would be likely implement Mono on a Windows Server 2003 system when it already has .NET built in. However, many organisations remaining sceptical of .NET may finally be happy to explore its potential knowing it can be run on Unix as well as Windows.
This shift will also be helped by the fact that skilled in-house VB and C# programmers can use their skills to build applications for other environments. They could use Mono to build under Windows, Linux or other platforms, and then to deploy the application on the most appropriate server platform.
Corporate use of Mono is likely to remain extremely low until its compatibility is proven. However, as happened with Linux and Samba, its free availability could well lead to point implementations of the technology, where in-house development teams use the technology to move less critical .NET apps onto alternative platforms. By the time Mono reaches the boardroom level, many companies will likely be using it for a variety of purposes.
Achieving this critical mass will require lots of work. Open source's tendency toward continual incremental improvement makes Mono a moving target for developers, who see platform stability over time as a major issue. As a result, its developers will need to carefully stagger new releases to minimise upgrade pain and maintain backward compatibility.
Perhaps the most important factor at this point, however, is spreading the word. And that's an area where the effective endorsement of a well-known company such as Novell could turn out to be Mono's biggest asset.
"As technologists, it's great for us to have access to this sort of technology," says CA's David Cook. "But until the business asks the IT department for this level of support, we're not going to see it in the enterprise space. Mono may be able to play technically, but it's in the hearts and minds of businesses that this battle is going to be won."