WordCamp San Diego 2012: Premium Plugins & Adhering To The GPL

WordPress is published under the GNU General Public License (GPL). This means that you can copy, modify, and redistribute the software under the license. This is part of the power of the CMS and why it’s evolved into the platform it is today. When you’re writing plugins, themes, or other derivative works for WordPress adhering to the GPL is a requirement.

When you’re selling your plugins, this can become a little complicated. You want to protect your work from unpaid redistribution because that is a source of income. However, the benefits of working with the GPL can outweigh the concerns.

Premium Plugins

When you’re paying for a plugin you’re typically paying for two things. First, you’re paying for the code itself. Second, you’re paying for the continued support of this code in your specific environment. 

With free plugins, often a developer comes up with an idea and publishes the code on WordPress.org. However, since the work is given away for free, the developer often can’t keep up with support for the plugin and have to abandon the work. In some cases, your lack of financial investment can turn into a waste of your time with no immediate recourse. Conversely, premium does not always mean better. There are some paid plugins that are poorly written, narrowly implemented, or not supported properly.

Under the WordPress license, all derivative projects have to be open-source, so how does the paid model co-exist with the GPL?

Plugin Models that Work with the GPL

There are several different models for working with the GPL when developing plugins. We’ll briefly describe each of them:

• Donationware – while not technically a paid model, donationware does provide teams a way to gain notoriety for their efforts.
• Freemium – a light version of the plugin on the WordPress.org plugin directory and a paid version of the plugin is available with additional features.
• One time payment – a fully featured plugin that you pay for once. With this model you typically don’t have support for the plugin or support may have a limited duration. One drawback of the model is that this can be unsustainable for the developer once the size of the user-base exceeds their ability to provide support.
• Recurring subscription – this is the model that we use and we’ll go into detail in the next section.

How Pixel Jar Works with the GPL

For AdSanity, our paid plugin, we primarily use the recurring subscription model. In recent years we’ve added a Lifetime license as an option as well. As this model has some drawbacks, we’ve priced it in accordance with our expected Customer Lifetime Value.

The subscription model is the most effective way to keep plugin development sustainable. It provides a recurring revenue stream. This means that developers can keep developing new features, providing support for new sites, and keeping plugins up to date with all of the changes to WordPress. Additionally, it can mean a lower price point for starting with a plugin. Instead of charging a higher amount to cover a one-time purchase, a subscription lowers the barrier for entry and if you decide the plugin isn’t for you, you can stop the subscription.

Encoding is Shady

Some developers balk at the idea of their code being copied, modified, and redistributed. In order to reduce the prevalence of that, they took to encoding their work making it harder for other developers to understand what was going on under the hood. 

This is a very questionable practice and there is an argument that it violates the license. It also serves to isolate your development efforts. 

Authentication Against a Mothership

Stopping piracy is a difficult problem to solve and costly to implement. Big companies like Microsoft and Adobe have spent millions of dollars to stop piracy and continue to still have issues. While you don’t want to use aggressive methods of protecting your code like encoding, there are some protections that you can put in place to help protect your income. Authenticating the plugin to your site is a great place to start. With authentication, you’re able to verify a user is eligible for support and has access to automatic updates based on a purchase or a subscription. It also gives a way to provide add-ons for your plugin and eligibility to extend the plugin further. When we started building our products back in 2011, we rolled our own purchase process and update platform using XML-RPC. This became difficult to maintain over time and as WordPress shifted to the REST API, XML-RPC became antiquated. These days, there are a number of plugins that allow you to sell digital products and manage licenses. WooCommerce and Easy Digital Downloads are both great options.

If you have any questions about plugin development or steps for creating a paid plugin, reach out to us. We love to collaborate on new products.

Slides for this presentation are here on Slideshare.net.

Please note: Links to external companies may be affiliate links. If you use our links, we may earn a small commission.