The Next Great Hurdle for Drupal: Organizing Competing Contrib Modules

Drupal is moving through one of the most transformative periods in its recent history.

We have Drupal CMS, Drupal AI, Recipes, and Canvas (now in its 2.x generation after evolving from the Experience Builder initiative) all pushing Drupal toward a more approachable, modern, and ambitious future.

But there is another hurdle Drupal will need to address if we want that future to feel clear and welcoming to new adopters:

Drupal needs a better way to identify, organize, compare, and resolve directly competing contributed modules.

The issue is not that Drupal has too many modules.

Choice is one of Drupal’s greatest strengths.

The problem is unmanaged choice: multiple modules solving essentially the same problem, often without a clear, structured, or prominently visible explanation of why each exists, how they differ, which one is recommended for common use cases, and whether collaboration or consolidation has been considered.

The Problem Is Not Innovation

Before going further, this is important:

This is not a criticism of Drupal contributors.

Contributed modules exist because people see needs, solve problems, share their work, and help others. That is the heart of open source.

Duplicate or overlapping modules often emerge for completely understandable reasons:

• A maintainer may not have been aware of an existing solution.
• An existing module may have looked inactive at the time.
• A project may need a different architecture or dependency strategy.
• A patch or feature may not have been accepted upstream.
• A contributor may simply want to experiment with a cleaner or narrower approach.

All of those can be valid.

The challenge is what happens afterward.

When multiple modules continue to solve the same primary problem, Drupal.org gives users a lot of information, but not always enough context. A site builder may see install counts, release dates, maintainers, issue queues, security coverage, and project descriptions—but still have no clear answer to a very practical question:

Which one should I use?

Case Study: Media Bulk Upload

The clearest current example may be bulk media upload.

At the time of writing, Drupal has several active or semi-active modules in this space:

• Media Library Bulk Upload
• Media Bulk Upload
• Simple Media Bulk Upload

Each of these provides real value. Each has a reason to exist. But to a site builder, content team, agency, or Drupal CMS evaluator, the distinction is not immediately obvious.

That table already tells a more useful story than a basic module search result.

Media Library Bulk Upload was selected for Drupal CMS, which is a major signal. But Media Bulk Upload currently reports significantly higher adoption, a more recent stable release, more maintainers, and a project logo. Meanwhile, Simple Media Bulk Upload has a smaller, more focused scope that may still be the best fit for certain projects.

This is not a situation where one project is obviously “bad” and another is obviously “good.”

It is a situation where users need a structured comparison.

The Duplication Problem

The deeper issue is not just discoverability.

It is duplicated effort.

Bulk media upload is not a finished problem. Drupal sites increasingly need richer media workflows, including:

• Metadata extraction
• EXIF handling
• Inline editing
• AI-generated alt text
• AI-assisted tagging
• S3 and Wasabi support
• Duplicate detection
• Bulk replacement
• Improved editorial review workflows

If three similar modules each need to solve these problems separately, the community loses time. Maintainers duplicate work. Users duplicate testing. Agencies duplicate evaluation. Documentation becomes scattered. Issues are reported in one queue while a similar solution may already exist in another.

This is exactly the kind of situation raised in Deprecate in favor of/join efforts with media library bulk upload, where the issue was closed as “works as designed.”

But if the design leads to confusion, duplicated maintenance, and unclear adoption signals, then maybe the design itself deserves a second look.

This Is Not Just Media

Media bulk upload is only one example.

Similar module families appear throughout the Drupal ecosystem.

Calendar Modules

Calendars are a long-running example of Drupal’s power and complexity. The available options include:

• Calendar
• Calendar View
• FullCalendar
• Fullcalendar View

There are already articles trying to guide users through this complexity, such as ImageX’s Creating Calendars in Drupal. The existence of those guides is useful—but it also shows that Drupal.org itself is not fully solving the comparison problem.

Notably, Calendar View does include a “Similar modules” section linking to Calendar, Fullcalendar View, and FullCalendar. That is exactly the right instinct. The problem is that this kind of comparison is optional, inconsistent, and not structured enough to support ecosystem-level discovery.

Slider and Carousel Modules

Sliders are another familiar example:

• Views Slider
• Splide
• Slick Carousel
• Views Slideshow

Again, the point is not that Drupal should only have one slider module.

There are legitimate distinctions between a legacy jQuery-based slideshow, a mature Slick implementation, a modern Splide integration, and a newer Swiper-based Views slider.

But Drupal.org could make those distinctions much easier to see.

Dark Mode and Olivero

Even a narrower topic like Olivero dark mode already shows this pattern:

• Core issue: Investigate use of the changing color themes for Olivero
• Olivero Dark Mode
• Olivero Dark Switch

Here the distinction is actually quite interesting. Olivero Dark Mode is a sub-theme responding to operating system dark mode preferences. Olivero Dark Switch provides a block-based toggle that alters Olivero’s CSS variables and notes that core does not recommend subtheming Olivero because backwards compatibility is not promised.

That is useful differentiation. It should be surfaced as a structured comparison, not discovered only by reading project pages one by one.

Drupal Already Has Pieces of the Solution

Drupal.org already provides many valuable signals:

• Active install counts
• Release history
• Maintainer lists
• Issue queues
• Security advisory coverage
• Maintenance status
• Ecosystem relationships
• Project descriptions

Some projects also expose ecosystem pages, such as Fullcalendar View’s ecosystem page. And some project pages already include “similar projects” or “similar modules” sections.

So the problem is not that Drupal has no information.

The problem is that the information is fragmented, optional, and inconsistently presented.

For a new Drupal user, a site evaluator, or even an experienced builder working in an unfamiliar area, this creates unnecessary research work.

Proposal: Module Families

Drupal.org should introduce an official concept of Module Families.

A Module Family would group projects that solve the same primary problem or occupy the same decision space.

Examples:

• Media Bulk Upload Family: Media Library Bulk Upload, Media Bulk Upload, Simple Media Bulk Upload
• Calendar Family: Calendar, Calendar View, FullCalendar, Fullcalendar View
• Slider / Carousel Family: Slick, Splide, Views Slideshow, Views Slider
• Olivero Dark Mode Family: Olivero Dark Mode, Olivero Dark Switch

This should not be treated as a punishment or a warning.

It should be treated as Drupal.org helping users understand the ecosystem.

What a Module Family Page Could Show

A Module Family page could include:

• All related modules in the family
• Active install counts
• Latest release dates
• Maintainer counts
• Security advisory coverage
• Drupal CMS inclusion
• Maintenance status
• Best-fit use cases
• Known migration paths
• Structured maintainer notes explaining why each module exists

For example, the Media Bulk Upload family could look something like this:

This type of matrix would help users without forcing maintainers into a single project.

Proposal: Module Relationship Review

Drupal.org could also provide a structured process for flagging highly similar projects.

This should not block new modules.

It should not shame contributors.

It should not automatically deprecate projects.

Instead, a trusted user, maintainer, site administrator, or official Drupal.org role could flag a project as potentially overlapping with an existing Module Family.

The project maintainer could then respond using a structured format:

• Why does this project exist?
• What makes it different from existing family members?
• Was collaboration with an existing project considered?
• Is there a migration path to or from another project?
• Is the module experimental, opinionated, intentionally narrow, or intended as a replacement?
• Would the maintainer consider joining an existing project as a co-maintainer?

The result would be visible on the project page and the Module Family page.

That alone would be a major improvement.

Possible Badges and Signals

Drupal.org could also introduce clearer ecosystem badges, such as:

• Included in Drupal CMS
• Most Installed in Family
• Most Recently Released in Family
• Actively Seeking Co-Maintainers
• Migration Path Available
• Feature Complete / Maintenance Fixes Only
• Part of Module Family
• Recommended for New Projects

These labels should be used carefully. They should be transparent, evidence-based, and reviewable.

But the current alternative is that users infer these signals manually, often from scattered project pages, issue queues, blog posts, and install statistics.

Why This Matters for Drupal CMS

This issue becomes even more important as Drupal CMS grows.

Drupal CMS is designed to make Drupal easier to adopt through opinionated recipes, curated module selections, and increasingly polished authoring experiences. That means its module selections will carry more weight. When a module is included in Drupal CMS, many users reasonably interpret that as the recommended solution for new projects.

That is powerful.

It also creates responsibility.

If Drupal CMS selects one module from a crowded module family, Drupal.org should help explain why that module was selected, what alternatives exist, and whether those alternatives remain better fits for some use cases.

That would benefit everyone:

• New adopters get clearer recommendations.
• Experienced builders get better comparison data.
• Maintainers get more visibility and fewer duplicate support requests.
• Drupal CMS can make opinionated choices without hiding the broader ecosystem.
• The community can identify opportunities to combine effort.

Module Families Are About Context, Not Consolidation

It is important to emphasize what a Module Family system would not do.

It would not replace existing project pages. It would not prevent new modules from being created. It would not require projects to merge, nor would it discourage experimentation or alternative approaches.

Instead, it would provide additional context. Contributors could continue pursuing different architectural approaches, user experiences, and technical philosophies while giving users a clearer understanding of how related projects fit into the broader ecosystem.

Drupal has always benefited from healthy competition and new ideas. A Module Family system would not reduce innovation—it would make innovation easier to discover, evaluate, and understand.

The Goal Is Not Fewer Modules

The goal is not fewer modules.

The goal is healthier module discovery.

Drupal should continue to welcome experimentation. It should continue to allow competing ideas. It should continue to support modules with different architectural approaches and different target audiences.

But when modules solve the same primary problem, Drupal should help users and maintainers understand that relationship.

Choice is good.

Unmanaged choice is expensive.

A Module Family system would not solve every problem in contrib. But it would give Drupal a practical, transparent, community-oriented way to reduce confusion, surface collaboration opportunities, and make Drupal easier to evaluate.

As AI, Drupal CMS, Recipes, and Canvas continue to reshape Drupal, this may be one of the next ecosystem challenges worth tackling.

And unlike many big challenges, this one feels very solvable.