WordPress History: A Proven Story of How Free Open Source Transformed the Web

WordPress turned 22 this year. I have been building with it for nearly 17 of those years. That is a strange thing to sit with – more than half of its entire existence, I have been writing code that runs on top of it, debugging things that broke because of it, and yes, sometimes cursing at it. But also watching it quietly become one of the most consequential pieces of software ever written.

When people ask me “when was WordPress created” or “how old is WordPress,” I usually give them the quick answer: May 27, 2003. Matt Mullenweg and Mike Little forked a dead blogging project called b2/cafelog and shipped the first version. But the short answer misses everything important about why that moment mattered and what came after.

This is the version of that history I wish someone had written when I was starting out. Not a changelog, not a Wikipedia timeline, but an honest account of what it actually felt like to build on this platform as it evolved – the exciting parts, the frustrating parts, and the moments that changed everything.

---

WordPress history starts in a very unglamorous way. Michel Valdrighi had built b2/cafelog as a blogging tool, then went quiet. The project stalled. Matt Mullenweg, who was using b2 for his personal blog, publicly posted that he was going to fork it and continue development. A few people joined. Most people shrugged.

WordPress 0.7 shipped in May 2003. The early versions were rough – a basic blogging engine with a handful of templates and very limited customization. But it had two things going for it: it was free, and it had a developer who actually cared about it.

I wasn’t there yet. I was still in school in 2003. But when I look at the commit history from that era, I can see something that would define WordPress’s entire trajectory: it was built by someone who wanted to use it himself. That user-first instinct never left, even as the platform grew into something massive.

“Code is poetry.” The tagline showed up early in WordPress’s life and it was never just marketing. The people building it cared about craft.

WordPress 1.0 arrived in January 2004, named “Miles” after jazz musician Miles Davis – a naming convention that would continue for every major release. It introduced the comment system, the permalink structure we still use today, and a basic plugin API. That plugin API was small and limited, but it planted a seed that would eventually grow into an entire economy.

---

By 2005, WordPress had a theme system. This sounds unremarkable now, but at the time it was genuinely exciting. Suddenly you could separate your design from your content. You could change what your site looked like without touching your posts. The choice between a free or premium WordPress theme became a real question people were asking – something you can only ask when there are enough themes to choose from. The template hierarchy – that logic of which template file gets loaded for which type of page – was crude by modern standards but functional enough to build real things with.

WordPress 2.0 landed in December 2005 and brought the TinyMCE visual editor. I remember this clearly because it was one of the first times I saw a client’s face light up when they used WordPress. Before TinyMCE, asking a non-technical person to format a blog post meant explaining HTML. After it, they could just type. That shift in accessibility is a huge part of how WordPress eventually won.

The plugin ecosystem in this era was genuinely wild. There was no quality control, no standards, no consistent API. Plugins would grab data in whatever way seemed easiest at the time – direct database queries, global variable manipulation, code that assumed other plugins existed or didn’t exist. Conflicts were constant. Security was mostly an afterthought. I remember spending an entire weekend debugging why two plugins were both hooking into the same database table and corrupting each other’s data.

The Community Starts to Form

What was happening in parallel, though, was the community. WordCamps started in 2006, beginning with a single event in San Francisco. The forums were active. People were writing tutorials, sharing code snippets, building things and giving them away for free. There was a genuine spirit of collective building that I haven’t really seen replicated elsewhere in software at that scale.

I got properly involved around 2007. At that point, WordPress had around 1.5 million downloads. By any reasonable measure it was already a success. But the codebase still had all the marks of something that had grown faster than the architecture supporting it. Things worked, but not always elegantly. The learning curve for building anything serious was steep, and it was mostly learned through reading other people’s code and trial and error.

---

WordPress 2.5 in 2008 brought what I consider the first properly modern WordPress admin dashboard. The previous design had grown organically and somewhat haphazardly. The 2.5 redesign was controversial at the time – people complained loudly about change – but it established a visual language that would guide the admin interface for years.

But 2010 was the year that really changed what WordPress could do. WordPress 3.0 merged WordPress MU (the multisite version) into core, making it possible to run a network of sites from a single installation. More importantly, it introduced custom post types.

Custom post types sound like a minor technical detail but they were transformative. Before them, if you wanted to build a site with a portfolio section or a team directory or a product catalog, you were essentially hacking the posts system or building a completely separate database structure. Custom post types made WordPress a proper CMS instead of just a blogging platform. That distinction matters enormously. It’s what allowed WordPress to power everything from personal blogs to Fortune 500 websites.

Custom post types didn’t just add a feature. They changed what WordPress was. Before them, it was a blogging platform. After them, it was a content management system.

I remember the projects I could suddenly take on after 3.0. Clients who had been told they needed a custom-built CMS could now get a properly structured WordPress site. The pitch changed from “here’s a blog you can adapt” to “here’s a system built around exactly the content you have.” That shift opened up a significant market and I benefited directly from it.

Post Formats and the Tumblr Wars

WordPress 3.1 in 2011 added post formats – a way to denote whether a post was a standard article, a gallery, a link, a quote, or a video. This was WordPress trying to compete with the microblogging aesthetic that Tumblr had popularized. It mostly didn’t work as intended. Most themes implemented it inconsistently, most users ignored it, and it faded into the background as a feature that was technically present but practically irrelevant.

I think about post formats sometimes as an example of WordPress trying to follow a trend rather than lead one. It’s the exception, though. Most of what came out of this era felt like it was solving real problems that real users had.

The 3.x series also saw significant improvements to the media management system, better import/export tools, and the introduction of the theme customizer in 3.4. By this point WordPress was powering somewhere around 15-16% of all websites. The number is staggering when you think about what it took to get there: no venture capital, no big corporate parent until Automattic emerged as the commercial entity, just a community of people building something useful.

---

WordPress 3.8 in late 2013 brought a major visual refresh to the admin – cleaner, flatter, more responsive. It felt like WordPress acknowledging that people were managing their sites on tablets and phones, not just desktop computers. I had clients calling me to say the new admin “finally worked properly” on their iPad. The shift was overdue but it was done well.

The REST API work began in earnest around this period. The idea was to give WordPress a proper programmatic interface – a way to read and write content using standard HTTP requests rather than requiring WordPress’s PHP template system. This might sound like plumbing, but it was actually a fundamental shift in what WordPress could be: not just a website CMS but a content backend for any kind of application.

WP-CLI Changes How I Work

Around 2013-2014, WP-CLI became a serious tool. For non-developers, WP-CLI is a command-line interface for managing WordPress – instead of clicking through the admin dashboard, you run commands in a terminal. For me, it changed how I worked entirely. Tasks that used to take 20 minutes of clicking now took 30 seconds of typing. Bulk operations that weren’t possible through the UI became trivial. Deployments became scriptable.

I remember the first time I ran a WP-CLI search-replace command to migrate a database from staging to production. The kind of operation that used to require either a plugin, a custom script, or careful manual execution of SQL queries could now be done with a single line. It sounds small but it was a real productivity inflection point.

WordPress 4.x: The Quiet Reliability Era

The WordPress 4.x series (2014-2018) was not particularly dramatic. There were no features that completely changed the game the way custom post types or multisite had. Instead, there was steady, reliable improvement: better auto-updates, better accessibility, a more capable media editor, improvements to the customizer, better REST API foundation.

This era is underappreciated. It’s the kind of software development that doesn’t make headlines but that keeps users and developers trusting a platform. Every update worked. Things didn’t break. The security response improved significantly. For those of us building real client sites on WordPress, this reliability was worth more than any individual feature.

By 2016, WordPress was running somewhere between 25-27% of the internet. One in four websites. That number still hits me whenever I think about it. A project started by one person who wanted a better blog became the backbone of a quarter of the world’s web presence.

---

Nothing in WordPress history has been more controversial than Gutenberg. When the block editor shipped in WordPress 5.0 in December 2018, the reaction from the developer community was split sharply down the middle.

The complaints were legitimate: the classic editor was mature, stable, and well-understood. Gutenberg was new, had rough edges, and broke backwards compatibility with a lot of existing content. Plugins that extended TinyMCE stopped working. Workflows that experienced users had built over years suddenly required relearning. The transition was painful.

But I was never in the “Gutenberg is a mistake” camp, even in those early difficult months. The core idea was right. The classic editor had become a bottleneck. You couldn’t build rich, structured layouts without either leaving WordPress entirely or using page builder plugins that had grown so complex they were practically separate CMSes bolted on top. Gutenberg was attempting to bring that capability into core in a way that would be sustainable long-term.

Era	WordPress Version	Key Shift
Birth	1.0 (2004)	Blogging platform with plugin API
Growth	3.0 (2010)	CMS with custom post types
Maturity	4.x (2014-2018)	Reliability, REST API, WP-CLI
Block era	5.0 (2018)	Block editor, structured content
Full Site	5.9 (2022)	Full Site Editing, block themes

Full Site Editing: The Next Frontier

WordPress 5.9 in January 2022 shipped Full Site Editing – the ability to manage not just post content but your entire site’s design using the block editor. Headers, footers, sidebars, templates, all of it editable through the same block interface.

I remember rebuilding my first site on a block theme. The learning curve was real. Understanding template parts, block patterns, the way theme.json replaced all those PHP functions I’d memorized – it took time. But once it clicked, the freedom it offered was undeniable. No more child themes just to change a header. No more PHP edits just to adjust the footer copyright. A properly built block theme gives clients genuine control over their site without any code.

For developers, the FSE era also meant learning a new way to think about extensibility. Instead of PHP hooks everywhere, the extension points shifted toward block variations, block styles, block filters, and patterns. The tooling changed. The workflow changed. It was disorienting for a while and then, gradually, it started to feel natural.

---

WordPress today is almost unrecognizable from what shipped in 2003. But if you look carefully, the same core DNA is there: free, open source, designed for people who want to publish without needing permission from a platform or a corporation.

The performance improvements in WordPress 6.x have been impressive. Speculative loading, better image handling, Core Web Vitals improvements built into the platform itself rather than requiring plugins to achieve them. WordPress sites that would have needed significant engineering investment to be fast a few years ago now perform well out of the box.

The AI integration conversation is ongoing. WordPress isn’t rushing to bolt AI onto everything, which I think is the right call. The ecosystem is experimenting – there are plugins doing interesting things with content assistance, image generation, SEO optimization. But core is moving deliberately. I’d rather have a stable foundation that the community can build AI tools on top of than have AI features rushed into core before the approach is well-understood.

How Old is WordPress in 2026?

WordPress is 23 years old as of 2026, if we count from the May 2003 release. In software terms, that is ancient. Most platforms from that era are either dead or barely maintained. WordPress is more actively developed today than at almost any point in its history. The release cadence is consistent, the contributor community is global and large, and the platform powers over 43% of the entire web.

That last number – 43% – is the one that still catches me off guard when I say it out loud. When WordPress started, it was competing with Blogger, LiveJournal, and a handful of other blogging platforms. The idea that it would eventually power nearly half the internet’s websites would have seemed absurd in 2003. It happened because of the open source model, because of the community, and because the people building it kept making decisions that prioritized users over any other consideration.

---

I’ve spent a lot of time thinking about this question. WordPress wasn’t always technically superior. There were competitors with cleaner codebases, more modern architectures, more elegant developer experiences. Some of them are still around. None of them have WordPress’s market position.

The answer, I think, comes down to four things. First: the decision to stay free and open source. This removed the barrier to entry for millions of people and created the conditions for a massive plugin and theme ecosystem that no commercial platform could replicate.

Second: the backwards compatibility commitment. WordPress takes this seriously. Plugins and themes built years ago still work. This is expensive to maintain and it creates real technical debt, but it also means people trust the platform with their investments. When you build on WordPress, you’re not worried that next year’s update will break your site.

Third: the community. WordCamp is a remarkable institution. Local WordPress meetups run in cities around the world. The documentation has been translated into dozens of languages. The forums have millions of answers. No company planned this community – it grew because people found each other around something they were all building on.

Fourth – and this is the one I feel most personally – WordPress grew because it genuinely helped people. Small business owners who couldn’t afford a developer could build their own websites and drive real traffic to them. Writers could publish without needing a publisher. Nonprofits could have professional web presences. The platform did something real and useful for a lot of people, and those people talked about it, and the word spread.

---

I don’t know exactly what WordPress looks like in 2030. The block editor evolution is still ongoing – the vision for Phase 3 and Phase 4 of Gutenberg (collaboration and multilingual support) is ambitious and will take years to fully realize. The balance between the open source project and the commercial entities in the ecosystem is an ongoing negotiation.

What I do know is that WordPress has survived every technological shift that was supposed to kill it. App stores were supposed to make websites obsolete. Social platforms were supposed to make blogging irrelevant. Static site generators were going to take over. JavaScript frameworks were supposed to replace PHP. Each of these things changed the web in real ways – but WordPress kept growing anyway, because the fundamental need it serves (publishing and managing content on the web without depending on someone else’s platform) doesn’t go away.

After 17 years of building on it, I’m still here. Still using it for client work. Still watching each release with genuine interest. There’s something to be said for a piece of software that earns that kind of long-term trust – not through lock-in or network effects, but by consistently being worth using.

---

• May 27, 2003 – WordPress 0.7 released. Matt Mullenweg and Mike Little fork b2/cafelog.
• January 2004 – WordPress 1.0 “Miles.” Plugin API, permalink structure, comments.
• February 2005 – WordPress 1.5 “Strayhorn.” Theme system introduced. The separation of design from content begins.
• December 2005 – WordPress 2.0 “Duke.” TinyMCE visual editor. Non-technical users can finally format posts.
• August 2008 – WordPress 2.6 “Tyner.” Post revisions. Finally, an undo button for content.
• June 2010 – WordPress 3.0 “Thelonious.” Custom post types, multisite merged in. WordPress becomes a real CMS.
• October 2013 – WordPress 3.7 “Basie.” Auto-updates for minor releases. Security patches happen without user action.
• September 2014 – WordPress 4.0 “Benny.” Improved media editing. The platform keeps getting more accessible.
• December 2018 – WordPress 5.0 “Bebo.” Gutenberg block editor. The most controversial release in WordPress history.
• January 2022 – WordPress 5.9 “Joséphine.” Full Site Editing. Block themes become the new paradigm.
• 2023-2026 – WordPress 6.x series. Performance, collaboration, refinement of the block editor vision.

---

If you’re reading this because you’re trying to understand WordPress history before diving in yourself, here’s what I’d tell you: the history matters because it explains the present. The rough edges and the brilliant parts alike are shaped by 20+ years of decisions made by a community of people who mostly cared about doing the right thing. That context makes you a better developer.

And if you’re a long-time WordPress developer reading this, taking a moment to look back at how far this thing has come – I think we sometimes forget how remarkable it is. A free platform, built by volunteers and a passionate community, that runs nearly half the web. That doesn’t happen by accident. It happens because a lot of people chose to show up and contribute.

I’ve been one of those people for 17 years. Here’s to the next 17.