Hello Mautic Team,
I see that a detailed version roadmap is already defined but it doesn’t show which new features (those not available in previous versions) are planned for upcoming releases. Bug fixes don’t need to be included but knowing which new features are already in progress would help community developers avoid duplicating work and better align their contributions with the project’s direction.
Thanks for considering and for all the work you do!
Hi there,
This was actually something that we discussed in the most recent council meeting, so we’re very much on the same page that it would be helpful if we could forward-plan with more clarity.
We have already been quite clear in terms of Symfony and PHP/MySQL version support and when our releases will be made for those, but it’s quite challenging to make a roadmap for all features, because more often than not things are contributed as PRs by organisations and they land when they get merged.
Mautic doesn’t always know when those organisations are going to contribute those things - and in the past we tried to make a roadmap based on what they told us they would contribute (reaching out to all our partners and asking what features they were planning to release to community and when over the next 18 months) and it became totally invalid within a single quarter because their client commitments changed with new client signings which meant that their roadmaps shifted, and things weren’t contributed when expected, or at all, in some cases.
Even work that we agree to be delivered in a particular version of Mautic doesn’t always make the cut in time, especially if there’s multiple dependencies which need to be addressed, unblocked and merged before it can be merged (automated A/B test selection being one that’s been punted forward release after release since Mautic 4 for this reason).
We’re working on trying to find a better way to do this, perhaps it’s something you’d like to be involved with?
Here’s our current process:
Hello rcheesley,
I really appreciate the openness in how you’ve described the complexities involved in managing new feature requests. It’s clear that balancing priorities, resources, and community expectations isn’t straightforward, and I think being transparent about the process really helps everyone understand the bigger picture.
I also like that feature requests can surface in different ways, through the forum, the new ideas portal, and even through discussions on Slack. Each space has its own strengths: the forum is great for more freeform brainstorming and community input, while the portal provides a structured way of collecting and organising ideas so they don’t get lost. Having the team move promising requests from the forum into the portal feels like a very sensible approach that combines the best of both worlds.
Another point I value is that even if contributors propose new features but don’t have the time or ability to progress them, the ideas don’t just disappear. Instead, they remain visible so that others in the community who find them useful can take up the challenge and move them forward. That’s a great example of how open-source collaboration works in practice, shared ideas can live beyond the initial contributor and spark momentum from others.
Overall, thank you for taking the time to publish and explain the current process. It’s really appreciated and it reinforces the openness of the project and the strength of the community behind it. My suggestion would be to keep encouraging community members to use the portal as a central point for tracking ideas once they’ve been discussed elsewhere as this will make it easier for others to discover, support and potentially take on the features that matter most to them.
Thanks for considering and for all the work you do!