> I have this vision of someone in the PHP community at some point randomly picking up the Gang of Four book and being like "holy shit, check this out people..

> I have this vision of someone in the PHP community at some point randomly picking up the Gang of Four book and being like "holy shit, check this out people...they had a solution to some similar problems 20 years ago..." It's more subtle than that, but there's indeed a great lesson to be learned: the architecture of an open source project affects and reflects both its code and politics. Many years ago, the following article was written and spread through the community: http://drupal.org/node/547518 http://drupal.org/node/547518 Though it has since been updated, the original premise remains intact: "You can point to chunks of Drupal's code and identify pieces which act similar to OO-patterns. Therefor, Drupal is OO-like and there is no problem." New Drupal developers have been reading this for years, and drank the kool-aid, including myself many years ago, before I left. But of course, OO isn't just about what the code does, but how the code can be re-used and re-factored, and this is where Drupal falls flat. It's always been architected as a waterfall of pieces that call each other directly. This was rationalized away with the trope that Drupal had a "solid, well-written core", meaning nobody should ever need or want to touch it. But what it really meant was that there was no room for innovation in essential parts of it. Drupal has always exploited the low bar in PHP land to position itself as more than it is. It is not better than WordPress, it is merely bigger and more meticulously annotated. This is the result of a review process that encourages people to participate, while only giving them superficial checklists to verify, rather than good software and product design practices. Creating and maintaining Drupal has become such a bureaucracy, that even ideas that should be dead on arrival can be ferried along, slowly being turned from "unacceptable" into "good enough to steamroll over the remaining objections". This creates a desire from many to see it go through regardless, to not have all that accumulated effort go to waste. As a result, big decisions come down to taste and politics, not technical merit derived from a consistent vision of what the end result should be. I can't count the number of times a committed core patch left behind an exasperated contributor, who'd lost all appetite to continue to work on it, even before their work had the official seal of approval. Code is abandoned as soon as it becomes relevant. Buytaert has always been aware of the limitations of Drupal's flat extension mechanism, always hesitant to add to it, but never seemed to want to modularize the module system itself to fix that. Of course, when the language you're developing in has the exact same problem, it is easy to rationalize this away as "not a big deal", even as the frog is slowly cooked to death one degree at a time. The frog is now dead, but rather than admit it, it lies open on the operating table, hooked up to a Frankenstein-like mechanism that makes its limbs twitch in a convincing fashion. Every year, his keynote would list a set of goals. Usually the same ones kept getting repeated, on account of them not being accomplished in a way that actually solved problems for end-users. A perfect illustration is WYSIWYG editing. For years, the only thing people could agree on was wanting to swap out the WYSIWYG editor component. Which may sound admirable. But WYSIWYG is not about dropping in a JS library to add formatting buttons to your textareas, in fact, that's the least important part. It's about creating a workflow for users where you can always edit content in the same place you're reading it, and to make that happen seamlessly and elegantly, regardless of whether it's text or media. Such goals cannot be accomplished in the Drupal community, even though several private companies have done it with Drupal over the years. Ironically, Drupal has a bottom-up process that results in a top-down architecture, which realizes a vision in the middle nobody actually needs directly. The WYSIWYG example is a perfect illustration: even as people say they're trying to reinvent the way editing in Drupal works, they're not willing or able to gut all the old stuff that keeps it clunky. While Drupal contributors maintain things are getting better, the same processes are still in place, and more importantly, the same attitudes. Here's a recent quote by Chx, prolific Drupal contributor, loved by many: "Drupal always did things better. Always. [...] That's a fact and a hard fact. [...] I hope we can get back on track for D9, finally." http://www.garfieldtech.com/blog/off-the-island-2013#comment-2249 http://www.garfieldtech.com/blog/off-the-island-2013#comment... Based on the current pace of development, Drupal 9 will arrive somewhere in 2015, maybe later. They've been supposedly turning this ship around for 2 years now, which shows you the real problem: these core contributors aren't in it for the end-result, they're in it for the process. There are social, political and financial benefits to be gained from putting yourself in a position where everyone relies on you, especially if you value approval from others. The community that declared loudly that it wanted to make the middle men of the web obsolete, has created the perfect product for middle men to exploit for their benefit. Every open source project is a social and political experiment. People should pay more attention to that fact.