Drupal in crisis

Interesting:

in other words: “Core developers really didn’t want to take on this burden, but it happened nonetheless.”

Those last-minute product features not only blocked Drupal 7 from being released. They also distracted and prevented many high-profile core developers from working on the much more important API and subsystem issues in Drupal core, of which many still remain unresolved today.

Newly introduced subsystems in Drupal 7 have a fair amount of complexity and interdependencies on even more complex subsystems. Newcomers are locked out, unable to help with resolving open bugs. Almost all bugs require in-depth knowledge of various subsystems as well as a solid understanding of the consequences of a change. They need to be tackled by already burnt-out core developers and contributors, or at minimum, require careful reviews and sign-offs from them.

If they don’t care for them, then they are not able to move forward with their development goals for Drupal 8. Even though these developments are mostly targeting low-level core functionality. But yet, core developers have to care for completely irrelevant functionality that someone thought would be nice to have for their mainstream product. Get it into core, let the community maintain it.

At the same time, some of the most active and most proficient core developers started to work for said company within the past three years, and in some cases, their core contributions suddenly and sadly dropped to nearly zero. Without any doubt, it’s merely an economical truth that free contributions and commercial enterprise interests are mainly incompatible, and of course, everyone needs to decide on their own on how to use and invest their resources. Nevertheless, 19% of all core maintainers (including the only two people being able to commit changes) are paid and influenced by a single, dominant (third-)party, which obviously presents a serious conflict of interest today and in the long run.