Mono and the Open Source Boom

In the next few years mono is going to cause a huge boom in open source development. I believe there are tens of thousands of highly skilled programmers eager to participate in the open source movement, but have been reluctant because of inadequate tools. The potential for success of the open source community has been hurt by the high barriers to entry. Although open source projects come in all shapes and sizes, a vast majority of them require knowledge of the C programming language and a dedication to learn a relatively obscure set of libraries (GTK, QT, Apache�s plugin API).

Having adopted Java�s concept of a single inclusive API set, and it�s directing attitude (memory management, exceptions, single inheritance, etc), .net gives programmers a better tool. Having ported that tool to a variety of platforms without sacrificing access to native features mono has improved upon both java and .net. The result is a very usable software development platform that has the cross platform capabilities desired by open source developers and the ease of use desired by those programmers once left out of the community.

New developers no longer need to learn a new language to develop linux and mac applications. They can continue programming in VB or C#. No longer do they need to learn a huge set of complex APIs to create linux and mac applications (just the GTK or Cocoa bindings, if they choose to use the native features). No longer do they need to resolve piles of endless dependencies while compiling the source code before they write their first line of code (.net assemblies are cross platform at the binary level, and can be distributed in this form without performance issues). The barriers are coming down.

Microsoft�s Ace

Many in the open source community seem to be firmly against the adoption of mono. Some even consider the creators to be traders to the community. They seem to think that mono is evil because of .nets origins at Microsoft. Others think that supporting mono will give more leverage to Microsoft (presuming that Microsoft controls this standard any more than they control other open standards such as ECMA-script, HTML or SOAP). In short, people seem to think that mono might be too good to be true. There must be a catch.

"Avalon will ensure that the .net UI bindings for Windows are better than the .net UI APIs for any other operating system"

There are two catches (Neither should prevent the adoption of mono). The first catch: mono will encourage developers of all backgrounds to learn Microsoft-compatible technologies (note, I didn�t say Microsoft-controlled technologies). A large number of C# and VB programmers benefits Microsoft even if they never buy a Microsoft product. Microsoft�s customers will have a large pool of skilled workers to pull from. Another catch: although they released a very large portion of .net to open standards (enough to keep mono safe from Microsoft control), they kept the best for themselves: Avalon.

Avalon is Microsoft�s ace in the hole. The rest of .net is just a re-implementation of Java with a focus change toward multiple languages and native windows support. While Avalon is also based on existing technology, it�s never been put together in quite the same way. Avalon will ensure that the .net UI bindings for Windows are better than the .net UI APIs for any other operating system (and probably will be better for years to come). Miguel de Icaza hinted that an open source competitive library may be built in the future, but it�s not even on a white board yet.

Why is Avalon so nice?

Some of its features include XAML, which separates layout from UI code by embedding the layout in an XML file. This technique is similar to the .frm files generated by Visual Basic in 1993 (and somehow forgotten by the creators of Swing and SWT). Cocoa uses this practice (.nib files) as well as IntelliJ IDEA�s Swing layout extensions and JGoodies tools. It works well to separate design-time component properties and component layout from event handling and business logic.

Avalon and XAML also model themselves after SVG. In addition to primitive vector based components like those in SVG, XAML also provides vector-based components. In a few lines of XML, you can create a combobox, position it on the screen and apply graphic transforms on it to rotate or skew it. Vector based interfaces are the next logical step. Apple took an intermediate step by creating Quartz Extreme, which renders raster images on a vector. This allows �vector looking� animations without the performance hit of using real vectors. Microsoft is counting on Moore's law to provide the processing power needed by Avalon's vector based interface (although longhorn is said to have a 'light' mode which uses XP-style components when required).

"Asking the open source community to beat Microsoft to the next big technology at this point is like asking Iraq to make a better car than the Germans"

Another big (and for some, scary) addition to Longhorn will be Avalon�s deployment model. Avalon based programs will deploy in several ways. An Avalon program can work like an applet and run directly from a web page. If it needs greater set of permissions, it can load like a Java WebStart program. And of course, an Avalon program can still be installed as a normal application. These technologies didn�t work for Sun for reasons that don�t apply to Microsoft: Sun needed (and didn�t get) cooperation from leading OS and browser vendors to provide a good user experience; and WebStart and Applets are used to display applications written in AWT and Swing (which all by themselves negate any chance of a good user experience).

Avalon will be able to apply its distribution model to all PC running Longhorn or newer operating systems. The resulting application will have access to the same Avalon UI that Longhorn uses. These will be real native Windows applications, only limited by Java-esque sandbox restrictions (which can be bypassed by certificate or by directly installing the application on the PC).

Even though there are no dramatic technology advances in Avalon, it is still a huge win for Microsoft. It allows them to open up .net without loosing their competitive advantage. It will encourage industry leaders to write software for Windows. It will encourage users to continue buying Windows PCs (and maybe feel a little less jealous of Mac users). And lastly (and this is my largest concern), it puts Microsoft�s user experience way out in front of the open source community.

Nothing New in Avalon

Interestingly enough, I was able to describe Avalon by comparing its components to existing software frameworks, yet none of those frameworks lives up to the expectation of Avalon.

SVG should allow many of the features in XAML, but it doesn�t support components. Even if it was extendable, and the community agreed on a set of standard components, there are very few open source SVG implementations that live up to the spec (Batik is the only I know of that supports animation). XUL should be a good cross-platform alternative for creating thick clients, but it�s based on Javascript. While Javascript is very powerful and widely excepted as a scripting language, mainstream applications written in Javascript will always be the exception and never the rule.

There are even fewer alternatives to Avalon�s deployment model. Because of Microsoft�s support, Avalon�s deployment will be much more successful than their distant cousins (Java Applets and Java WebStart). I don�t expect to see an open source alternative gain much more support than Sun did with WebStart (what advantage would an open source project have have over Sun in this arena?). As far as creating an compatable open source port of Avalon�s deployment model, I seriously doubt Microsoft would allow that. They had good cause to open up .net, but no reason at all to open up their new deployment model (although I would love to be surprised).

Catching Up

Many criticize mono saying the open source community should be innovating more and copying less. I believe we are too far behind the curve to be considering innovation. Asking the open source community to beat Microsoft to the next big technology at this point is like asking Iraq to make a better car than the Germans. First we need to catch up, and then we can work on surpassing. Mono is a good first step in catching up. The next step may have to be Avalon. Currently this looks like a huge uphill battle. I don�t expect to see a practical open source competitor to Avalon within the next 7 years, although I look forward to helping the effort where I can. Until then, Mono is a good step forward for the entire software community.