Our Software Philosophy

The framework and guidelines we use in creating the best platform to help growing organizations crush it online.

The MODX Way

Core Code Values

MODX has been continuously Open Source since 2004. We want to solve real-world problems pragmatically. To do that, we weigh a variety of factors when deciding what goes into the core and how we create and evaluate code. We believe the following core tenets lead to higher quality, more secure, better performing, and more flexible software which benefits organizations who communicate or conduct business on the web.

Flexibility and Freedom

Flexibility & Freedom

Before MODX, CSS-powered designs were impossible with other CMSes; they relied on bloated mixed-code template systems. We believe software should be flexible enough to adapt to a variety of use cases giving designers, developers, and site owners the creative freedom to build exactly what they want without compromise or needless complexity. Like with our first release 2005, you could power an HTML5/CSS3/React website despite those technologies not existing yet, MODX already supports whatever comes next.

Security

Security

From day one, security has been first and foremost in mind when deciding on software architecture and design software. This is why we were early adopters of PDO via xPDO for our data abstraction layer that helps prevent a variety of security vectors—which, in fact, was adopted years later by Drupal. Website security can no longer be an afterthought, and rarely can be successfully bolted on after the fact. MODX Software enjoys one of the best track records amongst all mainstream Open Source CMSes.

Speed

Speed

MODX also valued speed from its inception; we were one of the first content management systems to support CSS layouts when 56K dial-up modems were standard for the vast majority of Internet users). A 1.544 Mbps T1 line was unheard of except at large businesses. Speed weighs heavily in what we evaluate for inclusion in MODX, especially as we move to a more modular, standards-based core that leverages Composer. With the Core Web Vitals update from June 2021, speed is now even more critical.

Stability

Stability

The choices of what is included with our software must have a track record for being actively maintained over time, thoroughly vetted, and developed with complementary philosophy and values as our own Open Source software. Our integration processes help ensure our releases are vetted and high-quality.

Supportable

Supportable

We have to be able to connect with and get support on the technologies that are included in the MODX core. That means that there needs to be a solid track record of providing support for years. While we have dozens of translations and contributors from all over the globe, fluent English language support is important.

Small Core

Small Core

If we can omit things that aren’t absolutely essential for most from the core, we will. It’s a delicate balancing act and a constant state of evaluating options vs adding just one more thing … a slippery slope that can negatively affect security and stability. “It’s not the notes you play, it’s the notes you don’t play." — Miles Davis


Governance Model

Self-appointing Board

MODX has explored multiple governance models, and many Community members have taken on and subsequently moved on from important leadership roles. We understand life happens and people’s and organizations’ priorities change—we expect a constant flux in Community participation in the creation and maintenance of our Open Source software. As an organization, MODX is committed to being a constant presence and to continue leading, fostering, organizing, and investing in the Community’s involvement, participation, development, and leadership roles for the Open Source software. This means we also commit to being the primary corporate sponsor for its ongoing maintenance, development, infrastructure, and support.


Semver

Versioning & Release Cadence

Semantic versioning, or “semver”, is how we manage releases and decide what goes into the next minor and patch releases. In general, patch releases (2.6.1, 2.6.2, etc.) are for bug fixes between minor releases (2.7, 2.8, 2.9) which receive new features and APIs. Major releases (2.0, 3.0, 4.0) are where breaking changes happen. We shoot for 1-2 minor releases a year, patch releases when needed, and major releases every 2-3 years.