Copyright 2008-2009, Paul Jackson, all rights reserved
I started work a couple of months ago on a startup project. The product itself is a desktop client connecting to web services, an environment I'm very familiar with, but we also need a website. We have virtually no budget to start with, so we’re going to be doing the website ourselves too.
Now I’m familiar with the mechanics of HTML, CSS, etc. But the artistic side escapes me. I’m a coder – and I can design acceptable WinForms applications, because there are guidelines that dictate how controls are to be used and what patterns are proven to work. The web’s a little different – there’s more acceptance of different behaviors and the controls aren’t as set. But we want something a little nicer and professional looking than straight HTML. And we’re also looking to have the things you’d expect from a site selling a product – a knowledge base, my account settings, user registration, billing, product sales, etc.
Now we could do all this ourselves, but that takes time; we could hire someone to do the site, but that takes money. A tight budget and no money coming in until we have the product sold to customers (which requires the site, after all), means we have to look at another alternative. Basically we want to target our resources at the product the customer will ultimately buy, rather than at the sales channel that gets them there.
I’d looked at DNN once before in conjunction with a project to move our company’s website and intranet from Java and IBM WebSphere to a .Net environment. The candidates were straight-ASP.net, DotNetNuke and SharePoint. Doing everything ourselves in ASP.Net was something we rapidly lost enthusiasm for – this evaluation occurred several years ago, in fact we were starting our development of .Net applications using the Visual Studio 2005 beta, so there were fewer tools available to us than there are today.
Between SharePoint and DotNetNuke, we made the decision to move forward with SharePoint. The first phase of the migration was to add an Intranet, and SharePoint was perfectly suited for that and would meet all of the requirements we had for an externally-facing site as well. DotNetNuke, on the other hand, was something we had two major concerns about: first, it’s maturity as a platform didn’t seem to be entirely baked yet (we evaluated, I think, version 3.x); and, second, it was open source.
Open source was a concern to us at the time, because Java and WebSphere had left a very bad taste in our mouths over the years, at least in mine. I know it’s not entirely rational to be down on open-source because of experiences with Java and WebSphere, neither of which is open-source, but dislike is rarely rational: I dislike WebSphere with the white-hot intensity of a thousand suns and a bit of that heat burns my feelings for Java and that trickles down to open-source, Java so often being its darling.
Why do I dislike WebSphere so much? The reasons are myriad, but one example:
On three separate occasions, I encountered … oddities in WebSphere’s behavior and reviewed the associated section of the Java Specification. It seemed to me, from my reading, that WebSphere was behaving in contradiction to the spec, so I called WebSphere support and pointed this out. On all three occasions, in three separate and distinct areas of the specification understand, I was told by WebSphere support that their product was in compliance with the spec and behaving properly. So I changed code to accommodate the behavior. And then, all three times, a future version of WebSphere changed the behavior “for compliance with the Java Specification” and I had to change the code again.
As I saw it, the problem was that there wasn’t a single entity in charge of how the environment should behave, and this was one of the major reasons I supported our decision to move from Java to .Net and make .Net our primary development environment. As I said when participating in a Microsoft focus group once:
We already tried Communism and that sucked, there’s something to be said for Fascism.
So, rational or not, I just wasn’t ready to support an open-source platform at that time.
Maybe I’ve mellowed since then, or maybe seeing an entire track devoted to DotNetNuke at the South Florida Code Camp made me wonder what the big deal was, but I took another look at it in conjunction with this project.
Version 5 of DotNetNuke has come a long way since the version I looked at years ago. In examining the feature set, it seems like DotNetNuke has almost everything we need for our sales and support site. It obviously doesn’t have the product-specific functionality we’ll need, but that’s to be expected. Also, it doesn’t have a knowledge-base for support, but there are a lot of inexpensive modules available – I found a company that offers that as part of a package of multiple, useful modules for less than a hundred dollars.
So after a bit of review we’ve decided to move forward using DotNetNuke as the framework for our site. I think doing so will cut the development time considerably and the end result will be a nicer, more professional site than we otherwise would have been able to accomplish. This isn’t to say that the process won’t be without its challenges – even the evaluation process of DotNetNuke hasn’t been all rainbows and unicorns, but, in general, I think the decision’s the right one.