Why would a successful organization toss out an excellent open source web development platform that had an avid developer community? That’s the story I’m here to tell.
If eZ Systems isn't a name you’re familiar with, allow us to introduce ourselves: eZ is a commercial open source software vendor. We provide a content management system (CMS) and platform known as eZ Publish, which will soon be known as eZ Platform. eZ serves as a foundation for digital businesses, providing value-added solutions on top of our open source CMS platform.
Now that we’ve gotten the small talk out of the way, let’s get the ball rolling:
Around 2011, eZ decided to “re-platform.” But what does that mean?
It means rewriting the core of the software. Our goal was to change the way it works in order to improve it. Essentially, we had to look under the hood and strengthen our product before we even looked at improving the exterior.
Let me start by describing the situation at the time. In the spring of 2011, eZ Publish reached version 4.5. It was one of the last of a long series that started with the 3.x generation, each of which were all based on the same kernel, the same architecture, and the same code base that was originally introduced back in 2002.
At this point, eZ Publish was very stable. It was recognized for its strong extensibility, its core concepts, and its code quality. Compared to other PHP-based open source software, it had a much more “enterprise-ish” profile. The concepts were quite advanced and had a wide feature span with enterprise tendencies. It also had a great base for developers to build on by customizing and extending it.
Those capabilities were no doubt a key factor in the success of eZ Publish. The codebase, even if not perfect, showed great quality, which was still somehow unusual for PHP applications.
It offered developers plenty to work with: a fairly advanced extension system, a web framework, and a templating engine. eZ was definitely on the frontier of PHP-based web application platforms and frameworks.
Then we decided to re-platform.
Why? Because one of our first goals was to redevelop the core business logic—the content repository and its APIs—as the existing version was not an architecture that would allow for future scalability and cloud infrastructure needs.
Another of the main goals—fueled by the first goal—was to toss out our web framework (the templating engine, the controller, the extension system, the cache system, etc.) and to replace it with the Symfony framework full stack. Going full stack is quite different than using the Symfony framework partially, like some other systems, but that's another story.
Throwing away something that worked was crazy, don’t you think? It raised quite a few eyebrows back then, but time has passed and we're very happy with our decision.
Focus is the reason that comes first. Every company, especially product-based companies, have a lot to gain by focusing its activities on its core.
A web framework is fairly decoupled from a content management system. It's also a commodity, and there's nothing negative in being a commodity—very successful business are centered around commodity products.
There is no reason why you would want to develop both a web framework and a CMS at the same time when you can focus on the second—which is really our product.
eZ Publish 3 and 4 came in a period where there was no strong web framework, especially on the PHP stack, so we had historical reasons to do our own. But as Bob Dylan says, “The times they are changin’.” Ten years later, it’s not the same story!
So like Apple and Microsoft, who aren’t building the chips that are at the core of their computers; or like GM and BMW, who are not building their cars' tires, brakes, exhaust, or computers; or like Sony, Canon, Nikon, or Leica, who are not fabricating the captors of their digital cameras, we decided not to build the framework used by eZ Platform ourselves.
Cross-pollination between communities
There is a world outside of eZ. The eZ community is just one of the many communities out there. As a whole, we needed (and will always need) to be in touch with other communities—to bounce ideas, thoughts, innovations, experiences, and opinions off of each other.
To use a pompous word, this is about fostering the cross-pollination of ideas and projects across a diversity of people, organizations and applications.
By using a global and standardized framework, we make this possible. Companies like eZ are learning from other companies with different agendas, products, and business models. This transformation was about generating new ideas, new experiments, and accelerating outside-the-box thinking–especially outside of our eZ box.
To illustrate that, I recently went to a conference–the eZ and PHP summer camp–which is organized by some of our partners, Netgen, and others. There, I learned that some of our partners were combining eZ Publish with other components such as Sylius, an emerging e-Commerce solution based on Symfony, to build global solutions covering content management and e-commerce.
And this is only tip of the iceberg. By being on the most popular web framework, our customers can choose to easily integrate with many of the most popular e-commerce, PIM, and CRM systems.
Witnessing this kind of collaboration obviously reinforced our beliefs. This wouldn’t have happened in a closed and siloed world.
The third reason for moving to Symfony was about fostering contributions to eZ and beyond.
In the past, we had a lot of contributions of extensions to eZ Publish—projects.ez.no had more than 10,000 extensions available. It was, and still is, a truly great group of people sharing and contributing. And yet we had less contributions to eZ Publish itself and almost no contributions to the deeper parts of the framework layer itself, e.g. our own template engine library.
One explanation for that is probably that it doesn’t require the same skill set. The people who develop libraries are probably not the same ones who develop websites and applications.
Another possible explanation is that our framework was somehow deeply hidden into eZ and people had no incentive to go there. Of course, some community members would be able to contribute, and eventually they did, but for the average eZ Publish developer, it was clearly too complex.
By relying on a framework like Symfony, we encourage eZ developers to easily contribute at every level, including the framework. They can contribute to Symfony itself if they want, as it is an open source project with a strong community. Many contributors and a lot of resources make this easy. They can also build generic things (“Bundles”) for Symfony, which can be shared with the entire Symfony community.
And finally, we benefit from contributions to the core framework by people that have nothing to do with eZ, but share the same needs!
Making it easier to customize and extend
The most pragmatic of the reasons for adopting the Symfony full stack was about facilitating the way people customize and extend eZ.
Unlike many other content management systems, eZ has always been built as a platform and works hard to satisfy the need to extend and customize. You can never give a developer enough flexibility. Even if eZ Publish 4.x was doing a good job at that, we still wanted to take any opportunity to do an even better job.
We looked at Symfony a lot, first as somewhat of a competitor because we, too, were producing a framework and libraries. But year after year, we saw the Symfony project evolve into something extremely interesting that could bring a lot of value to our users.
To name a few things:
- Twig: The underlying template engine used by Symfony. Compared to our previous templating engine, Twig was a definite improvement in terms of usability and active maintainers.
- Composer: The package manager for PHP and a good companion of Symfony takes deployment of PHP applications to the next level. It is way more enterprise oriented.
- Doctrine: The database layer has a lot to offer to those extending eZ and accessing other data sets and other databases.
- YAML: The semantic configuration of Symfony brings a much more modern, comprehensible and efficient way to deal with settings and configuration.
- HTTP Cache: The native http “view” cache system (to which we contribute, as we use it extensively) comes with many more opportunities for developers to gain extreme performance using Varnish while still keeping their online content up to date.
- and many, many more.
That's why eZ tossed something perfectly capable and home brewed for something better.
Still think the move was crazy?
As time goes on, we hear again and again from “legacy” eZ developers in the community that were fanboys of the old eZ framework that they have finally embraced the change and love it. That’s the best thing for us to hear, as it strongly validates our choice.
At their root, the four reasons I’ve spelled out above all have the same idea:
Software is all about people
And the more open you are with them, the better. Technology is nothing without the people using it. By moving from a homebrewed framework to a standard one, we’re making it easier for a huge number of developers to get a chance to use our solutions. It’s a way to recognize that we’re not alone, and we won’t go far if we try to do it all by ourselves.
Open source is great, but if it sticks to the source code definition, it loses most of its power.
Open source is great because it connects people and helps them collaborate, despite them working on different topics, with different goals, different visions, and different skills.
We wanted to rely on a software infrastructure that was open source, which of course we did before Symfony, as all our inner components are open source. But most importantly, we wanted to rely on a software infrastructure that is used by many outside our own specific use case. This is done now!
This article is part of the The Open CMS column coordinated by Robin Muilwijk. Share your stories about working with open source content management systems (CMS) and platforms like Drupal, Joomla, Plone, WordPress, and more.