Up to that point, we had done every project in Coldfusion hosted on Windows (and eventually Linux). There is a price tag that came with that though, whether it be hosting, Coldfusion licensing/upgrading, or development costs. As people were let go due to the economy, we also realized that it is difficult to support proprietary code for a proprietary solution someone else wrote. Why? Because that person is the only person in the world who knows why they made the application/code that way. When something goes wrong, you spend hours trying to find the issue, and even more time coming up with a tested reliable solution.

Proprietary solutions are sold as the best thing since sliced bread, but what customers don’t know is that they are getting locked in to that company. You can’t easily cut ties with a firm and take your site someplace else. Proprietary applications are the brainchild of whoever developed it. Therefore, when you need support, you won’t get it. That developer is long gone, but you are stuck with their code. These firms put you in a box and want to keep you there- that is the whole point of proprietary systems. Why do you think you can’t install OSX on a PC? Why do you think video games are built only for Windows, and not Linux or Mac? It’s all about client retention.

With that, we decided to start fresh and drop our proprietary Coldfusion CMS and Ecommerce platforms. Everyday we were tied up in fixing Inclind Commerce, or trying to meet the needs of each client for Inclind CMS. Pete and I went as fast as we could, but we pretty much knew there was no way to compete with the rest of the world. We turned to open source solutions to provide us a solid base to build off of, instead of starting each project from scratch (which all essentially had the same core functionality as it were). Developing Coldfusion in Fusebox framework is/was an absolute nightmare and probably still is. It is a disjointed unauthentic implementation of MVC style framework despite what they say, and requires you to hold its hand every step of the development process.

We knew Wordpress would not be a solution at all. At best, it is a blogging platform and nothing more. You may read lots of articles that say how awesome Wordpress is and is a CMS, but it is not a CMS. You’ll also see that those articles are written by designers too, not developers. It’s a pain in the ass to develop for, it has patches every other week, plugins are prone to XSS attacks or theme hacking, and cannot sustain the level of development we perform. It is not a prime-time application for websites.

We also tried Joomla. Knowing it was based around Mambo, my expectations were low for it based on the experience I had working with Mambo. Even 5 years later, it had an ugly backend, scattered developer community, and little support. The developer area is full of confusing rules, practices and jargon. Take this for example, from the Joomla extensions page:

• Component – Mini-application to render the main page body.
• Module – Renders small html blocks on any page.
• Plugin – Changes code behavior dynamically.
• Language – Provides language translation.
• Ext. Specific Addon – Specific addon that requires another ext. to operate.
• Tool – External application that helps with creating or managing Joomla! site.

What the hell is the difference? All 6 bullet points say the same thing, yet they are 6 different kinds of extensions for Joomla. We couldn’t see ourselves training clients around the confusing backend or having lowered development time with their overly complicated extension system and scary licensing rules.

We came to Drupal. I had heard about this one on and off in various circles, generally more good than bad. After a week of successful proof of concepts for different kinds of websites, we decided Drupal was the best solution for us in terms of what we needed to accomplish.

Out of the box, Drupal provides:

• Database abstraction
• Auto-discovery of custom modules
• Managed workflow
• Robust Development API
• Experienced and organized developer community
• Intuitive administrative backend
• Easy integration of custom modules through the hook system

There is a solution for just about any scenario in the Drupal world. They have a very good approval process for modules. For example, if a module has security loopholes or bad coding practices, it will not be accepted until those are corrected (I don’t see this happening in other projects). If someone is trying to submit a module that already exists in some form, they are encouraged to merge efforts so the community isn’t littered with duplicate modules with the same functionality. It is differences like these that make Drupal the most widely used, highly regarded, best open source CMS bar none.

Our choice was the right one, proving vital in our relevance to custom web development and is a reason why we are still here and still the top choice for web design / web development / website building on the peninsula. We are able to deploy websites with a consistent codebase and backend in rapid succession. Clients are pleased with the added functionality and easier administrative UI. We’re at the point now where we can take Drupal and make it do anything we need it to do, big or small. We’ve been able to provide scalable solutions from the collaboration of many people providing a solid product. Instead of a couple of people making an in-house solution, we’re working with hundreds on a more polished result. We changed our entire development process so we could have a streamlined workflow and tighter communication between ourselves and the client with great results.

We have some pretty cool projects in the pipeline for 2010 utilizing Drupal and hope to have some things to show off in the next few months. iPhones, region-free real estate integration, content distribution, big boy stuff. Lookout.