After a fun but high-speed week at WooCommerce, I’m left thinking about the tradeoffs of using open source vs proprietary software. Don’t get me wrong, they’re good tradeoffs. But they’re tradeoffs.
You’ll often see this cycle when someone with an audience dives into an open source community: they start by loudly voicing complaints on Twitter, criticizing the lack of whatever specific feature is most important to them or the project management generally. It takes a lot of the same conversations until they ultimately come to a place of understanding about how the whole thing works. I go through it sometimes, too. Believe it or not, some community veterans are still running through the cycle from time to time.
Here’s my theory about why that is.
With most of the proprietary software we’re used to, you’re renting access to the software. If you want something different from the software’s owners, you must demand it from them. Twitter callouts actually work pretty well here (and they’re also great for building your own audience). Enough demand (or market pressure or churn) and the software owners may deliver what you want.
Then there’s the counter example and the central premise of open source- the software is yours, you own it. So now you get free access to software, but if you want something different, you can either wait for it or do it yourself. You’d think that means worse software, but often it can be the opposite.
The team at Ollie released their Menu Designer on the WordPress plugin repo recently. Some people in the community found bugs or wanted enhancements, and within days they had submitted PRs themselves for what they wanted done. For free. Free code for free code, or what DHH calls the open source gift exchange. What an amazing deal for both sides and the central value of open source.
There’s always people who want to use public pressure to demand something from open source software, like there’s some sort of board of investors worried about consumer trends or about their valuation, but it doesn’t work that way. Open source typically does what it wants (see Ruby on Rails, Laravel, Linux, etc). It reflects the concerns of the primary contributors first, the broader consumers second. That doesn’t mean every decision is right, by the way.
What’s been unique about WordPress, though, is that while it’s open source, it also appeals to such a large and diverse audience that some large segment of its user base doesn’t come from the same OSS school of thought. They treat it like some proprietary software afraid of losing paying customers.
Beyond that, WordPress always been uniquely extensible. This feels related to, but is ultimately different from, being open source. Extensibility means we can use hooks and filters to change or add functionality. It’s how you get entire ecosystems like Elementor or Kadence built on top of WordPress, and entire segments of users who aren’t even aware they’re using this thing called WordPress.
The extensibility is a large value proposition, but extensibility is not synonymous with open source. Plenty of closed platforms are extensible, they have APIs and app stores. The difference is that if something isn’t extensible in the way that I want it to be, like iOS for example, I can’t crack it open and submit a patch that gives me the exact flexibility I need. With open source software, you can. You’re not guaranteed it’ll get merged, but you can build and advocate for it or, at the very least, fork the software and run your own modified version.
That’s what it means to say that you “own” your WordPress code. It doesn’t mean you own the direction of the entire project (I wish I did), but you own your own instance of it and can do whatever you want with it. If you don’t like the block editor, turn it off. There’s plenty of other good options, and they’re all going to be very different.
WordPress is big and it’s grown because of- and suffered from- this balkanization of experiences. Separate islands of users. Separate mini-ecosystems that were able to be focused on a specific user segment, but also fed to the overwhelming user experience we now have- plugin overload, aggressive admin notices, disjointed user interfaces that look like separate apps.
This was one of the fundamental concepts of the block editor- one consistent design system instead of a million plugins with a million idiosyncrasies. A consistent and compatible approach on the front end and in the content editor.
As my colleague Birgit mentioned in our recent conversation at WCUS, if you want to go fast, go alone. If you want to go far, go together. I wish things moved faster, and sometimes it is good to move fast on an idea, just to see where it leads. But the goal should be bigger than that, we should be trying to create a better ecosystem, from core upwards.
To take a more recent example, WooCommerce could’ve released it’s own AI tools and MCP integration months ago, but then what? It would’ve had it’s own framework, different from the rest of the WordPress ecosystem. Another UI, another way to extend, more work for anyone who wants to be compatible with it. Then porting it back to WordPress core’s approach would’ve had to fight to be another development priority? But now it’s almost here and it’s built on the same tools as WordPress, the same tools for the entire ecosystem.
AI is going to be the next major user interface. I don’t want a different AI setup for my page builder, for my forms and CRM, for my store, for my analytics plugin. I don’t want more balkanization of experiences inside of WordPress. We should be prepared for that, and use all the lessons learned from the Gutenberg project. We have the advantage of a blank slate and a completely new paradigm. From what I’ve seen, the Core AI team has been really focused on empowering developers and building a framework before they work on an opinionated UI. I think that’s the right move, and I think it’s worth working together, and going far.
Links from around the web
I recently published my entire 7 Tools for WordPress Development series on YouTube. It used to be email-gated, but now it’s available to anyone.
Woo shared it’s ideas around agentic commerce, and Rae at The Repository gave a great breakdown and some context.
I published my first video on the Woo YouTube channel, covering our new Product Collections. It was my first attempt at a more concise, edited style and I really enjoyed being able to refine down to the least amount of words necessary. It felt closer to my first love, writing.
Ian Svoboda released his course on Local Development Basics. He’s a WordPress wizard and I highly recommend anything he puts out.
Nick Diego breaks down his approach to using Claude Code with WordPress.
The Woo engineers have been killing it on performance (the day we hit publish there was another internal post of improvements that we just couldn’t fit in).
Tammie Lister is having fun for Blocktober – a new block every day this month.
Ollie released Menu Designer for free, with some additional coverage by The Repository and The WP Minute.
If you haven’t seen Danny Sullivan’s (Google) talk about SEO+AI from WCUS, it’s worth your time.
Telex, a new AI-powered block builder from Automattic, is making all sorts of waves. I tried my hand at building the classic DVD player screensaver.
I love seeing more big publishers move to WordPress. It’s the ultimate use case.
That’s all, folks! See you at WordCamp Canada in less than two weeks.
Leave a Reply