The Monkey or the Gorilla?
The monkey is a reference to Mono, which is the spanish word for monkey. The gorilla is a reference to .NET, released by the 800-pound Microsoft gorilla. This weblog entry is an extension of my earlier entry concerning my indecision about which technology to use. Mono 1.0 is fully compatible with .NET 1.1, with the exception of Enterprise Services. Mono is not yet compatible with .NET 2.0, so there is a decision to be made about which technology to choose.
Right now, Charlie does not use a single capability provided by .NET 2.0. So, I could move it over to Mono 1.0 with very little effort. Or, I could evolve it to use .NET 2.0 with very little effort. But those are divergent paths that will not converge again until some time in the future. So, which path should I choose? Should I go with the monkey, or go with the gorilla?
I said in my earlier post that going with the Mono monkey would lessen my business opportunities. In a reply to that post, Brendan Ingram challenged that statement, and rightly so. I did not really explain what I meant when I said that. Brendan also concluded by saying that going with Mono may in fact increase my business opportunities. Whether that is true or not depends on the business model for Charlie. That is something to which I have not given due thought, which is a horrific oversight on my part. So, let me explain my thoughts on the matter.
First though, I want to put my thoughts in context. Specially, I want to repeat that I come into this industry from outside. As a result, the only sample applications that I have ever seen are framework applications, never bespoke applications. A framework application is like DotNetNuke, where its target is developers. They take the framework, plug in new pieces, flip a few preference switches, add some content, and away they go. A bespoke application is like Flickr, where its target is end users. Charlie started out as a bespoke application, as I had explicitly stated that its target users were my own clients, not other developers and their respective clients. But, because all of the sample applications that I have seen are framework applications, I keep losing sight of the fact that Charlie started out as a bespoke application. For example, I added plugins to Charlie in a way that would support other developers adding plugins too, even though that was not a goal for Charlie—it was just the way I have seen things done, so it was the way I did it too.
Now, framework applications and bespoke applications are naturally different, and require different decisions to be made to the same problems. Take for example the need to style a web application. If Charlie remains a bespoke application, then I can implement styling any damn way I please. No-one else will ever see the implementation, and no-one else will even care. But if Charlie were to become a framework application, then I need to implement styling in a developer-friendly way, which, in the context of ASP.NET 2.0, means using Themes and Skins. As a further example, take the possibility of adding AJAX functionality. If Charlie remains a bespoke application, I can implement client-side functionality any damn way I please. But if Charlie were to become a framework application, then I would need to implement AJAX in a developer-friendly way, which, in the context of ASP.NET 2.0, means Atlas.
I feel that I have two choices with Charlie. Leave it as a bespoke application, in which case I can go with either Mono or .NET. Or, I can make it a framework application, in which case I really need to go with the gorilla. Which should I choose? Well, that should be a business decision, and I see four ways in which Charlie can earn money.
The first way in which Charlie can earn money is the obvious way: find website clients and use Charlie to build the website. Charlie will be technology by which I can anwser “Yes” to questions such as “Can we edit the content of the website?” and “Can we extend our website later?” Whether Charlie is a framework application or a bespoke application makes no great difference here. But Mono would put a smile on the face of those website owners whose technical folk inevitably ask, “Do you use open-source software?”
The second way in which Charlie can earn money is by selling it, or its components, to other developers. Both the Wilson WebPortal and Community Server have a business model that includes this aspect. Going with .NET over Mono would help here, since the market is larger. More important, most Mono developers will be advanced developers who would have no interest in the simple Charlie. Conversely, many .NET developers are novice and intermediate developers who may certainly have an interest. But, this approach would mean that Charlie should become a framework application, not a bespoke application.
The third way in which Charlie can earn money is by releasing it as open-source software, and trying to encourage community development. Community development would mean that Charlie becomes a richer application than I could ever achieve by myself. Having a richer application would mean that Charlie could help me to obtain clients that I could not have obtained if I’d kept Charlie as a closed-source application. Going with .NET over Mono would help here too, simply because of the size of the market. However, I think the ASP.NET community is already saturated with open-source website frameworks, so I don’t think this is a realistic model for Charlie. Still, it is an option that needs to be considered.
The final way that Charlie can earn money is by providing an avenue by which I can earn incidental income. It has been suggested a number of times that I should write articles. If I were to move Charlie over to Mono, there would be very little that I could write about that would be of interest to others. MonoRail, for example, is just too hard for the average developer to install and use, and just too complex to write an article about (the example application on CodeProject doesn’t even work). But if I were to learn ASP.NET 2.0, I could write articles on the things that I learn along the way.
Does this rambling weblog entry explain why I sense that there are more opporunities if I were to follow the ASP.NET 2.0 path rather than the Mono 1.0 path (remembering that the paths are currently diverged, and may not converge again for a good long while)?
Another thing that concerns me (I worry about a lot, don’t I?) is that what I like most about Mono and its projects seem at odds with .NET 2.0. For example, the provider model of .NET 2.0 does not seem to be compatible with the O/R Mapping model that is prevalent in the Mono world. For another example, the rapid application development model of .NET 2.0 does not seem to be compatibile with the Inversion of Control model that Castle promotes. The goals of .NET 2.0 developers and Mono developers do not seem very compatible, which is why I sense that I need to make a decision on which way to go. I may have this completely wrong, and my concerns may be unfounded. However this weblog is a record of my ongoing learning and my increasing understanding, and this weblog entry notes my current thoughts on the monkey and the gorilla.
by Alister Jones | Next up: Charlie. The Little Engine that Could →
----
Going with the Gorilla makes the most sence at the moment.
The chance that MONO will catch up with all the features you use and support them is much larger then the other way around.
(using mono specific parts)
But the most part of this entry is about mindset and development.
MonoRail != Mono
And actually don't have that much to do with eachother.
Post a Comment