Mautic 3 is dead, long live Mautic 3!

The good news is that after 18 months of a complete lack of movement, now Mautic 3 is alive again and kicking strong. Work started around the first week of October, right about the First Mautic Community Summit.

A new Mautic 3 concept is born, Microservices might need to wait for some time, probably a loooong time...

But it’s not all sunshine and roses. Winter is coming!

I’ve been writing about Mautic 3 since it was first announced, in May 2018, I also wrote about it 9 months after the announcement, and of course again after the Acquisition of Mautic by Acquia, and now that some 9 more months have passed it looks like a great time to review the topic one last time.

So now that the Mautic 3 project has completely changed, I guess I owe a new post for anyone who dedicated any time to read my previous M3 posts, a continuation on the topic…

Why then the “Mautic 3 is dead” headline?

Well, If you remember the discussions and team-building efforts that we had over that year and a half, Mautic 3 was going to be a complete rewrite of the Mautic code with the objective to convert Mautic into an ultra-modern, microservice-based, headless-serverless application. A wonderful view of what Mautic 3 would become.
The bad news is all these wonderful ideas have either been lost or indefinitely postponed…

What Mautic 3 is, as of today, is nothing more, and nothing less than a migration from Symphony 2.x to Symfony 3.x, mainly due to the 2.X version phasing out of any support. Acquia’s clients are pushing to get this huge problem solved and so it is getting solved.

If Mautic is ever to become a series of microservices, it will be in Mautic 4 or whatever it’s called, if it ever happens…

Hence it would appear the original idea of how Mautic 3, the original vision by DB Hurley, is not going to make it to the third version of Mautic. Hence, the original concept of Mautic 3 is now officially dead.

Truth to be told, the idea never took off, at least not within the community, and that’s why the project got stalled for 18 months.

Long live Mautic 3!

However, a new Mautic 3 is born, one that is actively and vigorously being developed as a community effort, but strongly backed by Aquia’s developers and engineers, and when I say “strongly backed” I mean they are really doing most (if not all) of the heavy lifting.

I know, Aquia needs it done so it is only fair they put the effort in.
I know, you and I maybe don’t give a brick which version of the underlying framework is used, however, we will all enjoy the benefits down the road and it’s only fair to acknowledge the huge amount of work by all the volunteers and especially by Acquia.

It also needs to be stated, upgrading the Symfony version is a great move towards an eventual conversion to microservices, so maybe I’m wrong and it will happen in a relatively short period of time. While a daunting project, I am certain we would all enjoy the results.
This migration is a good thing and a necessary improvement that needed doing sooner rather than later.

All that said, you know I rarely start one of my opinion posts if I don’t have something to complain about, it’s just how I roll, so here it goes:
While the migration in itself is a good thing, the timing and the order in which the development is taking place is wicked and it will all converge in a huge disaster of epic and disastrous proportions…

Winter is coming!

Yes, it is December already, but that’s not what I meant.
3 storms are converging over the Mautic community right now, 3 storms which each hold the potential to heavily disrupt the Mautic community on their own, nothing new here, we’re used to these already, the problem is the timing and the order.
One at a time, these 3 storms would have brought problems, like they always do, and we would have solved these like we always do, but some genius decided that wasn’t fun enough.

Let’s see how bad can we make things… Let’s allow these 3 storms to mix together and become a hurricane, why not, those guys in the community must be bored anyways…

Storm 1: Mautic 2.16.0 is the most convoluted milestone ever, with 288 PRs waiting to be merged as of today, the quantity of PRs waiting to be merged is twice as large as the second-largest milestone in Mautic history, which means the 2.16.x series is probably going to be among the buggiest and most dangerous releases we’ve ever seen.

Storm 2: The Symfony migration is undoubtedly good news, however, it will also bring chaos everywhere. Lucky for everyone, it’s being managed by the Acquia team, which is known to produce extremely solid code, however, the intrinsic importance of the changes, which go down to the very core of Mautic, makes me think, there will be issues, lots of them, no matter how good the refactored code is.

Storm 3: We’re making our own code obsolete. 288 PR’s written volunteers and Mautic users all over the world, they wrote it for Mautic 2, and most of it might not work with Mautic 3. And this is the big deal, the heart of the problem.
The ideal solution would have been to first merge all the PRs, then migrate Symfony and finally take care of refactoring anything else, but this is not how it is happening. Strong pressure from the leadership to get Mautic 3 (aka the Symfony migration) completed immediately, with total disregard for the consequences for the community, has forced the teams to leave all the PRs in the 2.16.0 Milestone in a bad place, indefinitely postponed until the migration has been completed. Because all these PRs were created for Mautic 2.x and Symfony 2.x, a great deal of that code will never work with the new version.

To round everything up, nor Acquia nor the community leadership hasn’t yet given any clues of how the merging of all that code will take place, who will be in charge, will it be left to the PR owner to fix his or her code?

Nobody knows what the next Mautic version will be named after, will we just have one unique new Mautic release and incorporate all the PR’s to it or will we have 2 parallel versions of Mautic, one based on Symfony 2.x and another based on Symfony 3.x?

The end result: Pain for the Community.

Again we hit the historic wall of poor communication (or no communication at all) from the community leadership, again newcomers will suffer, a lot, with the resulting code, especially if no warnings are issued about the unstable nature of the code, and because this has been the standard since day one, I doubt they will do it differently this time and whatever comes out will be classified as “stable” and no warnings will be issued.

This time it’s going to be worse than ever before, more abandonments than ever among newcomers. As for the few long-term-mauticians, which already know how all this works, I foresee really poor adoption of whatever comes after the refactoring, I know for a fact I will stay away from it for as long as I can.

I wonder if the community leadership does give a freak about all the 288 pending PRs. After the migration is completed, will they also help migrate all this code or will they abandon it and force the PR creators to migrate it on their own?
The best-case scenario is a slow and painful migration of all the new code, the worst-case scenario is a huge chunk of all that code is going to be lost forever.

And there it goes, another huge nail on the Mautic stability coffin.
The saddest part of it all, most of this pain and damage to the Mautic reputation could have been avoided, by simply planning ahead (we had 18 months to think about it) and doing things in the right order.