As I listened to one of the last panel sessions at this years HOW Design Live conference, I was surprised by how many questions were asked by the audience about content management systems (CMS). They ranged from the easily answerable—Do I need to use one?—to the not-so-easily-answerable—How do I choose the right one? As the questions kept coming up, I couldn’t help but feel that the discussion was veering off into the wrong territory. It wasn’t just that the question of which tool to use lacks a simple answer—most experienced developers have a preferred platform and will be able to make a good case for using it—but it seemed to me to be the wrong question to ask in the first place. The more important question is, How do I choose the right developer? I believe that if you choose the right developer, you will also choose the right CMS.
For many organizations and individuals, the choice of CMS is representative of far more than just a tool; it is often seen as a much more existentially defining decision, life altering in the way we think of geography or ethnicity. But honestly, folks, it’s not nearly so grandiose. If you only built your website once, perhaps such a grand view of its inception might be merited. The mundane reality, of course, is that the lifecycle of the average active website is 3-5 years, often continually adapted to the changing technology of the ecosystem of the web. If you want to take a long-view at the beginning and make decisions accordingly, you’re better off making a choice of relationship—aligning with a person or firm that will bring wisdom and stability to that changing environment—not one of technology.
Still, it is very common for specific solutions to be chosen purely on the basis of a perception of portability—the idea that once the website is built, the CMS won’t impose any barriers to relocating it or enabling any developer to work on it later. While I’ll agree that portability sounds fantastic, my experience has taught me that it’s actually never that simple. A sophisticated website—anything more than what you might call “brochureware”—whether built upon an open-source CMS or something proprietary, will likely launch with enough customization to make it truly unique. In other words, two websites built upon the same platform could be speaking very different languages when it comes to their underlying code. From the point of view of one developer trying to make sense of another’s code, true portability is a myth.
Though portability may not actually be the most relevant consideration, thinking critically about the CMS a potential developer will use is still important to do. But rather than evaluating the various platforms technologically, I think it makes sense to do so strategically—looking for what you might discern about your future partner (and website) in the process. So this month, I’d like to evaluate three possible developer/CMS scenarios and hopefully provide you with some points to consider next time you’re making a buying decision.
Rather than assuming the technological distinctions between various CMS options are the most relevant factors in your decision making process, I’m of the opinion that strategic and relational issues should be prioritized instead. Below are three of the most common web development/content management scenarios, which I’ve evaluated from that perspective. At the end of each, I’ve simplified the major points in list format.
Scenario 1: Your Website, Developed with a Licensed CMS
I decided to start with this one because it’s the scenario I’d most strongly recommend that you avoid. By licensed CMS, I mean one that your developer pays a third party—the company that developed the software—to use. While there are certainly a great number of licensable, proprietary content management systems available, this is also the scenario I hear about the least. I think this is partly because I’m not likely to hear about many jobs that are kept in-house, where legacy agreements and processes preserve relationships with large, expensive, and generally outdated software vendors and make them the default starting place for any new project.
That said, consider for a moment the scenario you’d be entering into if you did decide to work with a dedicated “_______” (drop in your favorite licensed CMS product here) developer: On the bright side, a developer wielding a license to a third-party proprietary CMS is sharing the risk of longevity with you. What that means is that maintaining a working relationship with you is valuable to your developer, otherwise he wouldn’t be willing to make his primary tool an overhead expense. In other words, paying yearly license fees isn’t worthwhile to a developer who can’t depend upon recurring revenue from clients. But—and this is an important caveat—any developer in this position will also be a permanent barrier between you and the CMS itself. Your project is built upon a foundation over which your developer has no control. And to make matters more insecure, your only assurance that your developer is keeping up with the latest versions of the CMS is simply a matter of trust. Sure, you could keep tabs on that, but is that really what you want to spend your time doing? For anyone considering the long-term viability of an investment, this scenario offers far too many “what ifs” to feel secure enough to green-light.
Conclusions:
- CMS licenses can be expensive to developers, which will tend to drive up their prices.
- Developers using licensed CMS share risk with their clients (not a bad thing).
- Developers using licensed CMS can be a barrier between their clients and their client’s website.
Scenario 2: Your Website, Developed with an Open-Source CMS
In all honesty, interest in open-source content management systems is the reason I wrote this article. The scenario I described in the introduction, where only projects developed with open-source tools are approved is a very real one, often—as I also mentioned—because of the promise of portability. It is thought that a website developed on “______” (drop in your favorite open-source CMS here) can be hosted anywhere, and worked on by any developer.
Let’s take a moment, though, to think about the position of a developer using an open-source CMS. From an operations standpoint, the choice to use an open-source CMS minimizes the risk of doing business. First, the tool is free. Second, open-source tools are often easy to learn because of the abundance of documentation available online—again, a cost-savings choice for a developer who wants to get up and running quickly. Third, the abundance of qualified developers using a given open-source CMS creates the impression that if a developer wants to extract themselves from a client relationship, their client won’t be left high and dry. Sounds nice, no? But the abundance factor is a double-edged sword. The easier it is for developers to extract themselves from client relationships, the more vulnerable those relationships are in general. Sure, if your developer bails, you could theoretically hire another one, but you’d be signing on to the same vulnerability again and again. And by the way, that point isn’t mitigated by being related to the developer. In fact, my experience has been the opposite. When the site is being developed by so-and-so’s nephew, it’s a harbinger for a hand-off to come, not to mention the realization that you get what you pay for.
But the most important thing to consider is this: Open source content management systems serve a very wide audience, and therefore are great at providing a very basic set of features. But when they’re pushed beyond their “comfort zone,” their limitations go from being a matter of cost/savings to a frustrating pain in the neck. I’ve personally noticed that many open-source tools are developed with a user/developer paradigm. By that, I mean the idea that the CMS is architected in a way that is incredibly useful if the person building the site is the same person who will be managing it moving forward (e.g., a sole proprietor/freelancer/hobby/vanity site). In these situations, trying to build something with a planner’s mentality—a foundation-up point of view on information architecture—reveal all kinds of inefficient twists and turns that can make implementing something as simple as a few multi-field forms a day-long task. But for those that want to start with a basic blog and add pages in an ad hoc process moving forward, they can often be more than satisfactory. If that describes your project, great. If not, not so great.
Finally, the central idea of open-source tools is that their code is accessible to anyone. “Out of the box,” a developer is likely to encounter plenty of limitations in an open-source CMS, the likes of which I mentioned above. But because the code is available and modifiable, a savvy enough developer could customize that particular install of the CMS code base significantly in order to extend the capabilities of the website. With the right developer, that could be fantastic, but how different would what you end up with be from a website created with a proprietary CMS? Not very. Then you’re back to square one: a not-so-portable website.
Conclusions:
- Developers using open-source CMS won’t be as inclined to prioritize their relationship with their clients.
- Open-source CMS may do the basic stuff well, but they lack the functional sophistication required for enterprise-level websites.
- The more malleable the CMS code, the more likely a website developed around it will be custom, too, and therefore not very “portable.”
Scenario 3: Your Website, Developed with a Proprietary CMS
Let me begin by admitting my obvious bias toward this scenario. Newfangled has been developing websites using a proprietary CMS—one we developed internally and do not license to other developers—since 2000. We don’t have any plans to abandon this approach; in fact, we’re on track to make some significant updates to our CMS and release them by this fall. Though we occasionally do some projects with WordPress and Drupal if the fit is right for us, we’re committed to developing primarily on our own platform and believe it offers some significant advantages. All that said, let me examine this scenario generally as I did the other two.
The connection between commitment and the proprietary CMS model is one worth thinking about. A developer using a proprietary CMS is likely to have a business strategy that depends heavily on long-term service models rather than just project sales. Think about what that means for this kind of developer’s clients. The investment in creating and maintaining a CMS is great. And a CMS that is not, in and of itself, a product that generates revenue can only be justified by its ability to enable long-term, profitable client relationships. In fact, the ongoing development of that kind of CMS is very likely to be shaped by the needs of the clients using it. Both of these factors show that a developer that creates and works with their own CMS is very likely to show a strong, long-term commitment to their clients.
But, you might question why an investment in building a powerful CMS could not be recouped by just doing large, expensive, one-off projects. Maybe it could, but I doubt it. That is certainly not the way we see our investment in Newfangled’s CMS. For us—and I would imagine this to be true of other developers like us—the ongoing value of the CMS is reflected in how it enables process efficiencies rather than specific functional outcomes. While we’re continually thinking about how we can improve it and investing time to do so (we’re at version 5.3 now), the competitive feature set and stability of our CMS is only one part of why we continue to use it rather than some other open-source solution. The other reason is because of those process efficiencies; they keep us very competitive on price. We can achieve big results for our clients without charging them the kinds of prices that might pay for CMS research and development because we expect them to remain our clients for a long time to come. When a developer has multiple clients that generate recurring revenue, no individual relationship is disproportionately depended upon to keep the shop open. Those situations are healthy for the developer, and for the developer’s clients.
As for portability, I’m not sure how other developers that work with a proprietary CMS do it, but we offer our clients licenses to the CMS for free. What that really means is that if they want to end their relationship with us, they can do so and take their site with them. Our CMS can be installed on just about any Linux server friendly to PHP, so it’s portable as far as that’s concerned. But I don’t want to be disingenuous here, I still think that portability is bogus. Think about it: Yes, you can move it. And yes, it will work. But any developer that inherits a relocated website will have to sift through code—most of it unfamiliar—in a manner so inefficient as to make rebuilding it not only an arguably better use of time, but a very likely outcome. I’ve seen this happen again and again: Rather than move and maintain an existing site, it’s cheaper just to redo it. As I mentioned earlier, this is going to be as true of any sophisticated site developed on an open-source platform as it would be of one developed on a proprietary system.
Conclusions:
- Websites built on proprietary CMS tend to be less “portable” compared with those built on less customized installs of open-source CMS. But…
- Developers using a proprietary CMS will be more inclined to prioritize their relationship with their clients.
- The functionality of proprietary CMS are often shaped over time by the clients who use them.
The Big Picture/The Right Questions
Reflecting upon our client history verifies much of what I’ve written here. We’ve begun many relationships with clients at their wits end with trying to maintain a website developed on licensed and open-source platforms and looking more for stability than anything else. We’ve also retained many of our clients for very long and fruitful tenures—some for over a decade—that endure through redesigns, rebuilds, and even potentially losing them when open-source approaches have looked attractive.
With all that in mind, here’s how I’d like to wrap this up. If you’re questioning how to proceed with a web project and what approach to CMS platform makes sense, consider the following:
- How long will this website last given the best of conditions? How does a realistic idea of the average website’s lifetime (probably no more than 3-4 years) affect your assessment of the role that the CMS should play in your decision making?
- What are the functional requirements of the site? Will the CMS that you’re considering be able to meet them?
- How do you perceive the history and stability of the developer you’re vetting? A short history or unstable operation is more likely to determine the longevity and quality of your website than any specific technology.