Advantages and disadvantages of custom CMSes versus off-the-shelf CMSes

About 95% of my income as a front-end web developer comes from large ad and web agencies that hire me to be a part of project teams. These teams build websites that cost anywhere from 10,000 to 1,000,000 euro.*

The other 5% is from small jobs, and the smallest of those are when other freelancers hire me to update their websites. About ten years ago I wrote a couple of custom content management systems (CMSes) for some of these small customers, because A) that is the sort of thing fledgling web developers do, and B) at the time there weren’t really any good off-the-shelf products I could use.

Lately I have been trying to tempt these customers to switch to off-the-shelf** products like Drupal or WordPress because every time I have to update their custom websites I basically have to learn to understand my own code all over again. This grates.

I have found my customers to be remarkably resistant to temptation, however. The best part? I cannot really blame them.

The main reason my customers resist the switch is simply one of cost. If their sites were simple affairs that consisted of a bunch of static pages and a contact form, the switch would take somewhere between half a day and a day, and even that would be fairly costly for them, considering that any gains for them would be difficult to envision. Sure, site updates and extensions take me longer to implement, but we are talking in the region of hours here. If I have to build them a new feature every year, that might cost six hours instead of four. That means they have to envision major changes to their sites over the next five years, which is tough to do for anyone.

But we’re talking about sites that have evolved, that have acquired all kinds of neat features over the years that do not have third party alternatives in off-the-shelf products.

And who is to say that my customers will even be using that off-the-shelve CMS five years from now? Switching to an off-the-shelf product simply is not a wise investment from their perspective.

Having said that, all my customers who started with an off-the-shelf CMS are still happy users. (Their only problem being that they do not update often enough so that they need to hire me now and again to remove damage caused by hackers.)

I made the following list a couple of weeks ago to discuss this very issue with one of my small customers:

Advantages of using my custom CMS:

  • I know it well.
  • Does not require much maintenance.
  • Every conceivable extension possible.
  • Log-in system uses safety through obscurity.

Disadvantages of using my custom CMS:

  • Extensions can be pricey because sometimes I need to reinvent the wheel.
  • Log-in system becomes unsafe once discovered.***
  • Becomes difficult to extend or maintain as soon as I am no longer available.
  • If new legislation applies, implementation is expensive.****

Advantages of off-the-shelf CMSes:

  • Are regularly extended with current web technologies.
  • Security is an ongoing matter of concern.

Disadvantages of off-the-shelf CMSes:

  • Are popular targets by hackers and law enforcers alike.
  • Require continuous updating.

In short, you trade a relatively high price for new features for recurring payments for updates. If you are on a budget and you already have a website, it makes little sense to switch.

The only reason why small customers would have to switch, as far as I can tell, is when they stop being small customers.

*) I don’t think I’ve ever actually worked on a million euro website. I have been involved in million euro projects though. Usually what happens in those cases is that a company is involved in a million dollar effort to transition to the web, and in all those cases this involved multiple websites. Note that I don’t make millions, those pies tend to be divided among a great many people.

**) See also: The blog systems that made it as CMSes.

***) Not, I hasten to note, because I write unsafe systems. Rather because I am the only coder who ever looked at my system, making small flaws more likely to persist. As the saying goes, many eyeballs make excellent eyeball soup. (Hm, I may have remembered that incorrectly.)

****) The EU has just adopted a directive that outlaws most browser cookies. The advantage of a custom CMS is that it only uses the cookies it needs though.

The blog systems that made it as CMSes

Six years ago I blogged that open source CMSes tended to be too difficult to set up and use to be usable for small business and non-profits. I suggested that a number of blog systems and nukes could step forward and supplant them, and that is exactly what has happened.

In 2008, Joomla!, Wordpress and Drupal were the most popular open source CMSes, even though none of them started out as such. In 2009, these three still led the pack with a wide margin.

Wordpress and Drupal used to be blogging software, and Joomla! (formerly Mambo) was a so-called Nuke (a package for building web communities), but they quickly re-branded themselves:

  • Joomla! – dynamic portal engine and content management system
  • Wordpress – semantic personal publishing platform
  • Drupal – open source content management system

I have used all three to build professional websites with. Wordpress is well suited for small websites for small businesses, and I have built websites for huge organisations with Drupal. Indeed, for the past two years Drupal-sites have accounted for almost all of the websites I produced, the exceptions being one small Moodle project and a PHPfox website.

Installing Wordpress really takes me no more than 10 minutes or so. (In my experience, a single person business wants to spend at most a few hundred euros on a regular, fairly static website, so if I decide to go with Wordpress I can spend the remaining hours on making the site look good, which in turn helps the customer to establish their brand.)

In light of these developments it may not be too far fetched to conclude that ease of use, perceived or imaginary, can be very important for the adoption rate of an open source product. Ask the Firefox developers. It wasn’t the plug-ins or the built in search engine field or the tabs that made the difference, but the fact that the webbrowser seemed to work the way laypeople expected a webbrowser to work.

Indeed, I know plenty of people who never use tabs, who only seem to get confused by them, and plenty of others who search the web by entering a search phrase into the address bar (in the latter case a savvy web dude like myself included). The only Firefox feature I have consistently heard people name as the reason to use that browser is its perceived security. Firefox is, as the head rabbi of the world once put it, the one that “keeps out the schmutz“.

Bonkers: either I or the Tax Service

Belastingdienst, the Dutch tax service, sent a form for me to fill out in which I needed to indicate projected future earnings. They do this almost each year—well, regularly—so that they can let you pay your taxes for 2020 in 2019 instead of the more reasonable 2021. And every year I postpone filling out this form (deadline August 1) as long as possible, so that I can always include my latest earnings in the estimate.

That’s the pre-amble. When I checked the form yesterday, I noticed the tax service wanted me to fill out my projected earnings for last year, 2008. I received this form at the end of May, two full months after I had reported them my income for 2008 (the cut-off date for which is April 1 in the Netherlands). More than a year after they had charged me income taxes over 2008 based on their own estimates. And two full days after they had corrected my income tax over 2008, presumably based on my April report.

In other words, have I just gone mad or is the tax service not quite right in the head? What am I missing here?

(I returned the form with the box checked that says they already know my income over 2008, which should be sufficient.)

Without context

I found the following in a mail from a client:

I want this done tonight or tomorrow. It can’t take long and I don’t understand how to do it.

I have nothing to add.

Moving Drupal

Today I had to move a Drupal installation from one domain ( to another ( Most of my time was spent in waiting for back-ups to finish, but there was one other problem that took a good half hour to solve: one page ( would give 403 errors, even though the page existed (as a URL alias). What had happened is that until today the www address had contained the old site, and the customer did not want me to delete its files, so I just dumped Drupal in the same directory. Turned out that there was a directory “portfolio” in there that conflicted with one of the new site’s so-called ‘URL aliases’.

So here are a few tips for moving a Drupal install across domains:

  • empty all caches before you back-up the database
  • after moving the site, change the base_url setting in the site settings file (sites/default/settings.php)
  • if you’re using MS Windows, Xenu Linksleuth is a good tool to check if any of the old URL’s are still lingering on the user side of the web site
  • if you’re overwriting an exisiting site, make sure the old paths in your new Drupal root do not conflict with the path aliases of the new site.

Re: the caches: my database contained 66 MB of material, of which 61 MB were caches.

The above are additional tips, and most definitely not the entire story of how to move a Drupal site. For that you use either common sense or the search function at

Search: weigh or eliminate?

A couple of years ago I reviewed a book by web usability experts 37 Signals called Defensive Design for the Web in which they gave side by side examples of how to do web shops right and how to do them wrong.

One of the examples had two sports stores go head to head. Both let you search for basketball shoes, but one (the bad one) showed you all hundred or so results at once, while the other (the good one) let you use filters to help you further narrow down your search. For instance you could say: only show me the sneakers with black laces, or the ones that cost less than 100 USD.

Both methods though, the one that showed all the results at once and the one that let you use filters, had an underlying assumption that all search criteria are equally important. Perhaps this is a side-effect from the success of Google. Search has become so relevant—and therefore successful—that we apply the same assumptions about search everywhere. This is what search should be like, we say.

VU researcher Frans Feldberg begs to differ though (Dutch). He claims that online stores would be better off using a mixture of regular and weighted filters. His 2006 research into automated decision support systems seems to indicate as much. Unfortunately all the weighted support systems cannot help you if your search yields no results—I couldn’t find out what his paper is called, or I would have linked to it.

Where my home wiki fails as an organizer

I have been using the simplests of wikis, Usemod, as a business organizer on my laptop. For every day in the near future I make a link. I link to days from other days, and from month pages, and to month pages from year pages.

The great advantage of the wiki as opposed to proprietary software is that it is fully free-form. I am not limited to the things the makers of commercial organizers want me to do, but instead I can enter new items just by clothing the link text in double square bracket, [[like so]]. This example would create a new page called “Like so.” It’s like building an office by burrowing into a mountain, creating new storage rooms and offices as you go.

But I stumbled upon a very real problem which is that it is much harder to make meaningful todo-lists in a simple wiki like this. A todo list really should always live at the current day; my best method so far is to copy unresolved todos to the current day. Yes, a simple solution would be to keep todo lists separate from the day pages, but 1) that is counter-intuitive, and 2) it still leaves little space for notes and sub-todos if your todo list is limited to the list format.

Todos are living things that sometimes branch into sub-projects (for instance if you underestimated the amount of work involved), sometimes need to be closed when they are not finished (for instance when their blocking more important todos from ever getting done), sometimes need to be re-opened again, sometimes need to have costs attached (when your customer wants an itemized list of expenses) and so on. There are relations between todos that are not always clear beforehand, but that still need to be formalized once they become clear.

Illustration: mock-up of what my current electronic diary looks like.

The current strategy of compounding todos makes all my day pages look busier every time. Also, I don’t prioritize todos much, so that the ‘mathom’ todos (the ones I keep pushing to the future and that aren’t very important to begin with) start to outnumber the important todos. And as a result, I have in the past year forgotten to do some of these important todos in time.

I know this because strictly as a diary the wiki is unparalleled. I can make little stories of what happened on each day, and in this way create a history of my company that allows for much more exposition than a simple paper diary could.

A solution for the diary-meets-agenda problem would be to use more powerful software. For instance, if I used MediaWiki, I could save each todo as its own page, and then attach categories to it that would indicate its priority, status, deadline, starting date, cost attached, et cetera. I could then find all Top Priority jobs on the Top Priority category page, or all jobs that still need to be billed on the appropriate category page, and so on.

Even better would be if database wikis like the slow moving OpenRecord would come along (check out the cool video of what it can do! — start at “3. Editing”), so that I could actually build a relational database the way you build a wiki: by hacking out the tables and relations as if the substance were living rock.

N.B. My back-up strategy for this type of diary includes sucking out the pages in HTML format using wget. The problem with that is that the wiki makes new pages where wget asks for an as yet unfollowed link? Also this takes ages if you forget to tell wget to not bother with all the history pages. My wget recipe for this job so far is: ” –restrict-file-names=windows -E -k -R action=”. “–restrict-file-names=windows” makes sure the filenames don’t have strange characters in them, so that I can view the file on multiple OSes, which is important for a back-up in case you need to restore to a different OS. “-E”: add “.html” to the file names; on lesser OSes this will make the files “clickable,” i.e. it will cause the OS to open the file in a web browser once its icon or name has been (double) clicked. “-k” convert internal links so that they work locally; so far that hasn’t been of much use, because it doesn’t add “.html” to these links, as required per -E. “-R action=”: do not store pages where the URL contains the string “action=”; this filters out things like history pages.)

N.B. 2 There is a much simpler way in which the wiki organizer breaks down, and that is that I have to enter the template for each day by hand. Again, using a more sophisticated wiki would solve this, and it’s not really a problem I am much bothered with: it takes fifteen minutes each week to do this by hand.

Log in to register

I feel like such a rube! The Discovery Channel is organizing a reality show “in which the contestants will build elaborate Rube Goldberg machines“, according to BoingBoing. Being of a sometimes curious nature, I decided to check out the site they linked to,, but in order to view the entire application form I had to log in. Still being of a curious nature, I decided to look at the registration page. This is what I saw:


In case you don’t get the joke: in order to register, you need to log in first. In order to log in, you need to register first. And so on ad infinitum.

Perhaps they want you to make Escheresque Rube Goldberg machines? Or perhaps they want to test your inventiveness? (The Rube Goldberg site has a similar test: a “skip intro” link that doesn’t work. Or does it…?)

Would you perhaps be trying to sell me something?

It’s a question I have to ask regularly of the direct marketing scum that call me on the phone: “Excuse me, are you calling me to sell me something?” For some reason, the phonetards try to postpone the anti-climax of the conversation as long as possible by trying to obscure the reason for their call. This is because it’s not really a conversation. The longer they can convince me that we are having a conversation, the better it is for them.

But direct marketing is push. It’s in your face, it is unwanted, it is begging for me to take out the baseball bat and come by to clean the pond. You don’t expect pull marketeers to make life more difficult for the prospective customer. Any ad that has to lure me over basically has to make life as smooth as possible for me.

And I guess when Inmatrix put up a webpage to promote their Zoomplayer Pro product, their intention really was to make life easier for me. After all, if I find out after the fact that I cannot use their product, they’re are going to have one cross, baseball bat-owning customer on their hands. Nevertheless, if I read all the things I have to do for the privilige of using their product, I feel the need to grab my credit card dissipate immediately.

The list of requirements is this long because of Microsoft’s perfidious DRM scheme.

But! If you are going to have a page titled: “Why should I buy this product?,” don’t make the list of cons three times as long. Put that list on another page, titled Requirements, and keep the Why page for the good news.


DRM gone mad, I tells you!

Related earlier posts:

Bugzilla’s long tail

If you wish to report a bug to a FOSS project (FOSS = Free and Open Source Software), you may run into a couple of snags.

One is that some of the developers are zitfaced asshats who consider the slightest mention of the possibility of maybe something being wrong with their software as a direct personal attack. Indeed, that is not a very useful attitude when you are, you know, inviting people to tell you what’s wrong with your software.

Typically not all developers share this attitude, but when your first interaction with geeks happens to be when posting your bug report, it is easy to assume all developers are socially challenged.

A simple, traditional and non-technological solution to this problem would be to let only the people with people skills do bug triage. How do you know which developers have people skills? They are the ones who do not scream at other people.

Another snag is that the software you use for reporting bugs can be difficult to use, and a third snag that said software is not very flexible.

A user has to jump through a lot of hoops before reporting a bug: grow a thick skin, read the 1000 page book on How To Use Bugzilla, and formulate your bug report in a way that is least likely to offend, and most likely to fit the mold for the Good Bug Report.

This takes time.

But what if the time bug reporters are willing to invest follows a power curve; a few reporters willing to go all the way, and lots and lots and lots of reporters in the long tail, just wishing to post their message without jumping through all these hoops? In how far do FOSS projects appreciate and accommodate this last group of bug reporters?