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.

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).

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.

Everywhere I go I hear the same phrase, over and over: �we do things different than other companies because our product is different than anything else out there�. People treat each situation as if no other company in the world has ever had to deal with the situation before. Our [product|business|company|whatever] is so different that we need our own procedures for [version control|build process|conventions|source organization|whatever]. I wonder sometimes if this is some sort of disconnect from the rest of the world (most companies in my area have a lot of 10-20 year �lifers� who haven�t worked anywhere else and have never been exposed to the internal workings of other companies) or, even worse, some sort of superior thinking (maybe they really do believe they are just that unique).

Either way, I regularly find myself in a conversation about stupid, no-brainer decisions that I thought the industry made for us years ago. Most languages for example now come with their own coding conventions (Java, C#, VB.net). Why would you deviate from them? You don�t like where the brackets go? Get used to it! It takes a lot less effort to adapt to the convention than to try to enforce a new one (especially when you need to deal with third party source code). Is your build process a pain to use? Nothing a few more batch files can�t fix! Why not find out what the rest of the world is doing?

Why? Because the people in charge are the ones who have been with the company the longest. They are rewarded for their loyalty (which make sense in a Ross-Perot-pie-chart kind of way). In return, technical groups are run by those who are the least connected to the rest of the world. The most connected people in the company have the least seniority and the least say in procedure changes.

What can you do? I�ve tried changing the world. Damn thing won�t move. Currently I�m trying the �Thank you sir � may I have another� approach. My sanity has improved dramatically. I can�t be sure it will work in the long run. As far as I know that�s how all these lifers got here. I may just be adding to the problem.

UPDATE:

Weiqi Gao writes:
�It won't be long before you will become one of the old timers, managing a bunch young people who think they know the solution to every problem. And the cycle repeats itself. :)�

Weiqi can smell my fear. A year ago, the idea of completing this cycle really bothered me, but I'm beginning to think this stereotype is beatable.

This reminds me of a conversation I had with my wife over the weekend. We were talking about the difference between knowledge and wisdom. I decided that knowledge can be gained in any number of ways, but wisdom had to be obtained by experience (usually because when verbalized, real wisdom can't be distinguished from a silly clich� through outside analysis alone).

There was a time when knowledge and wisdom went hand and hand. Because lives weren't front loaded with education, people learned equally throughout their lives. The older they were the more knowledge they had. Wisdom of course always has worked this way, and always will. A couple hundred years ago, when formal education replaced apprenticeship, things changed. Now people gain most of their factual knowledge at a young age and do their best to keep that knowledge current as they get older (which of course is much more difficult in our industry than in others). They of course still gain wisdom as they gain experience.

This leads me back to my original post. In our industry we have a good deal of young knowledgeable people with, perhaps little real wisdom; and a good deal of wise people who could use a bit more knowledge. Not understanding the difference between the two, our society falls back on tradition and delegates power to the experienced.

The problem isn't in how the responsibility is being delegated (although that is what I inferred in my original post). The real problem is with the employees themselves. The young should recognize the value of wisdom (which is a bit of a paradox, as it requires a bit of wisdom to appreciate it in others). The experienced should realize that they cannot rely only on wisdom. The world is moving too fast to rely completely on past experience.

This seems a much more optimistic view. If we challenge our selves to gain good experiences (and pay attention to the results), we will over time gain wisdom. If we continue to learn and not become complacent, we can have both knowledge and wisdom, thereby breaking the cycle.