In 2007, Movable Type looked like the better CMS. Five years later, the ecosystem had changed our minds.

Technical superiority is overrated.

In 2007, if you were choosing a publishing platform, Movable Type had a compelling story. Its default publishing model generated static HTML. It offered considerable control over templates and output. It ran on Perl, which, in certain developer circles at the time, carried more credibility than PHP.

And it had serious users. Barack Obama’s presidential campaign was among the high-profile operations associated with Movable Type.¹ The campaign’s broader web presence was considerably more complex than a single CMS, with Blue State Digital building much of its organizing and fundraising infrastructure. But as a signal of what sophisticated teams were willing to use, it got our attention.

We were making a platform decision of our own, and we picked Movable Type too.

Why Movable Type seemed like the obvious choice

At the time, I was running a photography software company called Intothedarkroom with Anthony Ronga. Part of our offering was blog themes for photographers.

That sounds fairly ordinary now. In 2007, it required making a bet about which publishing platform our customers would want to use. We weren’t going to maintain parallel theme ecosystems indefinitely. We had to pick a lane.

Movable Type looked like the more serious product.

It had started life as a blogging platform, like WordPress, but its approach to publishing felt more deliberate. By default, it generated the HTML files visitors would actually request. The publishing system did its work when content changed, rather than assembling every page from PHP and database queries at request time. It could also publish dynamically, but static output was central to its appeal.²

In principle, that meant fewer moving parts on the public-facing side of a site. For photographers who wanted attractive, fast, reliable blogs, that was an appealing proposition.

WordPress, meanwhile, was still widely treated as a blogging tool. It was a PHP-and-MySQL application that generated pages dynamically. It was approachable, sometimes a little messy, and not necessarily the system you chose when you wanted to impress another developer with your architecture.

That impression was part of our mistake.

And frankly, how could Obama be wrong?

Thanks, Obama.

The platform was fine. The bet wasn’t.

Here’s an important distinction: Movable Type wasn’t bad software. We didn’t discover some fatal architectural defect that made it unusable.

What changed was everything around it.

Movable Type came from a commercial, proprietary licensing model. It was extensible, and it had plugins, but it didn’t have anything like the expanding plugin ecosystem that was becoming central to the WordPress experience. If you needed something beyond the basics, the path often felt more developer-centric.

WordPress was moving in the opposite direction. A live PHP application with an increasingly deep library of plugins meant more of the functionality customers wanted was already available. You could install something, configure it, and move on instead of building and maintaining another custom piece yourself.

That difference kept widening. The gap between what the platforms could do out of the box—or with readily available extensions—grew larger by the day.

And the benefits weren’t limited to developers:

• Hosting got easier. WordPress fit comfortably into the PHP-and-MySQL hosting world, and hosting companies increasingly knew how to support it.
• Editing got easier. Customers and their teams could make changes in a system more people recognized and understood.
• Extending got easier. The growing plugin ecosystem made ordinary requests less likely to require custom development.
• Finding help got easier. More designers, developers, agencies, and support resources were working with WordPress every day.

We felt all of this at Intothedarkroom. We were selling themes to photographers, not trying to make every customer dependent on us for the smallest change to their site. The surrounding ecosystem mattered to our product just as much as the underlying publishing engine.

By 2010, it was becoming obvious to us that we’d picked the losing side of that equation. By 2012, we’d fully converted our offering to WordPress.

The interesting thing is that no individual feature caused the switch. WordPress made the entire experience easier for everyone involved: hosting providers, developers, editors, and customers. As adoption increased, the ecosystem expanded; as the ecosystem expanded, adoption became easier. Each side reinforced the other.

The economics of an ecosystem

It’s tempting to compare content management systems on their technical properties alone.

These aren’t opposing columns where the left side stopped mattering. They are different dimensions of the same decision. We weighted one set of dimensions too heavily.

The fascinating part is that the ecosystem advantage compounds. Every new plugin, hosting integration, tutorial, contributor, and experienced developer increases the odds that someone else’s work will make your next problem easier to solve.

WordPress didn’t need to be perfect. It needed to be useful enough, extensible enough, and accessible enough for that cycle to keep accelerating.

None of this happened because Movable Type stood still. It kept developing its publishing system and opened its source code in late 2007. But by then the competitive question was already bigger than what either application could do on its own.

We’ve been here before. We keep coming back.

One of the ironies is that the technical ideas that attracted me to Movable Type haven’t gone away.

Static generation is fashionable again. So are headless architectures, content APIs, cleaner separations between authoring and presentation, and publishing pipelines that generate artifacts rather than render everything live.

Many of those approaches are legitimate improvements for the right requirements. I’m interested in them myself.

But I also remember thinking a static publishing model made Movable Type the obvious choice in 2007.

A technically cleaner solution in isolation isn’t necessarily a better platform for the people who have to use it, extend it, staff it, and maintain it for years.

That doesn’t mean WordPress should always win. There are projects where its assumptions are the wrong fit, and there are architectures that solve particular problems much better. Being dominant doesn’t make a system immune to replacement, either.

It means the evaluation has to include more than the elegance of the implementation.

When choosing a platform, I now care just as much about questions like: Who will maintain this three years from now? How much of the solution already exists? What happens when the original developer leaves? How many people know how to operate it? What will we need to rebuild ourselves?

Those questions can sound less interesting than a debate about rendering models. They’re often more consequential.

What keeps working over time

I first wrote about this ahead of PressConf 2026, where Anthony Ferrara was among the speakers. I suspected then that the underlying conversation would still be about the same tension: not merely what is better, but what keeps working as technologies, businesses, and teams change.

That’s the part of the Movable Type decision that stayed with me.

We didn’t choose an absurd platform. We made a reasonable technical judgment based on what seemed important in 2007. But we underestimated what would happen when one platform became progressively easier to host, edit, extend, and support—and the other required more specialized effort to do the same work. Our customers and the ecosystem taught us something we hadn’t weighted heavily enough.

WordPress isn’t dominant because it’s perfect. It became the easiest system to adopt and one of the hardest to displace.

And sometimes that matters much more than being technically right.