Monetizing your new Extension

In creating these series of posts I am trying to make sure that developers and companies that want to integrate their services into MainWP have the tools at hand to easily work with a framework to create their final product. I want to ensure that you have the help you need to add your functionality and unique product or service to MainWP as a whole.

In the previous posts we have covered how to create a basic WordPress plugin, connecting it to and turning that basic plugin into an extension inside of MainWP, then passing information to a child site in order to perform an action – in this case it was just to present a notice about an upcoming maintenance block. Finally, we ported it all from a basic PHP block into a Class-based system that allows for greater flexibility, and grouping of similar functions and code.

This post is part of a tutorial on creating your own MainWP Extension

1. How to create a basic WordPress plugin
2. Turning that basic plugin into an MainWP Extension
3. Passing Information to the Child site
4. Extensions using Classes in MainWP
5. Monetizing your new Extension

We’ve reached the point in the tutorial where we have a great basis for a plugin, and could potentially charge in future for it. I’m a huge proponent for open source, but it is nice to have a free coffee now and then, am I right? Lets investigate a few options for monetizing on your piece of code.

Types of revenue models

Freemium is the current best seller, as I’m sure anyone who has played Angry Birds can attest to. When you get REALLY stuck, you can shell out another couple of bucks to get past that really bad pig. WordPress has something similar – we can use Event Espresso as an example, which has limited functionality unless you are willing to shell out for features and add-ons.

There are lots of other examples of plugins that limit functionality or support unless you purchase the premium version, and more still that you can purchase from Code Canyon that aren’t listed on WordPress’s Plugin list. You can certainly go down this route but it requires big numbers of users using your plugin.

Then there’s the free base with premium add-ons.

Let’s take WooCommerce as an example – great core functionality, but if you want to integrate it into any other payment gateway other than PayPal, you’re looking at buying a plugin that already has the functionality, developing the API yourself, or paying someone to do it. There are extensions for memberships, deposits, additional shipping methods and calculators – the list goes on. So once someone has purchased it what prevents them from just giving it away? Well, chances are you’re going to fix and update the code in it, and the way WooCommerce works is that you enter a key that is tied to your purchase and you receive free updates with a few calls back in your code to the original server. There’s even an extension that allows you to generate an API key and indeed this is a handy method, as all you would need to do is integrate a few callbacks in order for users to be able to update their plugin or extension. Let’s investigate that in another post, along with other methods to tie activation keys to your software.

You can create a standalone web application (as I’ve done with a social media aggregator that I coded) and simply use a plugin to help you integrate it into a WordPress site, either with a [shortcode] or an insert (enqueue) into the header of your site. That way you get the free plugin and ‘advertising’ in the repository, but you can charge whatever you’d like outside of WordPress. Checkfront is a great example of a Software as a Service (SaaS) model: they have a WordPress plugin that just creates a link between the website and their reservation system via either JS or a Widget.

There’s the option of charging for support, or people buying support tokens for hourly or per-incident support. This is a great idea for developers as it basically weeds out the people who know absolutely nothing about plugins or WordPress that need you to hold their hand every step of the way. At the same time though, you alienate those same people, so you need to consider whether your online documentation is strong enough to support that model.

Finally, you can ask for donations – I have actually been in a situation where I found a great working piece of Drupal 6 to WordPress migration code that I used on a client’s site, and I ended up donating to the author because of the amount of time it saved me. I then extending his code functionality with my own plugin to migrate images from the same Drupal installation, and after wrapping the whole project up with another (modified) plugin to reset all of the permalinks, I found myself with an SEO friendly WordPress copy of a poor node-based Drupal installation as a basis for an upcoming website. If I know it will save me time, it’s worth my money.

Weighing in

Long story short, you have a lot of options available to you, and you will need to figure out the pros and cons of each based on your company model. Working with WordPress is, at least to me, the most financially viable option because of the sheer volume of users that utilize it. See below for a breakdown of market share of CMS systems:

In upcoming posts I will investigate a few “premium plugin” methods of selling such as CodeCanyon, using your own WordPress plugin like Easy Digital Downloads to sell on your site, setting up a method to track API/activation keys to activate features or unlock the plugin/extension, and finally hosting in a private git repository.