When it comes to selling a theme for both WordPress.com and for self-hosted installations, one of the questions that I find myself asking is:

“Is it worth maintaining two repositories for the same theme?”

And I wonder this because when it comes to maintaining a codebase of a theme on WordPress.com and a version for the self-hosted version of WordPress, you can make the case that there’s no need to have a difference in the version of the themes.

But for anyone who has worked in both variants of WordPress, then you know there’s actually little bit in variation.

Two Versions of WordPress Themes

First, I’m always of the mindset that if you’re going to be selling a copy of your theme – or any software, really – in a marketplace (such as the App Store, even), then you have to play by the rules of that environment.

If they’re bringing the market, and you’re bringing the product, then they set the rules. Easy as that.

When it comes to WordPress.com, there are a number of different things that dictate how you build features into your themes. Some of these include how the options are organized in the Theme Customizer, what options can be made available so not to interfere with other paid options in the WordPress.com marketplace, and so on.

Of course, this isn’t a criticism WordPress.com, either – it’s a fact of the marketplace. This could just as easily be ThemeForest, Creative Market, Mojo Themes, and so on.

On one hand, there’s a strong case to want to maintain a single copy of the same theme to sell for both hosted and self-hosted installations.

Think about it:

  • A single repository for the source code
  • One place to manage issues
  • One place to maintain pull requests or commits
  • A single way to manage tags and releases
  • …and so on.

But as nice as that sounds, it comes at a major expense: you lose the flexibility that comes with self-hosted installations.

Just as we have to play by the rules of the marketplaces in which we sell our work, those restrictions don’t exist for self-hosted installations. To that end, we’re able to offer our own set of unique features (or even potential upsells), how we organize the features, and other ways in which we architect the product.

In fact, some may say that the versions of the theme that are offered in marketplaces are “lite” or “lighter” versions of themes that are offered for self-hosted installations.

But, again, this comes with having to:

  • Have a second place to keep the source code
  • Track multiple support forums
  • Juggle different sets of bugs and issues
  • Multiple ways to tag releases
  • …and so on

And, coming from experience, I know that this can eventually reach a point where the code bases diverge to the point where they feel like different products.

Perhaps they are, perhaps they aren’t – I guess it depends how you look at it, but I digress.

But it gets to be significantly more work to manage two versions of the same product the longer they exist, and the more mature they become over time. No, it doesn’t necessarily have to be that way, but I think the case – more often than not – is that it is.

So should the extra work that comes with maintaining separate code bases for market-based products and self-hosted installations dissuade us from maintaining two variations of the project?

Personally, I think in the direction of no, but I think those who are looking to do so need to know what it is they are getting into as it relates to managing multiple variations of WordPress themes.