Netpop is a subscription site where users get credits every month with which they can purchase market research data. This data comes mostly in the form of graphs that show responses of broadband users to questions like "How frequently do you use a personalized home page?". Users can then further segment the responses by age, gender, or one of media-screen's unique segments. In most cases, responses for the U.S. can be compared to answers for the same question in China.
I'm proud of the outcome of this work. This was my first Drupal site, and it contains some fairly heavy customizations: a from-scratch theme, a credit system, a bunch of "mock ajax" that works in IE, and PayPal integration — including use of their subscriptions API. There are also a few features here that are probably overly complex. Perhaps the best example of this is the combination of the credit and subscription systems. It seems like these things should be mutually exclusive; either you pay monthly for blanket access to some of the data OR you pay as you go ("a buck a graph") and you buy credits a chunk at a time to avoid the thorny micropayment thing, but the two together are confusing. Also, PayPal's subscription management is simple at best, so there are some real limits on what we can do when, for instance, a user upgrades her subscription.
Of course, it's much easier to see this now that it's all built. With this site, it was hard to know exactly how the site should work until we got all the data in, and that pretty much happened last. But as a fixed-bid contractor, it's also hard to convince a customer that cutting features that seem important can actually make the first version of a site much better. I've heard stories about how Steve Jobs apparently edits the features of release like a movie (choosing to drop some that are ready to go.) It sounds crazy, but if you have the resources it does make a kind of sense. It's not till it all comes together that you really know what you've got.
Next up is another Drupal site for an up-and-coming author named Veronica Wolff. (Oh, and she's also my wife.) We had fun putting this site together, and Drupal excelled at this task. With Netpop, I found myself working around a lot of its features to handle its bulk loaded content and its unique requirements around credits, subscriptions, and access. With this site, I was able to get the shell of the site up on relatively short order. Veronica worked on the content and even did a lot of the formatting using Tiny MCE while I worked on the OpenLazlo app for the homepage and the theming of the HTML. Even though the homepage app is basically an elaborate skip-intro, it's still driven by configuration and assets that come from Drupal.
I still like Drupal, and I can't argue with its built-in features that would otherwise be a substantial amount of work: users, comments, access control, and the administrative side of things — but I also see a bunch of weaknesses. The main one is the code's poor modularity and lack of OO. There are a lot of times where it's just too hard to override a given behavior, or catch a hook before performing a specific action. Also, while the availability of Tiny MCE at first seems like a boon to the content maintainers of a Drupal site, it quickly becomes a burden. It's hard to use the editor to do things like relativize URLs or even apply simple CSS.
But I guess my core complaint is that Drupal (like a lot of PHP code, I guess) just isn't elegant. There are no unifying principles that tie together the essential elements of the system. The templating system is totally diferent from the menu system is totally different from the taxonomy system, and a bunch of seemingly simple features are only accessible through code. Finally, it's too hard to hard to tie objects together in Drupal. Although one object can contain a field referencing another, presenting this to the user is generally a lot of work, and there's no support for tasty ORM features like cascaded updates and such.
As I've said, though, I think most web apps do essentially what Drupal does. They have users who occupy a range of privilege from anonymous through administrator. They have content objects that can be related to one another, or found using search. And they have a relatively small nugget of custom stuff that makes that site different from all the others. I'm surprised that RoR crowd isn't working a CMS. I think its because they think that everyone would program in Ruby if given the opportunity. Ah well, I think there's still a real opportunity to build a killer web-based content management system that inherently supports AJAX and scripted interactions between its content types. It's on my list.