Content Management Systems just don't work.
- Written by
- Clay Johnson
- Date
- 02/23/2009 12:39 p.m.
Somebody asked me the other day what I thought of Recovery.gov using Drupal and it got me thinking about content management systems. In my consulting days, I watched companies and political campaigns and non-profits sometimes spend hundreds of thousands of dollars annually trying to make their content management system do what they wanted it to do for their online campaigns. As an honest developer and honest consultant, this made me apoplectic-- I knew that at the end of the day, technically what they wanted was fairly easy to build. But they had to pay hundreds of dollars an hour to get a "Drupal Specialist" at an outside consultancy to set up simple pages because they could not figure out how to get the stuff to work right.
Now, this experience isn't solely limited to Drupal. From working on the Dean Campaign to consulting for hundreds of clients at Blue State Digital, to working at a non-profit like the Sunlight Foundation, I don't think I've ever been happy with a content management system. I've tried dozens, from the ever so simple blog engines like TextPattern and Wordpress, to the more complex Drupal, MovableType, and ExpressionEngine, to the full-scale content management systems like Typo3, Bricolage, I feel like I've worked on and with as many content management systems as I possibly can in my career. And I can't help but feel as though I've never been satisfied with any of them.
Amazingly, I can't find anybody that's used their content management system that doesn't seem to either be resigned to using it, or have an amazing amount of contempt for it. People really hate their content management systems and I think the reason why is because full-blown Content Management Systems just don't work for any kind of sophisticated online presence. At the end of the day, you're probably going to want to do something that Content Management System can't do or worse-- you're going to run into something that your content management system can do and does poorly.
See-- the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more "opinions" it has. And the more "opinions" it has, the more likely one of them is going to really tick you off. Especially in the world of Content Management. Those opinions could be anything from "What should the admin interface of the website look like" to "how should workflow work for the editorial process" to "What kind of user registration system should there be" or a plethora of other opinions like "how should data be stored" and "how does a designer interact with me." More often than not, one of these pieces of functionality is bound to create frustration and anger-- potentially rage for either you or your users.
Our alternative is to take a step back from Content Management Systems. You have software frameworks-- generally a programmer's toolkit used to build things like Content Management Systems or other web applications. Instead of spending lots of money on a content management system and paying a specialist integrator to create and install and maintain it, you're better off finding a competent developer that is well versed in a framework like Django or Ruby on Rails. One competent developer using either of these frameworks can weave together a content management solution and constantly be developing tools inside of this solution that make sense for your organization.
With Government in particular you end up with even more problems going the standard CMS route. When Government picks a CMS over a framework, Government is basically saying that they're going to trust the CMS's standard way of delivering data or work to change those standards and replace them with new ones. It seems to me that especially in Government it is far more effective to be using frameworks than CMSes. Recovery.gov, for instance, isn't a content management problem but a data delivery problem. Government should be focused on delivering that data in the most thorough way possible and when you factor all the different data sources that recovery.gov is going to have to talk to, I'd much rather be using python than trying to hack within the confines Drupal to do the job.
There's some arguments against taking this route. The most knee-jerk one is "you're throwing away so much functionality" when you don't use something like Drupal. But the point of frameworks like Django and Ruby on Rails is so that much of the common functionality (user logins, registration, even things like social networks and shopping carts) can easily be baked in to any application in the way a developer and a customer chooses. They can be built custom or sewn together through components and plug-ins.
The second argument is: "But Drupal/ExpressionEngine/Silverstripe is a framework, too!" and it isn't. It just simply isn't. Drupal and the like are content management systems that may have modular hooks in them to build other software, but the software crosses the line into content management systems when it starts providing default user-experiences out of the box. This means you have to un-do the way default behavior works and apply what you want as desired behavior rather than writing behavior from scratch. That's where the primary difference is between a Content Management System and a Framework are: a framework provides a minimal amount of user-facing functionality (it may provide simple ways to create it) but generally focuses on providing tools that make a developer's life easier.
The third is: "Integration" which for most organizations is a quixotic windmill chase if there ever was one. In my years of working on voter databases, targeting tools, contribution systems and email systems people constantly asked for all these systems to be integrated, but when asked for practical reasons why they often came up short. When you do have those practical reasons-- those integrated queries you want to run on your user data -- your developer can make that happen to you probably better than you can with squeezing your data needs into a CMS.
There's also some gray area here -- a "Third Way" if you will. Sometimes a framework gets extracted out of a content management system. CodeIgniter, for instance, was extracted out of ExpressionEngine, and Sapphire was extracted out of Silverstripe. You may be tempted to say "Hey, this is the best of both worlds!" and it could be, but keep in mind that you're still choosing to adopt a bunch of opinions in your software from people who don't have your organization's priorities in mind. The point is to start with a framework that allows you to build solutions rapidly rather than to buy off on somebody else's solutions. Also, you have content management systems like Ellington and Mephisto that are built on these pre-existing frameworks. Same deal applies-- just because the content management system is built on a framework, even one that you like, doesn't mean that the design of the content management system works for your organization. It is likely better and cheaper to build a solution that works for you out of the framework.
This isn't to say that you need to build every application in your web presence from scratch. At Sunlight, for instance, we use Blue State Digital's[1] mailer and advocacy tools and integrate them seamlessly into our campaigns when they fit the bill. They're a great provider of services that fit around what we need. We're happy to drop in other off the shelf solutions as well-- the Sunlight Foundation blog, being a blog and all, is powered by WordPress. But when it comes to content management and end user experience, we want to control the user experience as much as possible.
Now, this isn't a decision for everyone to make. But if you are sitting there thinking about your content management needs and trying to figure out how to "power" your website and a vendor has given you a bid somewhere close to or over $40,000 for the first year of purely technical work, consider shopping around for a full time Django or Ruby on Rails developer instead. You'll find yourself with the ability to do more, faster.
One last caveat: never hire anybody who is religious about their software. If somebody believes that "Rails is the solution!" or engages you in a debate about why "Drupal creates so much possibility for our movement" and tries to inject some form of zealotry into your thought process, get away from them as quickly as you can. Writing good software is, at the end of the day, not about the framework you use or the content management system you're an expert at, but about being a good developer. A good developer is going to seem nearly agnostic about the tools that they use and instead be able to converse with you and develop the solution that is right for the problem. A language like Python or Ruby or PHP doesn't matter nearly as much as the competency of a developer. A great developer is going to be able to do amazing things in any language or framework.
Update 5:06pm It should be noted here that this isn't a Drupal specific post, though it seems like there's a lot of anger from the Drupal community about this post. To those that think that this is a direct attack on Drupal/Your Favorite CMS, I ask that you take another look through the article and keep a level head. It isn't. Another misunderstanding is that this is specifically geared towards the Open Source community, which it isn't.
Next, there's a new argument I didn't account for that I should have: "doing it all yourself means if your developer gets hit by a bus, you're going to be out of luck!" That's not true exclusively of frameworks vs. content management systems. That's where the competency comes in: if you hire a competent ruby developer to build a Ruby on Rails solution for you and help you maintain it, that code will be maintainable, just as if you hired a competent ExpressionEngine developer to make modifications to EE Core. And if you hire an incompetent Ruby developer their code will not be maintainable, just like when you hire an incompetent EE developer. The point is competency.
[1] it should be noted that I was a founding partner in Blue State Digital. There are plenty of other solutions out there for mass-mailing and advocacy, like Democracy in Action, Convio, and Vertical Response, and Constant Contact.
Discussion
What are Your Thoughts?
Have thoughts that might fuel this discussion further, post them below. (Markdown syntax is supported in comments.)
Hey Clay, there are some useful thoughts and points in here. I have a bit of a different take on things. In my experience consulting for small to medium sized non-profit clients, what they want to do with their sites can 90% of the time be covered by Drupal and Joomla (I imagine expression engine is in the same category), pretty efficiently. The larger clients have more integrated needs and typically have to go with a Convio/Kintera/Blue State, or custom solution.
But the emergence of these open source CMS tools in the past few years has been a great boon to our industry, as people can share modules, share developers, connect with other NGO's on the same platform to share ideas, and save money. It's just so much better than 4 years ago when they were all tied to specific vendors' proprietary systems, paying license fees for software that often wasn't even all that great.
Re: hiring a developer and rolling your own, I'm surprised to hear you suggest this in 2009. My clients (again, the small to medium sized ones) don't want to be in the software maintenance business - most don't have the skills to know what they want or manage a developer and know what they built - and what happens when that developer leaves? They are typically left with a customized, quirky, and often largely useless pile of legacy code.
I'm certainly no zealot but I think what Drupal/Joomla/Plone have brought to the social change sector are very very good things. Please don't run from people who believe in these platforms (though I agree the hard-core fundamentalists need to be tempered and "opened" themselves). The open source CMS movement is not perfect, but it's a huge improvement on the chaotic, dis-organized marketplace littered with failed platforms from before.
Content Management Systems and their baked in opinions work fabulously well if your opinions largely agree with those of the CMS and the set of problems you need to solve align closely with the options the CMS gives you. If you're the kind of organization that has a six figure budget for your web development needs, and your needs are complex/unique/interesting, you will probably do better hiring a good developer and building custom tools using a framework like Rails/Django/CodeIgniter/etc. However, if your organization's budget is smaller (or your web needs aren't terribly complex/unique/interesting) which is a VERY LARGE number of organizations, CMSes like Drupal provide an incredible value despite their flaws. I know lots of people who love their (well configured) Drupal/ExpressionEngine/Wordpress sites, especially when they've had long experience with the even worse alternatives (see: unmaintainable static Dreamweaver mess).
I agree with you, for the most part, but I think the closer you tie to a software package (aka CMS), the easier your perceived HR work. It is HARD to decide you want to hire a developer, know what competencies they need, and to judge those competencies in an interview process -- unless you already have that kind of expertise available to you. How can a "normal person" tell the difference between a decent programmer and a quack? This is even more complex when you're in the Python/Ruby space, where the frameworks are so young that "years of experience" are pretty much irrelevant.
I can understand why organizations are tempted by offerings like Drupal. "Look how much it can do out of the box!" You get functionality on Day 1 -- it's day 100 that's more questionable.
Clay,
First off, you should mosdef add Cake/Symfony to the Django/RoR list. I think they are both great (PHP) frameworks, and use the MVC pattern.
In general terms, I think if an organization is ready and able to drop $40K+ on a CMS implementation, and want one that is pretty specific for it's needs, then you have a point. For all of these frameworks, writing a basic CMS for them is actually a fairly short project (and one that most experienced devs that use those frameworks probably already have in the bag), so building out from that in the directions that you really want to go is not such a bad idea.
But it's the sites that are less than $40K where the power of an open source CMS comes into play. It would be impossible to build a site with bells and whistles (forums, specialized forms, different views, easy menus, etc. - think of all of the varied CMS modules/add-ons out there) for $15K using a framework like that, whereas it would be completely possible to do with Drupal, for instance.
And there are other big negatives to this approach. You'd need a developer who knows security well. You'd need to make sure that the organization and the developer that did the CMS remained fast friends for the life of the website (which you hope will be long.)
The main reason why people hate their CMS is the main reason why most people hate their software. Software just sucks, and it will for a while yet. And the adage that the easier software is to use, the more expensive it is, will hold true. So writing a CMS that an organization loves is going to cost a lot.
That's my buck fifty.
I acknowledge what you're getting at here, and most of what you've said is correct. I'd suggest though before you give up on the CMS entirely, that you examine Radiant (www.radiantcms.org). It is built on Rails, but has a methodical group of core developers that purposely leave out a lot of 'extra' functionality.
This functionality is of course available via third party extensions, which behave like Rails Engines (small verticals of Model, View(s) and Controller) which can then be integrated into pages using the Radius template language.
The extension system in Radiant is very robust and almost as simple as using plugins in Rails directly (something that you have suggested is a promising solution).
Clay, I'm kinda tired of my car. I just hate that it has all this stupid built-in default behavior, like "brakes" and an "engine" and "wheels." But modifying it actually requires me pay hundreds of dollars per our to a "car specialist" at an outside consultancy. What a rip-off!
Instead, I've had an epiphany and decided to scrap that car, quit my job, become an auto-mechanic and literally re-invent the wheel. True, I'm now unable to drive anywhere, and indeed no longer have time for anything except car-mechanicery. But I sure do feel liberated!
:P
Great post. In many ways, you're right, folks purchasing and running websites on a CMS often feel misled in what they thought it could do vs what it can do. WYSWIYG technology across the board is still quite weak for a non-technical administrator afraid to learn basic HTML (totally valid feeling for non-techs). Templating is hard to give clients truly freeform options. Organizations need to budget for some unknown no matter how advanced the platform.
I'm positioning my rebuttal here due to recent experience, but note the context: it always depends on the scale and sophistication of what you're trying to do. I am not building recovery.gov, so if I was, I'd definitely lean more in the direction of a platform like RoR over Drupal for the reasons you give.
And now, my rebuttal: In the past 10 years, I've seen the experience improve dramatically. This is not a veiled brag attempt (ok, maybe a little), but in speaking with my clients this morning at the Joseph Papp Public Theater/Joe's Pub in NYC -- they said they have no issues with the Joomla site we developed for them (it has complex customizations -- not a simple site) and that they're non-technical administrators have no issues using it. No issues! They've gone months without contacting us for help, even after some staff turn over. And the Web is integral to their theater operation, so I know it's not due to lack of use. This is the case with many of our clients. Not all. For some clients, what we built grew in scale to the point where we couldn't build every feature perfectly, leaving gaps in usability. That's the cost of scope creep. But that's more our exception than rule.
I can't say this is true for all of my clients, but I think having a CMS saves them thousands upon thousands in maintenance costs assuming they didn't overspend on the implementation.
CMSs are far more advanced than they were even 2 years ago and for most organizations, as long as they're not over spending, are still better served by a CMS. In all projects, it comes down to expectation management and doing your homework.
This is a pretty old debate and I think you need to define your audience first along a few axis before you can really lay out a conclusion: (1) Role: Executive, User, Developer (2) Budget: Micro (<5K), Small(15K), Mid(50K), Large (100K+) (3) Innovation: Cookie cutter or something "new"
Sunlight, from afar, seems like a developer, mid-level budget, doing new things type of shop. You conclusions make sense for that audience.
Now I'm gonna build a cookie cutter site... do I really have to code forum software in Django? Please.
I'm going to try to do something innovative on a micro budget... damn, some of those religious Drupal developers are looking pretty good right now.
I'm an executive picking a technology platform for web properties, Acquia supported Drupal seems to scratch my itches.
[sorry about all the Drupal examples, I'm just familiar with that community]
This stuff is so complex, I would be far more interested in reading the case study on what integration problem you had and why you choose the approach you did and how well it worked.
Finally, I would actually disagree about hiring religious developers. I agree NEVER pick a technology on the basis of religion or with the help of religious consultants, but once you do, the religious developers tend to have very strong skills in their platforms.
The password is, "pragmatism". You have to be realistic about this, just like anything else in life.
Look: CM systems, by definition, are generalizations. The frameworks you mention are also generalizations, albeit with different goals and different interface mechanisms. This is what you rather strangely refer to in your post as "opinions".
Generalizations and design biases hide enormous amounts of complexity. When your task at hand exactly matches the generalization, then you can save much time, effort an money.
However, the moment your needs diverge from the generalization, even in the smallest way, you can expect problems. Now you have to dive into the complexity that is hidden by the generalization. Now you have to specialize.
This is true for anything, not just software. And for software it has been true since the first day anyone ever developed a framework - from Cocoa, all the way back to (heaven forbid) MFC, OWL...way back into the ooze. From a certain perspective, even the operating system abstracts & generalizes the hardware, and this abstraction might or might not work for you. (Send in the fanboys.)
Take away message: Educate yourself about your tools, be up front with your customers about what to expect, and be skeptical about what you can accomplish in the realm of the generalization.
For what it's worth, just a quick note to say I'm in complete agreement with you Clay. In fact, I had a similar conversation -- almost identical in fact -- just a few nights ago with a good friends who's currently developing most projects with Drupal.
Like you, I've had my fair share of experiences. I've run the gauntlet of building a CMS from scratch to organizing DrupalCamps to where I am today, which is pretty agnostic / pragmatic about the whole thing.
It sounds like you agree that there's a use for content management systems, and -- in some scenarios -- they just make sense. If a client is setting up a blog, we recommend blogging software, a online shop: shops software ... and so on.
Unfortunately, the line between content management systems and application frameworks is starting to blur, probably to the benefit of some (those that work exclusively within those CMSs) and the detriment of others (typically, those clients that have to live with a "FrankenApp" -- part CMS, part applications, all bad user experience).
The other dynamic is the knowledge acceleration and production efficiency that is possible by focusing on just one CMS, as many consultancies do these days. There is no doubt, it's possible to make things faster and cheaper when there's only one tool for the job, and you know it inside and out.
But, these two dynamics are helping to create the same monocultures in the F/LOSS CMS environment that used to be reserved for propriety systems. Expensive solutions, expensive consultants, and expensive support contracts to keep things humming right along.
So, for me, I try to share with clients that -- as you'll hear in the Perl world -- "There's More Than One Way to Do It."
Personally, I focus on Bricolage implementations these days. But I'm clear on its limitations (and strengths) and tend to think that "Small Pieces Loosely Joined" is still the best approach for long-term flexibility, sustainability, and client experience.
Two cents,
Phillip.
P.S. Of course, I can't finish off without mentioning the Perl MVC frameworks out there, like Jifty, Catalyst and Mojo. ;-)
To the Drupal Consultants who have responded negatively: Who among you has implemented a serious solution other than Drupal or developed in a framework like the ones I've mentioned?
Links please!
Ah, I might have agreed with this article a little bit before I tried Umbraco.
Umbraco = .NET = no thank you very much
Overall you have a lot of sensible things to say, but your own reductionist conclusion that "CMSs Just Don't Work" itself reads as a kind of dogma (and the fact that you've been saying it for six years now doesn't help), but anywayyyyy I'll bite:
One competent developer using either of these frameworks can weave together a content management solution and constantly be developing tools inside of this solution that make sense for your organization.
This is really the crux of yr argument, and you're correct. Except that in practical terms I don't really see a lot of "competent" Django/RoR/Cake developers who fit this bill who you can hire for $40k a year, nor many small orgs that really want to be maintaining their own stack...
So then, I see your CMS downsides (which are real), and raise you the difficulty of determining who's competent, dealing with vendor/developer lock-in, lack of any kind of vetting, etc. You're basically up to somehow hiring some individual developer and trusting him/her to do a good job w/the framework they choose.
Further, you can transpose that statement and say the same about competent developers working within an organization making smart choices to build off a modular CMS. The difference is they'll need to write less code, there's a much larger body of best-practices to work off if they're a junior-level hire (which is likely at $40k), and if they totally blow it it's easier to find a replacement who doesn't need to start from scratch.
I think an important thing we can agree on is "competent" and "inside the organization" give you the best shot for excellence. But the problem is that those are really hard marks to hit, and so the question becomes: what happens when you don't or can't? In those cases, I think the advantages of using more commodity technology (as opposed to internally developed whatever) are compelling, if only from a risk-management standpoint.
A few years ago I really thought the Rails community was going to cross the rubicon with the Gems concept, and give people the freedom of a framework along with vetted and well-built components for a lot of the core stuff that everyone needs. But it never really got there.
Someone will though, eventually. Whether that grows out of a widely-supported and contributed FLOSS CMS project or the more narrow brilliance of a great framework remains to be seen.
An expert developer is everything you need.
If you have expert in any language / framework then dont worry about what your website - Just worry about content!
An expert developer is everything you need.
Right, this is true, but just to expound on my point above and explain why this is not really an answer in pragmatic terms:
1) What if your expert gets hit by a bus (or, more likely, gets burnt out). The story of PubSub is instructive here: they had a real guru code up most of their app in C++ as apache modules. Crazy awesome scalability! Perfect bespoke functionality! Amazing launch and takeoff! But then said developer got into a fight w/his boss, and their business imploded.
Again: risk management.
2) How do we address the meta-issue that the number of business and organizations that need some kind of interactive and engaging web-presence which helps them extend their operations on the internet is growing at a rapid rate? There aren't enough ninjas to go around.
Commodity software (FLOSS or not, really; sharepoint should be at least considered in the mix here) mitigates that problem by letting less-expert people do more-expert things. There are no silver bullets, but it helps to be part of a large developer population vs out on the edge rolling your own.
Clay-
I'm very sympathetic with your perspective (and this is speaking as a Plone-centric consultant!). There is no "one true way" to solve these constantly-evolving problems, and there is a LOT of groupthink in the progressive/nonprofit tech community, which tends to limit our ability to innovate, IMHO.
But I also think there are starting to be some interesting new approaches that combine the "best of both worlds" of products + frameworks. For example, the work that folks in the Plone + Zope + Python communities are starting to do with WSGI-based deployments, pushing lots of common services to middleware, is quite interesting.
It holds the promise of letting you use a CMS like Plone for what it's good at, then rolling some custom functionality "outside" using a lightweight framework like Pylons or Django or repoze.bfg (basically anything that is properly WSGI-aware). That custom work can share themeing, login, indexing/search and other middleware services via WSGI without having to "fight the framework" of the heavy CMS solution.
I think this is the direction the world will start moving in over the next few years.
Great conversation, excellent reading. The one thing implicit in the discussion that I'll draw out here is that ultimately the success of the system depends on people ACTUALLY BEING ABLE TO USE the system.
As developers, we can build out fantastic systems, but if our clients don't use them, the project overall is a failure.
We went through this very discussion several months ago while scoping out a project for a client. They had started with another developer building a Joomla system. We looked at what they were trying to do, and basically suggested we start from scratch with a framework and build exactly the system to solve the problem they were trying to solve--emphasizing simplicity in user interface design over all else.
And once we had nailed down the scope, found out that 90% of what we needed was in Drupal, and the overall project turned out to be a great fit after all.
A big part of deploying an open source solution is making it presentable and usable for the people trying to use it. Turn off everything they don't need. Provide videos for tasks they'll do regularly. Make all the tricky decisions about how to structure the site for them, limit the number of decisions they need to make to ones that really count.
What we find essential is ongoing support and training. How do you keep an open source package up to date? How do you add a new story when you haven't done it for a few months?
These are areas where open source shops can really shine. After all, we can't sell the software. There's definitely a matter of choosing the right software to fit the problem, but our decisions around this have gotten more clear over time. If it primarily involves text, Drupal it is. If it primarily involves numerical data, a custom app built on a framework, probably using Postgres.
So an organization is planning a new, non-trivial web presence. They decide to use Drupal as their CMS. While it does much out of the box, a consultant needs to be hired to create templates for the great new design that was created for the web site.
Almost everything is great, but the organization wants some maps on the site generated with shape files they have. The consultant then creates a Drupal module to accomplish this. It isn't a problem that fits neatly into the concept of nodes, but they make it work. As the site grows they keep getting custom features added. Each feature only adds to the complexity of the customization and forces the developer to hack around the CMS's limitations. And they have now tied themselves to a mangled system that will only hinder their progress in the future.
It is completely wrong to think that by not using a CMS you have to build everything from scratch. Django, for instance, has applications for almost anything a basic web site would need. The cost of tying these apps into the site is on par with the Drupal customization. The development of the custom maps module would actually be cheaper and faster because the developer would be enabled by their framework instead of working against the CMS.
And while it is true that an organization may not have the knowledge or means to hire a talented developer, they probably also do not have the knowledge or means to hire a competent CMS customizer. It will be just as difficult to bring on someone that can hack their way around poorly written CMS customizations as it would be to find someone to figure out a custom developed solution.
"Small Pieces Loosely Joined", as Phillip Smith wrote, is the key here. CMS customizations are always tightly coupled to their environment no matter how well they are coded. Well written framework applications can often be run in non-web contexts and are loosely tied to the rest of the web site.
SunlightFoundation.com is a good example of this. We develop the custom modules that we need. These can be reused on our other web sites. They are loosely tied to the framework itself so it would be fairly trivial to modify them to work with other frameworks. We also have the ability to use WordPress for our blog and to easily delegate tasks to other non-framework applications.
We have the flexibility we need to have an effective web presence.
You would be hard pressed to convince me that a CMS customization would be cheaper or more beneficial for the organization in the long run.
For an example of good, extensible framework applications, see Pinax.
CMSs are full of baked-in opinions. Yep, agree with that; pretty much any pre-existing application fits that definition, though.
Then you suggest using Ruby on Rails. Rails is pretty much the definition of "my way or the highway" so you pretty much lost me right there. Not only does RoR have baked-in opinions, but they enforce them!
I'm no Rails developer but I'll actually defend Rails here, there is a big difference between baked-in opinions on naming of database column and filenames and baked-in opinions on what functionality a website needs.
Rails may tie you to naming your tables in an annoying fashion, but it doesn't expose that weirdness to users nor limit the functionality and extensibility of your site that the way a more public decision like what types of content the site will need.
I've built small and large sites in straight HTML, hand-rolled classic ASP, DotNetNuke, Xoops, hand-rolled ASP.Net (with and without webforms), Movable Type, and Drupal.
I'm the first to say that Drupal is, like all other pieces of software, imperfect. It has some real strengths and some real weaknesses. The benefit you'll get on any project boils down to how closely your needs map to a product's strengths/weaknesses. For large projects who want to get something just-so, and whose requirements don't match an existing package's strengths, bespoke development or the use of a basic web framework are good ideas.
In raw developer hours, though, the work that goes into "rolling login/user profiles/forums/secure downloads/faceted search/etc" is considerable. Brushing it aside with "A developer can just whip those up, they're solved problems" is dangerous.
@Chris Johnson: There's a big difference between an opinionated framework vs. an opinionated piece of software. An opinionated framework puts constraints on how a developer goes about building applications, while an opinionated CMS puts constraints on how a user uses the application.
Some other thoughts:
@shawn Let's just keep the goodness of Umbraco to ourselves!
I think there's a lot of truth to what Clay's saying, but I wouldn't go as far. I say all of this as a former Drupal dev who's now working for Sunlight and using (and enjoying) Django, so take it for what it's worth.
But yeah, CMSes often lead to lackluster solutions. I think Clay's key quote is this one: "you're going to run into something that your content management system can do and does poorly." CMSes produce disappointment because, by design, they're general solutions built for unsophisticated administrators. If you've got a developer and a framework, he'll tailor the workflow to the problem so tightly that there'll be less room for those using the interface to make errors. If he's using a CMS he'll probably lean on existing junk that's lying around and produce a system that probably took just as long to build, but which isn't as nice.
But there's so much other stuff he didn't have to build. Jeremy's GIS example is instructive, I think. There are actually a bunch of foundational modules supporting exactly this sort of thing. And I'd argue that there's no particular problem with using the node metaphor for it. These days nodes are basically just Drupal's version of a GUID. It's a bit overweight, but the caching systems surrounding it make this not much of a problem. Is this as elegant as a ground-up GIS solution? No, of course not. But it'll get you most of the way there without needing to edit a line of code.
But I'm rambling. In the end I think it comes down to what others have said: if you've got the resources to do sophisticated framework-based development and have a problem to solve that's more interesting than wanting a blog with some web 2.0 junk stapled on, you should use a framework. If you don't, well, a CMS may let you achieve more of your goals than you otherwise could. I'm very glad to be using Django these days, but Drupal is bringing a lot of value to the small organizations of the world.
Clay, your dialogue about website development projects benefitting from a framework that can be built up to be a custom CMS is largely something we agree with.
The only issue with a pure framework project (be it rails, django, cake, even our sapphire) is that you have to reinvent the wheel to build a custom GUI for content authors and site administrators. Anything custom you build then can't be 'upgraded' through community/vendor generated code, but instead relies on the funds of the customer. Which is a shame.
We're trying hard to find the balance between a framework, a flexible GUI, extension modules, (which all provide an efficient upgrade path), with getting out of the way of developers and content authors' hair. I invite you to keep an eye on our ModelAdmin feature that shows some innovation in this regard. It was released in yesterday's new version of SilverStripe/Sapphire and documentation will be expanded shortly.
Just want to put my two-cents in: as someone working with external consultants on customizing an open-source CMS to fit the needs of our non-profit, I agree with Clay's insight on finding a developer and building/customizing a CMS in-house.
I can't underscore the importance of having someone who understands your vision and knows the workflow needs and limitations of the organization intimately. There are always going to be problems your consultant won't be able to anticipate that someone working in-house will.
I like the idea of mashing up different systems, I think it would work as long as you had an architect for all of these things who understands how they all fit in and who can really tweak them to suit your needs. I say find someone who is conversant in a variety of CMSes, who is also going to be passionate about what your organization does, and figure out what you want so you can build it together.
@Jeremy Carbaugh:
Django, for instance, has applications for almost anything a basic web site would need. The cost of tying these apps into the site is on par with the Drupal customization.
This is (somewhat) news to me, as I've been keeping tabs on a lot of the framework/toolkit development. In terms of "Django Pluggables" I'm not so sure tying these together is really very easy or stable without a lot of experience. At least, the range of styles, and pattens here seemed to suggest some less-than-trivial integration when I've looked. There's also no "login" plugin...
Is there another project or set of pieces we should look at?
As has already been said many times, your experience differs with mine, and it appears many in the industry. Sure, CMS don't do everything, and are not suitable for all clients, but they do a lot of what people need (90%). The rest need something written from scratch.
So CMS are fantastic, they let people who aren't technical add lots of content themselves. Once the drupal expert has set it up, which shouldn't take too long, the little people can get to putting it together. I don't know how you do it, but this is what we do, and it is a hug timesaver.
An interesting theme in this conversation is 'What happens if the developer leaves.' However, ask yourself -- what happens if your Communications director leaves? What happens if the founder of the organization gets in a fight with the Board? etc.
I've been on the receiving end of countless CMS sales pitches, and I always see the same demo -- "Here's how your sales guy can put up a press release himself without involving the tech people" -- and when I've implemented those CMS's (including Drupal and Joomla) I find they only one that thing well out of the box -- putting up press releases (or a plain blog post, which is technically the same sort of beast). The selling point is always "you will no longer have to work with your tech staff to be on the Web."
Many people dream that their tech staff should be plug'n'play. But if you're at all serious about the Web, your tech lead is as vital to your organization as your comms director or the other leadership positions. If you get a new comms director, he or she will evaluate the messaging strategy in place, and then probably rip it all out after a bit, taking some things they find useful from the existing elements and discarding the rest. This is no different from the approach your tech lead will take.
There is a political issue here; there are only so many slices to the power pie in any org. Bringing the tech lead to the table can be a scary proposition , especially for the comms/fundraising/activism people whose expertise -- REAL and VALUABLE expertise, I must stress -- doesn't look as shiny and pretty as the jargony strategies that your technical lead will be able to propose and get online in short turnaround. Sometimes the Web guy becomes the go-to guy that your policy leadership turns to, bypassing the comms/fundraising/advocacy experts, resulting in a muddle rather than effective advocacy etc; more often, the messaging/fundraising/activism people try to relegate the technical lead to a semi-clerical position.
Neither approach is a recipe for success. Even less successful is when a messaging/fundraising/activism person tries to pass him-or-herself off as technical by using jargon and buzzwords.
Which brings us back to Clay's original remark about CMS's. The reason that CMS's don't work is because technology is content. The medium is the message. A responsible comms director does not use an 'off the shelf' communications strategy -- he develops that strategy to match the situation and the organization. Same with fundraising and advocacy; and in any organization with real success online, the same with their technical approach. If your organization is 'too strapped for resources' to have a tech lead at the table helping make the decisions on what your web presence is going to be, then your organization is wasting its time online.
I'm willing to be that you could find people happy with their CMS if you bothered to look at all. But no. Everyone hates every CMS. Case closed.
Is this really one of your arguments? Every framework you listed has opinions... how is it any different?
This entire post would be more accurate and shorter if you would have wrote...
@Josh Koenig,
There is an authentication application that comes with Django: http://docs.djangoproject.com/en/dev/topics/auth/.
Pinax is a nice collection of Django apps. Unless one app relies on another, a developer can pick and choose the applications that are needed. Each app is as modular as possible.
Though I will concede that Django does lack a central repository for pluggable apps. Django-pluggables is a good start but is far from comprehensive.
What about all those organisations for whom an out-of-the-box CMS fits their requirements almost perfectly?
Publishing != software development.
You may have an agenda here...
Great writing!!
One of the things you missed is security. Not that CMS are not secure but they are generic in how they do things. When you develop from a framework the likelihood is that you will do somethings differently. As you explained your personal opinion becomes part of the application. This provides another layer of security and at the same time obsfucate things enough so that sitting writing a script or planning an attack on a single website is not worth the effort.
When you combine the fact that thousands are using the same security paradigm by using pre-baked systems in a CMS with the popularity of a topsite then you get the bees to pollen effect. The obscurity of building it from scratch is a good thing.
A good test for those that think their CMS or any open source PHP CMS is trustworthy is for them to ask themselves "Would I trust my medical records to a company that uses CMS in their intranet or website?"
"Would I trust my bank records to a company that uses CMS in their intranet or website?"
"Would I trust make a purchase from a major retailer, ticket company or airline that uses CMS in their intranet or website?"
Religion of software is as dangerous as its theological counterpart if it is carried to extremes.
Your article starts off with a troll of a headline, but you are careful later to put your words into more context. I call sensationalism.
When it gets down to it you're describing a specific environment that you work in - an environment where your clients are willing to budget enough to start virtually from scratch each time. You want to control every aspect when you do this.
I don't think your environment is normal. Most clients don't want to pay more than a few thousand dollars for a site. Heck, most don't want to pay more than a few hundred, but that's just silly. Most of the time conventional behaviour built into the CMS's do the job well enough, and the trade-off is worth it given the huge cost saving.
We've used our CMS (ocPortal, Open Source CMS) to deliver many websites, in a range of different markets. Sometimes we do need to change default behaviour, but usually we do not. The CMS is built so aspects can be added in, or overridden, on various different levels. That allows you to define your exceptions, but generally accept the norms - the best of both worlds.
There are other advantages to CMS's:
less bugs (as you get the benefit of maturity)
more cost-effective expansion (because other features can be added in that already exist in the system - for example in our software, surveys are a very useful unplanned thing you can just turn on for a client)
more cost-effective expansion (because things can be horizontally grown with greater ease than in something put together more quickly to fit an immediate need)
less expensive developers. In my career I have worked in the real world where we did do things from scratch, and I can say that in practice people aren't as skilled as they should be. Everyone in the industry knows this. If the skills to maintain and grow a site don't need to be 100% hard core programming skills, you can get competent people much easier.
I could go on.
"When you combine the fact that thousands are using the same security paradigm by using pre-baked systems in a CMS with the popularity of a topsite then you get the bees to pollen effect. The obscurity of building it from scratch is a good thing. "
I think this is outmoded thinking. You could use the same argument as to why you should run a custom OS - obviously that isn't practical. Anyone running a serious site should keep on top of security for the OS, and for the software they use on it. If you do it for the OS already as you should it's no big task to also do it for the software.
We live in a world where spiders go all over the net trying to hack sites by probing them. It doesn't matter if they know the code or not - they will try SQL injections, and many other things. Hell, humans will try XSS injections and many other things. A site written from scratch is more likely to have these problems.
Our software contains techniques that automatically detects and bans hackers, is built with a special version of PHP that detects XSS holes, has a well considered framework that makes security holes less likely, and is tried & tested. You can't say this kind of thing for your average custom apps. Software for banks may be somewhat of an exception - I have written this myself and know the security processes very well - but this is an exception to the rule here.
You kind of make it sound like all the idiosyncracies go away when you drop back a level from the CMS to a framework, but all you've done is taken away the top layer. Take away the framework and you still have "opinions" as you call them baked into the language itself. Each situation is unique. You have to balance the convenience of built-in functionality that matches your current needs against the (largely unknown) future needs which may prove more...cantankerous...to fulfill using the technology you choose up front. Even if you choose to reinvent the wheel every time, you'll eventually end up creating (and later fighting against) your own "opinions" at some level, no matter how low-level you start and no matter how carefully you plan.
I respectfully disagree.
Content management systems have revolutionized web development. We've built nearly 100 websites using Joomla and Wordpress at a small fraction of the cost and time of hiring a professional website developer. On our last major website we built, when compared to a similar website for which we hired a professional design firm, we saved nearly 3 months time and over $10,000 and alot of headaches. And of course we will continue forever to save significant amounts on update costs, since a good website is never static.
CMSes out of the box also provide a plethora of features (usually for free) that would take months or years for web developers to create by hand: forums, chat, photo galleries, databases, etc. There are literally thousands of nifty plug-in modules for Joomla alone.
CMSes are to web development what IDEs and 4GLs are to software developers: a tool to hide complexity, increase speed and improve efficiency.
I fully agree with your opinions on content management systems. They are way too broad to actually be useful.
And until I found the Andromeda Database "Framwork" I actually strayed away from frameworks because of the fact that I always found a need to break out of the framewrok, and then there was no point to use the framework.
Andromeda expects that and allows you to literally do anything custom you want but still stay in the framework itself. Andromeda also take the business rules out of the code itself and puts it in the database, so your data is validated by the database it self and not the code.
Andromeda can be found here: http://www.andromeda-project.org
It's a difficult problem to address and one that really has to be handled on a case-by-case basis. Sometimes your priorities and needs align so that you're willing to trade what a CMS gets you for what a CMS costs you. Other times it might go the other way around.
A bigger problem, I think, is that a lot of people get a CMS thinking it will solve a different problem than it actually solves. We say "this will make updating your web site easy."
We think this means "the CMS will automate much of your site updating processes." They think it means "you can build web pages without talking to a techie."
A CMS certainly doesn't do the latter. In fact, it's generally designed to inhibit the latter. But a lot of people don't seem to get that.
I wrote more on this here: http://tinyurl.com/87hhpm
Hey Clay
Interesting post - ditto for the comments. The amount of feedback is an indicator of how much of a hot topic this one is - I'm not certain there's one single answer.
Re the idea of building a custom system using RoR, I posted about this a while ago and only recently reinstated the article. You can find it here:
http://rubyredbricks.com/2009/2/24/rails-as-cms
We've actually done this fairly successfully, as our web designer is fairly tech-savvy and kinda digs having little RoR helper methods he can sprinkle around his HTML. As you put it you've got to be happy with the 'opinions' embedded in your CMS framework - everyone's mileage will vary.
Obviously everything has its place, and if you just want a blog, then just use a blog. But I think the point that Clay was making (or at any rate, a related point I think it's important to make) is that for those situations where you've decided it's worthwhile to make a non-trivial investment in technology - whether to extend an existing CMS or roll your own system - folks ought to be slightly more skeptical of the CMS approach and somewhat more open to the roll-your-own approach.
It's not about reinventing the wheel - it's about building a bike versus modifying a truck to be sort of like a bike... yeah, on paper it looks like they both have wheels and a steering mechanism, but the costs of building a new bike are obvious and more or less straightforward, while the costs of modifying a tank to be more like a bike are more obscured.
More facile analogies here...
"This provides another layer of security and at the same time obsfucate things enough" yeah we all know that security by obscurity is such a great thing. I am also sure that any lone developer hacking at his desk can write more secure code than any big CMS which has a good number of eyeballs on its code, security and other...
I think you're just being narrow minded if you can't adapt to using the best tools there is for a specific needs.
Every single software project should start by going over, what is the right tool for the job. And if you're so hung up on not using a CMS I really feel bad for your clients because they might be needing some simple software and you're selling them full-blown-custom-software whereas a CMS and a few modules/plugins/etc would have been sufficient.
On the account of "Hire a Developer argument", if you hire a great developer they can easily accommodate themselves to creating functionality as the CMS intended. If they are so great as they can easily migrate from one project to another with any framework they can easily migrate from project to project no matter the tools and learn to use the tools the project has been built and still do a bang-up job. If they can't they aren't that good developers.
And yes, why I'm writing this is your overall tone where you say CMS's suck and shouldn't be used. Again I say, it's incompetence if you can't make Drupal or some other CMS act the way you need it to be.
Yes, it might not be pretty always, but how many times have you seen bad written code? Every single project has developers or time problems that make developers create hacks and workarounds to circumvent a specific problem with minimal time investment.
I'm a very enthusiastic Drupal user, I'm also using Zend Framework. And I don't believe there's a right answer to any software problem, there will always be something you're not happy with the tools you work with.
And yes, I'm a project manager and an ex-developer and I believe choosing the right tools for my customers based on their needs, cost and how fast they need it.
Nice article -- very biased. Our clients love Drupal -- we train them so they can use it once the site is deployed -- and please tell me where I can get "hundreds of dollars per hour". I must be looking for the wrong clients. We deploy fully functional solutions on Drupal - for large clients -- for under $40,000 and often under $25,000. And that includes a custom theme.
No matter what you do, you've got limitations. The skills related to hiring, managing and retaining a good software engineer are not prevalent in most organizations, because most organizations aren't in the business of building software. Our clients hire us because they don't want to become experts in managing their code base. We do a lot of custom work in RoR, but we also do a lot of work in Drupal as well. Some problems need the ultimate freedom to customize, others are solving much simpler problems and respond well the CMS approach.
I have been in situations where I felt the outcome of a CMS project was poor - sometimes in the short term, and sometimes 5 years down the road when it's time to upgrade and the system is obsolete, or all the content is in some obscure format.
My overall impression is consistent with Clay's, in that the critical details about how modules interlock and how the "built in opinions" mesh with user opinions are often just not quite right with a CMS. If a CMS is cheaper, the question is how much are the details worth? Maybe a lot.
If you have a many-to-many relationship between users and organizations, you can make Drupal do it but the hacks and extra modules you require and painful and cause side effects.
A major science blogger that I regularly read just paid for a Joomla system from a top notch company and abandoned it after a week. Those who say "all my clients use and love system X" might consider that business tend to filter, retain, and remember clients that actually do like their offerings and stick with them.
All this being said, there are cases where I have recommended a CMS but not many (one of them is lots of multi-lingual content, by the way).
When reading through the comments in this thread, it seems to me like the CMS alternative is mainly being compared to a "build from scratch" method. That isn't fair,when you can use individual components from a given platform (say PHP or .NET), cobbling them together as needed. Of course you're not going to write a forum - there are lots of open source forums that you can install independent of any CMS. Using a CMS is sort of like having a Ford that you aren't allowed to buy aftermarket parts for. I realize it's not the best analogy, but a programming platform is always going to offer more choice for mixing and matching components, at the expense of slightly more difficult mixing and matching.
What about integration? As Clay pointed out, most of the projects people throw a CMS at don't require much. But what if you need, say, your forum users to be the same users as your "members only area" users? A CMS can be nice here, but I've found the "magical out of the box" integration often requires weird CMS hacking that is as complicated as programming but much less standard. To return to the Drupal example, once you've done weird stuff to support many-to-many users and organizations, cracks are going to start to appear in all the other modules which use a different assumption. Why not just minimize coding but use a programming platform that allows you to control all the critical details when you really need to integrate two or more components?
And I've found that static content works best as... static content, surprisingly enough. The best, cheapest, and most standards-based editors out there work on plain vanilla HTML. Only a minority of CMS's seem to get that part right.
From Jeremy Carbaugh: "...Almost everything is great, but the organization wants some maps on the site generated with shape files they have. The consultant then creates a Drupal module to accomplish this. It isn't a problem that fits neatly into the concept of nodes, but they make it work..."
A Drupal client of ours had such a need. We added Geo functionality to Drupal for a fraction of what it would cost to build a new project from the ground up.
Now, every Drupal site with such a need can simply install that module and do what they set out to do, probably without a developer's help. This has also happened for Media handling, 3rd party integration, political data, and so-on. And it will continue to happen for as long as Drupal provides value to its users.
Most of the disdain for Drupal is generated by the fact that the modules that look like what you want are too inflexible and the solutions you actually want are built with somewhat esoteric framework modules. That's not readily apparent to new users, and can be quite frustrating if you've invested time going in the wrong direction.
"The second argument is: 'But Drupal/ExpressionEngine/Silverstripe is a framework, too!' and it isn't."
It seems like your only objection to the "Drupal is a framework" argument is that you have to turn stuff off to start more from scratch, but you mischaracterize what that means. With a system like Drupal, you can either modify existing behavior (which you acknowledge), or you can go all the way to delivering content directly from paths you register with the menu system (which you seem to ignore).
When you can register paths and deliver content directly, there's very little forcing developers to "undo" CMS output when they want to deliver something custom.
Allie wrote, "A Drupal client of ours had such a need. We added Geo functionality to Drupal for a fraction of what it would cost to build a new project from the ground up. Now, every Drupal site with such a need can simply install that module and do what they set out to do, probably without a developer's help."
Right. And that is what an open source development team does. Open source development teams don't just use open source software; they build it and donate back to the community.
I loathe Drupal as an ordinary user. I hate its wonky interface and constant insult to the user's intelligence with the math problems at every turn just because I want to post a comment. Drupal is all to often seized upon by geeky web developers of the software-as-religion types and it becomes a ready-made community/cult that can provide them with a sense of a "progressive mission".
I don't want a cult, a mission, and "progressiveness" in a website that has to be flexible for public use. What I especially loathe about the closed nature of the fake opensource culture is the response to criticism, that general goes predictably like this:
"Patch or GTFO" " What are you doing to help?" "Maybe Drupal isn't for you". "You are a troll".
etc. That is, the zealots don't have the ability to absorb and manage and respond to legitimate user complaints, and bang on the user with the same ferocity that they bang on their fellow coders in the IRC channel.
And I'm so glad you've pointed up the dirty little secret of so many opensource software shills -- the hundreds of dollars in consulting you have to pay on top of them to get them to work...and keep on working...and work some more.
Actually to me this reminds of one of the Lessons Learned in Software Testing. They advocate that you should not use templates. I partially agree with their statement. You should first be able to do something without templates. Then, if you are can, there is nothing wrong with starting to use templates.
The same is my experience with CMSs. I know a lot of people that do great things with WebGUI (a framework that out of the box works as a CMS). The people I worked with also certainly can build a CMS (they did). But building a new CMS (even when using a framework) for each project would really mean redoing a lot of work.
The key here is competent. The people need to be competent.
That isn't to say that sometimes you need a compromise. You indeed have to do something the way the CMS builders designed it. But starting with nothing is in itself a compromise as well. All the time spent on rebuilding will lead to other compromises.
So what if you have to hire an expert in a certain CMS. There not more expensive than the developer you need to hire otherwise. Same difference.... Chances are that if that CMS expert doesn't work out, another can continue the work. Whereas the work of an not competent enough developer usually can best be thrown away.
Focus on the fact the people that do the job are competent. And lets not get religious about CMS out of the box vs Framework only
This is a great article. I have also experienced the frustration of getting my clients to use a complex CMS (usually for a simple website). I decided to create my own after many years of difficulty.
Where you talk about CMS systems vs. frameworks, I built something in between those two. My CMS provides all of the most basic content management features, but allows a developer to plug it into a site however they would like.
It's also an API so if say a Ruby developer wants to integrate it into a site, all he has to do is call some web services. I think there are increasingly more alternatives to complex CMSs lately.
add online game poker fr
Interesting opinion, we provide Content managment systems for our clients and have found that some clients are happy with a relatively simple CMS but some clients demanding a great level of flexibility in layout and actual content will never be happy with what a CMS provides. In this case we create a custom page for them. This only occurs maybe 5% of the time in our experience.
I know a lots of people hates cms, but cms works great for me, I have used TextPattern Wordpress, Drupal, MovableType. Like Drupal best
I think a lot of the problem stems from the swiss-army knife approach. Wanting one system which does everything. Generally speaking I've found that using the right tool for the job is always far more efficient, so rather than buying in one cms which tries to do all aspects of web publishing it is easier to use a number of dedicated tools and put the coding effort into making the public face of it all look integrated.
(see http://shadowfax.org.uk/wiki/The_Power_of_Simple)
Well. I am going to try to build a web app without a cms first. If I see the need, I'll probably build something on top of JackRabbit. The best CMS at this point in time ( for content based sites only, not e-commerce, not anything but content) seems to be Facebook or Myspace. Yes. They are basically gigantic CMS's.
I agree with much of what you say about how CMS seems to make life hard for everyone and moving to a framework with a competent developer is probably the best thing for most organizations. I have good news!!! Umbraco CMS frameworks!! Umbraco (http://www.umbraco.org) bridges the gap between CMS and programming framework. The system will allows and administrator to only display information that is relivant to the user to edit and does it in a friendly way without overloading the users with "features".
Daniel Bardi http://www.danielbardi.com http://www.dascoba.com http://www.twitter.com/dascoba http://cmstv.net
I imagine that there are a lot of people, like me, who are re-reading this post after the announcement of the whitehouse.gov site going Drupal.
I'm not a Drupal zealot -- I have used it and I like it very much. But at the risk of reigniting this argument, I do have a question in the same vein as the assertion you make in this post (i.e., that Content Management Systems just don't work).
Couldn't this same logic be applied to many other types of software that are used in almost every organization? For example, what type of phone system do you use at Sunlight? Do you have an off the shelf PBX system, or have you downloaded Asterisk and built from source?
"...the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more 'opinions' it has. And the more 'opinions' it has, the more likely one of them is going to really tick you off."
This same argument can be applied to almost every single off the shelf PBX system, whether commercial or open source. Someone has built a GUI to administer the system and engineered a basic suite of settings that is full of 'opinions' about how the software should work out of the box. These choices can be felt by every employee of an organization (everything from how they access their voice mail to how they receive or transfer a call) as well as every person calling that organization (everything from how calls are handled in queue to the choice of greeting menu).
Apart from a website, a phone system is the most public-facing system or piece of software that an organization has.
Off the shelf PBX systems allow a user to change many of these initial settings, and even to add new functionality based on their specific needs. Much like the CMS experience you describe having: "[m]ore often than not, one of these pieces of functionality is bound to create frustration and anger -- potentially rage for either you or your users." Has anyone at Sunlight ever complained that the phone system you have did something they didn't like? Or that they wished it did something that it doesn't?
There are mature, open source telephony platforms (of which Asterisk is but one) that anyone can download and configure to the exact needs and specifications of their organization. These platforms run on commodity hardware and softare. There are well developed frameworks for building phone systems on top of these platforms that come in a variety of languages - PHP, Ruby, Java, Perl - and lots of competnet developers that use them.
I guess my point is that if one applied your logic on CMS systems to PBX systems, then you are probably running an Adhearsion application with Asterisk on some flavor of Linux.
So I guess my question is, what are you running at Sunlight?
I agree with much of what this article says. Full blown content management systems are often bloated with all kinds of features that, when taken out of the box, cause more work stripping out then had you built something from scratch. There are certain systems like Wordpress by Automattic that are ideal for blogging and simple websites. They have plugins galore that allow you to create the kind of feature set you desire.
I like the concept of a base package of functionality and using plugins to customize the additional feature set you are looking for, instead of having every feature imaginable built into the core code.
I say right on the money! I have never felt so frustrated in my life! In my day job I use ASP.NET and I know my stuff, I can do all sorts of things, it does the job the way I want it.
It is the other times that I am so frustrated about, I have been trying to get into grips with Drupal since late 2007 and every time I get more and more disappointed. I really appreciate the real "Experts" who can make sense of it but as for me it is the last time I am using it.
Hello OOP, hello simplicity, hello frameworks, hello Ruby on Rails, I'm coming for ya!