Dear members of the development team, CU a few days ago I commented the announcement, that Neos and Flow get rid of "TYPO3" as part of their names, as follows:
Removing "TYPO3" from Neos and Flow makes it easier to quietly abandon these products. \o/
Additionally to this tweet I had a small twitter conversation resulting in this tweet:
@daskitsunet @dfeyer @zdavis I am really in favor of seeing Neos as an experiment. Start over with a worldwide accepted/documented framework
Later this day in the afternoon Christian Müller asked me on Slack where this resentment comes from and I told him that there is none because everything I say in favor of or against any product of the TYPO3 family is not in favor or against persons but decisions and failures. I am pretty much aware of the possible impact of negative comments for the moral of development teams, though. Unfortunately it's not easy to do the splits here and additionally to that fact, twitter is based on written words w/o facial expression, and mostly w/o an historical context as well. So, the meaning of tweets mostly aren't dependent on the author's real meaning, but the recipients understanding. That's the main flaw of written communication but that's the way it is. So each and everyone should avoid taking written words too emotional.
Having that said and as you are currently reading written words as well, this mentioned rule of thumb applies for this text as well. Feel free to get in contact with me if you like to have a discussion.
Let me continue with the conversation between me and Christian because we shortly talked about the essence of my tweets, seeing Neos and an experiment and start over with a worldwide accepted framework. Let me explain, why.
The tweet itself mostly explains why, because Neos and Flow are pretty much undocumented or their documentation state wrong information meanwhile and because the framework is absolutely not accepted. If you have a look at google trends and compare TYPO3 Flow to symfony2, cakePHP, laravel and many more, you see several different facts. See Google Trends:
- The search volume of Flow is limited to Germany. That means, that there are not enough search requests for Flow outside of Germany although its documentation is really bad.
- The search volume of Laravel is incredible. Knowing that it's documentation is up to date and awesome, the search volume impresses even more.
- Even CodeIgniter still finds a decent interest in this world despite that fact that it's really outdated.
I don't find it hard to explain this data to myself as I did projects with CodeIgniter, CakePHP, Ruby on Rails and Flow and it was really easy to develop with all of them, except Flow. Because, whenever I found myself struggling with the concept of a framework, I had a look at the documentation and I could continue my actual work. Whenever I worked with Flow I didn't have any documentation, well, despite the blog example, so I had to debug with xdebug, which gave me the creeps and then, when I understood the concept, hidden in the magic of some proxy class stuff, I often stubled upon bugs in the framework itself. And that's the moment you ask yourself what the actual purpose of a framework was. Making your life easier, getting things done more quickly. But all the time the opposite of that happened which may not be life threatening if you are employed but really can make your whole business fail if you are not into each and every implementation detail of the framework yourself before calculating the workload for a client.
Let me emphasize that I really don't have that much to say against the concepts of Flow and Neos. There are plenty of frameworks in the wild, so it's pretty easy to compare Flow to them and see that most stuff doesn't really differ. For example when it comes to MVC. The pattern is well known, even amongst PHP developers, so I can't say Flow does a bad job here. It's the same for Neos. The content repository approach for unstructured content data is not even new. The java world knows it for years now and even symfony started their CMF with a CR approach. Actually Neos was a pretty early adopter of this idea and I believe it's what content management should look like nowadays and in the future.
So, what a struggle with is the technical implementation of many concepts in Flow and Neos which I'd blame, along with the missing documentation, for the small acceptance in the world. I will not go into detail here – I'll cover that later – but I see huge flaws that do harm the whole system more than bring advantages. To name the elephant in the room. It's the messed up AOP proxy classing concept that nobody wants to work with unless his language of choice is java anyway, and he/she has the right tools for it. As I mentioned above, the debugging is really a pain in the ass. So, if proxy classing is the key feature of a framework to bring well, everything, from DI, over a lot of configuration, to the whole AOP implementation, then, it should better be bullet proof. I remember working with Flow in the end of 2013, finding a severe php class inheritance bug. I could only solve this issue with a lot of time and coffee, xdebug and the help of Christian Müller. This can easily be a major financial harm.
The next problem of a low acceptance of Flow and therefore a low contrbution is the fact, that Flow is not a framework build for the masses, but for Neos. It's just a guess but what is the key case for choosing a framework? Implementing REST-API's! To this day Flow and Neos do not rely on a proper HTTP implementation. There wasn't a need to properly imlement PUT requests for example because there was no need of Neos and no need in actual real life projects. I just used this example to demonstrate the main issues of Flow. Everything works perfectly according to Neos' needs, not to RFCs', resulting in a piece of software that can do a lot but is often not usuable due to missing implemented details.
Additionally to this flaw, Neos is completely build on top of the very unique concepts of Flow. There's no possiblity to port dedicated packages to symfony e.g. because these packages are tightly bound to Flow. It's not just changing a yaml configuration file, it's removing and replacing all annotations. Do you see what you did? You build not just one monolith, it's two, depending on each another. So, if Flow fails, Neos fails as well. That's a mess because if that happens, all of your precious time, that went into the good concepts, is simply lost. The fact alone that Fluid isn't available as a standalone version – well, Claus Due just came up with that –, shows the problems you created in your ecosystem. While the whole PHP world gets more open through composer, PSR's and the senseful decoupling of software, you did exactly the opposite.
Well, this post is not to blame you personally, I said that before. Instead I need to emphasize that in the current situation, blaming people is wrong in general. Over the years a lot of money has been spent, and a lot of time has been used for R&D. That's ok, because that's what you were told to do. Noone managed the process of creating a whole new CMS. You can see this by the fact that the community was surpised by getting a framework first, complaining about you guys and cutting you off the money flow. [UPDATE] There was a 50% cut of the budget application by the TYPO3 Association, a decision, influenced by the community. http://typo3.org/news/article/neos-and-flow-team-waive-typo3-association-budget/ Sure, people blindly put all their money and trust in you. That might be the biggest problem, the lack of control. But that lies in the past. And although we should learn from it, we should not be controlled by it. Yes, people wanted to see Neos 1.0 finally to be released and you did, which caused a lot of disappointment due to missing features. It's really weird, actually. But now, the effect of suprise is gone. Neos slowly follows the release cycle, people get used to bugs or don't use Neos at all. Some still do wait, some left the TYPO3 ecosystem at all, most stick to CMS.
This current situation is a tragedy and as you try to get more contributors, you loose trust because you can't deliver in time. As you loose trust, you loose possible contributors. Well, who wants to ride a possibly dead horse? It's a vicious circle you will most likely not escape. The community wants you to deliver, to make promises and reminds you of all the money you already got but what can you do? Nothing, you need to be relieved. That's why I am so much in favor of seeing Neos as an experiment, stop the development, use an accepted framework and start over, and not just you, but everybody in the community. Mix up the core teams, be more open and let fresh wind blow.
I don't expect anybody of you to follow my view of things. I just needed to explain why I personally see Flow and Neos as a failure and why that results in tweets like the one mentioned above. I am even very impressed you kept up the faith so long and still do. Don't let my words put pressure on you, but relieve you instead.
So, whatever you do, rock on!
I would have been so happy if Neos had been based on an existing framework like Symfony or Laravel, or that the coupling between Flow and Neos would have been less tight. In an existing software landscape of a company, it is very hard to argue for yet another new framework that your devs have to learn and stay up-to-date with.
And as the developers of Flow and Neos, why would you want to put yourself in a situation where you have to build and maintain two monster projects, a CMS and a new application framework? If you're at it , you might just add your own ORM, MySQL fork and custom HVVM. I think it's madness, and either underestimates the effort of the task or the capabilities (time-wise, not competence) of the developers.
Somehow I can't shake the feeling that the devs really wanted to do "their own thing".
Would it be too late to re-evaluate the current framework landscape and think about switching to something established and well-documented?