WordPress Doesn't Need a Fork. It Needs a Spine.
Every WordPress site starts the same way.
You install it. You stare at the dashboard. You spend the next hour installing plugins. One for SEO. One for security. One for analytics. Probably a page builder. A contact form. Maybe a caching plugin because someone online said you need one. Five to seven plugins before you've written a single word or design a single page.
This has been true for twenty years. We've normalized it so completely that most people don't even question it anymore. But normal doesn't mean good. It just means familiar.
WordPress core has had five years and millions of dollars worth of Gutenberg development. The block editor works reasonably well for blog posts now. But a fresh WordPress install in 2026 is still useless without a handful of plugins for things that should be basic.
SEO is meta tags and a form field. Two-factor authentication is a few hundred lines of code. Privacy-friendly analytics is a 2KB script. These are not unsolved problems. They're not technically difficult. They're not controversial. They're just... not there.
The reason they're not there is worth examining.
WordPress has a plugin ecosystem that generates enormous revenue. Yoast, Wordfence, WPML, Elementor: these are real companies with real employees and real business models, all built on filling gaps that WordPress core leaves open. The gap between what WordPress does and what a website needs isn't a bug: it's the business model. Billions of dollars depend on WordPress remaining incomplete.
I'm not saying there's a conspiracy. Nobody sat in a room and decided to keep WordPress deliberately limited. But incentive structures are powerful things. When the ecosystem profits from the gap, there's no economic pressure to close it. And so the gap persists, year after year, while the core team pours resources into editor features that serve developers more than users.
WordPress powers over 40% of all websites. That's not market share — that's infrastructure. When something runs that much of the web, the governance around it matters in ways that go beyond normal business competition.
The distribution platform — wordpress.org, where virtually all plugins and themes are published — is controlled by a single person. That person has used it as leverage in business disputes: blocking access, taking over plugins, banning contributors who disagreed publicly. Multiple core team members have resigned.
I'm deliberately not making this about one individual's character. People can disagree about who's right in any specific conflict. What's harder to disagree about is the structure itself. A platform that serves as critical infrastructure for 40% of the web shouldn't have a single point of control.
The WordPress community has always been stronger than its leadership. That's what makes it resilient. But resilience shouldn't be confused with good design. A system that works despite its governance isn't well-governed. It's just lucky.
For years I ran a review site that helped beginners set up their first WordPress websites. Every week, someone would follow my guide, pick a hosting provider, install WordPress, and hit the real wall: now what? I'd tell them to install a plugin for SEO for security, analytics, multi-language if they needed it. Each plugin with its own settings screen, its own update cycle, its own potential conflicts.
I kept doing this because there was no alternative. This was just how WordPress worked. You build the basics yourself from parts.
At some point it started to feel absurd. I was recommending a platform that required five separate add-ons before it could do what a website platform should do out of the box. Wix and Squarespace had figured this out years ago. They just... included the basics. WordPress, the most powerful CMS on earth, couldn't manage that.
So I looked inside those plugins. Not at the branding or the settings pages or the premium upsells. At the actual code. The mechanics of what they do.
And what I found was: it's not that complicated.
SEO is wp_head hooks and a meta box. Analytics is embedding a lightweight script. Two-factor auth is standard TOTP with zero external dependencies. These aren't massive engineering challenges. They're things someone just needs to sit down and build.
So I did.
SailWP is a WordPress theme that includes all of it. SEO with meta titles, descriptions, and structured data. Privacy-first analytics — Umami-based, zero cookies, no consent popups, no data leaving your server. Two-factor authentication. Multilingual support built into the dashboard. An AI page builder that generates pages from plain-language descriptions. A setup wizard that takes you from download to working site in about two minutes.
The total frontend payload is 94 kilobytes. CSS, JavaScript, and fonts combined. For context: Astra loads around 160KB. Kadence about 220KB. Divi comes in at 700KB. Elementor at 800KB. SailWP ships SEO, analytics, security, AI, and multilingual support in less than what most themes need for styling alone.
It's free. GPL v2+. No premium tier, no upsell, no account required. Download, upload, run the wizard.
I'm not describing it because I think you should use it. I'm describing it because it's evidence for an argument: the gap between what WordPress offers and what users need is not a hard engineering problem. One person, working alone, can close it. The fact that it hasn't been closed in twenty years tells you something about the incentive structure, not about the difficulty.
SailWP is deliberately not on wordpress.org.
This isn't a protest. It's an architectural decision. When a distribution platform has been used as leverage in personal and business disputes — when access can be revoked unilaterally, when plugins can be taken over, when contributors can be banned for disagreeing — the rational response is to reduce your dependency on that platform.
Direct distribution is simpler anyway. One download link, no middleman, no review process that can be weaponized. It means giving up the discoverability of the plugin directory, which is a real cost. But independence has value too, especially when the alternative is building on someone else's goodwill.
The broader principle applies beyond my particular project. Any WordPress developer distributing exclusively through wordpress.org is making a bet on the continued good behavior of a single individual. That may be a fine bet. It also may not be. The point is that it's a bet, and most people don't realize they're making it.
The most common objection to SailWP — and to any theme that bundles functionality — is that themes should handle presentation, and plugins should handle functionality. Separation of concerns. It's a real principle, and it has real merit.
But it's a developer principle, not a user principle.
The person who just wants to get their bakery online doesn't care whether SEO settings live in a theme panel or a plugin panel. They care whether the site works. They care whether it shows up in Google. They care whether it loads fast. The distinction between "theme functionality" and "plugin functionality" is invisible to them, and it should be.
Separation of concerns serves developers who need to swap components independently. It serves the ecosystem by creating clear boundaries between products. These are legitimate concerns. They're just not the user's concerns.
SailWP stores SEO data in standard post_meta, not in theme options. Switch themes and your meta titles, descriptions, and schema markup are all still there. The data is portable. The architecture respects the principle even if the packaging doesn't.
And every feature is modular. Want to use Yoast instead? Turn off the built-in SEO. Prefer a different analytics solution? Disable the built-in one. The theme doesn't lock you in. It just saves you from having to lock yourself into five separate products on day one.
WordPress isn't broken. I still use it every day. I still recommend it. It remains the most powerful and flexible CMS available, and its open-source foundation is genuinely valuable.
But the ecosystem around it is more fragile than most people realize. The governance is concentrated. The incentive structure favors complexity over simplicity. The platform that distributes critical software to 40% of the web has been treated as a personal tool by the person who controls it.
The answer to this isn't a fork. Forks are dramatic, resource-intensive, and they fracture communities. WordPress doesn't need to be replaced. It needs independent builders who close the gaps that the core team won't, and who distribute their work through channels that can't be unilaterally controlled.
SailWP is my small contribution to that. Not the only answer. Not necessarily the best answer. One theme, one person, trying to make WordPress a little less dependent on things outside its control.
The best part of open source is that anyone can do this. Not everyone will agree with my approach, and that's fine. Some will build better plugins. Some will advocate for changes in core. Some will create entirely new platforms. All of those responses are valid. The only response that isn't valid is pretending the problem doesn't exist.
WordPress doesn't need a fork. It needs a spine. A willingness to build what's needed, distribute it independently, and stop waiting for permission from a system that has proven it can't be fully trusted.
That's what I'm trying to do. It's what I think more people should try.