I've spoken a great deal recently about architectural priorities. In short, we as software developers cannot eat our cake and have it too. Improving flexibility in one area may hurt performance, while improving usability one another area may hinder flexibility. These trade-offs are not necessarily right or wrong, except in the context of the goals and purpose of the project with respect to its target audience.
But what is Drupal's target audience, and how does that impact our architectural decisions?
DrupalCon Copenhagen was a watershed event in terms of understanding how to conceptualize that question, in my view, based on conversations I had with the likes of Mark Boulton, Jen Simmons, and Sam Boyer. In his (excellent) keynote, Jeremy Keith noted that the HTML5 Working Group had a specific, defined set of priorities:
In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.
That may be a good priority order; it may be bad. That depends on your point of view and your goals. It lays out the order in which different stakeholders should be listened to, and if you come to a decision where you have to screw one group over to benefit another how that decision should be made. Having such a clear understanding of your constituent priority is critical to making good, consistent architectural decisions.
So what are Drupal's priorities?