Here is a checklist explaining how to make money with your free WordPress plugins. We used this very model to make over $250,000 in recurring revenue selling plans around Paid Memberships Pro. Today, with just incremental changes to this plan (using our own license server, building a custom support platform, raising our prices, and a lot of marketing work) the Paid Memberships Pro business brings in over $1,800,000 in revenue every year and growing.

A relatively modest plugin with 10,000 users could have as many as 1000 paying customers, which at $100 per year per customer is $100,000 per year. That’s very good money and very feasible for even niche plugins. That’s enough money to base a healthy career around. This kind of money may be available to you, but you’re holding off on doing something about it because you think it’s going to take more work or a more complicated business setup than you expect. Before you give up on this dream, read try implementing the steps below and see how it goes.

The Checklist

1. Use the GPL license. 100%.
2. Have just 1 version of your plugin. No free vs pro. No paid modules or extensions.
3. If you feel you must have extensions, use the 80/20 rule to separate certain features which are only useful for 20% of users, but confusing for the other 80%. Put the 20% features into free extensions or “add ons”.
4. Put all of your plugin code up on GitHub.com. Encourage other developers to get involved.
5. Put all of your plugin code in the WordPress repository.
6. Have the download link on your website require a free membership (created with Paid Memberships Pro), and then redirect users to the zip file in the WordPress repository.
7. Add documentation to the plugin website. Use the same domain. Start small and build it out as support requests are handled.
8. Require the same free level to access the documentation on your site.
9. Use the Limit Post Views add on for PMPro so visitors to your site can view 1-3 articles before being prompted to sign up. This helps with SEO as well.
10. Add a premium support forum using bbPress and the bbPress Add On for PMPro. Require a paid plan for one year of access. We found annual recurring plans to work best. Charge enough to cover your average support costs per paying member, plus some.
11. Set up a “do it for me” plan where you would install the plugin for users and offer up to 5 hours of customization or consulting. Charge a one time fee equal to what you would charge for 5 hours of consulting. It should be about 5-10x the cost of regular support. This plan was crucial in the early days, allowing us to work closely with customers, gaining valuable insights that helped us to improve the core plugin and add ons.
12. Address all bugs and pre-sales questions on the WordPress.org forums. Direct other support to the paid membership on your site.
13. Integrate with Omnisend or another email marketing service to automatically create a mailing list of your free and paid members.
14. Focus your consulting business on doing more projects related to your plugin.

At 14 steps, this isn’t completely easy. It’s work. Here are the pros and cons as I see it:

Pros

• You will save time by avoiding multiple versions of your plugin.
• Using the WordPress repository for distribution saves you a headache.
• Having all of your code open source and available for free will encourage use of your plugin to spread and will encourage other developers to get involved.
• You are no longer supporting your plugin for free or for tiny donations. Set support prices so they make sense for your hourly rate, etc.
• You are generating a potentially valuable mailing list from your otherwise idle plugin code.
• Focusing your consulting business will allow you to raise your rates or increase your margins.

Cons

• Your plugin will be labeled as the “free” option. People associate “free” with “worse” even if it’s not true.
• People with no ability or intention to pay you (i.e. not customers) will use your plugin and demand support. You need to learn how to deal with them gently without wasting your time.

What’s Next

Who knows. There are many paths depending on your goals. I’ll try to share more on the specific challenges we faced, decisions we’ve made, and the successes (and failures!) we’ve had.

If you give the above a try, please please let me know how it goes. Let me know what challenges you are facing. If they are challenges we’ve run into as well, I might have something useful to say about it.

The post A Simple Business Model for Your WordPress Plugin appeared first on Stranger Studios.

In 2022, Chris joined us on the Stranger Studios YouTube channel to talk about the similarities and differences between an LMS plugin and a membership plugin. As I watched the video, I was reminded of the past chats I had with Chris, and thought, “we should talk more”.

So we did. We started having regular chats about work and life.

During one of those chats, Chris mentioned that Thomas was thinking of leaving LifterLMS to pursue new opportunities. Chris initially just came to me for advice, but as we talked through it more, it became apparent that we could help out in a more tangible way.

Kim and I have invested in the LifterLMS parent company, codeBOX, and are now officially working with their team to build and grow the business and products.

LMS and membership plugins are on a collision course (puns intended).

Many people conflate the idea of a membership site with eLearning, and vice versa.

Chris and I always saw our businesses as both potential partners and indirect competitors. LifterLMS has membership features. Paid Memberships Pro has course features. Some sites do better starting with our plugin, some with LifterLMS. Some sites truly need both.

We launched our PMPro Courses Add On last year. By itself, the plugin adds Courses and Lessons as CPTs and tracks progress through both. Using PMPro levels, you can easily sell access to those courses.

The plugin also integrates with LifterLMS (and the other major LMS plugins)—so if you need more functionality than the default module, we encourage folks to consider using a complete LMS plugin alongside PMPro.

In 2021, the team at PMPro also started updating our marketing strategy and documentation to address the 8 key use cases we see with the PMPro membership platform.

The “courses” use case is one of our most popular, with somewhere between 1/3 and 1/2 of all PMPro sites either primarily selling access to courses or otherwise interested in including courses in their offering. We launched our Courses Hub and planned more content and services to help course creators get the most out of our membership platform.

This opportunity with LifterLMS came at the perfect time.

We can continue to improve the LMS experience for WordPress users. And we get to do that with an established team, brand, and code base. I really think we can get the best of both worlds here, updating PMPro to work as tightly as possible with LifterLMS, while ensuring that users can continue to use the plugins by themselves or together.

Kim and I are very excited to be on this journey with Chris. He’s incredibly committed to his work, and he’s good at it, too. We’re learning a lot from each other—and we’re implementing the best ideas to the benefit of both companies and both products.

We are still running PMPro and LifterLMS as separate businesses.

In the short term, we are focused on keeping both teams and products running as smoothly as they have in the past, while working on a tighter integration that will serve our common users.

We’re still figuring things out. Who knows what the future holds. I feel an incredible amount of excitement about the work we’re doing now. It’s an amazing time to be building software that empowers online educators and eLearning communities across the globe.

Finally, we’re hiring!

We’re looking for an experienced WordPress developer to join the LifterLMS team. Click here to apply for the developer position at LifterLMS or reach out to me personally on Twitter @jason_coleman. This work is extremely fun, challenging, and rewarding. I look forward to hearing from you.

The post Stranger Studios Makes Investment in LifterLMS appeared first on Stranger Studios.

You can watch a replay of the discussion on the GiveWP YouTube channel. This post shares thoughts that my team and I gathered on how we, as the creators and maintainers of the open source plugin Paid Memberships Pro, can approach fighting abuse and harassment through our code.

Jump to: Skepticism | Limiting the Potential for Harassment | Coding Against Abuse for Site Admins | Coding Against Abuse for End Users

At first I was skeptical: what can code really do?

Open source products are unique from traditional premium software or SaaS solutions.

1. Users are not customers. Our software is open source, so in general we can’t stop people from using it. If we find they have beliefs different from ours, or if we find out they are creating a membership site designed to abuse or harass others, we can’t stop them from using PMPro. We have no idea what people are doing with our product, and we have no idea if they are building secure WordPress environments that will keep their users safe.
2. Like WordPress, we carry a GNU General Public License. This means, among other things, that you may install the plugin on any site for personal or commercial use, and that the plugin is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In general, you cannot stop people from using your open source software. However, as a business, you can choose who you do business with. You can exclude customers from your support and paid services.

From a business perspective, this is the best route every plugin author can take to fight abuse and disrupt harassment. For example, include a policy related to hateful sites and action you will take against these users in your Terms of Service for any paid or free user support offered. Some TOS are more specific, but ours is pretty general and we use it to remove the occasional hate group customer: “Stranger Studios, LLC may terminate your access to all or any part of our Services at any time, with or without cause, with or without notice, effective immediately.”

Another important factor here is building in policies that support your team directly. Our team knows what to do if they get assigned a ticket they feel uncomfortable supporting. For any reason, a team member can hand off a customer or a specific ticket to their team leader, Jason, or myself.

These are all business policies, though. So what can code do?

Teach Site Owners How to Limit the Potential For Harassment

Aside from code-based solutions, I feel like it is our job as plugin owners to educate the people on all sorts of business topics related to running a membership site with PMPro. While this list is unique to the memberships/ecommerce domain, I’m including it as an important reminder. As a plugin author, you are in a unique position to share the depth of knowledge you have about your customer’s users. Use your knowledge to help them protect their sites and their communities from negativity.

• Remind the site owners that use your plugin product to have current Terms of Use and Privacy Policy pages. Plugin authors that facilitate user account creation and ecommerce should check that the site has defined a policy under Settings > Privacy and include a link to this page in the forms that allow user registration. WordPress allows you to suggest text for your users’ privacy policies.
• For membership sites, we have seen that charging even a notional fee for access to a site will keep some trolls from signing up. If you had a free membership level and saw a lot of account abuse, adding a small fee of $1 / month can greatly improve the quality of members joining your site.
• We encourage site admins to remove any friction that can lead to problems. For example, we are big fans of the “no-questions-asked 100% refund policy.” This simple policy prevents the majority of enraged communications that our team would have to process. Further, we advise site admins not to engage with these non-customers. A simple “Your refund has been processed.” is the best and only response needed.

Build Better Products for End Users and Site Admins

This section details some of our team’s code-based opportunities to build better products. Products that make it much hared for site admins to abuse end users and for end users to abuse the site owner.

Coding Against Abuse: For Site Admins

• Paid Memberships Pro, our primary product, allows users to create accounts on your WordPress site. We create all users with the site’s default user role, which for most WordPress sites is the “Subscriber” role. Plugin authors must protect the site admin and ensure that users do not have capabilities beyond the most basic access rights granted by the Subscriber role. Yes, there are cases where a higher level of access is needed. For most sites, though, the Subscriber role carries the correct level of account privileges.
• If you do give users a higher tier role, take steps to ensure strong passwords or even enforce two-factor authentication for specific users that have higher tier access. It is the site administrator’s job to maintain security for their WordPress install, specifically in an ecommerce environment with historic customer data.
• WordPress should consider a safeguard against the site default role. I cannot think of a single instance where the default role should be set to “administrator”. I suggest that we force an override in wp-config.php to show “administrator” as an option in the Settings > General > New User Default Role dropdown. (There is a trac ticket about this.)
• From a plugin standpoint, here are a few of our tools that protect membership site owners from various types of account-related abuse:
  • Lock Membership Level Add On: restricts a user from joining or cancelling membership on your site indefinitely or for a fixed term. We built this tool in part for our own use case as we noticed a few users would repeatedly sign up, receive help, then ask for a refund. While not the most harmful of cases for online abuse, our team did feel the stress of seeing these “customers” float in and out of the support channels. I recommend this tool to sites that are experiencing similar account abuse.
  • WP Bouncer plugin: designed to discourage user account sharing. This plugin is free in the WordPress.org repository. Similarly, setting up 2-factor authentication will further discourages account sharing.
  • Approvals Add On in combination with required registration questions: Membership communities often want to ensure that they are attracting and including the right type of member. These communities are successful because they create a safe space for members to discuss shared topics and values. For membership communities, using an approval process for membership allows them to pre-qualify members before allowing them access to their community. Sites can use a series of custom registration questions to force members to opt-in to your values before gaining access.
• Fields validation is another way plugin authors can ensure safe data is being collected and stored for the related field. Field validation can also protect the site admin from users injecting corrupt files or other scripts into their site.
• Consent logs, audit trails, and local data logs are a great way for plugin authors to support admins in the event that there is an abusive event. These methods track when a user or other admin managing your site makes changes. Along with this, though, plugin authors have a responsibility to anonymize stored data if that data log is “phoning home” to a remote location for technical support or other debugging.

Coding Against Abuse: For End Users

It’s WordPress. Everything is customizable. Site owners can get as scammy as they want, but plugin authors do not have to make it easy for them. For this reason, even though OUR direct customer is the owner running a membership site, we build our software with the end user customer in mind.

• Some misguided site owners might want to hide payment reminders or payment confirmation emails from their customers. We enable these by default because the end user customer would want it that way.
• In this same vein, we default to allowing members to cancel and terminate their subscription without the need for admin intervention or approval. Some subscription products make you call or write a specific letter to get cancelled. We believe users should have control to terminate their account whenever they want, for any reason.
• Not every member of your site wants their information made public by default. For example, we added an option to our Member Directory Add On that allows users to opt out of inclusion in the directory. If you are building a product that can expose user, member, or customer data on the frontend, please add a way for members to turn this off. For example, have you ever seen those FOMO “Social Proof” notices on an ecommerce site. Did that purchaser know their name and maybe even their avatar would be shown as a popup on your site? The people building these tools are overlooking an important step to protect the end user customer.
• With GDPR came a new system in WordPress to facilitate users in accessing or erasing all of the personally identifying information collected about them. Plugin authors should take steps to include their custom data in Personal Data Exports and Personal Data Erasures.

An Open Free Internet For All

Dealing with haters, abuse, and harassment is an important part of running an online community or open source software project. Ignoring these poisonous users and customers can lead to issues that spiral out of control and cause a lot of damage.

I hope that sharing some of our current thinking about these issues may help others. We will continue to review and improve our processes and actions to ensure that we are protecting each other while continuing to advocate for an open free internet for all.

The post How can WordPress plugin authors disrupt harassment and fight abuse through code? appeared first on Stranger Studios.

Here is the GitHub repository for the demo plugin I created.

What is a plugin?

• Extra code, in addition to the theme, that is run after WordPress is loaded.
• Plugins are stored in the /wp-content/plugins/ folder of your WordPress site.
• Plugins must have a php file and a valid plugin header comment.
• Only plugins activated from the plugin menu of the WordPress dashboard will run.

Why code your own?

• Because you are a badass.
• Because you need to tweak something specific to your site.
• Because someone like Jason gave you custom code to patch your site.

Why not use functions.php in a theme or child theme? (Or edit a plugin or edit WordPress core.)

• If you edit a theme or another plugin or WordPress core… that edit will be overwritten when the theme, plugin, or WP core is updated.
• If you have your own child theme, you can put the code there. It’s less likely to be updated. However, your code stops running when you change your theme. Or maybe you don’t want a child theme.

Demos

• Changing the excerpt length of archives.
• Removing unused profile fields.
• Setting a sitewide banner for Memberlite theme.

Other Demos?

• WooCommerce
• Ninja Forms
• Paid Memberships Pro
• Custom APIs

The post Creating Your Own Plugin for Customizing WordPress (WPReading Meetup) appeared first on Stranger Studios.

The show topic was How do I make sure I don’t have to re-do my website just months after it’s done?

The consensus was that you can’t make a website that won’t require updates. But you can do a few things to prepare for future updates and minimize their impact:

• Make sure you are using a good developer. Good developers will do things “the WordPress way” (e.g. using hooks and filters instead of hacking plugins), which will be less likely to be broken by plugin and core updates.
• Make sure you are using a good designer. Good designers will simplify things and use proven methods that are less likely to be broken by software and browser updates.
• Make sure your website has a purpose other than looking pretty. One year after your website goes live, it will probably be out of style… at least a little bit. But if you built a website that encourages people to call your sales phone number, it will still do that no matter what the design trends are.
• Make sure you have a maintenance plan. In addition to having someone on call to perform WordPress upgrades, have a developer on retainer or on call to fix things if anything goes wrong.

We need to do a better job of communicating with our clients about what role maintenance will play in their website. There were a few analogies thrown around on the show (websites are like babies?). My favorite was to think about your website like a car bought on lease (get regular oil changes and be ready to trade it in every 2-3 years) instead of a used car you buy and run into the ground.

The post Jason was on WPwatercooler again. Summary. appeared first on Stranger Studios.

It’s a cool little piece of functionality that will help out developers building asynchronous apps on top of WordPress.

At first, I didn’t see the need for it. (It’s not too hard for developers to create their own script to poll the server every few seconds.) But I soon realized why an API like this would be useful. If  you have 5 different plugins all with their own server polling, you are going to have 5 different hits to your server every 15 seconds. However, if they all piggyback on the Heartbeat API, those polling requests are going to be bundled so you are only hitting your server 1 time every 15 seconds. There are other benefits, but that’s the big one to me.

For people trying to get started with the Heartbeat API, I put together this nice little minimal example that you can use as a starting point. The script below simply sends the message “marco” from the client and then detects this on the server and sends back “polo”. The messages are logged in the JavaScript console (so if you inspect elements and click on the console tab in Chrome you will see them). You should be able to easily tweak this to send requests like “how many members are logged in?” and send back a number, etc.

Let me know if you have any questions about the API and I’ll try to address them.

View the code on Gist.

The post Heartbeat API for WordPress appeared first on Stranger Studios.

WordPress is distributed under the GPLv2 license. The basic gist of that license is that you can do whatever you want with the code, but if you distribute any altered code, that code must be distributed with the GPL license as well. Meaning anyone you sell your code to can do whatever they want to do with it. This makes things like “one site licenses” and other restrictions unbinding or outright illegal.

If you do a consulting project for someone, the GPL license doesn’t come into play. Only if you want to sell or otherwise distribute your plugin on your website, etc, will your code need to carry the GPL or a GPL-compatible license.

First, what everyone agrees with is that if you copy and paste someone’s GPL code, even if you tweak it a bit, you are inheriting that code and the GPL will apply to it.

But let’s say you built your plugin from the ground up and it doesn’t borrow any code from GPL code. (Which is actually hard to do.) Most would say that the GPL will apply to your theme or plugin anyway since it relies on WordPress to run. The most cogent argument is by Mark Jaquith here[1] . Part of Mark’s argument:

Note that WordPress theme PHP files are not “templates” or “documents” in the way that most people think of those words (though the word “template” is sometimes used, it is not strictly accurate). They are PHP script files that are parsed and run on the same exact level and by the same PHP process as all the core WordPress files.

The particulars of the GPL would make exceptions if the theme was actually being loaded and parsed by the WordPress code, but it’s not. It’s being executed in tandem. Your plugin is really like a patch for WordPress in a nice little package vs. a separate application run by WordPress.

Some people might disagree with Mark and the rest of us, but for the most part their argument is “but I don’t wanna use the GPL, wah!” (Anyone is free to reply with a real argument if you are in this camp.)

There is another thing called a “split license” where you license the .php (and maybe some .js code) under the GPL and license static assets like CSS, images, .html files, and some .js files under a different (more restrictive) license. This way people can’t just redistribute your theme as a whole without replacing the non-GPL pieces first… kind of an extra little hindrance.

Most will agree that this is legal for you to do with your plugin or theme under the GPL. However, some organizations will have stricter rules, requiring a plugin or theme to be “100% GPL” (meaning all files included in the package) in order to be listed/etc. Most notably themes and plugins hosted at WordPress.org must be 100% GPL. Also, WordPress won’t recognize or work with designers and developers who don’t release stuff that is 100% GPL. So, for example, as soon as Woo Themes (a big theme developer) made all of their themes 100% GPL instead of split license, they got a big ol’ link on the WordPress.org homepage. And recently a designer who sold a split license theme was banned from speaking at a WordCamp.

The idea behind requiring that themes and plugins be 100% GPL is that making them split license betrays the intent of the GPL, which is to make it easier for people to do other things with your code, improve it, and generally make the world a better place.

The intent of the GPL is NOT to keep you from making money. Even though there are companies (including mine) selling themes and plugins on their site, this doesn’t mean those plugins are not GPL. You can still charge for a GPL plugin even though someone could buy it and turn around and give it away for free.

There are several reasons people will pay for a plugin or theme even though they might be able to find it for free elsewhere: * They want to get it from “the source” * They are worried about free versions containing malware or other nasties * They want support from who they are buying from (Paid Memberships Pro) * They want to receive future updates automatically (Gravity Forms) * The plugin relies on a 3rd party service (VaultPress)

Now there are basically two camps of people selling GPL themes on their sites.

Camp 1 embraces the GPL fully and will have GPL stickers in their footer and mention it whenever they get a chance. Camp 1 is more likely to give away versions of their code for free (maybe a lite version, or one minus addons, or even the full code) and use other business models to make money.

Camp 2 will admit that the plugin is GPL, but you’ll have to dig around to figure it out. They won’t mention it on their website at all. They might not even include a license.txt or similar comment in their code, which they are supposed to. They are basically reluctantly GPL and hope they can hide that fact to avoid people trying to get their stuff for free. But if you confront them about it, they will admit that their code is GPL to avoid the legal and community ramifications.

I’m in camp 1. I’m still not sure if it’s best for my bottom line. However, I’ll leave with this:

If you are going to work with WordPress and try to make money off of it. It makes sense to be in alignment with the people running the show, namely Matt Mullenweg. WordPress is a community project, but Matt and the WordPress foundation are all about 100% GPL and definitely against non-GPL themes and plugins. You probably should be too. If you don’t want to be, you should probably look into other code bases with different licenses and different people running them.

Update: The best argument I’ve found for the position that WP Plugins and Themes are NOT “derivative” works is by Chip Bennett here. Give it a read. He cites copyright cases and applies their decisions to the question of WP Themes and Plugins. If he sways you, it’s possible that Mark Jaquith’s comment will convince you back to the other side of the argument. It’s a very interesting legal question.

The post Thoughts on GPL WordPress Plugins and Themes appeared first on Stranger Studios.

The discussion (argument?) went something like this: (paraphrasing here)

Scott Bolinger: The WP survey reported back that the two worst things about WordPress were updates and plugins. And Matt’s State of the Word Speech was basically a call for more updates and plugins.

Chris Lema: It’s really annoying and costs a lot of money to retrain people when WordPress is updated, especially in the enterprise.

Jason Coleman: You’re whining.

Chris Lema: Of course updates are easy for you, you bleed blue WordPress blood. You need to be able to relate to end users who are confused by UI updates, etc.

And that’s about where we left it before moving on to the next topic. If I had time, I would have continued on like this…

First, I do understand the end user’s perspective. I have to do these updates for clients, answer the support calls, and sometimes retrain them. I used to be in the Chris Lema camp and thought WordPress was needlessly updating their UI too fast. I mean, I thought the change in version 3.3 to hide submenus in the dashboard behind flyouts was a big big deal. But that’s nothing compared to the potential change between the current version of the WP dashboard and this mockup of how things might look under the new “MP6” dashboard UI.

I’ve since changed my mind. Here are a few arguments for faster WordPress updates.

1. What’s the alternative? Slow down? Have fewer updates? I don’t think Chris’ enterprise clients would like that option. WordPress needs to iterate to stay relevant. If WordPress gets stale, we’ll stop using it to build cool stuff.
2. Things aren’t even changing that fast. That flyout menu feature was added in version 3.3 back in December 2011. Since then, the media library update was the only big UI change which happened earlier this year. An MP6-like update to the WordPress UI possibly (possibly) happening by the end of this year will be a big change, but then so is the jump from Microsoft Office 2010 to Office 2013. Enterprise should be ready for these kinds of things.
3. What about new users? Sure existing users are disrupted when the UI updates. But if the changes are meant to make WordPress easier to use, it will make training new clients easier. I use a similar argument all the time with clients: sometimes you can’t worry about the few existing users you have and need to instead focus on the many future users you want to have.
4. Finally, faster updates should encourage some changes that will make things easier for enterprise users. Things like automatic minor version updates or a better decoupling of the admin UI to the underlying WordPress framework are a bigger focus of WP development right now. I think the updates in these areas will make up for the inconvenience of a larger number of core updates.

I really mean for this to be a continuation of the discussion we started on the show. So I look forward to feedback and counterarguments in the comments below. Why am I wrong?

Update: Chris Lema has posted a reply on his blog.

The post Continuing the WPWatercooler Discussion on Rapid WP Core Development appeared first on Stranger Studios.