💡 Info: This post is from 2020. You can find the up to date roadmap here.
You may have noticed that we've recently updated our public roadmap. In this article, I'm going to explain the reasons behind this "unexpected" update. Running a public roadmap is full of challenges, some of them were impossible to tackle, it was time for changes!
The main goal of having a public roadmap is to give as much visibility as possible to digital agencies, freelancers, free users, or customers. We truly wanted to share our internal planning for features development but we hit some roadblocks.
As an open-source project, a lot of bugs are fixed on a daily basis. Thanks to the amazing contributions we receive, there are issues that are fixed quicker than expected. Sometimes we also work on the same functionalities which are simultaneously being developed by a community member. Not very productive. We have to admit that, there is room for improvement in the way we collaborate with the Strapi community and ecosystem. Until we have completed the UX research and feature scoping, we cannot give a precise date and guarantee that a feature will be delivered on time.
In the last 12 months, we have done a decent job at shipping most of the features on time, but the community deserves a more accurate and tangible roadmap. Recently, the team grew and the way we were managing the roadmap was incompatible with our new work organization and the community's contributions.
The launch of the Enterprise Edition was the last missing proof that the way we've managed the roadmap in the wrong way. As the roadmap is public, we are accountable for what we put in it. We cannot move a feature from a quarter to another without giving explanations. We know that a lot of you respond to requests for proposals, or have roadmaps which depend on ours.
As a reminder, the Enterprise Edition shares the same codebase as the Community Edition one without the limitations. Currently, the only difference between both is the number of roles and the granularity in their customization capabilities. We are trying to understand how the users and enterprises use Strapi to define a boundary between both. Nothing is written in the stone and we are open to suggestions to make the best decision.
To improve the way we communicate about the future roadmap changes, we decided to rethink our strategy from scratch. We want to create and define a roadmap that you trust just as much as we trust it. One of the misconceptions about roadmaps is that we can predict everything. The future is, will stay always uncertain. Our goal is to share with you an honest roadmap.
Source: https://twitter.com/PavelASamsonov/status/1296818042928861184?s=20
Our first decision made was to postpone the features by 3 months. To be 100% transparent, we expect to release some of them in advance but we prefer to ship earlier than later.
Then, we decided to simplify the overall roadmap, we've started to create categories such as "Maybe in 2021..." to tell you that you shouldn't count on us to release the feature on time. It was our way to say: "It's not the priority, we lack resources, we are not ready.." The roadmap only contains features that we are working on and which are truly in our backlog.
We also wanted to include the technical roadmap within the public roadmap. Most of the features are delayed for technical reasons. For instance, the Internationalization hugely depends on our ability to ship the new Database Layer Refresh and Plugin API on time. These topics are massive and hard to scope. By doing so, we expect to increase the visibility and the "why" behind each feature.
Last but not least, we upgraded our productboard plan to enable more features to be able to collect more insights from you. It will also let us reorganize in a brand new way, introduce naming conventions, and identify what are your expectations.
These are the first steps of an iterative process designed to help you build successful projects and businesses with Strapi. There are more to come. For instance, we plan to improve and open our development workflow to work closely with you (the community) or introduce a long-term support strategy.
Co-founder & Chief Product Officer, I started developing since I was 13 years old, I already developed 2 CMS before and am currently in charge of the product vision & strategy.