The clearest current example may be bulk media upload.Examples:All of those can be valid.But there is another hurdle Drupal will need to address if we want that future to feel clear and welcoming to new adopters: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.Drupal.org could also introduce clearer ecosystem badges, such as: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.
The Problem Is Not Innovation
Sliders are another familiar example:Choice is good.Which one should I use?The issue is not that Drupal has too many modules.
- 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.
The problem is that the information is fragmented, optional, and inconsistently presented.But Drupal.org could make those distinctions much easier to see.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.”Bulk media upload is not a finished problem. Drupal sites increasingly need richer media workflows, including:
Case Study: Media Bulk Upload
It also creates responsibility.That alone would be a major improvement.So the problem is not that Drupal has no information.
| Module | Active installs | Latest release | Drupal CMS inclusion | Maintainers | Primary differentiator |
|---|---|---|---|---|---|
| Media Library Bulk Upload | 5,903 | 1.0.6 — October 29, 2025 | Yes — selected for Drupal CMS media workflow | 3 | Uses Drupal’s Media Library workflow and supports inline editing-oriented UX. |
| Media Bulk Upload | 16,594 | 3.0.5 — January 19, 2026 | No clear inclusion as the default Drupal CMS bulk upload choice | 8 | Mature bulk upload workflow with DropzoneJS option and broad existing adoption. |
| Simple Media Bulk Upload | 2,065 | 2.0.0 — September 26, 2024 | No | 1 | Lightweight bulk upload flow extracted from Lightning Media-style functionality. |
The project maintainer could then respond using a structured format:This is not a situation where one project is obviously “bad” and another is obviously “good.”The goal is not fewer modules.Duplicate or overlapping modules often emerge for completely understandable reasons:
The Duplication Problem
It is a situation where users need a structured comparison.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.These labels should be used carefully. They should be transparent, evidence-based, and reviewable.
- 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
After AI, Drupal CMS, Recipes, and Experience Builder, this may be one of Drupal’s next great ecosystem challenges.Drupal needs a better way to identify, organize, compare, and resolve directly competing contributed modules.At the time of writing, Drupal has several active or semi-active modules in this space:
This Is Not Just Media
A Module Family page could include:Before going further, this is important:
Calendar Modules
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.
| Module | Active installs | Latest release | Drupal CMS inclusion | Maintainers | Primary differentiator |
|---|---|---|---|---|---|
| Calendar | 38,906 | 8.x-1.0-beta5 — February 3, 2026 | No | 5 | Classic calendar layout for date-based Views, including year, month, week, and day views. |
| Calendar View | 6,076 | 2.1.10 — September 23, 2024 | No | 1 | Lightweight, no-JavaScript calendar display directly through Views. |
| FullCalendar | 3,611 | 3.0.3 — June 7, 2025 | No | 8 | FullCalendar 6 integration with advanced interaction features and Smart Date support. |
| Fullcalendar View | 21,710 | 5.3.0-alpha1 — March 6, 2026; stable 5.2.5 — August 25, 2025 | No | 2 | Views calendar display powered by the FullCalendar JavaScript library. |
The challenge is what happens afterward.Drupal is moving through one of the most exciting periods in its recent history.
Slider and Carousel Modules
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.
| Module | Active installs | Latest release | Drupal CMS inclusion | Maintainers | Primary differentiator |
|---|---|---|---|---|---|
| Views Slider | 48 | 1.0.1 — May 9, 2026 | No | 1 | Newer Views-based slider with Swiper JS integration and field mapping. |
| Splide | 2,970 | 2.0.13 — January 10, 2026 | No | 1 | Vanilla JavaScript slider integration positioned as a modern alternative to Slick. |
| Slick Carousel | 68,806 | 3.0.7 — January 10, 2026 | No | 3 | Mature, widely installed carousel integration with broad Drupal ecosystem support. |
| Views Slideshow | 73,633 | 5.0.1 — August 19, 2024 | No | 4 | Classic Views-based slideshow module with very high historical adoption. |
This is not a criticism of Drupal contributors.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.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.
Dark Mode and Olivero
That would benefit everyone: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.Drupal.org could also provide a structured process for flagging highly similar projects.
Drupal Already Has Pieces of the Solution
But when modules solve the same primary problem, Drupal should help users and maintainers understand that relationship.
- Active install counts
- Release history
- Maintainer lists
- Issue queues
- Security advisory coverage
- Maintenance status
- Ecosystem relationships
- Project descriptions
This should not be treated as a punishment or a warning.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.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.
Proposal: Module Families
Again, the point is not that Drupal should only have one slider module.Drupal CMS is designed to make Drupal easier to adopt. That means its module selections will carry more weight. When a module is included in Drupal CMS, many users will reasonably interpret that as a recommendation.That is powerful.
- 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 issue becomes even more important as Drupal CMS grows.Drupal.org already provides many valuable signals:
What a Module Family Page Could Show
That is useful differentiation. It should be surfaced as a structured comparison, not discovered only by reading project pages one by one.
- 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
The result would be visible on the project page and the Module Family page.
| Question | Media Library Bulk Upload | Media Bulk Upload | Simple Media Bulk Upload |
|---|---|---|---|
| Best fit | Drupal CMS-aligned media workflows using Media Library. | Existing sites needing mature bulk upload configuration and broad adoption history. | Sites needing a simpler, lightweight bulk upload flow with post-upload editing. |
| Primary UX | Media overview / Media Library-oriented bulk upload. | Dedicated bulk upload workflow with configurable settings. | Bulk upload action followed by sequential edit forms. |
| Dependency approach | Relies on Drupal’s file upload mechanism and Media Library. | Offers DropzoneJS support for faster multi-file upload. | Depends on DropzoneJS. |
| Adoption signal | Selected for Drupal CMS media workflow. | Highest reported install count in this family. | Smaller install base but clear lightweight scope. |
| Collaboration opportunity | Shared roadmap discussion around inline editing, metadata handling, AI alt text, S3/Wasabi support, and duplicate detection. | ||
It should not shame contributors.
Proposal: Structured Similarity Review
Drupal.org should introduce an official concept of Module Families.This type of matrix would help users without forcing maintainers into a single project.And unlike many big challenges, this one feels very solvable.Contributed modules exist because people see needs, solve problems, share their work, and help others. That is the heart of open source.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 deeper issue is not just discoverability.
- 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?
Media bulk upload is only one example.Similar module families appear throughout the Drupal ecosystem.
Possible Badges and Signals
A Module Family would group projects that solve the same primary problem or occupy the same decision space.
- 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
The goal is healthier module discovery.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
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:For example, the Media Bulk Upload family could look something like this:That table already tells a more useful story than a basic module search result.It should be treated as Drupal.org helping users understand the ecosystem.It is duplicated effort.Calendars are a long-running example of Drupal’s power and complexity. The available options include:
- 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.
The Goal Is Not Fewer Modules
Unmanaged choice is expensive.Even a narrower topic like Olivero dark mode already shows this pattern:Choice is one of Drupal’s greatest strengths.We have Drupal CMS, Drupal AI, Recipes, and the upcoming Experience Builder all pushing Drupal toward a more approachable, modern, and ambitious future.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.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 if the design leads to confusion, duplicated maintenance, and unclear adoption signals, then maybe the design itself deserves a second look.This should not block new modules.For a new Drupal user, a site evaluator, or even an experienced builder working in an unfamiliar area, this creates unnecessary research work.
