Drupal achieved this by requiring modules that get hosted on Drupal.org (the most popular site to find modules) be reviewed before they're published. Part of the review process requires verifying that the module (a) doesn't duplicate other modules and (b) doesn't belong as extra features added to another module. If your module doesn't work with the other modules on drupal.org, it will never be published. You're required to collaborate.

It works fairly well, although the review queue is long and you get people whining about how their module really deserves to be published.

I don't disagree with any of this, but would like to add that just because a module get published on drupal.org does not mean that (a) it works or (b) it's well-written.

The mainstream modules... the common ones used on thousands of sites, tend to be solid. There's a lot of half-baked crud once you get into the smaller or lesser-used ones.

This is true of any software library or framework that allows plugins, but it doesn't mean that the core idea itself is wrong.

For example, jQuery has dozens of gallery/slideshow and lightbox clones of widely varying quality, but jQuery itself is a brilliant foundation for Javascript development, including its plugin structure.

Indeed. I try to do rigorous reviews of modules (too much spare time at work), but I don't have enough time to install them and test every feature. I just check for obvious security holes and API abuses. And of course, once you've published one module you can make more without any review at all.

I was once tasked with upgrading a Drupal instance and while I surely don't have the experience you do I have opposing feelings about this. Some of Drupal's more popular plugins are certainly well maintained, but for this case (and I imaging somewhat commonly in the industry) they used numerous obscure plugins, some of which were only in "beta" stage. In checking the repo logs of these plugins it seemed as though some hadn't been maintained for years.

There is also no database restrictions placed on the plugins, so they could literally modify any database schema. Not only do plugin A and plugin B know about each other, they are required to know about each other to function correctly; and I see that as a problem. While it can be argued that this is part of what gives Drupal its power and flexibility, I see this power as a very dangerous thing in a community of its size. It almost requires developers to put out quality plugins which is often not the case (for Drupal as well as any other community driven software products).

It's also common sense to pick the right plugins for the job.

There are a lot of modules which have been deprecated or which are no longer maintained, sure. However, this doesn't mean that Drupal is in any way bad.

Let me present the case of Ubercart as a counterpoint. It was the upcoming, loved by many e-commerce system built on top of Drupal. When I first looked at it in 2008, it was still in alpha. But it looked like having solid devs and good community behind it. So I jumped on it, built my site around it and even developed custom modules for it.

Fast forward to 2010. The project has forked and the main dev has gove over to develop the next generation of Drupal e-commerce system which is a completely separate project. It is only being developed for Drupal 7 and has no migration path from UC. I heard that someone from the original team is still continuing to work on Ubercart but the site has had no updates for about a year.

To put it in perspective, this leaves me with 2 options. One is to live with the old UC (which still lacked a lot of stuff since it was pretty much work in progress) and keep investing further in developing on it while knowing that underlying platform is dead. Or I can jump over to Drupal Commerce which would mean I would need to move to Drupal 7 which would mean porting all the rest of my custom development (which has nothing to do with e-commerce part) over to D7 which I had no need to! For those who do not know, Drupal does not maintain backward compatibility between major version upgrades.

Having said that, I don't have any gripes with UC devs. I have benefited from their hard work and thank them for that. I am just pointing out that even Drupal ecosystem is vulnerable to what the original article said.

"FWIW, I'm not a core contributor or anything like that, I'm just a guy who's made a hell of a nice living using Drupal. "

Would you mind expanding on that. Do you offer a plethora of services or focus on one or two things? A friend of mine set up shop building small sites for local business with drupal and is always tell me how great it is.

Sure. Our niche is working with ad/marketing/traditional media agencies, SEO firms, and design groups to provide the technical muscle they don't have to get beyond "five pages and a contact form." So what we do is pretty focused: we don't do design, we don't do marketing, we don't do offer SEO (we build very SE friendly sites, but we're not doing keyword research or running PPC campaigns). We're just engineers/developers (if you can call anyone that works with PHP for a living an engineer). :)

I'm not sure the problem is necessarily Drupal, but I tend to agree with the post's authors that a Drupal written in something other than PHP would be a nice thing to have. Specifically Python would be really nice.

Why? Look, I hate PHP as much as the next passionate software developer. I did PHP full-time from 2000-2005 until I couldn't take it anymore. I spent a fair amount of time with Drupal and it was technically very impressive even though ultimately it was not for me because the tradeoffs were not where I wanted to be as a developer.

The thing is, what a CMS does is cater to a site which does not have the budget for custom software. A system like Drupal gives a tremendous amount of bang for the buck, and of the open source CMSes, it's hook system is definitely the most powerful once you really understand how to drive it. In the end you're hitting the Drupal sweet spot when you write just a bit of glue code here and there to tune the functionality of existing modules to what you need.

In short Drupal and other CMSes let you build sites with a scope of functionality which would be impossible to do custom development for. In this type of market cost is such a factor that anything less ubiquitous than PHP would be a strike against the system. Furthermore, as the number of modules grow, you need a very large community to keep everything working smoothly, so you don't want to go with a language that has lesser adoption.

Personally I can't stand CMSes because I feel like the abstraction is at the wrong level. To me it's mediocrity by 1000 tiny assumption mismatches. Using Rails or Django I feel like I can craft a minimal, excellent and highly tuned UX exactly to my vision with a better language and lower overhead. Making a CMS in Ruby or Python doesn't address the root pain of living within a heavy and immobile scaffolding. There's a reason you don't hear much about the many open-source Rails CMSes that have been floated over the years.

I don't know about Drupal - I would tend to agree it's a little too cumbersome to the point where I would rather write something with a good framework like Django.

But WordPress is really nice, aside from PHP, and my once-off design-a-simple-website projects that use it would be a lot simpler if there were something similar that had a better language. PHP does add a significant amount of gymnastics that make plugin development more difficult.

I don't mind living with a heavy and immobile scaffolding for small projects - but using bubblegum, shoestring, and when necessary sauter to put what little additions I need on is a lot more annoying than just having a clean, standard set of screws and brackets. WordPress especially has a decent set of screws and brackets, but at the end of the day it is PHP and I see a lot of stuff that looks suspiciously like bubblegum.

As for Drupal, I'm not saying I have an incredible amount of experience in it, but taking it for granted that it's a useful framework, I imagine it would be more useful if written in Python or Ruby. Also, I don't buy the argument that PHP is easier to find - I think you would actually have to go out of your way these days to find a place that had PHP but not Python or Ruby available. Certainly all the cut-rate behemoths like HostGator support it.

The problem you see with these applications is that they are bad PHP, not that they are PHP.

If you would, go take a peek at the Symfony2 framework. It's positively brilliant code, and it's PHP--Fabian Potencier and friends are excellent programmers, and they write excellent code in PHP.

I'm currently in the process of building a migration path from our two different older PHP frameworks (MidCOM and Midgard MVC) to Symfony2, and I've really been impressed by the community.

They seem to be very receptive to new ideas, and passionate about code review. I've received lots of GitHub comments on my bundles even though the commenters probably would never actually use them.

And when I found an issue in Symfony2 itself that made integration with AppServer-in-PHP harder, Fabien fixed it within the hour of getting reported.

I tried to address the issues of the PHP CMS space here: http://bergie.iki.fi/blog/my_secret_agenda_for_php_content_m...

I am actively contribute to Drupal and I will say just what you said - OP did not invest enough time to claim what he claimed regarding Drupal.

+ Community which is not just open source, but just open. Which tends to make their modules to work with others. And it is pleasure to contribute to community like this.

The person who wrote that article doesn't seem to have such great technical skills. He came off as the classic blogger who feels he has to share his opinion about everything without having taken the time to actually write some PHP code, to build a site with Drupal or otherwise.