Leading Open Source Modular Framework and Content Management System

Drupal Developer's Journal

Subscribe to Drupal Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Drupal Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


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.

More Stories By Paul Nowak

Paul Nowak first used Linux in 1995 while migrating from Sun to Linux at the University of Michigan. He used Linux in subsequent IT projects including web, telecom, telemetry and embedded projects and is currently CIO of a small professional association based in Washington D.C.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
paul.nowak 11/04/09 04:19:00 PM EST

Matt, thanks for the comments. I made an error on the version of Plone. It's 2.5 Plone running on Zope 2.9x.

In regards to the additional products, we have a skin installed and we have a product that we had custom developed for us that connects to a PostgreSQL database. We've looked at slow PostgreSQL queries causing problems and have not been able to find an issue. We've also tested for the case where the PostgreSQL server is down and have not been able to create an issue. We therefore think that it's not the product that makes the PostgreSQL connection that's causing the problem with our instances and that's why my comments focus on core Plone.

Paul

matthamilton2 11/03/09 05:33:00 PM EST

An interesting article, and great to see a side by side comparison of both Plone and Drupal.

There are a few points I think that need to be made regarding your assessment of Plone.

1) There is no Plone 2.6, I'm not sure what version you were using, but if you meant 2.5 then that was released approx 3 years ago, so it would be unfair to base your experiences of 3 years ago for someone looking to evaluate Plone today.

2) Related to above, I'm pretty sure if you tried to upgrade a Drupal version from 3 years ago to today's version you would also have quite significant issues as well.

3) "lacks many common features, like e-commerce modules" if you look on plone.org/products you will see dozens of e-commerce modules. GetPaid being probably the most powerful.

4) As for 10 minute startup times, I'm not quite sure what you've managed to do to that site, but I've never seen a Plone site take that long to start up.

5) Plone hanging, I'm not sure either what you've done here, but the only time I've seen Plone hang like that is when a custom written code includes an infinite loop... something an inexperienced programmer can do with any language.

I hope this sets things a bit more balanced, and allows users to make a more informed decision when evaluating Plone.

Plone has the best security track record of any Open Source CMS (source: CVE) and is used in a number of prominent large US government sites, such as cia.gov, fbi.gov and NASA.

If you are interested in the roadmap of Plone, version 4 should be released by the end of this year and Plone 5 scheduled for mid 2010. Full details can be found in a presentation I did recently: http://tinyurl.com/l2s7ab

-Matt