Weblog Tools Collection: My Thoughts on Premium Plugins

Most of you have heard by now of the departure of Lester Chan from WordPress plugin development. While he will continue to update his plugins as needed, all support will be terminated.

As a plugin author myself, I’m not surprised by this news. With the world economy still in the pits, more plugin authors are feeling the crunch. While they would like to release free plugins for all, at the end of the day, there are bills to pay and mouths to feed.

Within this article (rant?), I will go over the types of plugins I would pay for, an argument for paying for plugins, and go over several business models I see popping up.

Plugins I Would Pay For

Here are several categories that make a plugin something I would pay for (yours will undoubtedly be different).

An Argument for Paying for Plugins

In 2009, we saw the premium theme market jump into the stratosphere.

Jeff predicts the same for plugins in 2010.

One thing that has always confused me is that a lot of the “free plugins forever” advocates have a different opinion towards paying for themes. Why is that so?

Unless you purchase the theme’s developer license, you only get to use the theme on one site. And if you’re like me, you probably go through three (sometimes four) themes a year (I’m never satisfied!).

A plugin, however, is there before, during, and after the theme switch. I can use it on more than one site (if the license permits), and upgrading it is much less of a hassle than themes.

On my personal site, I’ve pretty much had the same plugins for 3-4 years running. If I were to pay for those plugins, that’s a good return on investment in terms of mileage.

For those who would never consider purchasing a plugin, remember, as the economy gets worse, your favorite plugin may be the next to get abandoned by its author for financial reasons. It’s not at all uncommon, and I would argue that this is the rule, not the exception.

Plugin Business Models

Over the past year, I’ve observed several plugin business models crop up. I will go over these briefly and weigh in on each.

Donation Model Only

Some plugin authors still choose to rely on donations for plugins. For a minority of plugin authors, the amount of donations is sufficient.

However, I haven’t experienced success with the donation model, even after pushing it heavily. My most popular plugin received 1-3 donations every six months.

Free Plugin – Charge for Support

While some plugin authors have been successful in charging for support, for the most part, users download the plugin and move on.

An example is providing a download link for the plugin, and charging the user a subscription fee for support forums.

One thing I don’t like about this model is that it reinforces the fact that the time to take coding/updating the plugin is trivial. Sure, support takes up time, but maintaining the plugin takes up a lot of time also.

Free Plugin – Charge for Add-ons

Another model I’ve seen is a plugin being provided for free, but add-ons for the plugin are an extra fee.

If the plugin proves popular enough, and the add-on is a must-have, you’ll likely find great success with this model.

The time you spent coding the “base” plugin will be offset by the income you receive from the add-ons.

One-time Fee for Plugin – Extra for Support

Another model I’ve witnessed is the user being charged a set fee for the plugin. If the user wants support, the user must subscribe to a forum of some sort.

I personally disagree with this model as the user often pays more for support than what the actual plugin is worth.

It’s also my opinion that if you charge for a plugin, support must be included.

One-time Fee for Plugin – Support Included

A model I’m fond of is just outright charging a fee for the plugin with support included.

The downside of this model is that the user should expect a higher price. Since the user is paying only one time, the higher price compensates for all the support the user is expected to have over the lifetime of the plugin.

Typically the price goes higher for additional site licenses, as support is expected to increase.

Subscription Based Model

A subscription-based model allows you to spread costs across all of the subscribers. The goal here is to gain as many subscribers as possible by charging a low price.

As a result, support and upgrade costs will be spread amongst all subscribers, where each subscriber gets the overall benefit. And since some subscribers will stick around for the next billing period, there is constant revenue.

One thing to include is to have a “Buy Out” option, which will allow users a lifetime subscription for a set fee. This is the One-time Fee option, so the price will be dramatically higher than a subscription cost.

I personally chose this model for my first premium plugin and it has been fairly successful so far.

Conclusion

Within this post, I went over the types of plugins I would buy, my reasons for purchasing a plugin, and the various models I’ve seen crop up.

I would love to hear your thoughts on any of these topics.


Most of you have heard by now of the departure of Lester Chan from WordPress plugin development. While he will continue to update his plugins as needed, all support will be terminated.

As a plugin author myself, I’m not surprised by this news. With the world economy still in the pits, more plugin authors are feeling the crunch. While they would like to release free plugins for all, at the end of the day, there are bills to pay and mouths to feed.

Within this article (rant?), I will go over the types of plugins I would pay for, an argument for paying for plugins, and go over several business models I see popping up.

Plugins I Would Pay For

Here are several categories that make a plugin something I would pay for (yours will undoubtedly be different).

An Argument for Paying for Plugins

In 2009, we saw the premium theme market jump into the stratosphere.

Jeff predicts the same for plugins in 2010.

One thing that has always confused me is that a lot of the “free plugins forever” advocates have a different opinion towards paying for themes. Why is that so?

Unless you purchase the theme’s developer license, you only get to use the theme on one site. And if you’re like me, you probably go through three (sometimes four) themes a year (I’m never satisfied!).

A plugin, however, is there before, during, and after the theme switch. I can use it on more than one site (if the license permits), and upgrading it is much less of a hassle than themes.

On my personal site, I’ve pretty much had the same plugins for 3-4 years running. If I were to pay for those plugins, that’s a good return on investment in terms of mileage.

For those who would never consider purchasing a plugin, remember, as the economy gets worse, your favorite plugin may be the next to get abandoned by its author for financial reasons. It’s not at all uncommon, and I would argue that this is the rule, not the exception.

Plugin Business Models

Over the past year, I’ve observed several plugin business models crop up. I will go over these briefly and weigh in on each.

Donation Model Only

Some plugin authors still choose to rely on donations for plugins. For a minority of plugin authors, the amount of donations is sufficient.

However, I haven’t experienced success with the donation model, even after pushing it heavily. My most popular plugin received 1-3 donations every six months.

Free Plugin – Charge for Support

While some plugin authors have been successful in charging for support, for the most part, users download the plugin and move on.

An example is providing a download link for the plugin, and charging the user a subscription fee for support forums.

One thing I don’t like about this model is that it reinforces the fact that the time to take coding/updating the plugin is trivial. Sure, support takes up time, but maintaining the plugin takes up a lot of time also.

Free Plugin – Charge for Add-ons

Another model I’ve seen is a plugin being provided for free, but add-ons for the plugin are an extra fee.

If the plugin proves popular enough, and the add-on is a must-have, you’ll likely find great success with this model.

The time you spent coding the “base” plugin will be offset by the income you receive from the add-ons.

One-time Fee for Plugin – Extra for Support

Another model I’ve witnessed is the user being charged a set fee for the plugin. If the user wants support, the user must subscribe to a forum of some sort.

I personally disagree with this model as the user often pays more for support than what the actual plugin is worth.

It’s also my opinion that if you charge for a plugin, support must be included.

One-time Fee for Plugin – Support Included

A model I’m fond of is just outright charging a fee for the plugin with support included.

The downside of this model is that the user should expect a higher price. Since the user is paying only one time, the higher price compensates for all the support the user is expected to have over the lifetime of the plugin.

Typically the price goes higher for additional site licenses, as support is expected to increase.

Subscription Based Model

A subscription-based model allows you to spread costs across all of the subscribers. The goal here is to gain as many subscribers as possible by charging a low price.

As a result, support and upgrade costs will be spread amongst all subscribers, where each subscriber gets the overall benefit. And since some subscribers will stick around for the next billing period, there is constant revenue.

One thing to include is to have a “Buy Out” option, which will allow users a lifetime subscription for a set fee. This is the One-time Fee option, so the price will be dramatically higher than a subscription cost.

I personally chose this model for my first premium plugin and it has been fairly successful so far.

Conclusion

Within this post, I went over the types of plugins I would buy, my reasons for purchasing a plugin, and the various models I’ve seen crop up.

I would love to hear your thoughts on any of these topics.


Leave a Reply

Your email address will not be published. Required fields are marked *