Drupal is a popular open source CMS. Some lessons learned and mistakes to be avoided.

All PHP developers have been there: lots and lots of arbitrary files, functions, and a procedural stack of hodege-podge data retrieval, markup and text munging, reorganization of lists of items, and at some point, output. It's not where you want to be. It makes maintenance nearly impossible -- you try and fix one bug and create two others. Customization to any core libraries becomes unavoidable and in doing so creates further chaos. It can be very frustrating.

So when I first started looking at Drupal I was impressed, in comparison with its messier brethren such as Joomla, that it was relatively organized, had an interesting module construction system and a general convention of functions and an expansive API. Initial tests of a default Drupal install went well, it was faster and lighter and better than its OS pals. There are lots of modules made by lots of people that give you lots of options. There is an active community of people on active message boards to bounce ideas off of, and a fairly active patch and versioning system for updates.

While those are some of the positive points of Drupal, after many months of using it, I know deep dark Drupal things you're gonna want to avoid.

The first is general scalability. Drupal has this unfortunate seemingly exponential use of resources -- each module is included through the bootstrap, and each module in turn may have functions which are called and stack on-top of one another, even when totally unnecessary to do so. This is fine when you have half a dozen modules, core stuff. But if you scale quickly, rush it, without thinking, you can end up with more than a hundred custom modules loaded on each and run on every non-cached page draw. Inheriting something like this is gonna make developers very grumpy indeed. It's so bad, in the case I'm dealing with, that the default PHP memory size had to be jacked way up for the site to even work. In a heavily trafficked site which has lots of money tied up in it, this is completely unreliable, and in my opinion, disastrous. If you need to use Drupal in a professional, heavily visited site (I'm talking more than a million uniques per month), you need to spend a couple weeks really assessing what your categorization of site elements are, realistically how many modules you'll need. I can almost guarantee you'll have to load in a lot less functionality than you may have at first wanted.

In other areas of scalability, the complexity of some of the core system calls are intrusive rather than complementary. Since there are lots of people who contribute, I often get the sense that Drupal code is pure competition. How clever can this simple function be? As the old adage goes:
programmer1 - 'I can do that in one line.'
programmer2 - 'Please, please don't, I have to work on this too.'
Competitive coding is bad coding and not productive. Moot point I think.

The Drupal API is too often forcing you to use it rather than convincing you to use certain helpful parts of it in any customized code you may need to write. This is why Drupal is a CMS and less a framework. To customize you need to circumvent Drupal code, working around it. This scales badly. If you are customizing core components to work around Drupal, you are thereby destroying the ability to use patches and other updates the community works on.

But I'm not sure this is exactly Drupal's fault. I don't think Drupal's purpose is to be a catch-all framework, at least I never thought of it as this. So implementation of it in this way is a primary mistake. Also, these sorts of problems are not Drupal's alone, they're endemic to most large PHP projects. Drupal could be one part in a system. It's never going to be able to do everything, and it shouldn't.

One of these problems, which I think Drupal didn't address enough, is that while Drupal works well as a CMS it is not sufficient by default at delivery. Which means if you need it to deliver under high pressure and high load you'll need to customize the core, which means you've lost scalability, upped bugs, and decreased reliability. As a app with forms to let users get info into a database, it works. Biggest downside is Drupal's caching, which is flat out badly intertwined with core components. Drupal by default uses the database to cache. If you get millions of visits you're pummeling your database. That doesn't work. In my opinion Drupal caching is not an option for a large site. Which means you have to come up with something else.

For Joe Blogger who wants multiple users, boards, some excellent tagging options, etc., Drupal is a much better choice than things like Joomla, and offers more than Moveable Type or Wordpress (which I think is a pretty nice project). Just keep in mind that when you're really ready to get serious, you're going to need to build because no 'package' will have exactly what you want. In this case consider building parallel to Drupal, believe me, you don't want to spend months fighting this thing.