Thoughts on tweet: "drupal vs. clearspace vs. dotnetnuke... and go."

Context: This is a response the tweet posted by @ographer. I've worked extensively througout my career with many open source frameworks. PHPNuke directly and Drupal directly. However, I've never worked with the Clearspace.

Pros

1. In a short time you can demo a lot of functionality...people will like that. (traditional check list of features)

This is especially true if the person making the buy decision is a "higher up" who won't actually use the tool. If an engineer, UX designer, or potential heavy user of the system digs a little deeper I think they would have a similar response to the one I rant about below.

Cons

1. Most of these tools feels like an open source project.

The following is a major rant about what it means to "feel like an open source" project.

Basically, most of these projects start out as home baked CMS (Content Management System) tools developed by a freelance developer. Why? Because these guys are doing webdev work on the side or full time, and they love doing the tech work but hate getting bugged by clients to update content, tweak this color scheme, add this little bit of functionality, etc, etc. for only marginal additional revenue. So, they build a system where they can put control into the hands of their clients and it works well in the beginning when there are only a few thing the end user has to configure/manage but it eventually balloons. The people who start these open source CMSish projects are usually coming from the scenario described above and have the mindset, "this job would be great if it wasn't for the clients".

What this means to the end user and potential purchaser of one of these products/services is that there is A LOT to manage. If you get into using one of these tools to build a community you'll notice admin interfaces with tons links. Translation, steep learning curve. You'll also notice that whenever you want to add a new piece of functionality (e.g. E-Commerce) you MUST KNOW to look for that external plugin module, load it up and configure it. To really do this you might have to actually go out to the web, search for the module you want, download it, load it into the framework's core, etc. etc....yikes. The end user is not going to like this when trying to make the community work for them.

The main point I'm making here is that these tools tend to be designed to make the developer's life easier...this makes sense when you consider how these projects start out. The other point to make is that within each module these engineers are going to make assumptions in order to make their life a little easier....the result is extremely complex admin interfaces and you'll notice that once you try to do anything above and beyond the basic functionality. One of the things that blows me away about our platform, HiveLive, is the architecture underneath. Actually, that is one of the main reasons why I joined the team. We don't make any assumptions about what the end user may or may not want. This gives us more flexibility than any other system. Although we also have a decent amount of admin interfaces right now, our architecture makes it easier for us to identify patterns and suggest prepackaged configurations to users attempting to admin the system...some of these open source tools are going to have a difficult time doing this because of the underlying architecture. The main point I'm trying to make is that our platform has been designed from the ground up with our users in mind while most open source tools of this nature are developed (notice I didn't use the word "designed") in order to make the engineer's life easier...they hate getting bugged by clients.