I want to be honest. I expected and feared a lot of backslash, disagreements, and even name-calling on my Drupal Crisis blog post. But to my surprise, almost everyone who provided feedback mostly agreed with most issues raised, and even more so on the overall problem space at glance. In fact, the only criticism came from "top-down" about "not being constructive".
Talk to me, darling.
However, an interesting part is that no one really started to raise concerns and complaints earlier. It looks like most of us swallowed pill after pill, issue after issue, announcement after announcement, in the mere hope it might be the last.
Drupal's overall (core?) development environment and "culture" of constantly criticizing, flaming, blaming, shitting, and pissing over the existing problems in APIs and code certainly is a factor here: We all do it all the way; and when another pill enters the inbox, there's a good chance it's silently trashed, since we've created plenty of flames about really annoying code-related stuff in the core queue already, so there's neither time nor energy for another one that's 1) not related to core architecture and 2) may not be so important at first sight.
Things pile up. And in retrospective, everyone obviously knows better and would have decided differently. As a matter fact, we don't have a proper public place anywhere to discuss these and related ramblings, which are crucial to the project: Does Acquia exert inappropriate influence on Drupal core?
(though this little post, given the size and amount of groups on g.d.o, looks a bit lost, compared to its importance.)
We need to discuss whether and how acquia presents a conflict of interest.
I can only applaud and cheer for effulgentsia (who happens to work for acquia): we instantly had a very long Skype call, iterating over every single issue to clarify what's ultimately meant, in order to pass that info on to others. Alex continues to amaze me with his structure, clarity, creativity, and unparalleled quality, both in terms of code and communication. If he didn't work for acquia and there wasn't that very same possible conflict of interest, I'd place all my votes for him to become a core maintainer.
rfay's core conversation about burn-out at DrupalCon London is closely related: it revealed that there are many more Drupal contributors who kept silent about their personal feelings for too long. In the end, we have several critical communication problems about fundamental topics in our community.
We need to discuss how we can resolve that lack of communication without sacrificing our contributors and putting them into a dark corner at the same time.
Chocolate and ice-cream, or: the carrot and the stick.
A detail that many didn't recognize in the original post: There have been 8,000+ new bug reports, within two years, of which every single one had to be 1) created, 2) analyzed, 3) patched, 4) peer-reviewed, 5) tested, 6) approved, and lastly 7) committed. On average, this means that 320 bugs had to go through this process per month, and 10 bugs per day.
As tsvenson pointed out, these numbers will only be increasing, and we already see a rapid pace today. The amount of bug reports itself is concerning. Somehow you'd expect the volume to go down over time - although that may be debatable, since core purposively changes things - but still, the total amount of open bugs goes up. Some core developers are arguing that we're able to cope with the increasing numbers by attracting more contributors for Drupal core development.
However, what is most concerning is the amount of work being required for the points 2 and 4-7 in above list, which has to be delivered by already experienced core developers, and, whether that is a sustainable model for the future.
So what I'm really after is this:
sun: I should have clarified what kind of stuff I'm ok with maintaining, patching, and reviewing patches against in core. And what stuff not.
catch: everyone who ever has written a post like this should've done that.
Apparently, no one did.
At least I don't think I've ever seen any kind of analysis or proposal of a core developer who stated what exact parts of Drupal core he/she actually considers as core material himself/herself. And, which he/she is willing to actively maintain in core. Instead of being forced to by current contents, present nostalgia, and current development processes.
We need to discuss, propose, agree, and define what we are able and want to maintain in Drupal core.
Another very long and heated call with chx and webchick revealed that basically all of of the "product features" in Drupal core are de facto unmaintained. In order to improve them, move them, or remove them, we need dedicated maintainers for our product features. But we're not only done with finding people, because:
We need to discuss which core features are actually product features.
Most of these feature modules are actually easy targets for newcomers. Most of them do not contain complex logic and code, so issues are on an entirely different complexity level than, say, refactoring System module.
But obviously, it's going to be hard to find maintainers for brain-dead modules like Aggregator. A product feature in line with the core architecture and the year 2012+ would rather be a total replacement with Feeds module (or whatever the current contrib lead is; sorry, I've lost track of that evolution).
The process to find people who're willing to take on maintenance for the product features and topics is going to take some time. Unless the Drupal community gets its act together. As of now, all of this based on hope only.
Many people have argued for the "traditional" open-source process on the original post already; i.e., move unmaintained ballast from core into contrib, and add new, modern features to core. Some core developers argued against this, because they originally found their way into core development through those old modules, and because a few of them basically served as unforeseen "regression testing" during Drupal 7. But yet, there's neither someone who wants to take them on, nor someone who has a vision yet.
We need to discuss a deadline for finding maintainers for product features.
And based on that:
We need to discuss what we are going to do with stuff that no one wants to maintain.
In Drupal core, we only need a certain and solid amount of consumers of core APIs. These can still make up for an awesome, basic product. But we don't need to maintain features that almost no one uses or needs. Those unnecessary features not only distract all of us during regular core development, they especially make the refactoring of core APIs harder.
Related to that, we seem to have a weird understanding of moving core features to "contrib". In the past, we only ever moved code from core to contrib that no one actually used. The proposal of moving the Standard installation profile, including the product feature modules, into a separate project (possibly everything in a single project) didn't yield much positive feedback yet.
Even though that very same project, if required, could theoretically be maintained by Dries as well. And even though all of those product features would be able to evolve in a much faster pace than Drupal core does. Which especially makes sense for pure UX modules. There are no dependencies on API changes that would have to be taken into account. In fact, all of those feature modules architecturally share the same principles as any other contributed module does.
We need to discuss whether we can or want to move product features into a separate product project in the long-term.
What may I serve you, master?
The primary objective is focus. Too many irrelevant things distract us from the important things and badly needed refactoring, and especially make the latter harder. Every single issue sucks core contributor time and energy.
And don't forget about core maintainer time. Spending less time on whatnot issues means to have more time for actual architectural discussions and reviews. Many core contributors repeatedly stated in the past that they'd really like to have "back" a technical lead. The current interactions of core maintainers are mostly about the very same topics all over again: sanity check, backwards-compatibility, API changes, coding style, documentation, yadayada, but close to zero feedback and discussion about actual architecture. The current situation is an extreme case of do-ocracy. The Drupal community expects (core and non-core) project maintainers to lead, provide and share vision, and direction. Also in core.
Make sure to watch eaton's talk about Product, Framework, or Platform? held at DrupalCon London. It provides in-depth historical insight for how we arrived in the current situation. It takes one hour, but that hour is more than worth to invest. Thanks, eaton!
Seen Jeff Eaton's presentation? Then look and see how a demo drupal.org Download page of Drupal as a platform would actually look like.
This solves pretty much all of of the identified problems (and many more). drupal.org's infrastructure is fully prepared. It's merely a matter of doing it.
But in order to do this to core, we need to have all of the discussions outlined above.Submitted by sun on 25. August 2011 - 7:37