Coming Full Circle

I was forwarded something interesting from a client. It was a service that we had discussed rolling out on our own. Interestingly, it also was developed and marketed by a firm not unlike my own - a small website and custom programming shop. I went to their site, and noticed they were touting their own CMS platform.

"Ah," I thought, "there but for the grace of god go I."

There was a point in time where I felt I needed to have my own CMS platform to be taken seriously. In fact, we founded KutterGroup with a custom platform we developed for The Paramount Center for the Arts, and ever since, we developed a custom CMS for each client from the ground up.

As anyone who as ever done so can tell you, it gets old fast. For every site there's about 90% of a CMS that's redundant. Users need to login and perform certain tasks depending on who they are, pages have titles, urls, one or more paragraphs of text, etc... Developing an engine to store, manage and display that over and over again isn't terribly difficult, but is quite redundant. Furthermore, each client had their own project, which, let's be honest, after launch, wasn't heavily modified unless the need arose. Over time, we came to the realization that we should have our own platform where this work can be centralized, and if each client was using the same platform, fixes and enhancements built for one could be enjoyed by the rest.

So we went about doing just that. It was pretty neat if I do say so myself. It was written in C# to run on .NET (more on that later), everything could be managed via a web interface, new content types could be defined, fields could be added to those types, and instances of those types could be created. It was centrally managed - it ran on our hosting environment and pushed out "compiled" sites via FTP (this was because we wanted to be able to push content to any website). It also had a mechanism for managing multiple sites under the same client. Perhaps the coolest feature of all, it was scriptable using IronPython - so collections of content instances could be searched, sorted and displayed via simple scripts.

And, it was a colossal waste of time and effort.

For everything it did, it didn't do dynamic things all that well - forms and dynamic pages needed to be handled outside the system. It was difficult to learn (it made perfect sense to me, but I wrote it), and it turns out, it was rather fragile.

The idea was to have it run on a shared host with a company then called Mosso (now RackspaceCloud). However, due to increased focus on security, Mosso changed their .NET hosting environment to "Medium Trust." Embedding IronPython meant I needed more than that. As a result my fabulous CMS could no longer run on our shared hosting environment. As we found out, many .NET hosts were Medium Trust or lower. We didn't want to invest in the infrastructure to run this on servers we maintained (a dedicated or even virtual windows server was cost prohibitive, especially since we only had a handful of sites that used it).

Long story short, we had something that we spent 6 months developing, that we couldn't use.

Around this time, we started to get a lot of questions from new and existing clients about the viability of Drupal as a platform. Up to that point, my attitude on Open Source CMS projects was that they gave you several kitchen sinks worth of stuff, and that really all you needed was a simple spigot, so you spent most of your time ripping out pieces you didn't need, and in the process, likely broke most of the product.

We had experience with Mambo (now Joomla) and WordPress, and we weren't terribly impressed. Simply, we felt it was easier to build required functionality from the ground up, than tear down unnecessary functionality from the top. However, despite all this, we decided to give Drupal a proper go.

Drupal, as a website platform, is, simply put - perfect. Well, not perfect, but it comes pretty close. It makes sense, that since 90% of the sites we developed had similar requirements, then in turn, 90% of the world's sites would have similar requirements. Drupal has been around for a while, and is quite popular, so there are a lot of other developers who have built functionality to cover that 90% quite well. Drupal is a big box of legos. Want to add a signup form for MailChimp? Here's a brick. Want to make a page that will show only certain types with certain criteria? Here's a different brick. Instead of trying to put everything possible into the CMS core itself, Drupal is modular, allowing us to find just about anything to meet a requirement. However, the real beauty is that if we need to do something that we can't find a brick for, we can use the incredibly powerful hook system to either make something that exists do what we want, or flat out make our own brick.

The module system is well thought out, and is a joy to develop for. We only need to spend our time working on integrating modules and building any remaining custom functionality, so our clients get much more bang for their buck. We're also able to turn sites around much faster, increasing our bang for the buck. We see it as a win-win.

It's fitting then, that we've come full circle.

Our very first project we did as KutterGroup was the custom CMS for The Paramount Center for the Arts, and it set the stage for subsequent sites. Now, with quite a few Drupal sites under our belt, we have the pleasure of announcing a revamped website for the Paramount, built, of course, in Drupal.