[TYPO3-core] (New) TYPO3 CMS Vision
tmaroschik at dfau.de
Mon Aug 18 10:05:49 CEST 2014
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!
TYPO3 CMS Active Contributor
TYPO3 .... inspiring people to share!
Get involved: typo3.org
More information about the TYPO3-team-core