| 
| 
|
 In This Article
NEWSLETTERS | JULY, 2011 CMS Crossfire: A Strategic Comparison of Open-Source, Licensed, and ProprietaryRather 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:
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:
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:
The Big Picture/The Right QuestionsReflecting 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:
 
|
    Subscribe To Our NewsletterApril 2012 Why Scope Creep is Your Fault (and What You Can Do to Prevent It)  |
Chris,
This really is a wonderful article!
I think you really nailed the portability topic when it comes to medium to larger-scale websites. The cost of migrating content is just so much lower than developing a deep partnership that it really shouldn't be a big factor when choosing a platform now that web development best practices have matured.
Great article, I've experienced exactly what you said with "pushed beyond their comfort zone".
Once things get a little different you end up at the drawing board ;)
Fantastic article!
Chris,
Great article. Your bias towards proprietary systems is obvious. But, hey! I'm open source all the way.
In my business, hardly a week goes by without an email from a potential client at the end of their tether asking for help because their developer bailed, or went back to uni, or just plain disappeared.
The low cost of entry into web development as a profession has led to the rise of an amateur army - spiky haired 20 year olds that think they can bang out a site in a day for a thousand bucks and every one will be happy. Had to chuckle at "that point isn't mitigated by being related to the developer."
I urge any potential clients to read the title of this article over and over. Choose a developer, not a CMS.
J
I can't express how strongly I disagree with your conclusion. Your premise is sound - I agree that people need to focus on choosing the right vendor to work with, not worry themselves with the specific technology choice. By hiring a competent firm, they will recommend the technology most appropriate to your needs (or they should at least).
However, this article takes a bizarre left turn into spinning the anti-customer business model of "single vendor lock-in" as the optimal choice. By deploying a proprietary CMS, you are now the only vendor the client can return to. Once the site goes live, they are essentially your hostage. With such guaranteed business, what motivation is there for the company to continue to produce high quality work at reasonable prices (aside from common decency, of course)?
I've had to save organizations from this kind of toxic "hostage situation" time and time again.
This is one of the big selling points to using an open source or even a licensed off-the-shelf system. If your relationship with your vendor goes sour, or the company goes out of business, you aren't left stranded.
As a client, I'd personally rather work for a firm who is dedicated to doing a good job to keep me as a client as opposed to relying on proprietary technology handcuffs.
Right On! Relationship is the key here. Technology in and of itself never solved anything. Understanding clients true needs is the real question. Offering real services, not shiny software is the only viable solution.
Admittedly it is quite hard at times to educate potential clients that they are paying for time and commitment, not just trendy one-stop shopping solutions.
Well written and informative as usual, but I must admit with James (last post) re the client hostage comment.
I had a recent case of this with a client at wits and wallet's end because of a technology company I had partnered with years ago. The client is now struggling financially and one of their biggest monthly expense was to keeping the site alive. Client was basically hostage to the developer's CMS, and in today's low cost hosting and CMS plans available it simply made no sense paying these ongoing fees.
Aside from the customization part of Scenario #3, this is no different than Scenario #1 re hostage aspect.
Keep up the great content, always enjoyable!
Joel: Thanks for reading! The whole question of portability was why I wrote this in the first place.
Peter: Indeed. But for sites with less complex functional requirements, some of the open source options can be quite good.
Ajay: Thanks!
John: The "my developer bailed" scenario is far too common, but it's a wonderful ongoing opportunity for commitment-oriented developers to step in and show these clients what a good relationship can be.
James: You're absolutely right: a hostage situation could be the result of working with a developer that uses a proprietary solution. But, that is certainly not the only result. In other words, it doesn't follow that every developer that uses proprietary tools holds their clients hostage. The missing link here, as anecdotal and aspirational as it may be, is, as you said "common decency." Of course, word-of-mouth and the power any of our clients have to share a complaint if they have one could do major damage to our ability to continue operating as we do. But we get continually positive feedback from our clients, who are very happy to remain in relationship with us after launch precisely because we have a very strong motivation to continue producing high-quality work for them. An unhappy client is extremely costly to a business—not just because they might tell other people not to work with us—but because serving them as long as they do remain would be arduous and unhappy for everyone. It would take more time, require much more free work, and create burnout among our staff very quickly. So, our motivation to continue high-level service is pretty holistic: it's good for our clients, and good for us.
Robert: Now that I've read your comment, I think it succinctly addresses James's point quite well. Thanks!
Josh: As I mentioned to James, this could happen, but it's very possible that it won't. It really depends upon the people involved. Thanks for reading!
Thanks, everyone, for starting up a great conversation!
@Christopher, I appreciated your point about a proprietary CMS making things more efficient for developers, and therefore more beneficial for clients. I've often yelled at WordPress, thinking, 'this isn't the way I want it to work!' when developing a theme or plugin. Developing for a platform that I created would certainly be quicker, and it would allow for faster customisation to my clients' needs. This article may yet convince me to develop the CMS I've always wanted to develop!
I do, however, think that developing for a certain platform does give a bit of portability -- if you're used to coding for WordPress, for example, and you adopt a customised WordPress site from your client's last developer who went AWOL, it will take you a bit less time to figure out how everything worked, because you'll at least be familiar with the basics -- how to use the hooks, how to call a DB query, how plugins are structured, etc.
One thing you may not have mentioned: Those developers who have actually participated in developing their own CMS, are going to be much more agile when it comes to actually customizing your website for you. How many Wordpress developers are there that can't customize something for you without going over the documentation every single time? I think the majority. Having a well documented system does not necessarily mean that development will be faster, it often only breeds the ability to find things in the documentation.
When you've actually developed and deployed an entire CMS by yourself, or with a team you work with daily (I've developed and deployed my own system entirely on my own), you know exactly how each part works intimately. Doing customizations are much easier when you've actually had a hand in putting the framework together.
As far as locking clients into using you exclusively as a developer, I don't see this as being as much as a problem as it seems to be. As a solution, I've offered to simply document the basics as to how my system works. Though the docs aren't done yet, any decent developer in the future could figure it out unless they're worthless as a developer in the first place. I put a liberal open source license on it, to give my clients permissive rights to use it as they wish. So while my system is sort of proprietary, seeing how I'm the only one deploying it, I'm using open source to make clients feel better about the freedoms they'll enjoy from using it.
I think this was a well thought out piece and finally something that addressed the human factors beyond just the technology.
@James and @Josh, did you make it all the way throught the proprietary section? The author talked about a connection between commitment and proprietary tools, and made clear that his opinion was that proprietary developers are "very likely to show a strong, long-term commitment to their clients."
@Chris I think you elaborated well on that thread, so you're obviously not advocating for forcing clients to work with you ongoing.
Love the illustrations but cannot agree with your points, all be them well laid. In summary: ditto "client hostage". Should a client of yours decide the relationship isn't working for them they'll be hard pressed to find someone to work on your proprietary system - much more so than even a heavily customized but already popular CMS with an active community behind it.
Cannot agree about open source vs. licensed platforms either - there is give and take there and it depends on site requirements and priorities. ExpressionEngine comes to mind, often a much better fit than WP or Drupal (but not always) and there's plenty of folks who can pick it up quickly thanks to public documentation (all platforms).
I can understand developing a bespoke site with a framework, you & your client benefit from a lot of heavy lifting being done already. Generally though, I find pushing your own private CMS totally self-indulgent.
Great article. Really enjoyed reading it.
With the argument against open source, I think the fact that those systems try to do *so* much that it also ends up affecting the Basics that they do well at the beginning. Systems like Drupal that are focused on supporting so many thousand features often can fall out of date with making some basic things (i.e., controlling meta data) easy for end-users. So, the longer an open source system is in the wild, it starts to not only lack in those extended features that you identify, but also some of the basic ones.
@Abel great point in how a firm w/ their own CMS has already mastered it and can likely build custom features into it much quicker than a developer working on an open source or outside-proprietary system. I mean, if the firm built it, you can be pretty damn sure that they're experts in using it and customizing it.
A very well written article (and comments) that covers the facts from different angles. I think all systems have their pros and cons but overall I agree with choosing the developer, not the CMS.
I have had many a conversation with clients about the benefits of using a 'in-house' cms over an 'off the shelf' product and it would have been great to refer them to an article like this ;) ... One sentence that sums up my view is: A propitiatory cms can be tailored to the project where as many open-source or licensed systems involve modifying the project to fit the cms.
Paul d'Aoust: My advice would be to measure your inclinations toward R&D against the typical functional scope of the sites you're building. If you find that you're continually stretching what one open-source tool can do, perhaps it's not a good fit. But, it may be that another tool is a better fit, especially in comparison with starting from scratch and creating your own. Creating a unique CMS is a big risk—one I wouldn't really recommend to many unless you have plenty of cushion (cash or clients) to help you through that process. To your point: there are other CMS out there that might be a better midway between something basic and something proprietary.
Abel: I agree and hinted at that here: Bill: Thanks for the backup ;-)
Mahalie: Thanks, I had just as much fun making the illustrations as I did writing the article! As to your points, I think the hostage issue has been dealt with already. This could be the result of a proprietary solution being employed, but it's not a necessary one. The relationship will be the distinguishing factor. As far as how that plays out in reality, well, we've had hundreds of clients work with us in the past decade, none of which have decided to end their relationship with us and take their site, house it elsewhere, and have a new developer work on it. This is not because we don't allow it. We consider our clients the owners of their sites; they are free to leave and take them whenever they like. Sure, that would be difficult, but not impossible. Our CMS is developed to run on LAMP-friendly servers and is PHP-based (i.e. very common development environments). Few do this because they see more to our relationship with them than just hosting and implementation. They see us as strategic advisors that will help them continue to move forward and excel in a constantly changing technological environment.
Clay: I've noticed the same thing, as well as the point that I made in this article that many of them seem to be architected with an assumed developer/user paradigm—in other words, that the person creating the site is the same person who will be using/growing it long-term. Thus, it is easier to add pages and functionality ad-hoc than it is to create a "master-plan" and create something fairly sophisticated from scratch. I referenced a scenario in which creating a multi-field form can take far longer than it should because of this (add field -> name it -> position it -> save -> repeat).
Justin: Thanks for reading. I hope you have opportunity to use this article as a resource in the future!
Thanks, everyone, for your comments! Keep 'em coming!
Chris,
As usual, a very insightful article that I enjoyed immensely.
Full disclaimer – I am a Partner of a boutique agency that has built a practice around an open-source CMS (Drupal).
You are absolutely correct that software development is a people business first – too often technology professionals lose sight of this. In fact, what I've found organizations value more than anything from professional service vendors that they have an existing relationship with is responsiveness or follow-up. The quality of code/product, pricing, experience, etc. is actually secondary to those who give the right amount of attention to a customer.
Historically, I've found that most organizations have already decided on whether to "go" open-source or proprietary. Rarely, are we asked to sell against a closed-source platform. The more likely scenario is that they've already selected Drupal, and the question becomes why should we hire you? At our firm, what I ultimately tell prospects is that what we are really selling is predictability – all firms have a reputation that can be determined by evaluating their track record.
Cheers,
Dave
Mediacurrent
Brilliant piece! First time I've seen CMSes compared based upon developer relationship strategy instead of specs. Verrry interesting!
Very informative, thank you. Right now, I stand before the choice of CMS.
Smart stuff as usual!
@Christopher (or maybe @Elliot?), do you have a specific recommendation for a CMS that a designer could use to build relatively basic sites? I've looked at Wordpress, Joomla, Drupal, and Expression Engine and I really don't know where to start. My experience is deisgn and front-end stuff, so I need something that is easy to use and doesn't require too much programming experience. What would you recommend?
Dave: I'm glad you agree about people > technology. It seems like this becomes obvious the more immersed one gets in technology, don't you think?
I'd be interested to know how your agency has customized Drupal for use on your projects, too.
Elliot: Thanks, and thanks for linking to the CMS comparison site!
Truper: Glad you found this helpful; thanks for taking the time to say so. Good luck with your decision.
Alex: Thanks!
Jen: It really depends upon what kinds of websites you are looking to build, and, more specifically, what functionality they need to have. I intentionally avoided naming specific tools because I wanted to keep the comparisons general and scenario-based. But, we have done projects using Wordpress and Drupal and have found them both to have strengths and weaknesses that make them best suited for smaller scale sites (compared to our typical project). Both have the advantage of having a very large developer community and a plethora of plugins that expand the available functionality of core install. As much as a pro as that can be, it can become a con if the site uses so many plugins that they become a barrier to future upgrades of the core CMS. I'm inclined to not go much deeper than that, since I am by no means an expert in either. (Perhaps @Elliot or @Dave will weigh in.) Meanwhile, you could easily grab and install Wordpress and start playing with it—probably a bit more easily than with Drupal.
A very informative and well debated article.
I'm definitely not in agreement with all things said but some great view points.
My main issue with what I call "Home Grown" CMS systems, the 3rd option Christopher describes, is the development budget and product road map is generally limited, which impacts on providing an extensive solution that covers the customers' needs now and in the future.
When you go down the path of developing features for a client's specific requirements, you develop a very focused feature, which may work for one client but not another. In the end you keep adding to the feature to suit each client's requirements, which leads to feature bloat. Also, as we all know the client's needs change as soon as the site goes live, which requires further development and more cost to the client.
With a commercial CMS, features are scoped for the needs all clients within the target market for the specific CMS. The depth of the feature development should (I say this loosely) cater for needs for the majority of the clients using the system.
What is also worth remembering… there is no one CMS that will fit every website requirement. Every developer has a bias towards a CMS solution so if you choose the developer first, you have limited your options severely. I firmly believe the decision is a combination of both. A CMS that fits the functional requirements of your website with limited custom development needed, and a website provider that will provide the level of service and on going support your organisation requires.
A really good article Christopher and some very interesting comments. This article really has gained some traction and it's good to hear some healthy debate.
As a website company, when we talk to clients we carry out an exhaustive scoping analysis to see what their requirements are likely to be further down the line, as well as their current ones.
Our CMS has a very defined road map, and comes ready to handle most requirements (for our defined target market) out of the box. Where there is a disparity, i.e. our CMS won't fit, or will require extensive customisation, we're happier to steer the client to another company - one that either has a tailor made solution for them (perhaps an area where they specialise in) or have a good development team able to handle bespoke customisation.
We have chosen one CMS only, prefering to be a specialist in one technology and for a clearly defined target market, rather than being a jack of all trades, (catering for a nmuch wider range of needs) but probably less well.
Vaughan: I think you're right. If we were to create an entirely new CMS for each of our clients' sites, we'd have a hard time being profitable as well as useful to the client. Instead, we've developed one version of our CMS with an architecture that allows it to be shaped for each install—kind of a flexibility that allows for fine tuning where necessary. The other side of this issue—as far as maintaining a workable scope is concerned—is not so much a CMS issue as it is one of positioning and sales for our firm. At the outset, we have a pretty good idea of what kinds of projects make sense for us to do. That is informed by our expertise and our capabilities (partly, what our CMS can handle and what it cannot), but is far less a technological question than a strategic one. Which brings me to your last point, which, again, I'm completely on board with. No one CMS will be right for every project. That's why we might occasionally have to pass on a project (though that tends to happen more as a result of timing and price) as well as why we leave our CMS customizable by our developers. That gives us the right amount of wiggle room needed to create websites uniquely suited to their purpose for the specific kinds of clients we're best able to serve.
Allan: Thanks! I've been pleased to see such an interesting discussion come out of it, too. We're like you in that we spend a lot of time in the sales process making sure that we are on the same page as our possible-future-client in terms of scope, timeline, and price so that we don't violate what our CMS can do, but most importantly, what we can reasonably do. You are right on the money when it comes to the importance of specialization, though. The web is far too large and complex for any one company to be able to build any kind of website well!
Thanks for reading and commenting!
Chris,
In reading @Vaughan's comment, I wondered how a small web shop can support both software development and website development? If you're not monetizing the product that your R&D team creates, then the project work you do would have to subsidize it, right? I'd have to guess that means that any project you do would have a higher price tag that if you worked with something off the shelf. I know you addressed this a bit in an earlier comment (how the efficiencies gained level it out) but do they really cover the cost of the CMS dev team? If you're ok with spilling the beans a bit, I'd love to hear more about how you guys pull this off.
Thanks,
Nate.
Chris,
What a timely topic. At least the latest issue of Adweek seems to think so.
http://www.adweek.com/news/press/trouble-back-ends-133917
Nate: That's a great question. Let me answer with a proviso: while I won't deny that in creating our own CMS we are developing a piece of software, I wouldn't call Newfangled a software development firm as well as a web development firm. On the other hand, much of what we create for our clients goes far beyond what the average person would think of when they hear the term "website," and pushes into application territory very often. With that in mind—especially that today's websites are commonly sophisticated applications of their own that gather, produce, and analyze data continually—I would say that Newfangled is a web development firm that creates functionally sophisticated work, including our own CMS.
All of that said, we don't spend too much time valuing the investment we make in maintaining our CMS against revenue. We periodically identify changes and improvements that we would like to make to the CMS and allocate time within our production schedule to do so—time which would otherwise be spent by the same developer(s) doing client production work. In some cases, we'll distribute the work across the team—something we did over the past year in order to make various changes that resulted in our last official CMS release (v5.3). In other cases, we'll map out changes and temporarily remove one developer from the production stream to focus on them as a project. We're taking that approach right now, as our Senior Developer, Dave Mello, is working on some major changes to our CMS that we hope to release later this fall.
Ultimately, this kind of investment isn't paid for by specific projects, but is worthwhile to us in preserving the efficiencies I mentioned already as well as keeping our CMS competitive in the perception of our clients and clients-to-be.
Justin: Thanks for the link. I hadn't seen that article but just skimmed through it. It's interesting to read through the many frustrated voices coming out of publishing, especially since it provides an explanation for something that many people have questioned in recent years—why big media publishing companies seem to be perpetually behind the times when it comes to translating what they do to the web. I especially liked the quote from a "former AOL employee," who said, "When you try to build a product that works for everybody, it works for nobody." That sounds exactly right to me!
Excellent article and some thought-provoking comments, I'll be returning to it for a second read when I have more time. Can I just mention another aspect that is vital for me as both a developer and an SEO - most open source CMS and most commercial CMS that I've worked with have all been poor from an SEO perspective and require considerable customisation to overcome the issues they bring up. This is despite the so-called SEO-friendly add-on modules that proliferate in some of them - often they are worse than useless because the programmers simply don't understand SEO correctly.
I previously worked with a company that built its own CMS from scratch but sadly failed to make enough cash-flow from it and folded - I still maintain a couple of sites that use the system and only wish I could develop it further because while it wasn't perfect it was genuinely SEO friendly because I made sure it was by haranguing the programmers constantly!
This issue gets even worse once you bring in ecommerce as well - there are too many CMS that need an add-on shopping cart and there are too many shopping carts masquerading as CMS.
Definitely concentrate on finding a good developer (preferably without cash-flow problems!) but make sure they are experienced with SEO or can bring in an SEO who can work with them effectively.
Bill: Thanks! I'm glad you enjoyed reading this, and especially the comments string, which has been fantastic.
I think you're right to point out the SEO-handling of a CMS as a critical factor. I've been surprised that some require plugins and other modules in order to frame the basic on-page factors that we've always maintained are essential for content creators to specify.
Thanks for the article. I read your blog often and find it valuable. However, I just had to chime in here.
I disagree what the following 2 statements.
* 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.
We work with open source CMS platforms all the time and have for years. I dont have any major issues with proprietary content management platforms but I think it is incorrect to say that open source platforms lack sophistication for enterprise-level websites. Yes, they might not have everything that is needed right "out of the box" but they can be extended with modules and customization.
And, I do not agree that open source developers dont prioritize their relationships with clients. I think that depends on the developer not the CMS. We specialize in open source platforms, keep up with the latest releases and modules, and maintain long term relationships with all our clients - regardless of platform.
Thanks again for such thought provoking articles.
Whatever you said about open source CMS and licensed CMS is true. However some conclusions at Open Source CMS are not true. One of them is about limited functionality of Open Source CMS. Nowadays wordpress is popular open source CMS which has a wide range of functionality with the help of various plugins.
Choosing a content management system can be tricky. Without a clearly defined set of requirements, you will be seduced by fancy functionality that you will never use. What then should you look for? Well, it is Core functionality, The Editor, managing Assets, Search, Customization, User Interaction, Roles and Permissions, Versioning, Multiple Website Support, and Multilingual support. Consideration of features is an important part of the process of selecting a CMS, but it is not everything.
I've never used a CMS written in Java, and none spring to mind. I would suspect that a Java CMS would have slightly more complex hosting and technical requirements, so it might not be suited for a non-programmer anyway. PHP content management systems are far more common and generally inexpensive to host too, so I'd suggest focusing your search there is your decide to host project yourself. Nice!
I was just reading this site's article on Content Management Systems and since I didn't see it there I thought I would let everyone know about a new CMS called Directus that just launched. It is free, open source and definitely worth checking out.
http://getdirectus.com