A Mini Case Study: How to Rescue an Abandoned/Neglected Drupal Module

The contribution ecosystem is one of the most important reasons for Drupal's success. With over 45,000 modules available to enhance and extend Drupal's functionality, these contributions are critical to maintaining Drupal's status as an enterprise-class content management system.

Getting involved in the Drupal community is beneficial to all parties but can be intimidating, especially when it comes to committing code. It can be hard to know where to begin, or you may not necessarily have an idea for a new module. But that doesn't mean you can't get involved.

Drupal modules are built and maintained by members of the Drupal community. Sometimes, community members move on for a variety of reasons and the module becomes stale. That's what happened to the TB MegaMenu module, a project with over 30,000 installations at the end of 2020.

Rescuing TB MegaMenu

Mega Menus are a critical feature for many Bounteous projects. We selected TB MegaMenu for Wilson.com a few years ago because of the flexibility to power the site's extensive dropdown menus.

Unfortunately, in addition to a number of bugs and missing features, accessibility was not well implemented by the module at the time. We were able to provide some patches to address these issues; however, since the project was not actively maintained at the time, we had no way to update the module for the broader Drupal community.

We were in a tough spot because we needed the improvements to keep using the module, so we found ourselves providing these enhancements solely for our clients. That situation was a perfect opportunity for us to get involved in the Drupal contrib community, so we decided to apply for ownership of the module.

Taking Control of Maintainership for a Drupal Module

What does that process of taking over a module look like? Turns out it's pretty simple. Creating a new request in the appropriate issue queue gets the ball rolling, and once you are approved as the new owner, you gain access to the codebase and the module's landing page.

The first thing we had to decide after taking over ownership of the module was how to prioritize our time. Needless to say, TB MegaMenu is not anyone's first priority, and all contributors have to strike the right balance between putting time into open source projects and billable work.

So with two codebases to maintain, one for Drupal 7 and one for Drupal 8/9, we prioritized our work as follows:

• Fix the most critical bugs that were preventing upgrades and new installs
• Commit the accessibility enhancements we'd developed internally
• Apply for security coverage
• Publish a stable release for Drupal 8/9
• Continue to address bugs in the Drupal 7 version while prioritizing enhancements for  Drupal 8/9

Maintaining Open Source Contributions

Let's face it: carving out time to contribute to open source contributions can be difficult—especially if your clients' projects are not relying on updates or enhancements to that work.

The availability of our Drupal developers at Bounteous fluctuates as team members move between projects, so we knew that our contributions to maintaining the TB Mega Menu module would naturally ebb and flow over time.

In light of that, we knew that we'd need to push ourselves a little bit to keep up with TB MegaMenu maintenance work, so we gave ourselves some parameters for getting stuff done:

• Established weekly "office hours" to prioritize issues and ongoing work
• Leveraged a Jira board to track bugs and progress
• Promoted our efforts internally to get other team members excited and drum up additional support 
• Simplified onboarding for new contributors by creating dedicated local development environments for TB MegaMenu work
• Lowered the barrier by providing different ways to contribute other than code

Fortunately, the odds turned out to be in our favor—particularly during the last quarter of 2020, when a core team of contributors came together and gained considerable traction on moving the module forward. Giving back to the community is a core part of working at Bounteous, and contributing to open source modules is just one way we bring that to life.

Quick Wins When Reviving a Drupal Module

It doesn't take much to bring real value to a stale project right away. If you're considering rescuing a module, scan this list to get an idea of the time investment needed and consider how small changes can make a big difference. Here are some things we were able to do right off the bat to start reviving the module.

Better Communication to Developer Community

One of the first things we did was to update the module's homepage to let people know that the module had new maintainers. This was one of several efforts to restore "faith" in the module and reassure developers who might otherwise be deterred by the number of open issues and lack of recent commits to the module's codebase.

Test, Review, and Commit Patches

The TB issue queue had several instances of patches that had been posted but never tested and/or reviewed. Merging commits for issues that have already been patched is a great way to improve the module right out of the gate—without having to write any code yourself.

Clean Up the Queue

We evaluated and either closed or postponed open issues that were duplicates, not reproducible, were no longer applicable, or had already been addressed in another patch.

This can be time-consuming, and in the case of TB MegaMenu, there is still an enormous backlog of open issues going back years and years that we'll probably never get through. But on a smaller project, this kind of cleanup can go a long way to making the issues queue more manageable.

Identify the High-Priority Items

Inheriting a large number of bugs and feature requests dating back years (7+ in our case!) might seem overwhelming at first—even after cleaning up the queue. Fortunately, drupal.org forces every issue to be tagged with a priority level, which can be an invaluable tool for determining where to start.

Aside from noting the obvious urgency of critical and major issues, it can be helpful to also look at context and feedback from the community. Issues that have received a number of comments over time show recent activity probably warrants your attention more than one that was reported a while back.

Creating Documentation for Developers

TB MegaMenu's documentation was limited, so we created getting started guides for both the Drupal 7 and Drupal 8/9 versions of the module, following the Drupal.org guidelines, and posted links to them on the module's homepage. If it's easy to understand how to use the module, developers can much more quickly determine if it fits their project's needs.

Providing simple, concise, and accessible documentation can make the difference between hours of headaches and a smoother, more efficient working experience. Inevitably, our investment in documentation will yield a more popular module with a larger install base.

Bringing TB MegaMenu Back to Life

Most of these things can be done without too much effort, and they are a great way to start breathing life back into the project. Here's the fun part: shortly after we started work on TB MegaMenu, we noticed an uptick in activity in the issue queue. By pushing out new commits and simply responding to tickets, the community came back alive!

We started seeing new issues being reported, and new requests for support and features (not that we like bugs, but we do like being able to fix them!). All of those community members who are getting involved now are helping us to make the module better and could also be contributors in the future.

Looking Forward: Contributing to the Drupal community

Now that we have some momentum and are more comfortable with the process and the code, we have big plans for more work with TB MegaMenu. Some recent commits improve upon accessibility and coding standards, and we're getting ready to start a 2.x version of the Drupal 8/9 codebase which will simplify the front end. We've also applied for security coverage, which is a big step towards validating the module for use on some sites.

Contributing to the Drupal community is good for everyone. It benefits you as a developer because it gets you involved in the community, gives you ownership, and helps build your expertise. Of course, it also helps to strengthen the community of Drupal users and developers because our collective efforts translate to better modules. And finally, it's good for your brand—since your work will help to elevate your company's status in the Drupal community.

Are you aware of a module that needs some help? Here are some links to help you get involved:

• Taking over unsupported (abandoned) projects
• Getting Support as a Maintainer or Co-Maintainer
• Drupal Projects Seeking Maintainers
• Ways to Get Involved in Drupal

Thank you to Andy Olson, Irene Dobbs, and Wade Stewart for the contributions to the TB MegaMenu module and their help on the blog!