In early 2009, it just so happened that I became a full-time Contao developer. It didn't take long for an email to arrive saying: Can you devlop a shop module for Contao?

Of course I could have done that. But why reinvent the wheel? I knew that something was being worked on in Germany. And I had heard from a team that was building a solution in the US. So I wrote to both of them. My customer needs a shop, can I use your module for it?

The answer from Germany:
It's coming in X months, you'll have to wait.
But that schedule didn't suit my customer.

The answer from the US:
Sure thing, here is some code, see if you like it.
And how I liked it!

Thus I became co-developer of a shop extension for Contao, invented by Fred Bliss and Blair Winans. It was triggered by frustration with external ecommerce solutions. The name Isotope eCommerce was already there.

What originally began in an SVN repository was made available to the general public in May 2010. You can view version 0.1.0 on GitHub; Isotope "started" with 239 files and around 40,000 lines of code. https://github.com/isotope/core/commit/cbcc72d57b9a5c4191dd2dcb3d1fad534660ab5d

If you understand Contao code and have used Isotope before, you will recognize familiar patterns. There are product types, attributes, addresses for members, payment and shipping methods, tax rates and tax classes, even related products already exist in their basic form. The classes for DC_ProductData (product management in the backend) and DC_TablePageId (linking products to pages as categories) still exist today with exactly the same name. Concepts such as the image upload in the backend (to their own /isotope folder) have also remained the same to this day.

Shortly after the first version, a large part of the further development moved to Europe, especially thanks to the German Contao community. The Contao Conference and the Camp played their part in spreading the word, and there was always a request for an Isotope session.

Version 2.0 was released just in time for Christmas 2013. The adjustments to Contao 3 were extensive and various problems with the 0 and 1 versions were fixed. A migration tool had to be created for existing stores, as Contao did not yet have the necessary resources. Another important milestone was the Notification Center, which Yanick invented for Isotope 2. In addition, Bjarke completely rewrote the documentation.

Ten years have passed since a major version of Isotope was released. Ten years in which dozens of new functions, payment methods, extensions and an extensive ecosystem were created. But also 10 years in which Contao has evolved. It's hard to believe that Isotope still benefits practically nothing from Symfony.

Software ages because its environment changes, so it has a limited lifespan. At last with Contao 5, we know that major adjustments are necessary to ensure that Isotope remains usable. The good news is: the structure of Isotope will not change significantly. We are not reinventing everything, no migration tool or anything like that is needed. But there is a lot of work ahead of us that we can't do in our spare time.

In conversations, by e-mail, at Contao events and in the forum, the Contao community has repeatedly expressed the need for a future-proof shop system for Contao. Now we need your help to make this happen.

We would already like to thank the members of the Isotope Circle who support the maintenance of Isotope every year with their contribution.

As a developer, I have always struggled to find a sensible release cycle for extensions. We admire big companies that use a lot of (wo)man power and money to launch new product versions. We wish that we could use the same marketing machinery. In reality, this is hardly feasible for open source projects and usually doesn't make sense either.

I would like to give version numbers less priority. It is not without reason that Office for Mac 2021 has the version number 16. The info popup in Photoshop 2024 shows version 25.11. Version numbers refer to API compatibility for extensions. Semantic Versioning should ensure that only what works on my system is installed. As a user, the process is simple: the higher the number, the newer the product. Ideally, you always have the latest - or whatever Composer installs due to your dependencies.

The hurdles to publishing new versions have become much smaller thanks to Composer. Tools such as the Contao Manager or trakked also contributed to this. What I have been doing with other extensions for some time now will be applied to Isotope as well. Bugfixes will be released as soon as they are available. There will be a minor version as soon as a new feature is implemented. Only features are worth writing about in our blog. And if a feature changes the API compatibility for extensions, there will be a major version instead of a minor version, following SemVer best-practice.