Drupal Developer's Journal on Ulitzer

Plone and Drupal are two leading open source Content Management Systems (CMS). Both were recognized in the 2009 Open Source CMS awards, run by Packt Publishing.  Both also have large installed bases and large developer communities.  This is made evident by some quick searching on Google:

A search for LinkedIn profiles that mention Plone (search for 'plone site:linkedin.com/pub/') turns up 1350 pages-a large increase from 500 results in 2006.

The same kind of search for Drupal developers turns up 9700 pages (search for 'drupal site:linkedin.com/pub/').  This tells me that, in LinkedIn anyway, there might be approximately seven to eight times as many Drupal developers as there are Plone developers.

Below I will outline the strength and weaknesses of both systems. As a site administrator who has worked with Plone since September 2005, I'll give you an idea of what you'll find under the hood of Plone that you might not read about elsewhere.

Plone and Drupal Strengths
Where Plone really shines is usability. Navigation and search work nicely "out-of-the-box."  Plone features a nice little AJAX drop-down that autocompletes  as you type in a search term. The system also instantly updates the search index every time new content is saved.  The overall ease of management of everything from pages and folders to navigation and search provides a generally good experience for both end-users and content administrators.

Drupal, on the other hand, is turning out to be a juggernaut in the open source CMS space.  It's rapidly growing in popularity, finding its way into many segments fueled by LAMP (Linux, Apache, Mysql, PHP/PERL/Python) architecture. Drupal's clean code base and flexible design make it easy to work with and extend.  Drupal scored the CMS coup of the year by being chosen as the development platform for the new whitehouse.gov site in October 2009. Besides providing easy-to-use menu management and content editing, Drupal's standout strengths include its large base of available modules and the low cost of module development.

Digging into the Oddities of Plone
One of the biggest differences between Plone and other open source CMSs is that Plone is not based on LAMP architecture.  Plone is designed to run on the Zope application server, which is written in Python.

When you start Plone, you spool up the Zope application server and then Plone on top of it.  Zope tends to use quite a bit of RAM so expect very large memory footprints for Plone compared to a system run on LAMP architecture.  Plone also spools a large number of content items into RAM as well. This feature is configurable and results in somewhat better performance if you have the RAM to handle it.  My own view is that Zope and Plone are built with this large content cache to improve upon marginal performance, perhaps due to the custom object database that comes native to Plone.

As an anecdote, our Plone data file (Data.fs) grew to about 2.7GB after 3 years of use with regular packing of the file.  The Plone process that was tied to this data was showing about 300MB of memory use (274MB resident, 283MB virtual in htop).  The above comments are based on 2.5x Plone installs.  The more current 3.x version of Plone reportedly uses more memory than the 2.x tree.

The approach Plone has taken leads to some problems that you might expect based on the description outlined above, but also some problems you might not expect.  For example, the memory requirements mean you need more robust server hardware: more memory, more CPU-much more when compared to LAMP.  Many hosting companies are not ready for the Plone experience so you need to take extra precaution when selecting  a hosting solution, especially related to memory.

The bigger problem we found with Plone, however, is that it's difficult to manage as a server process.  We found that Plone/Zope will often hang.  Why?  That's the problem.  We don't know why.  We think it's related to content administrators being logged in, but that's all we've been able to determine.

This is where the problems with Plone thicken.  In our experience, when Plone/Zope hangs, the process does not exit but it stops responding to requests and it does consume more CPU resources.  We don't get the usual error reports or logs that you would expect with a LAMP stack.  Not only is it hard to tell when Plone/Zope hangs, but we also don't have a way to find out why.

Worse yet, when Plone hangs, all the sites on the instance become unresponsive.   No crash signal, no error report-other sites crash along with the site that caused the problem.

This is from Plone/Zope that's been installed from source on Debian.  We managed this situation with custom scripts that verify that specific static Plone content is downloading within certain time limits.  When problems occur, the drill is to kill the Python system processes tied to that Plone/Zope instance and then use the Zope control file (zopectl) to start Zope again.  Because of the large memory requirements, starting Plone can easily take more than 10 minutes on a server with 2GB of memory and a large Data.fs file like mentioned above.

In addition, we learned that Plone development typically costs more than development for popular LAMP CMS products like Drupal.  Plone is expensive to get data in and out of, and it lacks many common features, like e-commerce modules. Plone gives developers a lower starting point from which to begin work.  Plone also has a very steep learning curve and a lack of good documentation. Overall, it's a little complex structurally and a tough environment to learn.  This is the case even with the advantages of Python, which is a mature language known for programmer productivity.

I rolled out our first Plone site in September of 2005.  That later grew to a total of 9 Plone sites running on two instances of Plone/Zope on the same server.  Because of our inability to debug problems with Plone hanging, our only resolution has been to migrate to newer major versions of Plone.  This forced migration basically resulted in a poor experience for our organization and consultant fees that would have otherwise been avoided.

Praise for Drupal
While rolling out Plone sites, we also built a few newer sites for ourselves and our partners in Drupal.  Our experience with Drupal has been fantastic.  The sites themselves perform well, are easy to add features to. Additionally we had better training experiences than with Plone.  Drupal's developer community is much larger, as is the breadth and depth of software, so it's easier to "get things done" and, in our experience, quicker and less expensive as well.

If you have experience with the LAMP stack, Drupal will be very comfortable to you.  Unlike Plone with it's reliance on Zope, the major aspects of the Drupal technology architecture drive right down the middle of the Linux and open source server road map with Apache, MySQL and PHP at the core.

Digging into the details of Drupal's features, we like how little things work, such as menus, search and content editing.  We also like how big things work, such as how efficient it is to write new modules and how it's easy to build on the many many modules currently available for Drupal.

Looking Forward
Many sites will continue to run Plone but I expect there will be an additional inflection in the adoption curve in favor of Drupal.  I wrote this article only as a point of caution for potential adopters and to help arm people considering Plone with the perspective of someone who has been an administrator and user of both Plone and Drupal over the past four years.

For most needs I am encountering these days, Drupal is a much better fit than Plone.  Both a better fit in terms of features but also a better fit in terms of value and long-term costs of ownership.