I’ve also faced similar challenges while working with MagicMirror modules and exploring different GitHub repositories.
From my perspective, the biggest issue is not the lack of good code, but the lack of consistency in how repositories are maintained and evolved over time. Many modules are actually very well-built, but as updates to MagicMirror happen, maintainers either abandon older repos or create new ones (like v2, v3, etc.) instead of maintaining continuity. This creates fragmentation and makes it difficult for users—especially new ones—to identify which repository is stable, active, or recommended.
I completely agree that GitHub already provides solid solutions for this:
Releases & Version Tagging: Instead of creating new repos, maintainers can tag releases based on MagicMirror versions. This keeps history intact and avoids confusion.
Branching Strategy: Having a main branch and version-specific branches (e.g., mm-2.25, mm-2.26) can help manage compatibility without duplicating repositories.
Changelogs & Documentation: Even a simple CHANGELOG _md can drastically improve usability for others.
Another point I’ve noticed is around forks. Many contributors fork a repository, add useful features, but never push those improvements back via PRs. Over time, this leads to multiple “almost similar” versions floating around. I think part of the problem is awareness—many hobby developers may not be fully comfortable with Git workflows like rebasing, syncing forks, or creating clean pull requests.
Maybe as a community, we can improve this by:
Creating a basic GitHub workflow guide specifically for MagicMirror module developers
Encouraging maintainers to actively review forks and invite contributors to submit PRs
Defining some community best practices, like:
Avoid creating new repos unless absolutely necessary
Use releases instead of renaming projects
Add clear README notes about compatibility and maintenance status
Also, from a practical standpoint, I think maintainers don’t always have the time to manage contributions or support users—which is completely understandable. In such cases, maybe adding co-maintainers or clearly marking a project as “seeking contributors” could help keep things alive.