Thanks @robert for starting this discussion. You have my for more or less all your points. Bellow a short/unpolished resume from my POV
I’m fine with that as a goal, but it’s a bit too early to communicate on this point from my POV. DDD is hard (and we don’t do DDD in a really advanced way currently). If we decide to follow this path (and I think we should), we MUST include in the process guys like Mathias Verraes (http://verraes.net/), even if this cost us some money. As said before DDD is pretty hard, doing it well at application level is hard, but in an opinionated framework it MUST be done right from the ground.
I love Flow since the first day (maybe the second or the third), because of how useful it can be and improve the quality of the work in our team. Convention / Opinionated sounds good to me. If we can specialize Flow (like low level DDD support), i think we can have a market. But we currently lack a lots of ressource, so we need to work closely with Symfony, I remember a discussion with Fabien, that say that we can collaborate and maybe the next major version of Symfony can be adapted to support what we need. If we can have Flow 4 as a slim layer on top of Symfony that add the magic/useful layer that we like (AOP, Property Mapper, Fluid, …). For AOP we can collaborate with Alexander from GoAOP. If we move in the direction of a really open community, focused on building a framework a bit more opinionated and focused (DDD) that the others, we have a chance to gain more visibility and confidence from the market. Yes the first step will be very hard, but after this we can really focus on our vision, and stop maintaining the full stack alone.
For me, the framework is pretty cool now, but market wise to need to be more specialized on communicate more around key features. I don’t see a big opportunity to become the next hot framework, so we need the be aware resource wise.
Disclaimer, i spend 80% of my time between Flow and Neos project, if I can spend 110% of my time on Flow/Neos project before the end of the year, it’s pretty ok for me
- Decouple & Modularize
- More test / Less regression in the UI
- Major features (Media Browser, HTTP Redirect, Asset Meta Data Handling, …) need to be in one or more dedicated Package, and not required in a basic setup
- Less Page/Web centric as fast as possible
- Become an opensource contentful, prismic, … (mix deck), maybe we can do it like Mattermost, fully compatible with one the competitor API (don’t reinvent the wheel, check Contentful API, https://www.contentful.com/developers/docs/concepts/apis/), and extend to offer more in some area.
- Target: Pro tools, focus on agency that now how to setup a server go away from the shared hosting hell as fast we can.
- Open: Integrate more external service when possible (FilePreviews.io, Zapier, OData, …)
- Roadmap: Need to public, even if no date are define, but need to communication the next major feature, for the next versions (roadmap is not written in stone, things/priority can change)
- Communication: More, more, more … but that’s hard, and not my preferred hobby And from my POV the best things we can do for communication if working with other community and gaining visibility in the developper community (and it’s not communication but code, and we know how to code)
- Resist to the NIH syndrome (sometimes).