The agitation created with the WordPress 5.0 roadmap is exactly what we want to avoid

Change is hard, and no matter what some people say, no one likes unsolicited change.

But change is also a fact of life. You will never grow and improve if you just blindly reject change.

The question is always about the balance which you need to keep between investing in change while still staying sufficiently safely in your comfort zone, and how you facilitate change.

We think that the roadmap for WordPress 5.0 is a great example of how to not facilitate change and a total antithesis to what we believe in.

You should read the roadmap first if you are not familiar with it. It is important for context that while everybody was aware that there will be a 5.0 release at some point, but too many promised deadlines that had passed left everybody wandering when will that happen.

One day out of the blue there is an announcement that version 5.0 will be ready for production (RC milestone) in less than 4 weeks, it will not include feature that were already worked on trunk (and people might have expected them to be in 5.0), but will include updates to all core themes, and a new theme that no one ever talked about before.

Time to General Availability from announcement? about six weeks.

People complain about dates coinciding with busy holiday and shopping season in the US, and while it is true (as core contributor pointed out) that it is always a holiday or shopping rush somewhere in the world, the real issue is that a two months time is relatively short and people might have already made commitments for that period of time and they just do not have the available time to invest into checking their software’s compatibility with the new version and produce fixes if needed.

And it gets even worse, because in case it will be needed, the time to GA might end up being four months in the future instead of the promised two. No one can realistically plan anything based on such a fuzzy schedule.

In calmPress we simply reject this kind of planning. For us it is not the issue of the kind of change (yes, I personally hate gutenberg as much as the other 50% of WordPress users do), but the realization that users should be provided with as many tools as possible to both prepare for a change, and postpone it until they can make the time to deal with it.

We do expect a relatively fast release cycles while we are working on transforming a vision into actual code, but the ultimate goal is to have a slow release cycle, maybe even as slow as having no more than one major release a year like PHP itself has. We know that people become nervous and agitated when they need to confront a change, especially if they are not very technical, and we want to keep them as calm as possible and let them focus on content creation and not on site maintenance.