Mono and The Fort Worth .NET Users Group
Late last year, Paco, Stephen and myself talked about having Paco come in and do a presentation to the Fort Worth .NET Users Group related along the lines of “Mono for the Microsoft .NET Developer”. Although I'm not a fan of Linux, I find the idea behind what Mono is to be very beneficial to *all* .NET developers. I also believe that if Linux wishes to be approachable to *all* developers that it needs a development platform akin to VB... if not specifically VB. Like it or not, VB is one of the deciding factors that has made Windows as successful as it is today. Although Mono is still currently a C#-centric project, the road map states very clearly that VB is part of their overall strategy... again, another thing that keeps my interest in Mono alive. As I stated previously, Paco demonstrated an application written in VB using VS2K3... rebooted and it ran in Linux as a native (Mono.NET) application. No code changes or recompiling necessary. At that time, what was demoed was the GTK# Windows Forms style UI... so I'm still keeping a close eye on Mono's progress with their implementation of Microsoft's Windows Forms UI.
OK, so if I'm not a fan of Linux, why should I even be interested in Mono? There's a few of reasons:
1. As a developer who makes his living by either selling software to the masses or developing software for those that sell software to the masses... I'm looking for additional target audiences to sell software to. My opinion of the Linux customer is that they want something for free, therefore I'm not interested in that audience. However, Macintosh... now there's a group that *is* willing to pay for software. Sure, it's a lot smaller market than Windows, but nonetheless it's a market that's available.
2. Since Mono is an open source project not held to the rigid release cycle that Microsoft has to be locked into... Mono is able to be a bit more agile in what technologies they can implement. This allows us to play with concepts that are only in the announcement phase from Microsoft; yet are in early implementation stages within Mono. Sure, Mono still has a long way to go, but what's there is very promising and, in many instances, production ready.
3. Mono brings to the table a strong competitive playing field between Microsoft and the open source community. If your a Microsoft .NET developer, you can do nothing but benefit from this fact. Mono will help drive Microsoft forward. As Mono matures, this will become even more evident and hopefully will bring back the days similar to Microsoft C++ and Borland C++ competing for the edge. I don't foresee Mono being “one step ahead” of Microsoft... however, I do believe that Mono can keep Microsoft “on their toes”.
4. Having Mono in your toolbox will allow the Microsoft .NET developer to say “Yes I can target Linux“. In some cases, having at least part of your networked based applications on Linux might be cost beneficial. There is no one right answer in technology... having Mono in your toolbox allows you to have more options available while still allowing you to focus on being .NET developer.
Now some may point out that Java can do the “same thing”. That may technically be correct, however, from my personal observations... I don't really care for Java. Just compare any JSP based site with an ASP.NET based site. The performance (perceived or real) is night and day between the two. In addition to that... Java just does not have an answer to the Smart Client question. I firmly believe that we are at the beginning stages of a shift back to the Client based applications (that still leverage internet connectivity)... moving further away from the browser based application. This is not to say that the browser is dead, only that we've reached the limits of browser based applications and users will begin to demand “intuitive” applications once more. I could site an example of seeing my insurance agents office personally interact with the web based applications versus their 1985 era terminal client applications... but rather than bore you with my observations and conclusions... try visiting your own insurance agent and watch them play with both types of applications. This is just one example of the problem...