The Drupal content management system is an amazing piece of software. It’s an open source project that people all over the world contribute to and it’s currently celebrating its 20th birthday. It’s a rare beast in the computing world that survives for two decades as a single system. Depending on who you ask, Drupal powers something like 2% of all websites on Earth. Drupal can do everything from simple “brochureware” sites to elaborate platforms that integrate with dozens of other services. However, all that power and flexibility comes with a price.
Like any large, complicated system that’s been around this long, Drupal has a lot of bugs. At the time of this writing, we’re approaching 100,000 issues ever submitted to the Drupal core issue queue. That includes feature requests, tasks, and so on, but half of those issues are bug reports. Of course, that includes every bug report for the last 20 years, including everything we’ve already fixed (~24K), bugs that were reported that no one else could reproduce, etc. But right now, there are 10,401 open bug reports.
Not every bug impacts every site, but nearly every site is impacted by at least one of them. Most of us who build Drupal sites will run into at least something that doesn’t quite work as expected. Being an open source software project, the ethical thing to do when you encounter a bug is to try to fix it “upstream.” Since each of us is benefitting from literally millions of hours of developer time that have been contributed to the core system over the last 20 years, it’s up to all of us to pitch in and help ensure that those bugs are reported and fixed.
Sometimes, you’ve found an entirely new bug, but that’s honestly pretty rare. Hopefully when you encounter a problem, you search for existing bug reports. In most cases, the bug is already known. In many of those cases, someone has already come up with a fix (~5K). So why did you still encounter the bug? Running into a bug someone else already found, and fixed, can be extremely frustrating.
Drupal has very high standards for any changes that are accepted into the core system. Just because you’ve identified a bug, and even come up with a fix, it doesn’t mean that the fix will be included in the next release. All changes, especially bug reports, must include automated tests to demonstrate the bug and to prove that the fix solves it. The bug report itself must be well written and properly scoped. The code must strictly adhere to Drupal core’s coding standards. There are a number of “gates” your change must get through before it can be committed, including documentation, performance, accessibility, usability, and the aforementioned testing.
All this policy and process helps ensure that Drupal’s codebase keeps getting better, not worse, as time goes on. It means that new releases don’t (usually) break your existing site. It means that websites built with Drupal tend to be more accessible. It means that a bug “fix” isn’t going to slow down your site, or make the user interface more confusing, or otherwise add more technical debt to the system. But it also means that when you’ve identified a bug, you’ve got a lot of “hoops to jump through” to get it fixed and released.
These standards are great, and they all have wonderful reasons to exist. They arose to address real problems, and are part of what makes the core system powerful, flexible and reliable enough to build so many incredible things with. But it’s collectively an enormous waste of time for the community when known bugs linger and fixes aren’t polished to a sufficient level of perfection to be included in the next release.
Folks without as much experience debugging such a big complex system can spend many hours trying to understand what’s happening. Some won’t succeed, and might give up on Drupal entirely. Others might quickly smell trouble, know where in the system to look to make sense of it, search the issue queue, find an existing report, review the proposed solution and even start applying the latest patch in their
composer.json file. But then the bug lingers, people don’t have time to keep “rerolling” their fix to address points raised by community peer review. Or worse, there is no peer review, no one else looks at your proposed fix and the issue sits in “Needs review” status (~2400) for months or years. Meanwhile, other changes are made to Drupal that conflict and the patch no longer applies. Hundreds (maybe thousands?) of sites will each have to spend time after the next release to find or produce a new patch that applies to the current version. A single bug can cost the community many thousands of hours of collective time.
This sad state of affairs is what led some of us to launch the Bug Smash Initiative. It’s a community effort to fix the known bugs in Drupal core. We started it in June of 2020, and since then, we’ve already closed nearly 1000 bugs, including over 200 that we’ve actually fixed. (The other ~800 were open bug reports that we triaged and discovered are no longer valid, are duplicates with other bugs, are already fixed, etc). We’re definitely not the only people trying to fix bugs in Drupal, but we’re working together to make a dent in that backlog of 10K bugs. We want to help ensure that more bugs get resolved and the fixes get released, so that as a community we can focus on all the other fabulous things we can do with this system (build better sites, make the world a better place, make the community more inclusive, diverse and friendly, or spend more time away from the computer doing whatever else brings us joy).
One of the best things about contributing to the Bug Smash Initiative is that we’ve got a culture of “review swaps”. If I’ve got a bug I’m trying to smash, and I post a new patch (or push more commits to the issue fork), someone else needs to review those changes before one of the core committers will even look at it. So I can jump into the #bugsmash Slack channel and start a thread asking for a review swap. If anyone else is willing to look at my changes, they can give me a link to a bug they’ve been working on and I’ll review their fix.
We can quickly chat about how to improve the code, anything that needs better comments and documentation, how to write a good test for the bug, make sure all the core gates are being satisfied and so on. Instead of waiting weeks or months for someone else to look at it, we might get a few iterations on each fix within an hour. We can learn from each other about best practices. Other folks in the channel might chime in with their own experience and expertise. Instead of trying to do it alone, we can rely on some mutual support to get something done more quickly.
When we finally mark each issue “Reviewed & tested by the community” (RTBC), it’s more likely that the core committers will actually commit it (instead of finding their own problems with the code and sending it back to Needs work). With more eyes on the bug and the proposed solution, we make a better fix that’s more likely to be committed and released. Everyone wins.
How You Can Contribute
I’m extremely happy to be working for TEN7 as my “day job.” It’s a fabulous company that sees the value in contributing “upstream”. They give me 5 hours a week “on the clock” to do whatever community contributions I want to work on. Part of it goes to “maintaining” (if you can call it that) some of the contributed modules I’ve shared with the community or co-maintain, but most of that time goes to the Bug Smash Initiative, since I know what a huge collective win it is when we fix more of these known bugs. It means that every site we build is being built on a stronger foundation. It means we can spend more time adding new features and making things better for our clients (and most importantly, their users), not just working around weird and broken behavior. It means when a client asks us to fix a problem they’re having, we get it all the way fixed, so that future versions of Drupal will include the fix, instead of having to allocate hours every few months to keep our bug fix working as Drupal makes subsequent releases.
More Drupal shops could actively sponsor their employees and contractors in this way. We definitely need more people to participate in this initiative, and asking folks to do it as a labor of love on nights and weekends isn’t going to resolve the backlog. If you’re working for a client to fix something, please contribute to getting the fix done properly in core. It’s better for your client, since they won’t have to pay you again in a few months to get the fix to apply when you upgrade their site to the latest security release (which you’re already doing regularly, right?). It’s better for you, since you’ll gain experience, earn credibility in the community and you’ll have a sense of accomplishment that you helped improve Drupal core. It’s better for the community, since hundreds or thousands of other people won’t run into the same bug and waste their time working around something you already helped solve.
Our community initiative page includes a lot of info on how to jump in and participate. During the upcoming DrupalCon, Wednesday (2021-04-14) will be focused on both the Bug Smash Initiative and the Automatic Updates Initiative (so that sites can automatically and securely apply updates when critical security bugs are fixed). There will be a bunch of folks available throughout the conference, but especially on that day, to mentor you through the steps on helping to fix a bug in Drupal core. There are active members of our Slack channel spread throughout the globe, so no matter what timezone you’re in, you’re likely to find someone in there who can help you get started.
Please join us. Drupal workers of the world unite! We have nothing to lose but our frustration (and hopefully the
patches section in our
composer.json files). We have a world to win.