Almost 2 months after the announcement that Acquia is acquiring Mautic, the community Mautic remains waiting for the announcements planned within 90 days, which should provide a bit more clarity on how things will work going forward under the company.
This major change for the community is an immense opportunity to benefit from the experience of Acquia with Drupal and to redefine certain rules. As one of the main contributors to this community, let’s share a few lines of work stemming from our thoughts and discussions with other community members, with the goal of making its management more effective.
1. Governance rules—let’s make them clearer
Acquia acquired the Mautic company as well as the brand and, as a result, the community itself, since it carries the same name. Even though we are free to join or leave this community whenever we like, if you want to invest in it, it will be under Acquia’s management.
However, everyone should feel comfortable with that! They paid for it, and there’s nothing wrong as long as it’s well clear to everyone. That’s my first point and probably not the most complicated to manage! Simply write clear governance rules about who owns what and who manages what. With that, no unpleasant surprises are possible. In this regard, it leads us to the next two topics: some suggestions for community management to bring more comfort and better working methods.
2. Appoint a Community Manager
I’ve been working with the Mautic community for almost 4 years (since its beginnings), and I’ve been lucky enough to see it grow incredibly fast. I’ve also noticed that some people have taken on more and more responsibilities (such as managing and providing releases, for example), whereas not so long ago, everything rested on the shoulders of DB Hurley (the founder of Mautic). Unfortunately, things are a bit disorganized today.
As much as the Mautic community, it needs an excellent manager, a person completely dedicated to this task ; to help people, keep a schedule and roadmap up to date, delegate responsibilities, etc. To illustrate this idea, I’ll talk here about technical contributions to the community, but I’m convinced this model can be applied to any other topic Acquia may choose to delegate to the community (marketing, blog, functional definition, etc.).
Let me share an example: the way Symfony works (the PhP framework used by Mautic and… Drupal). Indeed, any new technical contributor (developer) excited by the idea of joining and contributing to the open-source Symfony project would need to contact Nicolas Grekas. Nicolas has a crucial role, and he carries it out exceptionally well: he will share a list of “easy” bugs to handle as a first contribution. He also grants him the time needed to review the code, help out, and answer the questions the contributor might have. This “first-step-in process” is tremendously effective for growing the group of contributors while ensuring they are well integrated. After a little experience, the contributor will become autonomous enough to tackle more complex topics.
As I mentioned, I think this manager/point-of-contact model is applicable to many other topics. But regarding the technical aspects, I think someone like DB Hurley himself, who put so much energy into bringing this community to life, would be the perfect person. We can also think of other people who have always served the community members and have an astounding number of contributions to the project, Alan Hartless and Jan Linhart.
3. Committees for roadmaps: technical and functional
This is a delicate subject and a major expectation from the community. Some roadmaps have been communicated in the past, but I believe the community hasn’t been included enough in their creation for them to become a success.
That’s why I would suggest creating 2 committees for the product roadmap (roadmaps can also be applied to other topics), one dealing with the technical aspects (PhP, Symfony updates and dependencies, the goal of setting up a microservices architecture, etc.) and another dealing with the functional aspects. These committees will need to ensure the strategy and direction chosen for the project are followed while also incorporating community expectations. In this approach, a voting system for features would be very useful for identifying users’ real needs. I also think that implementing GitHub Sponsors would be an excellent way to motivate developers to join the community and contribute to this great project.
These roadmaps will give users and marketers visibility. They would also be an excellent source of content for communication around Mautic in the marketing automation market. Finally, it’s the best way to bring an ever-growing number of members together for the community.
That’s it for these lines of work. As always, Webmecanik would be proud to take part in these new ideas and initiatives that will make the Mautic community even better and more effective.
