Open Source Software

Is WordPress Really Open Source? A Complete Guide

Ask ten people whether WordPress is open source and you will get ten confident answers, several of which are wrong. The confusion is understandable. There are two websites with almost the same name, a company that profits enormously from the software, a foundation that owns the trademark, and a licence that most site owners have never read. In 2024 the whole arrangement came apart in public and a lot of people discovered that they had misunderstood how the thing they depend on is actually governed.

This guide is an attempt to answer the question properly. Not the marketing answer, and not the licence-lawyer answer either, but the one that a person running a real website actually needs. It covers where the software came from, what the GPL obliges you to do, who holds the levers, what the freedoms mean when you are the one paying the hosting bill, and where the model genuinely falls short.

It is long. Use the links below to jump to whatever you came for.

The short answer

Yes. WordPress is free software released under the GNU General Public License, version 2 or later. You can download the whole thing, read every line, change whatever you like, run it on any server you can get your hands on, and give your modified version to other people. Nobody can revoke that. There is no licence key, no seat count, no audit clause, and no vendor who can decide you are no longer a customer and switch you off.

That is the part people get right. The part they get wrong is assuming that open source licensing also guarantees open governance. It does not. The licence governs the code. It says nothing about who decides what goes into the next release, who runs the plugin directory, who owns the trademark, or who can remove a company’s access to the update servers. Those are separate questions with separate answers, and some of those answers are uncomfortable.

So the honest version is that the software is unambiguously open source, and the project around the software is something more complicated. Both facts matter. If you only know the first one you will be surprised by events like the 2024 fallout. If you only know the second you will talk yourself out of a genuinely good platform.

Where WordPress came from

WordPress exists because someone abandoned a different project.

In 2002 a French developer named Michel Valdrighi was maintaining a small blogging tool called b2, sometimes written b2/cafelog. It was PHP, it stored posts in MySQL, and it had a modest but genuine following. Then Valdrighi went quiet. Development stopped. For a proprietary product that would have been the end of the story, and every user would have been stuck with whatever version they had.

b2 was released under the GPL, so it was not the end of the story. In January 2003 a nineteen year old Texan named Matt Mullenweg wrote a short blog post saying he was thinking about forking it. An English developer, Mike Little, replied to that post offering to help. That exchange is the founding document of a piece of software that now runs a substantial fraction of the web. The name was suggested by Christine Selleck Tremoulet, a friend of Mullenweg’s. The first release came out on 27 May 2003.

The detail worth sitting with is that none of this required anybody’s permission. Mullenweg did not have to negotiate with Valdrighi, buy anything, or sign anything. The licence already granted the right to fork, in advance, to everyone. Valdrighi later joined the WordPress project himself, which is a pleasant ending, but the fork would have been equally legitimate if he had objected.

That is the single most useful thing to understand about open source. It is insurance against abandonment. Every proprietary tool you use carries a quiet risk that the company behind it will be acquired, change direction, or simply stop caring. Open source does not remove that risk, because maintainers burn out and communities fragment. What it removes is the situation where the code dies with the company and you have no recourse at all.

The years that shaped it

A few moments did more than others to make WordPress what it is.

Plugin support arrived in 2004, in version 1.2. This is arguably the most consequential decision in the project’s history, and it happened early. By defining a way for outside code to hook into core behaviour without editing core files, WordPress made itself extensible by people who would never contribute to the main codebase. Almost everything WordPress became afterwards follows from that.

Also in 2004, the main competitor at the time, Movable Type, changed its licensing terms in a way that alarmed its users. A meaningful number of them migrated. Timing matters in software adoption, and WordPress had working plugin support and a free licence at exactly the moment a lot of bloggers went looking for an alternative.

Themes as a distinct, swappable layer came in 2005 with version 1.5, separating what a site looks like from what it does. Automattic, the company Mullenweg founded to build a commercial hosted service on top of the open source project, was also created in 2005. Custom post types in version 3.0 in 2010 quietly turned a blogging tool into a general content management system, because suddenly a “post” could be a product, a property listing, or a staff profile.

The REST API, which landed in stages around 2015 and 2016, let other software read and write WordPress content over HTTP. That made it possible to use WordPress purely as a content store behind an application written in something else entirely. And the block editor, shipped in version 5.0 in December 2018, was the largest and most divisive change the project has ever made. It gets its own section further down.

What the GPL actually requires

The GNU General Public License is the legal instrument that makes all of this work, and it is widely misunderstood in both directions. Some people think it means nobody can charge money. Others think it is a formality they can ignore. Both are wrong, and the second one occasionally ends up in court.

The GPL grants four things. You may run the software for any purpose. You may study how it works and change it, which requires access to the source code. You may redistribute copies. You may distribute your modified versions. Richard Stallman and the Free Software Foundation wrote it to guarantee those freedoms permanently rather than as a favour that could later be withdrawn.

The mechanism that makes it permanent is the condition attached to the third and fourth freedoms. If you distribute the software, modified or not, you must pass on the same freedoms you received, and you must make the source available. You cannot take GPL code, improve it, and ship the result under terms that forbid your users from doing what you just did. This is what people mean by copyleft. The licence uses copyright law to force openness rather than to restrict copying.

Free as in freedom, not as in zero dollars

Selling GPL software is entirely permitted. The licence has never said otherwise. What you cannot do is sell it and then deny your buyer the rights the licence grants them. A customer who buys a GPL plugin from you is free to give it away to everyone they know, and you have no legal ground to stop them.

This sounds like it should have destroyed the commercial WordPress market. It did not, and the reason is instructive. Almost nobody in the premium plugin business is really selling the bytes. They are selling updates, support, documentation, and the reassurance that somebody will fix it when it breaks. Those things are not covered by the licence and cannot be freely redistributed. You can hand your friend a copy of a premium plugin quite legally, but you cannot hand them the developer’s support queue.

There is a thriving grey market in redistributed premium plugins, often marketed as “GPL clubs”, and it is generally lawful as far as the code goes. It is also a genuinely bad idea, because you have no way of knowing what was added to the copy before it reached you, and the update channel is exactly the mechanism a determined attacker would want to compromise. Legal and safe are different questions.

Version 2 or later, and why that phrase is there

WordPress is licensed under GPLv2 or later. That trailing phrase gives anybody receiving the code the option to use it under version 3 instead, which closed some loopholes around hardware that refuses to run modified software and added explicit patent provisions. In practice the WordPress project has stayed on version 2, and the flexibility is mostly theoretical. It is worth knowing the phrase is there, because “GPLv2 only” and “GPLv2 or later” are meaningfully different and people quote them carelessly.

WordPress.com and WordPress.org are not the same thing

This trips up more people than any other aspect of WordPress, including people who have run WordPress sites for years. The two names differ by three letters and the distinction between them is fundamental.

WordPress.org is the open source project. It is where the software is developed and downloaded, where the plugin and theme directories live, where the documentation sits, and where the volunteer teams organise. Download from there, install it on hosting you control, and you are running what people call self-hosted WordPress. You have complete access to the code, the database, and the server.

WordPress.com is a commercial hosted service operated by Automattic. It runs a version of the same software, but it is a product with plans, tiers, and terms of service. On the cheaper tiers you cannot install arbitrary plugins or themes, you may not have direct database access, and Automattic may place advertising on your site. Higher tiers remove most of those limits at a price.

Neither is dishonest, and WordPress.com is a perfectly reasonable choice for plenty of people who do not want to think about servers. The problem is purely one of naming. Someone signs up for WordPress.com, hits a restriction, and concludes that WordPress cannot do the thing. Very often WordPress does it fine and the hosting plan does not allow it. Whenever you read that WordPress “will not let you” do something, check which WordPress is being discussed.

The confusion is not accidental in its effects, whatever the intent. A commercial service carrying the name of the open source project it is built on gains enormous marketing value from that association. This is one of the threads that eventually pulled loose in 2024.

Who actually controls WordPress

Here is where the tidy story about community-driven software meets the organisational chart.

The WordPress Foundation is a non-profit established in 2010. It holds the WordPress trademark and runs the WordCamp events programme. Its stated purpose is to ensure the software remains free in perpetuity.

Automattic is a private company, also founded by Mullenweg, which operates WordPress.com, Jetpack, WooCommerce, Akismet, Tumblr and a good deal else. It is valued in the billions and employs a large number of the people who work on WordPress core.

The contributor community is everyone else. Thousands of volunteers and sponsored employees spread across core development, accessibility, documentation, translation, support, design, security and the plugin review team.

Matt Mullenweg is simultaneously the co-founder of the project, the chief executive of Automattic, and the person who leads the open source project in the role commonly described as benevolent dictator for life. He has decisive influence over the Foundation, the company, and the project. There is no elected board with authority over technical direction, no formal appeals process, and no mechanism by which the community can outvote him.

Concentrated leadership is not automatically bad. Linux has Linus Torvalds, Python had Guido van Rossum for decades, and design coherence is genuinely hard to achieve by committee. Plenty of projects with elaborate governance structures produce worse software more slowly. But it does mean that when you choose WordPress you are placing a degree of trust in specific individuals and a specific company, and it is better to know that going in than to discover it during a crisis.

The important counterweight is the licence. Whatever happens at the top, the code that has already been released stays free, and the right to fork is permanent. That is not a hypothetical comfort. It is the same right Mullenweg himself exercised in 2003.

The four freedoms, tested against reality

The four freedoms get recited a lot in open source writing and they can start to sound like liturgy. It is more useful to ask what each one actually does for a person running a website.

Freedom to run it

No licence server, no activation, no per-site fee, no restriction on commercial use. Install it on a thousand sites if you like. For agencies this is the difference between a viable business model and an unviable one, and it is why so much of the small web development industry standardised on WordPress in the first place.

Freedom to study it

Every line is readable. When something behaves strangely you can open the file and find out why rather than filing a ticket and waiting. When a plugin misbehaves you can inspect it before deciding whether to trust it. For anyone doing a security review this is the whole game, because you are not reduced to guessing at a black box.

The realistic caveat is that this freedom is worth much more to people who can read PHP than to people who cannot. Most site owners will never exercise it directly. They benefit indirectly, because other people do.

Freedom to modify it

You can change anything. In practice you should almost never change core, because your changes will be overwritten at the next update and you will have made your site unmaintainable. The hook system exists precisely so that you can alter behaviour without touching core files. Modifying core is the freedom equivalent of a fire axe, and the fact that it is available matters more than how often it gets used.

Freedom to share it

You can redistribute WordPress and anything you build on it. This is what produced the ecosystem. Tens of thousands of free plugins and themes exist because sharing them was permitted by default rather than negotiated case by case.

How the software is put together

You do not need to be a developer to benefit from a rough mental model of the architecture, because it explains why certain advice keeps getting repeated.

At the bottom is core, the software you download. It handles users, content storage, the database layer, the admin interface, and the rules by which everything else attaches itself. Core is the part you should treat as untouchable.

Above that sits the theme, which controls presentation. Classic themes use PHP template files. Block themes, which arrived with full site editing in version 5.9 in early 2022, use HTML templates composed of blocks and a configuration file that defines colours, spacing and typography. This site runs a block theme, which is why its header and footer are editable in the same interface as its pages.

Plugins add functionality. A plugin can be twenty lines that change one label or a hundred thousand lines that turn the site into a shop.

Holding it together is the hook system, made up of actions and filters. An action lets your code run at a defined moment, such as when a post is saved. A filter lets your code intercept a piece of data and hand back a modified version, such as changing the excerpt length. Nothing has to modify anything else in place. That single design decision is why a WordPress site can run thirty plugins written by thirty strangers who have never communicated, and mostly survive.

Mostly. Plugins that hook the same thing in incompatible ways do conflict, which is why the standard diagnostic advice is to deactivate everything and switch on one plugin at a time. The architecture makes coexistence possible rather than guaranteed.

Child themes, and the mistake everyone makes once

If you edit a theme directly, the next theme update will erase your work. A child theme is a thin wrapper that inherits everything from its parent and overrides only what you specify, so your changes survive updates. Almost every experienced WordPress developer has learned this by losing something, usually late at night. Consider this your chance to learn it the cheap way.

The plugin ecosystem and the licence question

The official plugin directory holds tens of thousands of free plugins, and the commercial market alongside it is larger still. This is WordPress’s greatest advantage and its most reliable source of problems, for the same reason. Anybody can publish.

Directory submissions are reviewed by a volunteer team before first publication, and plugins found to contain serious vulnerabilities get closed. That is a real safeguard and it is not the same as an ongoing audit. A plugin can pass review in 2019, be abandoned by its author in 2021, and still be sitting on your site collecting dust and known vulnerabilities in 2026.

How to judge a plugin before installing it

The directory shows you everything you need, and most people look at the wrong field. Install count is the least useful number on the page. Check when it was last updated, because anything untouched for more than a year deserves suspicion. Check whether it declares compatibility with a recent WordPress version. Read the support forum rather than the reviews, since reviews capture enthusiasm at install time and the support forum captures what happens six months later. Look at how the developer responds to bug reports, or whether they respond at all.

Then ask the question that saves the most grief. Do I actually need this. Every plugin is code running on every page load, another update to track, another author to trust, and another candidate when something breaks. A site with eight well-chosen plugins is easier to keep secure and fast than a site with forty.

What plugins are actually for

The useful ones tend to solve a problem the site owner can describe in one sentence. Contact forms. Backups. Caching. Search engine metadata. Ecommerce.

A good example of the narrow, single-purpose kind is attribution tracking. If you run any advertising, a contact form on its own will tell you that somebody enquired but not where they came from, which means you cannot tell which campaigns are working. A plugin such as LeadSource captures the UTM parameters and referrer from the visitor’s session and attaches them to the form submission, so the enquiry arrives with its origin story intact. It is a small piece of functionality that would be tedious to build by hand, which is exactly the territory where plugins earn their place.

Do plugins have to be GPL

This argument has been running for fifteen years and it is not fully settled.

The position held by the WordPress Foundation, supported by an opinion the Software Freedom Law Center provided in 2009, is that PHP code in a plugin or theme is a derivative work of WordPress, because it cannot function without calling WordPress functions, and must therefore be GPL. Under the same reasoning, assets that do not depend on WordPress to work, such as stylesheets, images and JavaScript, may be licensed separately. This is why you see premium themes described as split licence.

Not everyone accepts the reasoning, and it has never been tested in court for WordPress specifically. It came closest in 2010, when Chris Pearson, author of the Thesis theme, argued publicly with Mullenweg that Thesis was not a derivative work of WordPress. Pearson moved Thesis to a split licence that year, putting the PHP under the GPL while keeping JavaScript and CSS proprietary. A later version of Thesis returned to proprietary licensing. The dispute clarified the project’s position without establishing a legal precedent, which is roughly where things still stand.

For practical purposes, anything distributed through the official directories must be GPL compatible, and that covers most of what most people install.

Gutenberg, and why people got so angry

In December 2018, WordPress 5.0 replaced the editor that users had known for fifteen years with a block-based one named after the printing press. The reaction was ferocious.

The rationale was sound enough. The old editor was a single text field with a formatting toolbar, and everything beyond basic formatting had been bolted on through shortcodes, custom fields, and page builder plugins. Building anything visually interesting meant learning a proprietary builder or writing HTML. Meanwhile Squarespace and Wix were showing people that layout could be a matter of dragging things around. Blocks were an attempt to bring structured, visual editing into core, where it would be standard rather than dependent on whichever builder your developer happened to like.

The execution is what caused the trouble. The first release was slow, the accessibility problems were serious enough that the accessibility team lead, Rian Rietveld, resigned in October 2018, citing the difficulty of getting accessibility work done on Gutenberg, and the workflow of people who wrote in plain text or relied on custom fields was disrupted with no obvious gain to them. The Classic Editor plugin, offered as a transitional measure, was installed on millions of sites and its promised end-of-support date has been extended more than once. That tells you something about how the transition went.

Several years on, the editor is substantially better. Full site editing extended the block model to headers, footers and templates, which is genuinely powerful and lets a site owner change the whole layout without touching PHP. The accessibility situation has improved. A lot of the original criticism has been addressed.

The episode is worth remembering for what it shows about the governance question rather than the editor. A change of that magnitude was pushed into core over sustained objections from experienced contributors, on a timeline set from the top. Open source licensing did not give the community a veto, because licensing was never the mechanism for that. Anyone who assumed otherwise learned something.

Security when everyone can read the code

“If anyone can read the source, surely attackers can find holes more easily.” It is the first objection people raise and it deserves a straight answer rather than a slogan.

Attackers can indeed read the code. So can everybody else. Eric Raymond’s formulation in The Cathedral and the Bazaar, “given enough eyeballs, all bugs are shallow”, is optimistic but not baseless. Vulnerabilities in WordPress core are typically found, reported and patched quickly, and core has a dedicated security team plus a bug bounty programme. Automatic background updates for security releases have been standard since version 3.7 in 2013, which means a large share of the installed base gets patched without anyone doing anything.

The honest counterpoint is that visible code does not audit itself. The eyes have to actually be looking, and for an abandoned plugin with four hundred users nobody is looking at all. Core is scrutinised heavily. The long tail of the plugin directory is not.

Which is why the statistics are so lopsided. Year after year, analyses of compromised WordPress sites find that the overwhelming majority of breaches trace back to vulnerable plugins and themes, weak credentials, or outdated installations, rather than to flaws in current core. WordPress sites get hacked far more often than WordPress does.

What actually keeps a site safe

Keep core, plugins and themes updated, and treat that as routine maintenance rather than an occasional project. Delete anything you are not using, because a deactivated plugin still has files on the server. Use strong unique passwords with two factor authentication on every administrator account. Give people the lowest role that lets them do their job, since not everyone who writes needs to be an administrator. Run backups that are stored somewhere other than the server being backed up, and test a restore occasionally, because an untested backup is a hope rather than a plan. Choose hosting that takes security seriously.

None of that is exotic and all of it is boring, which is precisely why it gets skipped.

The newer problem of automated traffic

Something has changed in the last few years that the older security advice does not cover. A large and growing share of traffic to the average website is now automated, and much of it comes from crawlers gathering training data or answering questions on behalf of AI assistants. Some identify themselves honestly and respect robots.txt. Others disguise themselves as ordinary browsers and ignore it entirely.

Whether you want to allow that traffic is a genuine editorial and commercial decision, not a purely technical one. Some site owners are glad to be cited by AI systems. Others object to their work being ingested without attribution or payment, and others simply want the server load back. What almost everyone lacks is visibility, since standard analytics packages are built around human visitors and quietly discard most bot traffic before you ever see it.

Tooling for this is starting to appear. A plugin such as Forge AI Bot Log logs which AI crawlers are hitting a site, verifies whether they are genuinely who they claim to be rather than trusting the user agent string, and provides the option to block them. The verification step matters, because spoofing a well-known crawler’s identity is trivial and blocking by name alone achieves very little. Whatever you decide about access, knowing what is actually visiting your site is a reasonable starting position.

The 2024 dispute and what it exposed

In September 2024 the tension between the open source project and the commercial interests around it stopped being theoretical.

Mullenweg publicly attacked WP Engine, one of the largest specialist WordPress hosts. In a post published on 21 September 2024 he wrote that “This is one of the many reasons they are a cancer to WordPress, and it’s important to remember that unchecked, cancer will spread.” He had made similar criticisms of the company, and of its investor Silver Lake, in his WordCamp US keynote the previous day. The stated grievances were that WP Engine contributed too little back relative to its revenue, that it disabled post revisions by default, and that its branding traded on the WordPress trademark. Demands for trademark licensing payments were made. WP Engine sent a cease and desist. Automattic sent one back.

Then came the part that genuinely alarmed people. WP Engine was blocked from accessing WordPress.org’s servers, which meant sites hosted there could not install or update plugins and themes through the normal channel until workarounds were put in place. Shortly afterwards, a popular commercial plugin called Advanced Custom Fields, developed by WP Engine, was taken over in the plugin directory and replaced with a fork renamed Secure Custom Fields. Users who had installed Advanced Custom Fields found the update channel now pointing at software maintained by someone else.

Lawsuits followed. Employees left Automattic. The details continued to develop well past the initial flashpoint.

You can argue the merits either way, and reasonable people did. Large hosts profiting heavily from volunteer labour while contributing modestly is a real problem in open source generally, not an invented grievance. Equally, taking control of a plugin listing that thousands of sites update from is a serious act, whatever the provocation.

What is not really arguable is the structural lesson. The GPL protected the code exactly as designed, and nobody’s existing installation stopped working. But the licence never covered the distribution infrastructure. The plugin directory, the update servers, the trademark and the .org domain are not community property in any enforceable sense, and in a dispute they turned out to be levers that could be pulled unilaterally.

If you take one practical thing from this section, make it this. Open source protects your right to the software. It does not by itself guarantee your access to the convenience layer built around it. Those are worth valuing separately.

What open source means when it is your website

Strip away the philosophy and several concrete advantages remain.

You are not locked to one supplier

This is the big one and it is chronically underrated until the day it matters. On a proprietary platform, your site is built in someone else’s system, and if the relationship sours your options are to stay or to rebuild from nothing. With WordPress, your site is a database and a directory of files that run on ordinary hosting. Any competent developer anywhere can pick it up.

That changes the commercial relationship in your favour. If you engage a firm of website designers to build a WordPress site, you can move to another provider later without discarding the work, because the platform belongs to you rather than to them. Good agencies are relaxed about this, since they would rather keep clients by being useful than by holding the site hostage. The ones who resist are telling you something.

Nobody can discontinue it

Proprietary platforms get shut down, acquired, or repriced. Anyone who built on a platform that later closed knows the feeling. WordPress cannot be withdrawn, because the code is already distributed under a licence that cannot be revoked. In the worst imaginable governance scenario, the community forks and continues. That is not a fantasy, since it is how WordPress itself began.

A large market keeps prices honest

Because anyone can host WordPress, hosting is fiercely competitive at every price point. Because anyone can learn it, developers are plentiful and rates vary accordingly. Because anyone can write plugins, most common problems have several solutions at several prices. Compare that to a closed ecosystem where the vendor sets the terms for everything.

Owning your data, and what portability really buys you

On self-hosted WordPress your content lives in a MySQL or MariaDB database you control, and your uploads sit in a folder on your server. You can take a full copy at any time without asking anyone. There is an export tool built in, and for anything serious you take a database dump and copy the uploads directory.

Worth being precise about what that gets you, because portability claims are often oversold. Your content is genuinely portable and moving between WordPress hosts is routine. Moving to a different platform entirely is harder, because your layout lives in blocks and theme templates, your functionality lives in plugins, and none of that transfers. What survives is the valuable part, meaning the words, the images, the URLs and the structure. Rebuilding presentation is annoying. Losing a decade of content is fatal.

The other quiet benefit is that you can see the database. If you want to know exactly what personal information your site holds, which matters under the New Zealand Privacy Act and equivalents elsewhere, you can look. Not every hosted platform makes that straightforward.

The costs nobody mentions

WordPress is free. A WordPress site is not, and pretending otherwise sets people up for disappointment.

You will pay for hosting and a domain name, which is unavoidable. You will probably pay for a premium theme or a few premium plugins, since the free versions often stop just short of what a business needs. If you are not doing it yourself you will pay for design and development, which is usually the largest line item.

Then there is the cost that gets left out of every quote, which is ongoing maintenance. Updates need applying, backups need checking, broken things need fixing, and security needs attention. On a proprietary hosted platform that work is bundled into the subscription and invisible. On self-hosted WordPress it is yours, either as your own time or as somebody’s retainer.

This is the single most common way WordPress projects go wrong. A site gets built well, launched proudly, and then left alone for three years until it is running outdated everything and something finally gives. The freedom to run your own software is also the responsibility to run your own software. Budget for it at the start, because the alternative is paying more later under worse conditions.

Six common misconceptions

“Open source means amateur”

Linux runs most of the internet’s servers and every Android phone. Firefox and Chromium are open source at their core. PostgreSQL, Git, Kubernetes and Python are all open source and all industrial infrastructure. The model is how a great deal of serious software gets built, and has been for thirty years. WordPress core is written by paid professionals at large companies alongside volunteers, and the code review process for core is stricter than most private codebases manage.

“WordPress is just for blogs”

This was true in 2005 and has not been true since custom post types arrived in 2010. WordPress now runs news organisations, universities, government departments, membership systems, learning platforms and a very large number of online shops through WooCommerce. The blog heritage shows in some of the terminology, which is why you will find a “Posts” menu on a site that has never published a blog post, but the capability question was settled long ago.

“Open source software is insecure”

Covered at length above, and the short version is that the security record of WordPress core is good while the security record of neglected third party plugins is poor. Blaming the platform for the latter is like blaming the road for an unwarranted car. Security through obscurity, meanwhile, has a worse track record than open review, because obscurity fails silently and you find out at the worst possible moment.

“There is no support”

There is no single vendor obliged to answer your call, which is a real difference. What exists instead is documentation, active support forums, a large body of published writing, and a global market of professionals who will support you commercially. For many organisations a paid relationship with a developer who knows your site beats a general support desk that does not.

“WordPress is slow”

WordPress can be slow, usually because of cheap hosting, an overloaded theme, too many plugins, or enormous unoptimised images. A well built WordPress site on decent hosting with caching is fast. The platform gives you plenty of rope, and slow sites are generally a result of how it was used rather than what it is.

“Because it is open source, the community decides”

The most important misconception on the list, and the reason so many people found 2024 shocking. The licence guarantees your rights to the code. It does not create a democracy. Decisions about core direction, the plugin directory and the trademark are made through structures that concentrate authority narrowly. You can fork, and forking is a real right, but forking a project of this scale is a heavy undertaking rather than a casual option.

When WordPress is the wrong choice

Any guide that recommends one tool for every situation is selling something. There are cases where WordPress is a poor fit, and recognising them early saves a lot of money.

A genuinely static site with no editors. If a site is a handful of pages that change twice a year and only a developer will ever touch them, a static site generator will be faster, cheaper to host and effectively immune to the entire category of attacks that target dynamic applications. WordPress earns its complexity when non-technical people need to publish.

A web application rather than a website. If the core of what you are building is complex interactive functionality with unusual data relationships, and content publishing is incidental, you are likely fighting the platform. WordPress can be bent into an application framework, and people do it, but a purpose-built framework will fit better.

Nobody will maintain it. This is the one people ignore. If there is genuinely no budget and no person to apply updates and check backups, self-hosted WordPress will degrade into a liability. A fully managed hosted platform, with less freedom and someone else handling maintenance, is the more honest choice. Choosing freedom you cannot exercise is not a win.

Very unusual scale or compliance requirements. WordPress runs at large scale, but if you have extreme traffic patterns or regulatory constraints that dictate particular architectures, the decision belongs with people who know the specifics rather than with a general guide.

How to contribute, if you want to

The thing most people miss is that writing code is a minority activity in the project. WordPress is organised into contributor teams covering core, design, accessibility, documentation, support, polyglots for translation, themes, plugins, marketing, training and more. Most of those need skills other than PHP.

Answering questions in the support forums is the most immediately useful thing a knowledgeable user can do. Translation work is enormously valuable and chronically short of hands, and it is how WordPress ended up available in so many languages. Documentation always needs improving. Testing beta releases and filing clear bug reports takes little expertise and saves developers real time. Reporting a security issue responsibly through the proper channel is a contribution too.

Companies that depend commercially on WordPress can sponsor staff time through the Five for the Future initiative, which asks organisations to direct five percent of their resources back into the project. Whether enough of them do is exactly the argument that ignited in 2024.

If you only ever do one thing, keep your own sites updated. A patched site is one fewer machine available to whoever is assembling the next botnet, and that is a small contribution to everyone’s security.

Common questions

Is WordPress free forever

The software, yes. Every version already released is under a licence that cannot be revoked, so even a hostile future owner could not make existing code proprietary. They could change the licence on future versions, at which point the community would fork the last free release and carry on. Hosting, domains and professional help are separate costs and always will be.

Can I use WordPress commercially without paying anyone

Yes. Build client sites, run a shop, charge whatever you like. There is no commercial restriction and no revenue threshold. If you distribute modified WordPress code you must pass on the same licence, but running a site is not distribution.

Do I have to release my custom theme publicly

No. The GPL’s obligations trigger on distribution. A bespoke theme built for one client and installed on their site is not being distributed to the public, so nothing needs publishing. If you sell it to many customers, the PHP portions should be GPL under the project’s position, though your customers are unlikely to be the ones enforcing that.

What happens if Automattic disappears

Your site keeps running, because it does not depend on Automattic to function. The project would face real disruption, since Automattic sponsors a lot of core work and operates infrastructure. But the code is distributed across millions of installations and the licence permits anyone to continue it. Disruption, not extinction.

Is self-hosted WordPress better than WordPress.com

Better at different things. Self-hosted gives complete control and complete responsibility. WordPress.com trades some control for someone else handling maintenance. If you have technical capability or a developer, self-hosted is usually the better long term position. If you have neither and want to write, the hosted service is a reasonable answer and you can migrate later.

Should the 2024 dispute change my decision

It should inform it rather than decide it. The episode revealed that project governance is more centralised than the open source framing implies, which is worth knowing. It did not break anybody’s website, did not affect the licence, and did not remove anyone’s right to their own installation. Weigh it as a governance risk alongside the substantial practical advantages, and note that every platform carries governance risk. Most of them just do not argue about it publicly.

Where this leaves things

WordPress is open source in the way that matters most. The licence is real, the rights it grants are permanent, and no company can take your website away from you or charge you rent for software you already have. Twenty three years of history, an enormous ecosystem and a genuinely low barrier to entry are not nothing.

It is also a project with concentrated leadership, commercial interests woven closely into its non-profit structures, and a distribution layer that turned out to be less neutral than most people assumed. Those things are true at the same time. Anyone telling you WordPress is a pure community endeavour is skipping the interesting part, and anyone telling you the licence is meaningless is skipping the part that actually protects you.

Understand both halves and it is a very good platform to build on, with your eyes open.

A note on how this was made. This article was drafted with the assistance of AI and reviewed before publication. Version numbers, dates and the sequence of events described were checked against primary sources at the time of writing. Where a question remains genuinely unsettled, such as whether plugins are legally required to be GPL, that has been described as unsettled rather than resolved in either direction.