You are here
I received a free copy of the Forrester report that compares blogging platforms (including Drupal). Thanks Forrester!
The report is concise: it presents the final results of their comparison and formulates platform-independent recommendations for IT managers. Very useful but free of (interesting) details and nuances.
Fifteen pages, 995 USD, freed from many worries ... add to cart.
Google trends is a tool that analyzes Google web searches and that can visualize search trends over time using so called "search-volume graphs". These graphs usually provide a good mechanism to compare the popularity of two or more products.
© <a href="http://google.com/trends?q=drupal,joomla">Google Trends</a>
It is worth pointing out that Joomla has been around a lot longer than the graph suggests. In 2005, the bulk of Mambo's core developers left Mambo and started Joomla after a dispute with Miro Corporation, the company that founded Mambo. Keep this in mind when interpreting the graph. (I tried adding Mambo to the graph but the term Mambo isn't unique to Mambo, the content management system.)
That said, you can see that Joomla is more popular than Drupal, and that Joomla has been growing a lot faster. Why? The general consensus is that Joomla has a more appealing balance between functionality, flexibility, performance, quality of code, ease of use, documentation, user interface design, support and product marketing.
I want to add that Drupal is not trying to compete with Joomla. We are actually pretty good at ignoring the competition, and just do what we think is best to do. Regardless, there is significant overlap in functionality and many of our users ask questions about the differences between both ...
Sun's new Fire T1000 and T2000 servers are much touted for their low power consumption. According to the Sun Fire T2000 power calculator, an idle Sun Fire T2000 with 4 cores and 8GB of memory consumes 203 watts, and a busy one consumes 251 watts, resulting in a difference of 48 watts.
Now, hosting companies pay something like one dollar per month in power and cooling costs for every 6 watts of power used. Thus, a Sun Fire T2000 costs 33.83 USD per month (203 watts divided by 6.00 watts/USD/month), and a busy one costs 41.83 USD per month (251 watts divided by 6.00 watts/USD/month).
Imagine that you have one such machine for your Drupal website and one such machine for your Joomla website. Now, say that the Drupal website is on average 100 times more efficient than the Joomla website (a theoretical example) and that the Drupal machine's workload is 0.8%, while the Joomla machine's workload is 80%. That means that the monthly cost to power and cool your server is 33.90 USD per month (203 / 6 + (0.008 * 48 / 6)) for Drupal and 40.23 USD per month (203 / 6 + (0.8 * 48 / 6)) for Joomla.
In this simplified and hypothetical example, you save 6.33 USD per month by choosing Drupal over Joomla, or 75.96 USD per year! Three years will save 227.88 USD. ;-)
That, and Greenpeace will love you! (Greenpeace UK, by the way, has chosen Drupal as their platform of choice.)
In exactly 30 days we'll kick off DrupalCon Brussels. DrupalCon will host over 30 talks and tutorials by outstanding members of the Drupal community. It is a service for the Drupal community, by the Drupal community, and is open for everyone to join.
Furthermore, I'm speaking at EuroOSCON, we'll have a Drupal booth at EuroOSCON (we're an exhibitor taking part in their "Dot Org Day") and many of us will camp out at GovCamp Brussels and BarCamp Brussels.
If you want to join us, make sure to register for each of these events.
When a popular Drupal module is not maintained properly, it creates all kinds of problems: people can't upgrade their websites, they have to backport security fixes, etc. As a result, the Drupal community has a strong desire to make sure that important modules are always stable and up-to-date. In practice, however, this isn't always the case. Sometimes, important modules are slow to be upgraded, or have stopped being maintained altogether.
It is remarkable how many people think Drupal will never quite manage to realize its full potential unless we make sure that important modules continue to work. I don't necessarily share this belief. However, if some people think that this part of the Drupal development model is broken, we have to try and fix it.
Now, some people demand that we force developers to help fix and upgrade the most important modules in a timely manner. That is, of course, fundamentally flawed ...
You need to realize that if you created a Drupal module that thousands of people depend upon, you created a successful Open Source project. Successful Open Source projects need responsible maintainers in order to sustain. As the maintainer of your project you are in charge, and you have to take responsibility. Period.
We can't force volunteer developers with no particular interest in your module to help you maintain it, nor can we hold them to deadlines. Open Source is all about letting people scratch their your own itch and having good ol' fun. Clearly, there is no fun in being told to upgrade someone else's code by a specified time. Plus, assigning more programmers to a project running behind schedule will make it even later (The Mythical Man-Month).
This is an organizational problem. We can't solve it with a technical solution. So what to do instead?
Well, we have to accept and acknowledge the fact that a project the size of Drupal is always going to be a bit broken, and that command and control won't cultivate the Drupal wilderness. Drupal got built by people who chose to build it, not by people who were forced to. Rather than forcing people to do something, we need a culture that uses peer pressure to encourage responsible maintainership.
For starters, an important Drupal project should not depend on a single person, especially if that person is a busy one. If you are the author of a successful project, you have to delegate responsibility and provide leadership and structure for others to help you. Avoid being a bottleneck. Avoid being a single point of failure.
In order to make your project sustain, you have to make sure that it scales and that you build a team of passionate users and developers. You have to find, motivate, guide, and empower people to take on a role within your project. You have to help others help you.
Anything else is a failure of leadership. It doesn't mean that you are a bad person or that you lack leadership skills -- it might simply be the case that you are too busy or that you have no particular desire to support your project's growth -- but it is a failure of leadership nonetheless.
As a community, we have to make sure that we have the right people at the right place. The people who maintain popular Drupal modules should invest enough time and energy in these projects, and they have to make sure that there is enough programmer effort available to help fix and upgrade these modules in a timely manner.
And me? All I can do is help create the right environment by providing the tools required to build a successful community around your Drupal project, by providing enough time to upgrade your modules and by cultivating the right culture. What I absolutely must do, is debunk the myth that forcing hordes of volunteer developers to rescue you will provide a sustainable solution.
I used the "Apache, mod_php, PHP4, APC" configuration from previous benchmark experiments to compare the performance of Drupal and Joomla on a 3 year old Pentium IV 3Ghz with 2 GB of RAM running Gentoo Linux. I used the following software: Apache 2.0.55, PHP 4.4.2, MySQL 4.1.4, Drupal 4.7.3 and Joomla 1.0.10.
I simply downloaded and installed the latest stable release of both Drupal and Joomla, and tried my best to make them act and look the same. To do so, I enabled the login form and the "Who's online" block. I also setup two links and a search widget in the top menu, enabled the hit counters for posts, and setup identical footers. Next, I created one author, one category and one post as shown in the images below.
Apache's ab2 was used to compute how many requests per second both systems are capable of serving. The page was requested 1000 times with a concurrency of 5 (i.e.
ab2 -n 1000 -c 5). To test the impact of gzip-compressing pages we specified whether ab2 can accept gzip-compressed pages (i.e.
ab2 -n 1000 -c 5 -H "Accept-Encoding: gzip;"). Note that
ab2 did not request any images or CSS files; only the dynamically generated HTML document was retrieved.
Requests per second
When caching is disabled Joomla can serve 19 pages per second, while Drupal can serve 13 pages per second. Hence, Joomla is 44% faster than Drupal.
However, when caching is enabled Joomla can serve 21 pages per second, while Drupal can serve 67 pages per second. Here, Drupal is 319% faster than Joomla.
In other words, Joomla's cache system improves performance by 12%, while Drupal's cache system improves performance by 508%.
It is important to note that Drupal can only serve cached pages to anonymous visitors (users that have not logged on). Once users have logged on, caching is disabled for them since the pages are personalized in various ways. Hence, in practice, Drupal might not be 319% faster than Joomla; it depends on the ratio of anonymous visitors versus authenticated visitors, how often your site's page cache is flushed, and the hit-rate of your Drupal page cache.
Lastly, when serving gzip-compressed pages Drupal becomes slightly faster compared to having to serve non-compressed pages. Joomla, on the other hand, becomes a little bit slower. The reason is that Drupal's page cache stores its content directly in a compressed state; it has to uncompress the page when the client does not support gzip-compression, but can serve a page directly from the page cache when the client does support gzip-compression.
The first figure shows that the cost of compressing or uncompressing pages is neglible. The second picture shows that it can, however, have significant impact on the document length, and hence, on bandwidth usage.
Drupal always attempts to send compressed pages. Joomla, on the other hand, doesn't compress pages unless this option is explicitly turned on.