Several months ago, one of my Web sites using Joomla got hacked. It wasn't a particularly important site, and wasn't bringing me in any money or giving me any useful exposure, so the best option was to simply drop the Joomla system and put up a holding page.
Well, the holding page has been up long enough, and I'm thinking through how to do the next site. The problem with Joomla, like Wordpress, Drupal, or any other software-intensive approach to deploying information, is that they degrade at a far too rapid pace to pay back the initial investment, let alone the hidden on-going maintenance costs.
There are many reasons for the degradation. All software contains bugs and security holes, some of which are known by original core developers at the time you, the software user, deploy your site, but many of which are not. Every security flaw discovered in the core software, exposes your deployed site to increased risk of hacking. That discovery process, which happens over time, immediately reduces the value of your site. You have to incur the cost of responding by updating your deployed site with newer software, which contains a whole new set of bugs and security flaws.
In turn, you potentially incur costs to deal with new bugs. If you had made fixes to bugs in the older software version, you will also incur costs to determine whether those fixes to the old bugs are still applicable... such forks to the core software must be backed out if they are incompatible.
The situation is considerably muddied by a general lack of comprehensive revision control in databases and file-system based media (giving non-repeatable and non-reversible operations), and complete absence of testing discipline in many (most?) Web software deployment strategies. The state of the machine at a given point in time is simply not knowable, so we cannot properly evaluate the impact or mitigate the consequences of changes without completely revoking them.
Instead, the profession has attempted to deploy even more software, layering one piece of software over another in order to monitor and control one or another aspect of the deployment. The reality is that it usually falls to individuals to act heroically, if they can, or to pay others to act heroically, which can get exorbitantly expensive.
When your business is on the line, people will pay such costs, but that doesn't change the fact that basically this cost of owning software is a usury fee... a kind of professional protection money to keep the consequences of software bugs off your business' back. The realization that something isn't intrinsically providing positive value, is what gives rise to many clients of a feeling of being extorted. It is as if you went to a doctor to set a broken bone, only to be told that due to the way the doctor chose to set it, you'd have to return to have it reset -- every month for the next 5 years.
Other reasons for the degrading include the relative unavailability of developers skilled in an idiomatic technology; the waxing and waning popularity of the supporting technologies in the "stack"; changes to public services that your system is interfaced to; the fading of the memories of the developers and stakeholders involved in making decisions that determine how the system operates and how it is structured. Most of all, the goals of the organization operating the site usually necessitate changes simply for the sake of enacting a process -- a communication cycle, performance monitoring, marketing program staging and execution -- and these all have the requirement that stuff on the site change.
We call that rather euphemistically "content management", but collectively it is really about changing stuff to do stuff that will accomplish goals. The more stuff we can remove from that universe of discourse, the better off we'll be.