I postponed writing this post several times, because I wanted to come up with a well-prepared, well-written proposal for a product vision which could be a basis for further discussion. But I realized that it is probably better to come up with some sketchy notes which could trigger a discussion, rather than not discussing this topic in the team.
So, without further ado, here are some of my thoughts regarding the future of Flow and Neos. I won’t get very specific here, but rather would like to point out a few thoughts regarding the “how”.
I regained passion and motivation for pushing Flow again. In the past I said that we probably need to position Flow as “the framework which powers Neos and is also useful for standalone applications” due to the fact that there are already many frameworks with big communities out there. However, I do hear from many people, and see it from my own experience, that there is still a lot of beauty in the approach Flow takes. And that there are a couple of things which make Flow unique today.
Considering what I hear from the community and am passionate about myself, I think we should strengthen Flow and position it as the Domain-Driven Design framework for PHP. We could take all the experience we made together and work on Flow 4.0 which provides excellent support for Domain-Driven Design, CQRS, Event Sourcing and so on. During the last couple of weeks I have experimented a lot with Flow + CQRS + ES and I really see an opportunity there.
While CQRS + ES don’t actually need a framework to work, I think that we can take Flow’s approach of being an opinionated framework which guides its developers. By that approach we can possibly open the world of DDD to a larger group of developers who would feel lost or overwhelmed without the guidance. And for experienced developers, Flow will provide many convenient features which simplify day-to-day programming tasks and testing / debugging of DDD applications.
I think that the picture of a Content Mix Deck is still valid and a good (part of a) vision for Neos. We need to make this picture more concrete and also extend the meaning of content. While I have been working with Commands and Events, I realized how much more meaning you produce when you develop using these techniques. We can take advantage of this for Neos as well and produce meaningful content and events generated by Neos or external systems. Rather than regularly importing XML from some CRM system, we try to deal with events (customer John is not interested in canoes anymore) and use these semantics in Neos.
A new Content Repository, based on CQRS / ES, would provide many more possibilites than the current one. The whole publishing process and also the authoring experience (undo …) could be improved and provide features which are not possible with traditional approaches.
There are lots of ideas around about rewriting / refactoring / improving the UI technically. And not only there - we continue to come up with new libraries, techniques and so on. And that is a very good thing, because we want to keep innovating, so we need to make use of the best tools and practices. On the other hand, we have a growing community who trusts us to provide realistic upgrade paths and a product which can be hosted and maintained in their typical customer projects.
There is no simple answer for this compromise between conservative and bleeding edge. But it is a technical challenge which experience, professional developers and architects can master. If we agree on the direction (using innovate tools and techniques), we can also find a path which leads there. But we can’t just jump and hope to land at the right spot. In programming, you start encapsulating and decoupling code parts in order to be more flexible regarding internal changes. In DDD you define Domains, Subdomains and Bounded Contexts. And we can do the same with Neos. If we want to develop a new UI, we need to strengthen the service API in order to decouple the UI more from the server side (like the Calypso project for Wordpress did).
And we need to stay shippable and be able to progress while we refactor: if we decide to switch the JS framework for our UI, we can’t develop a new UI for a year and stop implementing new features in the meantime. Maybe we can introduce the new library in a single screen for the first release, then two modules in the next one. It shouldn’t become an all or nothing decision.
I think that we can continue introducing new technologies, but that comes with a price: we have to be even more careful and quality concerned if we want to keep juggling with all this new technology. And we must not forget that developers working on Neos customer projects are our users. They deserve a great Developer Experience. And that includes that they don’t have to learn everything new on every second Neos release. For customers like for developers, staying with Neos and Flow must be worth the invest - I don’t like Neos to become famous for difficult upgrade paths.
Regarding target groups: I think it is important to have big corporations / projects as our major target group. Smaller target groups will benefit from that, but only these bigger projects will enable us to develop the features we want and in the quality we expect. Personally, I’m not in for Neos as a pure hobby project, because I’d like to work on Neos during my work time - and for that we need enough customers we can attend to.
Oookay, I warned you - this won’t be the polished pamphlet …
I’ll try to condense it to a few key points for now:
- position Flow as a DDD framework, with its own website and major new features
- further decouple, modernize and clean up Neos, but with the clear objectives to (in that order)
- provide more value to the users
- keep existing Neos devs motivated and attract new good developers
- be able to proceed with new features faster
- continue to follow and make more concrete the vision of Neos as a content mix deck + authoring tool with the true meaning of content and the actual user in mind
Now shoot, I know you have a lot of ideas to contribute as well!
Oh and, I’m really looking forward to putting all that (and what you guys come up with) into practice. Because, FUN!