Drupal haters say:
"Documentation is a problem".
Answer: we have an active documentation team. Documentation is not as good as it could be, but it never is. It's put together by volunteers, which makes it easy to contribute. Every module has a readme.txt. And there's a huge amount of documentation at . There are hundreds of videos - just last week all of drupalcon.org held in Munich was videoed and put online. And I note that the OP is a book review on another Drupal book.
"It's spaghetti code"
Answer: The code is hugely well structured. It works on a callback-by-naming system, so there's no need to register callback functions, it happens automagically. Mostly, I think that this criticism comes from people who don't understand the architecture. It's not perfect - there is cruft - for instance there hasn't been a settled standard for code-level plugins - e.g. I want to rewrite the standard paging through lists, so that it works better for my site. That uses one style of plugin code. There are others. This is part of growing pain, and is ironed out with each version.
"It's not Object Orientated"
Answer: Much, but not all of the code is OO, but was designed to work on PHP4 as well as PHP5. In time it will all be OO. But more importantly, OO is an idea to promote modularity and extensibility, which are notions that are built into the architecture. For instance, a pattern that is repeatedly used is the system of overrides by putting a well named piece of code in the right place.
"It's written on PHP"
Yep. It's not as fast as C++. Or Java. It's also cheaper to write, easier to learn, runs on almost every webserver, and is a mutt of languages, rather like English. There are hundreds of developers who contribute to the core development and thousands who contribute to modules. I don't know of any open-source C++ CMSs with the same rate of growth. Hardware is cheaper than developers. Turns out that PHP is good enough for Facebook. (Yes, I know: Hiphop. That's optimization.)
"It's complicated and over-engineered"
If you want a tool that is just a blog, then Wordpress is excellent. If you want a tool that grows with you, and can do anything you want then Drupal is probably going to work out better for you than many other tools. That's not to say that there aren't great Drupal blogs, but out-of-the-box, Wordpress is better than Drupal as a blog. But Drupal also has distros/install profiles, which are versions specialised for a particular job. And maybe one of those is a better match for your needs than the core version of Drupal.
"I'm a Joomla/Silverstripe/Wordpress/Perl/whatever user"
Those are all excellent tools. You should carry on using what works for you. But if you are interested in what's happening elsewhere, then come by drupal.org and have a look around. Have a play with one of the pre-packaged versions like drupalgardens.com.
"I can make a CMS. Why do I need someone elses?"
I too made and sold CMSs. Turns out that you can't compete with the rate of growth, the rate at which maintenance is done, or the availablity of add-ons.
"I've always been fine with my hammer and nail and plain HTML."
Yep. You don't make websites that work on mobile phones. Or large websites. Or ones that change frequently. Or you make something which for which a completely custom solution is better: Drupal is never going to be the best forum software. If you just need a forum, then use specialist forum software. But if you need forums, and to put some pages up, and to have an image gallery, and to send SMSs on update, and...etc, then start with a tool that can grow.
"It looks terrible"
It will look exactly how you want it to look. It's true that some other systems have many more off-the-shelf templates. And it's true that Drupal could be more designer-friendly, but shouldn't how your site looks reflect you?
"It does hardly anything - it doesn't even do Wysiwyg"
When you install it, you get a bare-bones system, to which you add parts. The core is a framework to build out on. So you download and enable the bits that you need for your site, which lets you pick and choose your Wysiwig editor as well.
"It constantly breaks module backwards compatibility"
Yes, when we release major versions, about every 18 months to 2 years, we do not guarantee that the modules from the previous version will work. They may only need a small upgrade, but they will almost certainly need _some_ changes. We do however guarantee that for core modules, your data will be ok. You'll put in an updated module, run the upgrade routine, and voila! For modules which are not core, this is almost always true too. Where this sometimes falls down is when there is no longer a need for a particular module, because it's become part of the core. We always support 2 versions (and it doesn't stop working just because it's no longer supported), so there's at least 36 months before you need to think about upgrading.
"James Joyce's Ulysses of CMSs. A small group of people (usually with too much time on their hands) have mastered it"
There are thousands of contributors. Conferences on your continent once a year. Local events all the time. Thousands of user groups. Runs some of the largest and smallest sites on the internet. I guess Ulysses was pretty good.
"There are global variables everywhere. The names of variables are completely unintelligible and the depth of data structures is heinous."
It turns out that there aren't. $node and $user are probably the two that are everywhere, which is not surprising since they carry information about the current page and the user, and the callback system lets each module interact with the aspects of the system that interests them. I guess that some variable names are unintelligible, if you don't understand the architecture. Regarding the depth of data structures: this is a fair comment in a way... the system builds up a picture of the requested page in a data structure, giving each module the chance to decorate or alter it, then it renders each piece, and combines the output into a page. So yes, the data structure that represents a page _is_ big. And it's well structured, so that the decentralized system of modules can reliably interact.
"Why the fuck is Drupal taking several tens of megabytes for only 100 fields?"
It could be that you were using hundreds of modules. It could be you were storing a lot of data in those 100 fields. It could be you had a massive menu structure which needed to be rendered. You can use a GUI tool, which has to cater for lots of flexibility that you won't ever need, or you can write a very tight custom module, that only uses the memory you required. It's a trade-off usually, and usually it's cheaper to use the general purpose tool. Drupal needs between 8 and 16 MB for a starter site. If you add more modules, then you use more memory.
"..If you are an actual developer, and need to do a lot of custom things, then try a real framework like Zend, or Codeigniter, or Laravel, or Yii"
This is definitely true sometimes. But this is the minority of users. Most people are not developers. And most sites, while needing custom things, fit inside a range that has mostly been done before - for instance a slideshow; adding one in Drupal is as easy as downloading and switching on a module. Writing your own slide player, whilst fun, is not a productive use of time for many of us.
Drupal lovers say:
Drupal is not the best at everything. If you have a very specific need, and a specific tool deals with it, then use that tool. Drupal will never be the best game platform, for instance, but I'm sure there is a game platform built on Drupal which is also used for community interaction.
It's a big system, and like any large system, there are annoyances, but one of the benefits of open source is that annoyances get solved quickly.
It's used by mom & pop, and by multinational corporations and governments, micro sites and some of the largest. It can start small and can grow.
There are conferences and events and groups constantly talking - look at #drupal on twitter or look at drupal.org. Last week 1,800 people got together in Munich for a week of Drupal, and in about 6 months time Portland, Oregon will host the next US Drupalcon, with around 4,000 to 5,000 attendees expected, I think. Between now and then, there will be hundreds or Drupal camps and meetups.
If you are thinking of developing a website, then Drupal is a good place to start, and we'd love you to be part of our community.