[TYPO3-core] (New) TYPO3 CMS Vision

[Thomas Maroschik]

Hi,

due to lack of time I have to cite a mail I've recently written, but it 
fits the topic. I am and was always an advocate for integrating Flow 
into CMS. Mostly due to the fact that creating a unified ecosystem 
should be our most important goal. But now my vision shifted slightly to 
include the broader PHP world instead of only our own one.

Read on what I wrote:

CMS is to me currently an „over-feature-complete“ that struggles to move 
forward due to it’s legacy. Many concepts there aren’t used widely 
anymore and still have to be maintained for this one single customer 
somewhere. The ACs fear removing features because it could also mean a 
loss of customers. Personally I don’t fear that because new features 
will evolve faster out of a lean code base and this could attract either 
some new or existing customers again.

I recently talked about our CMS architecture and how Conway’s law 
applies to it: http://en.wikipedia.org/wiki/Conway's_law
In it’s roots it’s just a big ball of mud where everything depends on 
everything and this may be due to it’s roots in a single person building 
that. Then more and more people joined the project and had basically 
access to all parts at once. This means even if the architecture is 
virtually based upon extensions the interdependencies between system 
extensions are terrible due to the fact that everybody may speak to 
everybody. In order to reduce this for the future we try to build those 
CIGs that oversee some substantial part of the system and communication 
happens via those aggregated channels.

Looking at Flow Conway’s  law applies to it too. Although it’s a smaller 
mudball than CMS it’s structure reflects strongly the communication 
structure of the team that has grown around Robert and Karsten.

Further my experience from the TYPO3 camps and Developer Days is that 
the biggest part of our „Developers“ out there are rather integrators. 
And they have a hard time to follow the becoming more and more complex 
products. Many of them have never written a single line of PHP or used 
ever the CLI but are willing to contribute and use our products!

So after spending the last two years with thinking about our ecosystem 
and talking to all product teams and users I personally see complexity 
as our biggest issue in our ecosystem.

We have very complex products, complex solutions around them 
(Gridelements, Surf, Fluid), complex team structures, complex workflows 
(Forge, Wiki, Gerrit, Jira, SSO), complex communication (as identified 
in the OSS watch workshop), …

I’m rather unsure now if integrating Flow in CMS is a big benefit for 
those users mentioned above as it makes CMS again a bit more complex to 
understand. Do they care about whatever runs their stuff as long as it 
runs and has their desired output?

I think CMS success story began with extensions/components/packages. 
People that were generalists could compose their system from components 
built by specialists and connect them in a defined way. This was a great 
approach as it lead to plenty of extensions and people building webpages 
in days instead of months. An impressive return on invest.

Currently I have the feeling that we lost the momentum and our products 
become fatter and fatter. A solution to that situation would be to 
decompose the products and enable people to combine things again as they 
need it. It would also be beneficial in keeping our core domains in our 
products clean: extensibility, storage and editing interface.

This is why I’m currently rather working on integrating composer 
strongly in Flow and CMS. We had a meeting on the DDs where some people 
from the CMS and Flow team have been asked by me if we want to commit 
fully to a composer based ecosystem. You can compare that to a 
conference in 1866 in Bern where Germany, France, Switzerland and other 
European countries tried to align upon a common rail standard. The 
standard here is already adopted by large parts of the PHP ecosystem and 
if we commit we could integrate more and more components from this 
ecosystem as maybe in the mid future vice versa.

While this sounds great on the paper we may not forget our integrators 
which are not familiar with the  command line where you interface with 
composer. This lead me to the proposal of building a Web UI on top of 
composer and ship it as an easy package. That would reduce complexity in 
a way that all our products won’t need an extension manager anymore but 
will use that single package where substantial parts are maintained by 
the whole php community. It would be also an interesting product for the 
php ecosystem as well, as this thing could be a one click installer not 
only for our products.

Currently our TYPO3 ecosystem relies upon centralized structures. We 
have for extensions the TER, Forge, Mailinglists, Git and SVN hosting. 
Back then there was only sourceforge which was ugly and we wanted to 
give our ecosystem a "one stop shopping“ solution to build their 
extensions. But it’s hard to maintain stuff that is solely used by 
people which are unable to contribute to that platforms. Meanwhile
there are plenty of services which do a better job for those like 
Github, Bitbucket, private Gitlab and so on. Many extensions already 
don’t use the TER anymore for distribution and ask their users to 
download their current version from github.

Composer flips that around and is just a directory to a decentralized 
structure. In the end it let’s the contributors of the ecosystem choose 
their own tools that will be maintained by themselves. This is great, 
because it’s agile. If you see a chance to improve your process you can 
do it without the need to ask someone. This could in the end help us to 
reduce complexity again. We don’t need to maintain forge, gerrit and 
more stuff for our ecosystem anymore because we are connected to the php 
ecosystem which could evolve unlike us without such centralized structures.

After all I hope this step leads to the mentioned decomposition of our 
products because the demand from the php ecosystem will be there. We 
have some unique properties in the products other projects are eager to 
get and this could enable them to contribute to the decomposition process.

So my personal vision for TYPO3? An ecosystem of great people that build 
and maintain small, focussed solutions which are then composed 
creatively into distinct products. We’re not running a company, we’re 
running a marketplace!

Greetz,

Tom


-- 
Thomas Maroschik
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org