[TYPO3-mvc] TYPO3-Core complete rebuild to realize modern development paradigms?

[Gabriel Kaufmann | Typoworx]

Hello Felix,

thanks for your answer. Please note that even cricitcs are welcome to 
me. With the current reply I try to answer your statments on my last post.

> I don't really get that bashing. Feel free to fire up some pi1 class 
> and write some good old typo3db->exec_SELECTquery(), what's the 
> problem? I mean ... even just put a .php in your fileadmin and wrap up 
> some USER_INT typoscript. There's no gun to your head ... 
The Pi-Base way is not very modern anymore. As we are also trying to 
focus on modern programming paradigms, the old classic PI can't be a 
solution for the next years to deliver modern, flexible and time-/cost 
effective development (compared to other modern frameworks).

> Developing this way takes a lot more time and budget than calculated 
> on basis of our current project experiences. 
Well in our experience it is like i stated before. Either you are trying 
to go the Pi-Base way and that way you can't efficiently focus on modern 
paradigms. Or you are giving a try to Extbase which is published as 
"Stable", and then month later reading books and trying to practice, you 
will note that in fact it does not "feel" like production ready and 
stable yet.

May be the only compromise would be to use own classes without piBase. 
But even that would lead in something you have to build your own libs 
that don't lead in a community-like solution that has a more common and 
standardised character (just think about the bunch of 
developer-custom-libs you have to install separately using TER to get up 
one plugin you like to use... I hate that).

To shortly anser your state (now that I've drifted off a bit), I can't 
agree your statement that these complexities on piBase and Extbase don't 
harm your customers projects and time-/cost factor. We noticed that with 
Extbase in some productive customer projects (that were some more 
complex than listing some records out of any common table). Developing 
some more complex solutions on basis of TYPO3 is not very profitable 
anymore as you have to invest more and more time without having less 
money in the end. I know you will blame that argument "money" as others 
still did, but more money means more time and more money to profit in 
the community (either paid or by doing bugtracking/work for the 
community). Or do you really think there would be any sponsoring 
companies without having money earned with TYPO3 and having profit of it?

Regarding your proposal to use exec_SELECTquery... even in Extbase you 
can't miss it woking around some bugs or non-working things. And I like 
mySQL!
But have a look on Doctrine (http://www.doctrine-project.org/) and then 
tell me you still want to work that way if you can get it better. I 
don't wholy criticise extbase itself. But the database-mapper and fluid 
templating are not really production ready and should have been 
delivered optionally through TER.


> PS:
> We have currently a look on TYPO3 Catharsis (a TYPO3 6.x fork; 
> https://github.com/lolli42/TYPO3.CMS-Catharsis) and get in touch with 
> the fork-developers team. 
Good to know... as I didn't get in touch with Christian yet, I think we 
have to do it on our own then.


>> If anything fails and we can't find a consense with them - we are 
>> thinking about our own roadmap for a additional TYPO3 tree
>
> I really really don't mean that personal, just a quick thinking:
>
> If you are not able to deal with the bugs, current core is giving you, 
> how are you going to build up on your own one? I mean, your fork will 
> be a copy of the current core, so you will have exactly the same bugs.

I did never say I can't deal with bugs. I am very active in posting bugs 
or missing features either on Extension-Bugtrackers or the TYPO3-Core. I 
also spent some time in fixing bugs - even in core, because I don't like 
local patching and of course I prever to share those fixes to have them 
in the official release. In fact most of your bugs are later then 
supported with a patch by us.

> You will have to fix them AND THEN develop your own stuff ... so you 
> probably could just fix the bugs in the current core in the first place. 
Of course you are right. I was trying that very often, but sometimes 
those bugfixes have not been noticed, not been accepted or were 
rejected. Even sometimes I thought I was the first sending in a Bugfix 
and then noticed that any one else did and sent in a patch.

But if you then notice that bugtracks even providing a working patch are 
rejected or left unnoticed you feel like spending time to the wrong 
thing. It's useless doing patches if they're left undone and ignored by 
the community then. And there are some bugtracks older than 12 month and 
the bug still exist, even if there is a patch provided (by us or other 
users we noticed). Not fixing those bugs we are trapping more and more 
in  problems realising our projects - most times for banal problems, 
that are going to make as stuck in our work. So we have to fix them 
anyway and if they're not accepted by the community/core-team, then we 
also can run our own fork and do it there.

And the second reason is, that me and my programmer team have some ideas 
(keep modern programming in mind) to improve TYPO3. I know that some of 
those ideas are not able to be realised on TYPO3 4.x and 6.x tree and 
partly I understand that core-developers are rejecting them to go their 
plans.

But there is no plan to have a middle-solution between TYPo3 6.x doing 
not such a clean-up and improvement that would be hardly needed to arm 
TYPO3 to be present and modern enough to stay interesting for companies 
and larger projects in the next few years. As TYPo3 6.x has only support 
for some extensions I earlier expected PiBase and some other things to 
be dropped. In fact I sadly noticed it was not.

And... to be gently, but realistic... TYPO3 NEOS is nice... but it is 
still alpha and you really can't compare the "known TYPO3" feature-set 
with that yet. Our customers mostly ask explicit for TYPO3-CMS... but we 
can't fob them with something like NEOS and tell them it's still TYPO3. 
And of course we can't wait 2-3 years to be NEOS ready...may be...for 
production /customers projects.


Have a look on google.... more and more users and developers are 
resigning because of that behaviour of the community or the way Extbase 
is bundled/developed and integrated into the Core. Even in other 
communities like Zend-Framework or Symphony the term "TYPO3 Community" 
is well known as negative outcome for a broken/non-working/non-optimal 
condition for something.


I still feel like a TYPO3-Community supported and I still want to keep 
working with and on basis of TYPO3. But the current progress of 
developing and the less positive experiences in Core-Bugtrackers lead to 
a clear solution... we have to fork on our own if there are no other 
plans in the TYPO3 Team to have a "missing-link" TYPO3 between the 
current ones. Else we would have to completly drop TYPO3 that is not one 
of our current plans.

I think in worst case at the latest the TYPO3 team will note that 
something has went wrong if the user-loss on the community and 
developers dropping TYPO3 will grow. May be even platinum sponsors will 
note that any time and leave the TYPO3 community. Then it's too late to 
start some plans against that.

Best regards

Gabriel Kaufmann