Common Bloggers and Proprietary WordPress Development

The average WordPress user is someone who tends to buy WordPress themes and plugins as turn key solutions for their website development needs. Of course they will have to configure both and they may make some customizations, but they cannot write (or understand) complex code.

Or any at all, for that matter, depending on where they fall on the technical spectrum under “developer”. Basically, anything more technically advanced than dropping in some code snippets or making basic CSS customizations is not possible without outside help.

This is the customer base most WordPress theme and plugin shops are targeting when they create a product. Ironically though, this is the very group who is most likely to be ignorant or misinformed about WordPress development best practices that could negatively impact their project or business.

Such is the case with the practice of proprietary WordPress development.

What is Proprietary WordPress Development?

In a nutshell, proprietary WordPress development is any practice that a) restricts the freedom of a WordPress theme or plugin’s end user beyond the existing limitations of WordPress’ GPL license; or b) uses non-portable code to lock users into a single product or product ecosystem’s continued use.

Types of Proprietary WordPress Development (& What They Mean for You)

If that sounds a little confusing, don’t worry. The sections below will focus on explaining what exactly non-GPL compliant code and non-portable code are and how they can negatively affect end users.

Non-GPL Compliant Code

Before you can understand what non-GPL compliant code is, it’s probably a good idea to understand the main points of the GPL license to begin with. So, what is the GPL license and how does it apply to WordPress, WordPress themes, and WordPress plugins?

GPL stands for General Public License. Any software (WordPress) or derivative products (such as themes and plugins) released under this license provides its users with the following freedoms:

The freedom to run the software for any purpose

The freedom to study how the software works and make any desired changes to it

The freedom to redistribute the software

The freedom to distribute copies of modified versions of the software

It is important to note that there is nothing in this license that prohibits charging for the software–which is how the entire WordPress theme and plugin market is able to exist.

WordPress itself is free of charge by choice; as are the plugins and themes offered through the official WordPress.org repository. Premium WordPress themes and plugins are required to honor the freedoms of the GPL license–which can make it hard (but not illegal) to charge for a freely distributed product–and so tend to charge for easy file access, support, and updates.

(If you’re hazy on how exactly that works then I would recommend reading Chris Lema’s article called What Are You Paying for When You Buy GPL Themes and Plugins?)

Ok, so now that you know what the GPL license is and how it applies to WordPress themes and plugins, how can non-GPL compliant code affect you? And what constitutes non-GPL compliant code in the first place?

Non-GPL compliant code would be anything that restricts the four freedoms above. Code that is compressed or encoded to avoid being read would be the biggest offender here as it would stop you (or anyone you hire) from studying the code, making changes to it, and freely distributing it in any meaningful way.

Thankfully, nearly every single premium WordPress theme shop is 100% GPL compliant. The only major hold-out is Themeforest which offers both 100% GPL and Split GPL licenses. The split license is there to cover elements such as code or code libraries not directly tied to WordPress core functions that might be included in a WordPress theme but are either already licensed under something else or the creators want to retain ownership.

In the case of split GPL licenses you will want to review the restrictions per theme or plugin to be sure you are not prohibited from using the software as you are intending to. In my opinion though, this is rare enough now that it no longer constitutes the biggest problem posed to end users by the practice of proprietary WordPress development. That’s where our next type comes in.

Non-Portable Code

Finally we come to what I see as the biggest problem in the WordPress community in terms of proprietary development: non-portable code. This is when a plugin or theme is designed, either intentionally or unintentionally, to lock a user into the continued use of a single product or product ecosystem. There are three main perpetrators of this: non-portable shortcodes, non-portable themes, and non-portable plugins.

Shortcodes Dependent on Themes

Shortcodes that come with a theme, and which are not dependent on a separate plugin, cannot be ported to a new theme in the future. This practice of packaging shortcodes as part of the theme itself traps end users into either sticking with the theme they have or go through the tedious and time consuming process of removing/replacing all of the shortcodes used in their content. Sometimes, there are no alternate shortcodes available.

Theme Functions and Templates

Ideally, a theme should come with all of its major functionality in the form of a plugin or bundle of plugins. This includes custom templates that once used over and over again will need to either be ported to a new theme or reconstructed by a new developer.

Take a theme that comes with a built in page builder for instance–like Elegant Theme’s Divi. Once you use that theme to create page after page with its custom page builder you cannot switch themes with anything approaching ease. This is one major reason they recently announced they are converting their builder into a theme independent plugin.

Plugins Dependent on Theme Styles

Some plugins, such as the Aesop Story Engine, are dependent on complimentary theme styles to make the plugin work as intended. Right off the bat it means that you need to purchase a theme by the plugin’s author for it to work properly and then you are basically stuck within that family of themes once you’ve used the plugin to create your content. This was one of the reasons the team here at Cohhe recently released the Longform storytelling theme for free. To make a great free plugin actually free to use.

The Aesop Story Engine is far from the only free (or premium) plugin to use this method of directing users to premium products or product families, just one that stood out to me after the release of Longform. In general, these kind of plugins can be hard to spot without acquiring the plugin and testing it yourself. Your best bet is to read as many reviews and articles about your plugin choices as possible before choosing those you will be absolutely dependent on–and then testing them extensively before making any final decisions.

So, What Should the Average WordPress User Do When They Spot Proprietary WordPress Development Practices?

Ideally, avoid it. Non-GPL compliant code is pretty rare now (among trusted and established WordPress theme/plugin creators) and so less likely to cause you problems. Or even come across your radar.

Non-portable code, on the other hand, while frowned upon, is not illegal or even against WordPress licensing. It is against the recommended WordPress development best practices, but there are almost always going to be developers out there who see non-portable code as an easy way to retain customers.

In those cases, you’ll need to follow my advice above and simply be on the lookout for it. Oh, and again, test everything.

If for some reason you cannot avoid using a theme or plugin that practices proprietary WordPress development, there are a few things I’d recommend:

1. Avoid using the features that cannot be ported, even if you have to download a plugin that “duplicates” features

2. If you must buy into a particular product or product family, choose wisely. Pick a theme/plugin shop with an impeccable reputation and enough success to guarantee that they will be around for a while

3. Encourage those developers to bring their products in closer alignment with the recommended WordPress development best practices.

In cases such as the Elegant Themes Divi Builder mentioned above, it seems that they took note of this complaint from their user base and made a decision to align their development practices with the overwhelming consensus of the WordPress community.

As a result, I wouldn’t be surprised to see their customer base grow significantly in 2016.

Have you had any negative experiences as a result of proprietary WordPress development? If so, it would be a great resource for the community here if you took a moment to share your story with us in the comments below.