WordPress 2003-2026: From b2/cafelog Fork to Block Editor Era

WordPress is the oldest credible open-source content management system still in mainstream use, and one of the few that has survived three full generations of web architecture, from server-rendered LAMP through to AJAX-driven dashboards and now to headless and block-based composition. In 2026 it still powers an estimated 43 percent of all websites tracked by W3Techs, which is a remarkable share for software that started as a weekend fork.

This retrospective walks the arc from the May 2003 fork of b2/cafelog through to the AI-augmented WordPress 6.x releases of 2025 and 2026. The objective is to lay out the technical inflection points alongside the community and governance choices that kept the project coherent. The WordPress story is unusual in that the technical and the social decisions are roughly equally important.

b2/cafelog 2001 to WordPress fork May 2003

The pre-history matters. In 2001 Michel Valdrighi, a French developer, released b2/cafelog, a PHP/MySQL blogging tool licensed under the GPL. b2 was technically credible. It supported friendly URLs, comments, RSS feeds and a plugin-style hook system. The community around it was small but engaged.

In early 2003 Valdrighi’s activity on the project slowed to the point where it was unclear whether b2 was still being maintained. Forum threads went unanswered for weeks. For users running production blogs on b2 this was a quietly serious problem; the alternatives at the time were Movable Type, which was Perl-based and proprietary, and a handful of less mature PHP projects.

On 27 January 2003 Matt Mullenweg, then a 19-year-old university student in Houston, posted to his blog under the title “The Blogging Software Dilemma”. The post laid out the choice as he saw it: wait for b2 to resume, switch to Movable Type, or fork b2 and continue the codebase under a new name. Mike Little, a British developer who had been active on the b2 forum, replied that he was up for the third option. The fork was named WordPress, and the first commit landed in May 2003. Valdrighi himself joined the project shortly after.

The first stable release, WordPress 0.7, shipped on 27 May 2003. WordPress 1.0, codenamed “Davis”, followed on 3 January 2004. The 1.0 release added clean permalinks, a moderation queue, a plugin API and the first iteration of what would become the themes system. The GPL inheritance from b2 was preserved, which would later prove decisive for the ecosystem.

The milestone releases that defined each phase of the project, laid out as a table, make the evolution legible at a glance:

Themes and plugins economy 2005 to 2010

The shift from “blogging tool” to “general-purpose CMS” happened between 2005 and 2010, and it was driven by the themes and plugins ecosystem rather than by the WordPress core team alone.

The default theme through this period was Kubrick, designed by Michael Heilemann and shipped from WordPress 1.5 onward. Kubrick was a single-column layout with a blue gradient header and was probably the most-installed PHP file on the web for several years. Its successor, Twenty Ten, shipped in 2010 and started the tradition of an annual default theme.

Plugins grew in parallel. Akismet, the comment-spam filtering service launched by Automattic in 2005, became the most-installed plugin for over a decade. WooCommerce, originally a fork of Jigoshop by the WooThemes team, launched in September 2011 and turned WordPress into the most-deployed e-commerce platform on the open web. Yoast SEO, launched by Joost de Valk in 2010, became the default on-page SEO tooling for WordPress sites and was acquired by Newfold Digital in August 2021.

The plugin directory at wordpress.org/plugins crossed 1,000 plugins in 2007, 10,000 in 2010, and over 60,000 in 2026. The economics of the plugin economy stabilised around a freemium model: a free plugin distributed through the .org directory, a paid extension or pro version distributed through the developer’s own site. The model is structurally similar to the AppExchange flywheel that the Salesforce platform built in 2005, although the WordPress version is more decentralised.

The themes side mirrored the plugins side. ThemeForest, launched by Envato in November 2008, became the dominant marketplace for premium WordPress themes. By 2016 a number of theme houses (Elegant Themes, StudioPress, ThemeIsle, Astra) were running multi-million-dollar businesses on top of WordPress’s GPL theme model.

WordCamp and community 2006 to 2012

WordCamp is the in-person community programme that emerged out of San Francisco in 2006 and quickly globalised. The first event, WordCamp San Francisco in August 2006, drew around 500 attendees and was organised on a shoestring by Matt Mullenweg and the early Automattic team. The 2007 edition is widely treated as the inflection point at which WordPress crossed from “developer tool” to “credible content management ecosystem”.

The community pattern that crystallised between 2006 and 2012 has persisted in 2026. WordCamps are licensed by the WordPress Foundation, organised locally, run on a per-event budget cap, and follow a strict code of conduct. Speakers are not paid; sponsorships are capped to prevent any one company from dominating an event. Approximately 100 WordCamps run globally each year, with regional flagship events in Europe (WordCamp EU), Asia (WordCamp Asia, launched 2023 in Bangkok) and the US.

WordCamps mattered because they kept the project’s governance visible. Decisions taken in IRC channels (later Slack) had faces and accents and personal histories attached to them. The “five for the future” pledge, introduced by Mullenweg in 2014, asked organisations that benefited from WordPress to commit 5 percent of staff time to contributing back to the project. Compliance has been uneven; the principle is still cited.

The shadow side of the community model is that it relies heavily on Automattic’s resources, and Automattic has its own commercial interests. The 2024 and 2025 disputes between Automattic and the host WP Engine over trademark usage and the .org plugin directory made the dependency visible in a way that previous decades had not. The disputes are still working through the courts in 2026, and the long-term governance answer is unsettled.

Automattic 2005 and the WordPress.com/.org dichotomy

Mullenweg founded Automattic in August 2005 to commercialise the WordPress ecosystem without distorting the open-source project. The flagship product was WordPress.com, a hosted blogging service running the WordPress codebase, launched in November 2005 with a freemium model.

The org/com dichotomy is the structural choice that has shaped most of WordPress’s commercial dynamics ever since. wordpress.org is the open-source project, governed by the WordPress Foundation (incorporated in 2010). It distributes the GPL codebase, hosts the plugin and theme directories, and runs WordCamp Central. wordpress.com is a commercial business operated by Automattic, with managed hosting, a curated plugin and theme selection, and tiered pricing.

The two are deliberately distinct in name and in legal entity, and they are also genuinely entangled. Automattic employees contribute substantially to .org core. The .com service exists because Automattic operates it. The .org plugin directory is hosted on infrastructure that Automattic helps fund. The Foundation depends on Automattic for several operational functions.

This entanglement is the engine of the 2024-2026 WP Engine dispute. WP Engine is a competing managed-host provider founded in 2010, with revenue estimated above 400 million dollars annually. Mullenweg’s public position is that WP Engine benefits from the WordPress trademark and the .org infrastructure without contributing proportionally. WP Engine’s position is that the Foundation and Automattic are functionally indistinguishable and that Mullenweg’s actions amount to an attempt to extract rent. The court filings are extensive; the underlying question is whether the WordPress project’s governance structure can sustain a serious commercial dispute between its two largest hosts.

REST API 2016 and the headless WordPress era

The REST API, integrated into WordPress core in version 4.7 in December 2016, is the change that quietly turned WordPress into a credible headless CMS. Before the REST API, building a JavaScript front-end against a WordPress backend meant scraping the admin AJAX endpoints or installing a plugin. After the REST API, every standard WordPress object (posts, pages, custom post types, users, taxonomies, comments) was available over a well-documented JSON API.

The strategic effect was that WordPress could now be the content layer for a separately-deployed front-end. Agencies started shipping WordPress + Next.js, WordPress + Gatsby, and WordPress + Nuxt stacks for clients who wanted editorial workflows alongside performant front-ends. The pattern was named “headless WordPress” and has stabilised as a small but durable segment of the ecosystem, with hosts like WP Engine (Atlas) and Bluehost (Cloud) marketing dedicated headless products.

WPGraphQL, an open-source project led by Jason Bahl, added a GraphQL interface on top of the same WordPress data model in 2017. By 2026 WPGraphQL is the more popular API choice for new headless projects, although the REST API remains the default for plugin and theme integration.

The headless segment is small in 2026 (perhaps 5 to 10 percent of new WordPress deployments by some agency surveys) but disproportionately influential, because it is the segment that competes most directly with JAMstack CMSs (Sanity, Contentful, Strapi) and with no-code builders (Webflow, Framer, Wix). The fact that WordPress can compete in this segment at all is a function of the REST API decision in 2016.

Gutenberg and the block editor 2018

The block editor, codenamed Gutenberg, shipped in WordPress 5.0 in December 2018. It was the most contentious release in the project’s history and it remains a useful case study in how to ship a major UX change across a heterogeneous user base.

The argument for Gutenberg was that the classic TinyMCE-based editor was a dead end. Page builders (Divi, Elementor, Beaver Builder) had captured the visual-editing market by working around the editor rather than improving it. The block paradigm, in which content is composed of discrete typed units that can be rearranged, configured and reused, was the same paradigm that had won in modern editorial CMSs (Notion, Medium, Ghost). Mullenweg’s public argument was that WordPress had to ship a credible first-party block editor or cede the editing experience to plugins.

The argument against Gutenberg was that it shipped before it was ready. The 5.0 release in December 2018 had accessibility regressions, plugin compatibility breakage, and a steep learning curve for users who had spent a decade with the classic editor. The Classic Editor plugin, shipped as an official escape valve, has remained one of the most-installed plugins on the platform and is currently committed for support through 2026 and likely beyond.

The medium-term outcome is that Gutenberg is now the default editor for the majority of WordPress sites and has stabilised into a competent block editor. The Full Site Editing extension, shipped in WordPress 5.9 in January 2022 and refined through 6.x, applied the same block paradigm to themes, header and footer templates, and site-wide design tokens. Block themes (Twenty Twenty-Three, Twenty Twenty-Four, Twenty Twenty-Five) replaced the older PHP-template theme model for new default themes.

The long-term outcome is still in motion. Block themes adoption among third-party themes is slower than core hoped. The block editor’s interaction model is unfamiliar to a generation of WordPress users trained on TinyMCE. The ecosystem effect is real: Gutenberg has standardised the editing experience across the WordPress, WordPress.com and most page-builder integrations, and the standardisation pays compound dividends in interoperability.

WordPress vs other CMS: the competitive landscape in 2026

WordPress did not become the default open-source CMS by accident, and it has not stayed there without competition. The 2026 landscape is worth laying out explicitly, because the relative positions explain why WordPress kept compounding while its peers either plateaued or retreated.

Joomla, forked from the Mambo CMS in August 2005, was for several years the most credible alternative for users who wanted more structured content modelling than WordPress offered out of the box. Joomla’s market share peaked around 2010 at roughly 3 percent of all websites and has steadily declined since. As of 2026 W3Techs surveys put Joomla at roughly 1.6 percent of CMS-detected sites, well behind WordPress.

Drupal, released by Dries Buytaert in 2001, took the opposite positioning. Drupal targeted developers, agencies and large enterprise and government deployments, with a richer content modelling system, a more flexible permissions layer, and a steeper learning curve. Drupal 7 (2011) and Drupal 8 (2015) maintained that audience; Drupal 10 (2022) and 11 (2024) consolidated it. Drupal’s CMS share is roughly 1.4 percent in 2026, smaller in volume than WordPress or Joomla but substantially deeper per site.

Ghost, launched by John O’Nolan in October 2013 after a Kickstarter campaign, took a Node.js-and-markdown approach focused on publication workflows. Ghost has captured a meaningful share of the writer-and-newsletter market (Stratechery for several years, Platformer, and many one-author publications) but has not crossed into general-purpose CMS volume. Ghost’s CMS share is well below 1 percent in 2026.

The static-site-generator era (Hugo from 2013, Jekyll from 2008, Eleventy from 2017, Astro from 2021) and the JAMstack CMS era (Sanity, Contentful, Strapi) have eaten a different segment of the market: developer-led publishing where the content team is small and the front-end stack is opinionated. These are not direct WordPress competitors at the volume layer, but they are the most credible competitors at the early-adopter and developer-influence layer.

WordPress’s own market share has moved upwards across the same period, from roughly 30 percent of all websites in 2018 to an estimated 43 percent in 2024-2026. The compounding came from the long tail (small business sites, agencies, hobbyists) where the ecosystem advantage of plugins and themes was more decisive than the architectural advantages of newer entrants.

The Gutenberg controversy 2018 to 2020

The Gutenberg release deserves its own retrospective because the social dynamics around it are still cited as the canonical case of how to ship a major UX change in an open-source project. WordPress 5.0 shipped on 6 December 2018 with the block editor as the new default. The reaction was sharp and divided.

The Classic Editor plugin, shipped by the WordPress core team as an official escape valve in late 2018, crossed 1 million installations within weeks of launch and reached over 7 million active installations by 2020. The plugin’s existence is the cleanest evidence that the rollout had genuine user pain, not just resistance to change. The WordPress core team committed to maintaining the Classic Editor plugin through 2026 and likely beyond, which is unusual for an opt-out compatibility shim and reflects how much of the existing user base depended on the older editor surface.

The accessibility regressions in the early Gutenberg releases were particularly contentious. Rian Rietveld, the lead accessibility contributor for WordPress at the time, resigned from the project in October 2018 with a detailed public post citing the project’s handling of accessibility issues during the Gutenberg development. The resignation became a focal point for criticism that the rollout had prioritised feature velocity over accessibility commitments. Several rounds of accessibility audits and fixes were shipped in 5.1 through 5.4 to address the most acute issues.

The community split was real and partly persists in 2026. Some agencies and freelancers (particularly those serving non-technical small business clients) stayed on Classic Editor and have built their practices around the older editor model. Others (particularly those serving editorial publishers and content-marketing teams) embraced Gutenberg and have built block libraries, custom block plugins and block-based theme businesses on top of it.

The long-term verdict is that Gutenberg was the right strategic call shipped on the wrong timeline. The block paradigm was clearly the future of editorial CMSs; shipping it in late 2018 forced the WordPress ecosystem to make the transition years before it would have otherwise. Full Site Editing in WordPress 5.9 (January 2022) extended the block paradigm to themes, which produced its own round of compatibility friction and is still being absorbed by third-party theme authors. What got reverted, or quietly de-emphasised, was the original ambition to make Gutenberg the universal editing surface for plugins; many plugin authors built their UIs in React or vanilla JS outside the block model, and the core team has accepted that the block editor is one editing surface rather than the only one.

WordPress 6.x and AI integration 2024 to 2026

The 6.x release line, which started in May 2022 with WordPress 6.0 and is up to 6.7 as of mid-2026, has been an iteration cycle rather than a major-version disruption. The headline changes have been Full Site Editing maturity, performance improvements, and a deliberate slowing of the cadence to focus on quality rather than features.

The AI integration is the 2024-2026 story. WordPress 6.6, in July 2024, shipped the AI Assistant beta as an opt-in feature, with content generation, summarisation and translation hooks exposed to themes and plugins. WordPress 6.7, in November 2024, made the AI Assistant generally available and added prompt templates that themes could ship as part of their design tokens. The 6.8 and 6.9 cycles, planned for 2026, focus on agentic capabilities: editorial workflows where the AI can take multi-step actions across drafts, media, taxonomy and SEO metadata.

The implementation is deliberately provider-agnostic. The AI Assistant exposes a configuration surface for OpenAI, Anthropic, Mistral and self-hosted models. Hosts (WordPress.com, WP Engine, Pressable) ship their own provider integrations with bundled billing. Plugins (Jetpack AI, Elementor AI, Divi AI) ship parallel features that pre-date the core integration.

The strategic question for the project in 2026 is whether the AI integration becomes a credible default editorial assistant or whether it sits as a feature that plugins continue to outcompete. The answer is partly product execution and partly governance; if the WP Engine dispute keeps the core team’s attention divided, the AI roadmap slips. As of this writing the integration is shipping and is meaningfully used in the WordPress.com hosted product.

The headless WordPress segment has compounded in parallel. The REST API, integrated in WordPress 4.7 in December 2016, is the foundation; WPGraphQL, the community-led GraphQL endpoint, became the more popular API choice for new headless projects by 2023. Agency surveys in 2025-2026 put headless WordPress at roughly 8 to 12 percent of new deployments at the agency tier, with disproportionate adoption in publishing (CMI Media, Time Inc properties, several regional newspapers) and in commerce (WooCommerce headless via Next.js Commerce and Faust.js patterns). The Astro and Eleventy ecosystems have made WordPress-as-content-source a standard pattern, with the WordPress admin retained for editorial workflows and the front-end rendered through a separate build pipeline.

The native AI features in 6.6 and 6.7, combined with the headless deployment patterns, mean the 2026 WordPress is structurally different from the 2018 one. The editorial team still uses wp-admin; the AI Assistant suggests drafts, summaries and metadata; the published content is fetched through REST or GraphQL by a separately-deployed front-end; and the entire stack is held together by the same plugin and theme economy that made WordPress the dominant CMS in the first place. The newer Astro + WordPress hybrid (Astro fetching WordPress content at build time, then statically generating the public site) is a notable 2024-2026 pattern, used by sites that want WordPress’s editorial workflow without the runtime performance cost.

For more on the GPL ecosystem and on the early-2000s open-source culture that produced WordPress, see the open-source topic page and the WordPress topic archive.

FAQ

Who created WordPress?

Matt Mullenweg and Mike Little forked WordPress from b2/cafelog in May 2003. b2/cafelog had been written by Michel Valdrighi, who joined the WordPress project shortly after. Mullenweg went on to found Automattic in 2005; Little continued as a community contributor and runs the consultancy Zed1.com from Stockport in the UK.

What is the difference between WordPress.com and WordPress.org?

WordPress.org is the open-source project under the GPL, with code anyone can download and self-host. WordPress.com is a hosted service operated by Automattic that runs the same codebase, with managed hosting, a curated plugin and theme selection, and tiered pricing. The .org project is steered by the WordPress Foundation; .com is a commercial business owned by Automattic.

What is Gutenberg?

Gutenberg is the block-based editor introduced in WordPress 5.0 in December 2018, replacing the older TinyMCE classic editor. Content is composed of discrete blocks (paragraph, image, gallery, embed, custom blocks shipped by plugins) that can be rearranged, configured and reused. Full Site Editing, which extended the block paradigm to themes and site templates, shipped in WordPress 5.9 in January 2022.

Is WordPress still relevant in 2026?

Yes. WordPress in 2026 powers an estimated 43 percent of the open web according to W3Techs surveys, and the ecosystem around it (themes, plugins, hosts, agencies, page builders) is the most mature in open-source content management. The relevance question has shifted from ‘will WordPress survive’ to ‘will the next generation of editors choose WordPress, a JAMstack CMS, or a no-code builder’, and the answer varies by audience.