The Dilemma

In case it isn’t obvious from some of my previous posts, I’ve been giving a lot of thought to some of the problems with the WordPress plugin repository.

Though I’ve already stated this in previous posts, my goal isn’t to complain without offering solutions – I hate seeing it, and I hate doing it – I don’t think it’s proactive and that’s why I enjoy many of the comments that have happened around this particular space.

But as I begin consider moving back to a premium model of offering WordPress-specific products and services, this has raised yet-another-dilemma.

WordPress Plugins

When it comes to working with WordPress plugins, the dilemma is:

  • Exposure and ease of installation at the cost of free support (and other similar demands)
  • Potential for well-supported software that’s harder to discover

I know there are various models that dance between the two faces of this dilemma, but I think this is how we can distill the core issues.

Ease of Discovery, Installation, and Free Support

Discovery

If only WordPress plugin discovery looked like this!

This point has been belabored in a number of different posts here and elsewhere so I don’t want to continue the discussion anymore than necessary.

So suffice it say that one of the nicest things about the WordPress repository comes primarily from a user’s perspective: From within the dashboard of WordPress, they are able to search for plugins, install, evaluate, deactivate, delete, and repeat as much as possible.

Permitting the user is experienced with WordPress, it’s a relatively nice experience that’s hard to beat. In fact, I’d say it’s akin to Apple’s App Store without the need to actually pay anything.

The problem, though, is that users either end up asking for support that may be difficult to come by (though, as I’ve discussed before), though I don’t necessarily fault them for that.

Secondly, developers often treat the plugin repository has a way to tease or to offer ‘lite’ versions of their premium products in order to hook users into upgrading.

While I don’t necessarily have a problem with this, I think there are right and wrong ways to go about doing it, and I can understand how this may backfire by negatively impacting the user’s experience.

Higher Quality Products, Premium Support

Money Buys Better Products. Or not.

Money Buys Better Products. Or not.

This particular heading is somewhat of a misnomer because I don’t believe that premium products are necessarily of higher quality. In some cases, sure, but in other cases, not so much.

It’s a fallacy to say that if you don’t have to pay for something, then you’re getting a lower quality product.

However, there is something to be said for the level of support that can be achieved in a given product. In fact, I’ll even go as far as to say that if people are paying for a product, then you may be able to build a more tailored version of the plugin because customers are really good about identifying the problems that they are experiencing and how they’d like to see it enhanced.

Since they are paying, this incentives the developer or company to continue investing in the product.

When the product is free, I see almost the exact opposite behavior: “You aren’t paying for this plugin, so your suggestions provide less merit.”

But I digress on this topic for now.

The Problem of Exposure

Exposure

Exposure, sure, but not this kind (even though it’s kinda awesome).

If you opt out of promoting your plugins in the WordPress plugin repository, then it’s hard to deny that you’re amputating a significant source of exposure, but you’re doing so with the risk of providing an overall better customer experience – at least, that’s what I assume.

I could just be wrong :).

The WordPress Economy

Finally, I’d be remiss to say that part of what has made WordPress so successful is that there are people who contribute in a variety of different ways all of which end up making it the application that it is today.

Aside from core, there is documentation, themes, plugins, thoughtful dialog and conversion, and so on. Contributions matter, and though I do think one way to contribute back to WordPress is by extending it, I don’t necessarily agree that contributing plugins into the repository is the best way to contribute to WordPress.

But I’ll gladly open this idea up for discussion :).

Anyway, I wouldn’t present this if I wasn’t curious about where you guys stand on the issue, so if you’ve got experience or even general thoughts and opinions on this, please share.

Category:
Articles
Tags:

Join the conversation! 17 Comments

  1. Hey Tom,

    This is a really good question and It would be great if we could get a good discussion going on this.

    I agree with you that there are many ways to contribute to WordPress. Unfortunately, contributing to WordPress core can be very limiting because every commit goes through the filter of “will blogger users understand this” and “is this important to {Automatic, Core Team}”?

    It takes a long time to push through features that are important to advanced WordPress developers. This is good for the stability of WordPress but its very limiting for people who use WordPress to create more advanced sites and apps.

    One of the side effects of the fore mentioned filters is that we are not getting the APIs that are necessary to make development of apps and large sites easier. Everyone who builds bigger things with WordPress spends a lot of time reinventing the wheel. A good example of this is the menu manager in WordPress. Before WP introduced nav-menus, we had at least 5 different implementations of nav-menus. Now we only have 1. But even the nav-menu API is not complete. Anyone who tried to work with nav-menus programatically knows what a pain in the butt it can be.

    I’m not complaining, but rather summarising the situation that we are in.

    I and a few other people are taking a different approach to this problem. We are creating the missing APIs with the hope that they’ll be able to elevate the kinds of problems that we get to deal with on daily bases.

    The hypothesis is that if we have APIs to make it easier to build apps on WordPress then our conversation will be elevated from “how can I make a site for a restaurant” to “how do I build a WordPress-ish apps that I can package as a product to sell to people who want to create restaurant sites?”

    There are companies who’ve been trying to build apps without proper APIs. AppThemes is a good example of this. It’s also a good example of “when you have a hammer, everything looks like a nail.” Building apps as themes is fraught with limitations and problems. It forces the developers to find ways to work around WordPress instead of leveraging what made WordPress popular.

    Architecture diagram of Apps as Themes

    This architecture doesn’t give any room for an eco-system to grow because it doesn’t allow designers to create themes or allow developers to create plugins that can extend these apps.

    We need – I would argue – a way to create apps that are WordPress-ish. WordPress-ish means that they behave similarly to the WordPress Blog App. The apps that we create should be themable using WordPress themes, extendable using plugins, and redistributable as plugins. These apps would use WordPress API + the missing API to make it possible to create large sites and apps easily.

    Architecture diagram of Apps beside Blog App

    If we can make this happen, then we’ll have a new eco-system emerging that allows people to as easily build apps with WordPress as it is to create beautiful sites. In this new eco-system, we can create products that people want and be in control of the APIs that enable us.

    What do you think?

    • It takes a long time to push through features that are important to advanced WordPress developers. This is good for the stability of WordPress but its very limiting for people who use WordPress to create more advanced sites and apps.

      Agreed. As much as I see the viability of using WordPress as an application foundation and want to continue to see API’s grow, the core vision of the application is still to be a publishing platform or a content management system (whatever you want to call it, I suppose).

      To that end, features that aren’t aligned with the core vision are always going to take a backseat to those that fulfill it’s core vision.

      I know you get that, but I bring it up because I think that there are ways that we, as developers, can add functionality to WordPress that allows us to accomplish what we want through plugins.

      I mean, I think it’s be pretty neat to have a suite of plugins specifically geared towards developers that may (or may not) be folded into core. Regardless, I’m sure that we – as developers – all have snippets of code that we reuse. It might be kind of cool to have a library of these tools and code snippets that we use ourselves.

      Maybe one day when we’re not all too busy, we could build something like that ;).

      But even the nav-menu API is not complete. Anyone who tried to work with nav-menus programatically knows what a pain in the butt it can be. I’m not complaining, but rather summarising the situation that we are in.

      Sure, sure. Granted, I’m relatively early in my career, but I assume this is just the nature of software. It’s basically a living thing that’s going to grow, change, mature (and even regress in someways) over time.

      That’s the nature of the beast.

      So just as incomplete as it is today, at least we’re down to one solution rather than five or rather than reinventing the wheel, you know?

      We are creating the missing APIs with the hope that they’ll be able to elevate the kinds of problems that we get to deal with on daily bases.

      Yep – I’m even familiar with a number of different groups like The Theme Hook Alliance that’s trying to define a set of consistent hooks that themes will provide.

      In theory, I think it’s a good idea, but from a pragmatic standpoint, I’m honestly not sure. I see the benefits, but I also see the fragmentation and lack of consistency it creates. But, honestly, I’m not a fan of having a single entity be the end-all-and-has-the-final-say about things, either.

      To me, it’s a dilemma with no clear solution.

      Building apps as themes is fraught with limitations and problems. It forces the developers to find ways to work around WordPress instead of leveraging what made WordPress popular.

      Spot on. Couldn’t agree more. My stance is that if you’re going to build things with WordPress, then you need to work within the confines of the API. The challenge, though, is since the underlying language is PHP, you can almost force the program – be it your app theme or whatever – to do whatever you want by circumventing the core API’s and manipulating globals, the $_POST, the $_GET, sessions, arrays, and so on.

      And at that point, it’s almost worth asking why bother with WordPress at all? But I digress.

      These apps would use WordPress API + the missing API to make it possible to create large sites and apps easily.

      I like this idea, but I think it has to be discussed further (hopefully by other commenters, as well – I don’t have answers, either. Just thoughts like you :)).

      The thing is half of creating applications using WordPress is stripping away (read: hiding or masking) features that irrelevant to the problem at hand. On top of that, there’s also the challenge of styling the admin or creating your own custom dashboard and handling the rewrite rules, permissions, etc. to keep users within the confines of the program.

      All good thoughts, IMHO. Hopefully we can breed a larger discussion from this.

      • Thank you for for the thorough response. I’m glad that we’re aligned on so many topics.

        Maybe one day when we’re not all too busy, we could build something like that .

        I started to work on this the beginning of this year with frequent feedback from Mike Schinkel. I’ve been calling this library ScaleUp. You can see early versions of it on Github at ScaleUp & ScaleUp App. They are 2 separate libraries at the moment, but I’ll probably join them into 1 in the future.

        I invested over 250 hours developing ScaleUp and I’ve gone through 2 iterations of ScaleUp architecture. I haven’t had much time on further building the ScaleUp App functionality. ScaleUp App will be my primary focus after I finish my current project.

        I’m positioning my company WRKTG Inc as a company that “builds MVPs for Lean Startups using WordPress & ScaleUp.” All other applications of this framework will be out of my primary focus. I have several startups who will be contributing some of their seed funding support the development of ScaleUp for the benefit of leveraging modules that will be contributed by other startups.

        I’m currently working part time on ScaleUp while I’m finishing up my last non-ScaleUp project. Starting June, I’ll be working fulltime on ScaleUp.

        The time is now :)

        I value your prospective very much and would be honoured if you would consider giving me feedback ( at some point ).

        • All other applications of this framework will be out of my primary focus.

          I should say that it will be out of my main focus, but I welcome feedback from others who would want to use ScaleUp for whatever purpose that wil benefit their business.

  2. Hey Tom,

    Interesting points. I’ve been following your thoughts on premium/free plugins. I think that maybe the problem is that premium plugins can benefit from two things.

    1. Curation
    2. Centralization

    So here’s what I’m thinking. You can set-up a centralized premium plugin marketplace. But not like code canyon is set up now, rather a monthly subscription based model. If the plugin repository is like the App Store then this would be like Netflix.

    This marketplace would bulk license plugins from developers. If a user pays however much a month, they have access to all of the plugins in this premium repository. And if they have a problem with a plugin they submit a request to this marketplace. In turn, the marketplace takes a little bit of a cut and manages support, aids with documentation, connects users with problems to the right people, and can even help to find people to take over plugins that an author would like to give up.

    With everything in one place, and access to it all, the experience would be much better for the users and for the developers. Exposure would be a little easier too, as you could browse through lots of new plugins selected by the marketplace to be featured. Also, plugins would be held to a higher standard then the current WordPress repository, to make sure that they won’t break themes or interfere with other plugins.

    This may be able to draw from some of the best parts of the WordPress repository, mainly ease of access between users and developers a la support and forums, while still ensuring premium quality, support and of course payment for hard working developers.

    But I’m just spit balling. Do you think something like that could work?

    • @Jason Hoffmann, “pay for what you need” might be more appropriate than “pay once get all” because it creates a direct relationship between user’s needs and development and support that’s necessary to support those needs.

      The other problem with “pay once get all” approach is that it doesn’t account for the fact that support and maintenance of code requires ongoing effort. WordPress upgrades happen twice per year. These upgrades might require additional support from the developer. If the use pays only once, then the developer gets an ever increasing liability with a diminishing value of every purchase.

      It might be more suitable to have the user pay per plugin per year for support subscription. This would generate repeating revenue to the developer and create incentive for the developer to continue to support and improve the plugin.

      There is another issue that’s related to licenses that needs to be considered. Currently, some commercial plugin developers provide license for a certain number of sites. I find this extremely awkward. It requires addition infrastructure to maintain and the user needs to manage license keys.

      I’d like to see that per site license model go away. The “per plugin per year” subscription model could serve as a good counter balance to the elimination of the “per site” license.

    • So here’s what I’m thinking. You can set-up a centralized premium plugin marketplace. But not like code canyon is set up now, rather a monthly subscription based model. If the plugin repository is like the App Store then this would be like Netflix.

      The reason I’m not a fan of this model is primarily from an standpoint: Users pay a flat fee to access plugins that are of varying complexity. Whereas one plugin may be worth $10 and another may be worth $100, the user is subscribing for, say, $5 / month thus the cost to development, maintain, and support the core application doesn’t scale.

      And this doesn’t handle the case of the third-party cutting into the cost to take their profit sharing for hosting, managing, or maintaining the plugin.

      But I’m just spit balling. Do you think something like that could work?

      Respectfully, I disagree. I completely get the concept and the direction that you’re taking this, but – and I may be over simplifying this – it’s kind of “kicking the can down the road” by basically recreating the existing marketplace, but with a paywall.

      That said, I’m biased towards a product model where a vendor provides the service or product and is also responsible for the support. The more that I see certain behaviors in the ‘free-for-all-forums’ or the ‘community-driven’ networks, the less I am inclined to want to share my work there.

      There’s more to say on this, but I don’t want the comment getting too long ;).

      • Just a related point here RE recurring memberships for plugins: It’s important that how you charge people is inline with how they use your service.

        If people are paying monthly for your service/product/etc, but they just download everything on day 1 and get their support requests handled in week 1… they are either going to cancel their account after a month or see your charge on their credit card statement 6 months later and submit a chargeback.

        If you are charging your customers every month, make sure you are giving them value every month.

        • These are all good points (and your membership model is one that I’ve actually been considering for when I finally move everything over), but one of the things that I’ve been considering is offering, say, three options:

          One time download with 1 month of support
          One time download with 6 months of support
          1. One time download with 1 year of support

          Beyond that, they would then have the option to choose or renew how they wanted.

          There are still issues with this particular approach that I’m thinking about, but I figure it puts the challenge and ethical responsibilities on the customer rather than myself.

          • You definitely need to limit the support. I find most people get their support in the first week and you never hear from them again.

            However, at the time of checkout, they might be kind of “scared” into a higher price point. Having tiers related to response time might also make sense as a way to get customers with fatter wallets to pay a higher fee.

            Some of our customers who are developers come back time and again with different questions for different client sites, etc. Since they are developers, the quality of question is usually really high and often times they are really helping to find bugs and improve the plugin. In a sense they become partners instead of customers.

            It might make sense to do different plans like you suggested. Another thing I’ve been considering is limiting support to one domain per support account (on the honor system I suppose) and maybe charging a higher price for developer support plans.

            I think the main drawback with the “everything is free but support” model is the impression that your plugin is “free” and the stigma that comes with that. There are also some types of plugins that require little support but also require a lot of development time and the ratio of people using the plugin vs. paying for it might be too low to make good money.

  3. Why not do what Jason Coleman has done with Paid Memberships Pro? He’s created a feature-rich solution that he offers for free but he charges for support. I know it’s simple yet it gives him exposure, while also providing a mechanism for revenue generation at the point of pain (the need for support). He also offers packages for client customizations (a different pain point for different users).

    • Thanks for the mention, Chris. I think that the business model we have chosen would be a good way for a lot of WP plugin developers to go because it allows you to have the benefits of the WP repository while still giving paying customers a legit way to pay you and get support. I did a write up that should be helpful:

      http://www.paidmembershipspro.com/2013/02/the-paid-memberships-pro-business-model-copy-it/

      I have yet to prove that I can build a larger business focused solely on one or more plugins, but that’s what we’re shooting for and I think we’ll get there. In the meantime, the revenue from support and installs offsets the time I spend supporting and developing the plugin, and the visibility of the plugin has gotten us better consulting gigs.

      • As a customer, not a developer I have different view – I like to try out a plugin for free to see if it will be compatible with my theme and other plugins, but I like the option for paid support and extensions for additional features.

        Although Jason does not use paid extensions for Paid Membership Pro – I use it on my membership site – I do like that and think it could be a very good model, like what Yoast is doing, or like WooCommerce does.

        Or offer maybe by offering great free plugins you can lead people to buy your themes, like GraphPaperPress.

        I want to see developers charge – I have a favorite free plugin that has not seen any updates in almost a year, their premium addons have not come out – I keep checking – their home page is dormant, and I worry soon that it will no longer work, and then what will I do? I’d be happy to pay for it, and I think others would have to, rather than see it slip into oblivion by relying on donations.

        • Love this perspective, Lisa. Thanks for sharing it!

          As a customer, not a developer I have different view – I like to try out a plugin for free to see if it will be compatible with my theme and other plugins, but I like the option for paid support and extensions for additional features.

          So based on what you’re saying, you seem to be a fan of the whole freemium model for plugins. One question that I have for this: if a free plugin doesn’t look right with your theme, are you apt to contact the developer and ask for help for styles or do you typically uninstall it?

          I want to see developers charge – I have a favorite free plugin that has not seen any updates in almost a year, their premium addons have not come out – I keep checking – their home page is dormant, and I worry soon that it will no longer work, and then what will I do? I’d be happy to pay for it, and I think others would have to, rather than see it slip into oblivion by relying on donations.

          I hesitate to make a blanket statement like this, but I think that the donation model simply doesn’t work. There’s a sense of entitlement that free plugins have bred among the WordPress user base (not with everyone – obviously, you’re up for paying), but people ask questions, are generally rude, or near-demand some type of fix that just makes it really hard for developers want to do when they’re not being compensated for the time to build something that helps others with their site, you know?

      • i’m going to take a close look at what you are doing. I don’t like the idea that once your code is out there you can’t pull back and have it be premium. So I would like to organize in a way that straddles the line. With both paid plugins and free plugins but with a similar support model.

        I think that if you have free and premium. That the free should always work for the data manage by the free version. And that the premium version might just include more tools. So that someone can use the free version so that their site won’t break. That might not work in all cases. I like the types and views approach that I read about (but haven’t used yet). Where you have custom post types as free and then views as pay. Which is sort of analogous to themes.

        But I think that you might make a custom post type with a free plugin and then a high quality workflow plugin for editing and managing that type as a paid plugin. Because just having the custom post type is fairly trivial. It is all the work to make the admin user friendly that is of value.

        Even more than the styling because styling is hard to package unless you are creating full themes. And styling has to be tweaked to match whatever is being used.

    • Oh, totally. Jason and his team have done it right, in my opinion.

      Ever since I stumbled across his post on his method, I’ve kept it bookmarked so that when I begin to migrate over to a more premium solution, I’ll borrow a lot of what he’s done.

      I may not do everything the same – I’m still mulling a lot of it over – but there’s plenty of good stuff that he offers that I think will provide at least some form of longevity over a lot of the models that currently exist.

      • (This you might have replied to the wrong comment, but I’ll reply to yours here.)

        I’m really looking forward to hearing how you organize things and how the model works for you (especially if it is like the one we’re using with Paid Memberships Pro). It would be good to get more data on whether or not this can work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.