Plone (first released in 2001) is an application that runs on Zope (first released in 1998) and here at Openia we have been developing on Zope and Plone since 1999. We have therefore been in the privileged position of seeing how the two of them have developed in tandem over the years. Developments in Zope, specifically as it has progressed from Zope2 to Zope3, have driven profound changes in the way that Plone works, starting from the very lowest layer.

At times it has been quite a roller-coaster ride as we have had to relearn how we do even the basics every couple of years, often much to our annoyance. Why does software evolve so quickly? More importantly, are newer versions actually any better, or do they just adhere to stricter and more abstract philosophies? After all, if you obey a stricter ruleset, surely the end result must be better? Or is it just harder work for the same end result?

It is against this that we observe newer competitors in the open-source CMS market really coming to the fore. Drupal (first released in 2001) and Joomla (first released in 2005) are foremost amongst these, and they have many things in common. They are both based on PHP/MySQL, and they both place a great emphasis on extensibility via plug-ins or modules, and inspire a huge level of community involvement. Since PHP is the most widely used website scripting language in the world, the number of potential plug-in and module developers is enormous. This huge strength of community involvement will surely wipe Plone from the CMS map of history - or will it?

Whilst developing on Drupal we have been struck by the number of similarities between it and Plone. CCK is just like Archetypes. ImageCache is just like Plone Images. Taxonomy is just like Categories. Views is just like... well, nothing on Earth! The point is that to a certain level of approximation the functionality of the two CMS platforms is converging. True, you actually have to install CCK, ImageCache and Views in order to make Drupal more like Plone, but many people do. It's not just us who regard those three (plus the rather eccentric Views module) to be the 'Fantastic Four' without which Drupal is simply incomplete.

So, to a certain level of approximation it doesn't matter which of the three you choose. That's good news, approximately. However it is worth bearing in mind that one of the greatest weaknesses of PHP as a website scripting language is its complete lack of strictness. It is very hard to write totally secure PHP code, so hard that it is almost a fruitless exercise. The aphorism "I wouldn't start from here if I were you" certainly comes to mind. Why choose PHP to try and write something secure? Choose something else - anything else!

The truth is that it's only a matter of time before some kind of loophole is found in whatever PHP you have written, no matter how carefully you write it. Attacks using extra parameters fed in using POST or GET are on one level, but cross-site scripting (XSS) is on another level entirely. Here I would say that Drupal and Joomla are better off than other open-source projects, due to their high level of community involvement to spot the errors, but even here there are limits. You might think a few attacks are not much to worry about, but you will think very differently when the front page of your website has been defaced by a hacker, and you still can't work out how they're getting in!

Against this Zope is starting to look like quite a sound technology choice. It was designed from the ground up with a totally different concept of security in mind. It does not rely on a filesystem to store information, where that information is vulnerable to being read by any user with sufficient access. Instead it stores all its objects in an Object Database - a single, monolithic and unreadable file to all intents and purposes. We trust Zope implicitly, and do not know of any situation wherein the underlying technology itself has been breached.

It does take more server resources to host this monolithic Zope Instance - it is a real heavyweight application - but the payback comes when your website is handling thousands of hits instead of just hundreds. By that time a Drupal site's underlying PHP technology, even with caching, is starting to struggle, whereas a Zope instance simply keeps on going. So does this mean that Zope is only suitable for medium to large scale enterprises? I would argue that it isn't, and we have plenty of clients who agree. Even to a small enterprise, the cost of any website security problems that occur can be punitive, and completely swamp any considerations over technology choice.

The final question comes down to size of community. Will Plone cease to grow and develop if it has a smaller community than Joomla or Drupal? Does not the larger community always win? Won't Plone simply cease to exist? The answer to all of these questions is 'no'. It doesn't actually take a huge community to run a successful project - just a sufficiently committed community of just the right size to keep on top of things, and that is what Plone has. Plone has shown no signs of running out of steam, or of running out of community. But even that's not the issue. The point is that the world is quite big enough for all of these CMS projects to coexist, and there is no real need to ensure that your website is developed using 'the winner'.

It's a clichéd example, but in the end VHS won out over Betamax, even though it was technologically inferior in every way. So am I saying that Plone is like Betamax, and then advocating that all our clients buy Betamax? Yes I am, because Content Management Systems are not like video-recorders. Betamax video-recorders ceased to be, but Plone is not going anywhere.