By 2020, the CMS/CMF war had ended, and tools from MODX had been declared the winner. MODX had (almost) become a household name with a large share of the market and had gained enough critical mass to be a self-sustaining entity. Here’s the story of how we got there.
When solving a difficult problem, I often find it easier to start at the end state and then work backwards. The dates involved here are of course just made up, but figuring out the steps backwards in a logical manner seems to work better for me than a “where do we go from here” perspective. To put it another way:
“Every battle is won before it’s ever fought.” Sun Tzu (sometimes mistakenly attributed to Dora the Explorer)
To best explain the world of MODX 2020 to someone from 2015, here is what we have in 2020: Two tools with one brand. MODX is the tool which you have come to know and love as a designer/developer that gave you total Creative Freedom. MODXpress (as in “MODX Express”) is a tool which is for your amateur web creators who want to easily create their own website without all of the worries of the underlying technologies. MODXpress was built on top of MODX, and is not to be confused with MODX Press, which is MODX’s publishing entity responsible for getting Bob Ray’s amazing book out to the masses. Those with a keen sense of observation and irony also noted that books created by MODX Press were, in most cases, things that MODXpress users would most likely not read.
At a certain point in time before 2020, MODX had a choice of either making two completely separate tools, having one unified tool or building one tool on top of the other.
Making two completely separate tools, although favoured by some members of the community, was ruled out due to the maintenance that comes along with two completely different code bases.
Having one unified tool was the favourite for a while, but from a branding perspective (and the fact that the two “target markets” were incompatible) meant that we had to make a lot of compromises. At each step, we had to choose whether the web professional would be given priority or the web amateur would be given priority: a tool can be something that can be an enabler, or an obstacle. The community realized that although there were times that either both groups of users viewed the world the same way (or that those views could be reconciled), at some point in time those worlds could not and should not be reconciled. Wise men and women (knowing the early days of the internet) remember Eternal September, which was an event in September 1993 when two different groups of users, Usenet and AOL formed together. For those that didn’t know, this was a time when two groups (coming from very different viewpoints on technology) were put all together. The chaos that ensued when those who saw technological complexity as something to be embraced were placed alongside those who saw technological complexity to be avoided was a lesson not to be repeated.
Creating two tools, with MODXpress built on top of MODX 3, made the most sense for several reasons. The first was code reuse. The second was that some that started as MODXpress users advanced to the level of wanting what MODX 3 offered. The group that advanced from MODXpress to MODX wanted to have more control over the design of their site and were willing to deal with additional complexity and augment their skill set in order to get there without having to start with a brand new tool with their site. All MODXpress sites were in fact MODX sites with a different administration application (a.k.a. manager).
Though the “which came first, the chicken and the egg” astounded laymen, academics and chickens alike, the story of MODX and MODXpress was much easier to solve: the core of MODX (i.e. MODX 3) was built first and then two separate teams worked on the administration applications using the same core.
So far I’ve only spoken about MODX 2020 from a tool perspective. One would be remiss in neglecting the community which brought us there.
Once the main framework for the architecture had been determined (mostly by Jason Coward), groups of dedicated developers and designers, each donating some of their time for a specific aspect of the tool, went to work in creating this based on some very flexible guidelines. Some of these people had been hardcore MODXers from the beginning and some were completely new to MODX. Though some historians debate the impact, most historians agree that having an on-boarding kit was the catalyst needed to level-set all developers and designers, and gave the teams (working in small groups) both the freedom and the structure to make something awesome.
The rationale for this was that simply talking about design and not creating anything leads to close to nothing (which in 2019 was confirmed by a study in the Journal of Medicine which found that vapourware was determined to be invisible to human beings). Giving people some degree of freedom, with the understanding that their work may be refactored or majorly reworked turned out better than trying to figure out the best way of doing things at the start. The rationale was that it’s easier to offer feedback on something you can see and interact with rather than essays on high level design. As well, many lessons were learned going along and the initial design and the end product looked much different (in a good way).
Before all of this, there were a few prerequisites:
1) On-boarding guide for developers and designers which I wrote about earlier
2) A somewhat clear set of designs based on objective surveys sent to both the professional and amateur groups on what they wanted to see in MODX 3 and MODXpress respectively.
3) A process for managing pull requests (i.e. updating peoples’ code into the main code) in a way that allowed Quality Assurance to prevent substandard code from reaching the main branch
4) A team that was made up of different skill sets playing different roles: Developers, Designers, UX, complete beginner, QA and mini-project coordinators to work with other teams and be the person at the end of the day to be making sure the team’s efforts weren’t being laid to waste because of missed dependencies or missed opportunities to get stuff from other teams. The mini-project coordinators also arranged for show and tells and objectively collecting feedback.
If you’ve made it this far, I either have not bored you to tears or your ability to find the end of a document are well honed.
What I offer is fodder for praise or flame. Where do you agree? Where do you disagree? How do you want the future of MODX to be written?