Official Plugin Store

[angrybrad]

Created by: Selvin Ortiz (selvin@selvin.co) on 2015/03/10 20:43:19 +0000 Votes at time of UserVoice import: 224

---

Plugin development and the Craft community as a whole would benefit greatly from an officially supported plugin store.

The plugin store would allow us developers to more easily sell/distribute our plugins and more quickly provide bugfixes and updates as well as enable our customers/users to have a single place to manage plugin licenses, request plugin specific support, and possibly have access to plugin docs right within the control panel.

Granted the plugin store is built into the control panel and provides a feature set similar to the one that has been discussed in back channels. Most of which is not public knowledge at this point.

Having websites like straightupcraft.com to discover new plugins and craftpl.us to sell/distribute commercial plugins is a descent start but I feel that an officially supported plugin store built into the control panel would benefit us far beyond the immediate problems it solves and would allow us to be better organized and to be more closely aligned with what a modern CMS should be.

Though some people have said that there are other priorities that should take precedence, I believe that the plugin store should be at the top of the list because formalizing this process would most likely motivate other agencies to invest in Craft plugin development and hopefully we can get some big guns to actually fill the gap that freelances have been unable to fill for so long and finally have fully featured commercial tools for draft/review/approval workflows and calendar/event implementations as well as robust e-commerce solutions we can deploy and that take advantage of Crafts localization, element type API, etc.

Without a formal process, we're going to continue to have quantity in plugins but not as much in the way of quality, continued development, and adequate support.

A plugin store, in my humble opinion, should be high priority on the list.

[angrybrad]

Posted by Christian (seelbach@gmx.de) on 2015/03/09 00:49:13 +0000

It would be nice if the plugin store would allow donations or “pay what you want” licences.

With some kind of indication in the settings / plugins view that reminds the users that they’ve done good (a small Happy Developer badge or something like this).

I think this would be a nice way to support developers who

• want as many people as possible use the plugin (do something good for the Craft platform and community)
• offer a plugin that make the developer’s life easier (hard sell because the client has no direct benefits from it)
• offer a small utility/helper plugin (e.g. stop developers abusing Twig)

All these plugins do still require maintenance and support, and I’m quite confident that there’s quite a few developers and client’s who are willing do give something.

[angrybrad]

Posted by Matt Wilcox (mail@matthewwilcox.com) on 2015/03/10 18:54:52 +0000

I would deeple appreciate plugins being rolled into the Craft update system; because as joyful as one-click updates of Craft core is - it is a ball-ache having to manually update plugins every time. It'd also be useful to know beforehand, on one page, if certain plugins are compatible with a pending Craft update yet.

[angrybrad]

Posted by Florian (fw@demodern.de) on 2015/03/13 06:38:29 +0000

it does indeed. Expected it a tad earlier as well. Better save then sorry. In P&T we trust :)

[angrybrad]

Posted by Julian Kovalsky (julzmon@gmail.com) on 2015/03/19 18:25:13 +0000

Woo hoo. A year from now seems so far.

[angrybrad]

Posted by Nate Iler (nate@flipboxdigital.com) on 2015/03/11 14:29:14 +0000

With the announcement of the Plugin Store being added to Craft 3, I'd like to voice some features while it's early.

1) Licensing: Inherit similar functionality to the Craft licensing...trying to mitigate someone buying one plugin and using it across multiple installs.

2) Recurring/Renewal: Ability for developers to collect recurring (terms unknown) or renewal (terms unknown) capabilities. Help developers support their plugins and add new features.

3) Testing: Establishing some min standards for plugins getting added to the store. Code coverage / pass tests / etc.

[brandonkelly]

Some things we can share, now that development is underway:

• We will be dropping support for manually-installed plugins via the plugins/ folder. All plugins will have to be installed via Composer (though it will be possible to install/update plugins from the Control Panel for the terminal-averse).
  • Therefore all publicly distributable plugins must be available from public GitHub repos (whether OS or commercial/proprietary), and registered with Packagist. (For private/internal plugins, see my comment below.)
• Plugin Store license validation will work similar to Craft CMS / Commerce – all plugins can be installed for free on non-public domains indefinitely as a trial; license validation only kicks in for public domains.
• License validation only works for plugins that are sold exclusively through the Store, since Craft can’t be sure if a plugin is legit if there’s a chance it was purchased elsewhere.
• Subscription-only pricing tiers (no one-time pricing) at a range of fixed price points (starting at ~$49/year). Tier options are:
  • 1 license ($X/year)
  • 2-5 licenses (~$1.5X/year)
  • 6-25 licenses (~$2.5X/year)
• We will take a 20% transaction fee, which includes CC processing fees, which will get reinvested back into the Store
• ~We are considering $100/year developer fee, as a way to keep cruft out of the Store.~

Things that won’t be there at launch but worth considering down the road:

• User ratings/reviews
• Sales
• Bundles
• Plugin/developer certification

cc @nateiler @selvinortiz

[tjdraper]

I just want to make sure I’m getting my head around this correctly:

• No one license per domain pricing? Only subscriptions can be purchased through the store?
• Plugins that do not wish to participate in subscription pricing much be available publicly in a GitHub repo so they can be installed through composer (and only composer)?

[brandonkelly]

No one license per domain pricing?

If you only need one license, then yes you can start with that. But as soon as you need two licenses, you can upgrade to the 2-5 license subscription tier, for roughly 50% more. Same goes for the 6-25 tier. If you need more than 25, you’d start over with a second subscription, etc.

Worth noting that in practice, the 2+ tiers only apply to devs/agencies that tend to manage licenses on their clients’ behalves. If your clients are the ones owning the licenses, they will just have their own single-install licenses.

Only subscriptions can be purchased through the store?

Correct. Our stance is that one-time pricing just doesn't make sense for web software, especially CMS plugins. Even relatively simple plugins that are “feature-complete” are never actually “finished”, given all the moving parts, between bug reports, security vulnerabilities, browser and CMS platform changes, etc.—and that’s not even touching on normal support or feature updates! So one-time pricing just ends up being unsustainable in the long run.

Plugins that do not wish to participate in subscription pricing much be available publicly in a GitHub repo so they can be installed through composer (and only composer)?

To be clear, all Craft 3 plugins will be Composer-installed, commercial or otherwise. We are going to completely remove support for manually installing plugins in the plugins/ folder, for a variety of reasons. The Plugin Store will provide a way to install plugins without going into the terminal (probably even for plugins that aren’t in the Store), but it will still be Composer under the hood.

[wbrowar]

@brandonkelly Thanks for sharing this info early on. Here are a couple more questions:

Therefore all plugins must be available from public GitHub repos (whether OS or commercial/proprietary), and registered with Packagist

• There are times—like when integrating with Third-party systems—where we'll need to write a plugin specific to one project's needs to use PHP functionality that's not available in Twig. Forgive me as I'm not super familiar with Composer and Packagist, but does this mean that we'd have to put that plugin up on it's own public repo in order to use it in our project? If that were the case I'd have a concern that we'd have to expose code that we're otherwise prefer to put in a private repo, just to use PHP in our sites.

• Does subscription pricing mean that you'd pay annually (or whatever the term will be) to maintain the license to use the plugin (if so, what happens when the subscription lapses)? Or does it mean that if you decide to stop paying the subscription, you'll be able to keep the plugin on your site, but no longer be able to get support/download updates?

Thanks! Will

[brandonkelly]

does this mean that we'd have to put that plugin up on it's own public repo in order to use it in our project?

Great question, @wbrowar. There are 2 ways you can avoid putting your plugins on public repos:

1. Define a path repository in your project’s composer.json that points Composer to a local Composer package for your plugin. Composer will symlink it into your project, rather than attempting to fetch it from Packagist. (We explain how to do this in the plugin docs.)
2. Use Private Packagist – basically Packagist for private repos (not free).

Also worth noting, in Craft 3 you don’t actually need to make a plugin for project-specific code. We have to document this, but I touched on it a bit at the Craft 3 Plugin Dev workshop at Peers. See slide 45 of https://speakerdeck.com/brandonkelly/craft-3-plugin-development for the gist.

Does subscription pricing mean that you'd pay annually (or whatever the term will be) to maintain the license to use the plugin (if so, what happens when the subscription lapses)? Or does it mean that if you decide to stop paying the subscription, you'll be able to keep the plugin on your site, but no longer be able to get support/download updates?

The former, as we wouldn’t be able to halt updates even if we wanted to. If a subscription lapses, everything will continue to work, but a nag alert will appear at the top of the Control Panel prompting users to renew the subscription or uninstall (similar to what happens if you try running Craft Pro with a Personal license on a public domain).

[wbrowar]

Thanks for the clarification, @brandonkelly! Really looking forward to seeing this come together.

[davidhellmann]

What is with Private / Portfolio Sites. I've no Problem for Client Projects or Agency Projects but as a Developer with my own site and some little Sideprojects it is maybe a bit cumbersome to spend hundrets of doller to use plugins and play with it. Maybe a Pricing Model close to the Craft License Model would be fine. Like: Personal / Client / Pro with different Pricings for the Plugins,. Maybe also free for private. I'm 100% with the Plugin Devs that they get their money but the money should come from client projects where is the money and not from the personal devs / desginer the are happy to go with craft.

But just my two cents.

[steverowling]

@brandonkelly Thanks for sharing your thoughts on this.

Thinking through a scenario, I wondered how it might work in practice.

Assume I buy Plugin A through the store in January and pay the 1x subscription tier. A couple of months later in March I buy the plugin again for a different site and now I'm on the 2-5 subscription tier. When is my renewal payable at this level? January or March?

If each plugin purchase subscription lasts for 1 year, but multiple copies are purchased over 12 months, how are these grouped together and how is the renewal date calculated?

Or would I need to commit to a particular subscription tier for a year when I first purchase a plugin, which then allows me to install it on up to as many sites as the licence tier covers within a 12 month period?

[narration-sd]

@davidhellmann I think your point is covered in Brandon's first statement, happily?:

Plugin Store license validation will work similar to Craft CMS / Commerce – all plugins can be installed for free on non-public domains indefinitely as a trial; license validation only kicks in for public domains

@brandonkelly went after your Speakernotes to see non-plugin extension --- that's the best set of speech notes I think I've ever seen. I kind of knew most of it anyway by now, but has its impact...!

Cheers both

[carlcs]

@narration-sd using a plugin on a non-public domain (trial usage) is not the same as using it for free on personal sites (similar to Craft Personal license).

[davidhellmann]

@narration-sd

I think your point is covered in Brandon's first statement, happily?: That sound more like in dev enviroments not on my wish :)

[narration-sd]

@carlcs You're right -- I missed that distinction, this time of night. Ditto @davidhellmann

Maybe @brandonkelly can have a thought for this. It's how I presumed it would work also....though it's true Craft sites nor presently licensed plugins don't...

I should go to bed, but now I'm not sure myself that the proposed way isn't the wisest.

David, where did you enjoy this privilege before -- and wasn't that given by a plugin developer like Squarebit, who could do that also for an unlicensed version off their own site in Craft 3? The discomfort of Composer install might tend to see it was used as intended.

Definitely needs more thought, as to what even we want, and quite possibly @takobell and @brandonkelly already have gone well through it.

[mmikkel]

Correct. Our stance is that one-time pricing just doesn't make sense for web software, especially CMS plugins.

@brandonkelly What about CMS'es? Are you moving Craft to a subscription based model?

[dennisfrank]

@brandonkelly Thanks for sharing. It’s great how much you care on how to maintain a healthy and rewarding plugin ecosystem. I hope you can answer a few questions and comments.

1. Could you explain the tiers? What does “2-5 licenses (~$1.5X/year)” mean? For 2-5 licences each licence costs 1.5x or up to 5 licences cost 1.5x all together?

2. I am also interested in your thoughts on bundling plugin licences to Craft Personal/Client/Pro licences. I plan to use Craft for personal or non-commercial sites too (e. g. a site for a friend’s band). A yearly licence fee could be a deal breaker for those kind of sites.

3. I would prefer a Sketch-like licence renewals:

When you purchase Sketch for the first time, you can use it for as long as you want—but you’ll only receive free updates for a year from your date of purchase. If you find that your license has expired after that year don’t worry, you can continue to use Sketch on your last-updated version. You will not be eligible to download any further updates without first renewing your license.

A license model like that would encourage plugin developers to maintain and update plugins regularly. They could bind custom support to paid licences as well.

Any thoughts on this?

[brandonkelly]

Maybe a Pricing Model close to the Craft License Model would be fine. Like: Personal / Client / Pro with different Pricings for the Plugins,. Maybe also free for private.

We could consider adding something like a “Free for personal use” option that plugin devs can opt into. /@davidhellmann

[brandonkelly]

Assume I buy Plugin A through the store in January and pay the 1x subscription tier. A couple of months later in March I buy the plugin again for a different site and now I'm on the 2-5 subscription tier. When is my renewal payable at this level? January or March?

Good question @steverowling. If you wish to upgrade a subscription to a higher tier, we will probably just discount it by some % of what you paid for the lower plan. So if you’re 1/4 into a single-license subscription for $100, and the 2-5-license subscription is normally $150, it will only cost you $75 for that first year (150 - (100 * .75)). Essentially we would be giving you a refund for however much of the lower tier plan you didn’t end up using, and then starting you fresh with the new higher tier plan. Your renewal date going forward would be March.

[narration-sd]

Well, think to weigh in one more time here, especially after considering on comments of others, showing up on Slack.

I guess I'd really like to suggest a separate (and not competing in concept with the store) tier -- a simple one.

Why. Well, continuity of situations developers, and as they grow, is at the root of it -- that and protecting ability the for small and not so profitable projects you guys have always been so well in support of..

People have to start somewhere, and that is not often as a full-service agency prepared to advertise, promote, create constant innovation, and so forth, as would be the justification from the customer's side to purchase subscription plugins.

I also still remember the original considerations about the store, how to assure its quality levels, etc., and those are important, with the present plan an intelligent route-around for any number of those issues. I was impressed.

How about this, then?

• the store just as you propose it, for the 'substantial for agencies' types of offerings
• the same delivery mechanism only, offered to be freely used -- unadvertised, unsupported except for the mechanism itself, which will be paid for by the premium subscriber path as you plan.

With that second, quiet part, now the new, the free-for-certain-uses, the self-sold, and the single-payment of any kind plugins all have a solid basis in Craft, which can easily remain not very visible.

The premium products and the store's value on the other hand shine, for anyone who goes to that stage, and are paid for their qualities.

It's worth considering, would think, that you'd also save on support costs occuring, for persons who would otherwise attempt to configure plugins via Composer raw etc. -- the kind of case that's rising as you see already for other areas, even PHP installs, as Craft's appeal broadens.

Always these things are a great balance to discover, and I often respect just how good you guys are at at that, so you know the way this is simply a suggestion, @takobell and @brandonkelly.

[brandonkelly]

Could you explain the tiers? What does “2-5 licenses (~$1.5X/year)” mean? For 2-5 licences each licence costs 1.5x or up to 5 licences cost 1.5x all together?

The latter. For a little context, we’re basing this off a popular model in WordPress’ plugin ecosystem, which seems to work really well for plugin devs.

Our top priority with the Store is to make Craft plugin development a sustainable business, so devs are encouraged to stand by their plugins and customers for years to come, and we think taking a firm stance on this model is our best chance at achieving that.

I am also interested in your thoughts on bundling plugin licences to Craft Personal/Client/Pro licences. I plan to use Craft for personal or non-commercial sites too (e. g. a site for a friend’s band). A yearly licence fee could be a deal breaker for those kind of sites.

I don’t see this being a huge issue, especially if you’re on a 2+ license sub and are able to charge the client a discounted rate on it, but we’ll see how it plays out :)

I would prefer a Sketch-like licence renewals:

I agree it seems like that would be a good option on the surface. But there’s two issues:

1. Even if we wanted to go with that model, the Plugin Store doesn’t control updates (Composer does) so it can’t put a stop to them if the subscription ends, and we aren’t handling plugin support (the plugin developers do), so we can’t put a stop to that either.

2. There are more moving parts with CMS plugins than a desktop app (browser/CMS platform updates, compatibility with other plugins), and they are at a much higher risk for security vulnerabilities, so the idea that you can buy a plugin and “use it for as long as you want” without ever updating it just isn’t realistic.

/cc @dennisfrank

[wbrowar]

Maybe a Pricing Model close to the Craft License Model would be fine. Like: Personal / Client / Pro with different Pricings for the Plugins,. Maybe also free for private. We could consider adding something like a “Free for personal use” option that plugin devs can opt into.

@brandonkelly I think this is what you're saying, but here's a bit more elaboration on my thoughts on this:

It puts a bit more work on Craft's end to manage this, but it would be great for a plugin developer to be able to offer one plugin code base at both a "Free" and "Pro" level. It would be great if Craft could provide a way to check which level the plugin is at so a developer could provide functionality based on which level they are using. When the customer is ready to use the Pro features, they can subscribe to the plugin at that point.

• This would allow plugin developers a way to offer some functionality fitting for a personal or smaller website without requiring payment, up front.
• Upgrading from Free to Pro would be a much better customer experience than having to migrate settings from a Free plugin to a separate Paid version.
• As a customer of Wordpress plugins, I hate when you download the free version of a plugin, then the plugin spams the control panel with "Upgrade to get this other feature" messages. Having a controlled and consistent way to do this—within the Plugin Store—would avoid plugin developers having to come up with their own upgrading methods. This would avoid my frustration, as well as avoid my clients needing to be bothered with these types of messages.
• It provides a simple way for a developer to communicate which features they choose to be supported, if they choose to say the Free version is provided as-is (which ideally the Free version would still be updated)

[ryanmasuga]

Therefore all publicly distributable plugins must be available from public GitHub repos (whether OS or commercial/proprietary), and registered with Packagist.

Question about that: We don't use Github for our repos. To participate, we'd have to move repos to Github from Bitbucket? In other words, our commercial Link Vault plugin that is currently in a private repo at Bitbucket needs to move to a public GitHub repo?

[brandonkelly]

@masuga Looks like Packagist also has a BitBucket hook (https://packagist.org/about) so that should work too, but yes it will need to be a public repo.

That may feel unsettling at first, but remember you are distributing unobfuscated PHP code, so there's not much your repo is keeping secret in the first place. And FWIW we are finding it to be a big net positive having Craft CMS out in the open, and we're looking forward to doing the same with Commerce.

[aelvan]

Looks like the training wheels are off for business models too! :)

Correct. Our stance is that one-time pricing just doesn't make sense for web software, especially CMS plugins. Even relatively simple plugins that are “feature-complete” are never actually “finished”, given all the moving parts, between bug reports, security vulnerabilities, browser and CMS platform changes, etc.—and that’s not even touching on normal support or feature updates! So one-time pricing just ends up being unsustainable in the long run.

All though I agree that there is a problem (sustainability of CMS plugins) and the analysis of the problem (making and maintaining software is frikkin' hard), I think the solution you're proposing is grossly simplified. I don't see the pricing model as being the main problem here.

If the volume of sales, ie. the size of the Craft user base, was big enough, a one-time fee (at the right price) would be able to support the maintenance of a plugin. The problem is that developing plugins for Craft is like trying to make a living by making custom gear-knobs for Dodge Vipers. Most likely you'll not sell enough to make a business out of it...

Comparing it to what works for developers of Wordpress plugins isn’t really relevant. With the difference in market size, it’s to be expected that different pricing models are necessary. When EE started to tank, prices got raised and new subscription models were introduced. That didn't help anyone, and the reason it didn't wasn't because the price models was wrong, it was because there wasn't a market to sustain the products anymore.

As far as I know, P&T has always used one-time fees both for your EE plugins and for Craft? Correct me if I'm wrong, but it seems to have worked out just fine. The fact that it hasn't worked out for a lot of other developers, brings me to my second point...

Very, very few developers have what it takes to make a living off of making plugins. Developers see plugin development as a quick way to make some extra cash, and don't have the required skills and stamina to do long-term product development. It doesn't matter if the client pays a subscription, when they're off on vacation, burnt-out, or otherwise indisposed, there is no support and no upgrades. That tiny trickle of cash isn’t going to save anyone from being burnt out.

Don’t get me wrong, I’m not opposed to having the option of subscription pricing models, I just don’t think it helps one way or the other. I think a much more effective strategy for long-term sustainability would be to discourage developers from venturing into the commercial plugin business. But, that can of course be done no matter how the plugin store works. :)

And, since I’ve already let it shine through that I hate commercial plugins and believe that the Craft community would be much better served by having a strong FOSS community backing it…

Subscription-only pricing tiers (no one-time pricing) at a range of fixed price points (starting at ~$49/year).

@brandonkelly Does this mean that there won’t be a place for free plugins in the official store?

[gisu]

As I read this, the free plugins are not available through the store. Actually the store was once thought for all plugins as a central starting point. @aelvan

[carlcs]

@aelvan @gisu Free plugins will be allowed and plugin devs are still free to sell elsewhere. See @brandonkelly’s replies to my questions in the #craft3 Slack channel this morning (9 hours ago).

[ryanmasuga]

@brandonkelly Thanks...so, let's say we decide to not sell or share/distribute Link Vault for Craft any longer, then. We don't want to share the code (no public repo), we want no one to ever see it again, anywhere, except us. We're just going to use it ourselves, on every site we build (which we do, currently). You may have mentioned this above, but would we need to convert that into a bootstrapped non-plugin kind of thing, per your slide deck, otherwise we wouldn't be able to install it? Or can it remain a plugin, and we set it up as Composer dependency as you mentioned earlier?

[clowerweb]

First, I'm going to summarize what I understand from what I've read so far, please correct me if I'm misunderstanding anything.

• Putting plugins in the store will probably require a $100/year developer license from Craft
• Craft will take an additional 20% of plugin sales/subscription fees
• All plugins must be on the official store, so they can't come from third party sources anymore
• ~No more free plugins~
• No more flat-priced plugins, all plugins must follow a subscription model
• Plugins MUST be installed via Composer or Packagist
• Plugins must be hosted as public/open source repos on GitHub or Bitbucket, unless you pay for a special Packagist license to access your private repos
• If someone cancels or stops paying for their plugin subscription, the plugins continue to work and update as normal, but the user gets a notice at the top of the Craft admin section asking them to either uninstall it or renew their subscription

Assuming I'm understanding all of this correctly and I'm not just way out in left field somehow, I can see a lot of developers and clients alike being alienated by some of these. Let's go through the items one by one:

• Developer licensing: I get that it's supposed to be to keep junk out of the store (and completely not for extra profit), but what's wrong with letting the market decide what's "junk"?
• The 20% fee is fine, or the $100 developer fee, but I dislike models that double dip like this (see the iOS store for a popular example; it also does nothing to keep junk out of the store if it wasn't obvious).
• So, as a web developer, if I'm making a custom plugin for a client, it HAS to be in the official store, even if it's supposed to be proprietary for the client? And either myself or my client has to purchase a subscription for my/their own plugin? What about during plugin development? You implied that the system somehow enforces plugins only being installable via Composer/Packagist, from a public repo, and it must also be in the store - how is this enforced, and how do I develop and test my own plugins?
• If I have 10 plugins, now I have to keep track of and maintain subscription fees to all 10 plugins? Sounds like a hassle. Further, I hate how software is moving more and more into subscription models. It feels greedy and anti-consumer. I already have to pay for subscriptions, as a developer, for Microsoft Office, Adobe CC, PHPStorm, GitHub, web hosting, and now Craft and Packagist... it's a lot to keep track of and for the software, I wish I could pay a one-time fee (and maybe again as I choose to update to major releases) and be done with it. If there were viable alternatives that didn't require the subscription model, I'd jump on them. They get away with it because they don't really have competition in their market space - the PHP CMS market space is however teeming with competition, if you catch my drift ;)
• If plugins have to be hosted open-source (barring purchasing a special Packagist subscription... more fees, yay!), what stops people from pirating them? Is it constantly calling home to check the license? I'm not sure if I like that. What about the overhead? What if it can't connect to the Craft site to verify the license? Is any of this blocking and adding to load times? And again, what if my plugin is supposed to be proprietary and I don't want it on the store or in a public repo?
• What motivates people to keep subscriptions to a plugin if all of the features work regardless of maintaining the subscription? Now they can just get it for a cheaper flat price. Who cares about notices politely asking you to uninstall it? Plugins will require a subscription but it's all based on the honor system?

Just my $0.02. Correct me if I'm wrong on anything, because I can't be the only one a bit confused.

[AbbeyDesign]

As an agency, we'd be the only one's doing bulk purchasing of plugins and so therefore getting a discount. What happens if I need to eventually transfer a license to the client if we part ways?

[tjdraper]

@clowerweb Brandon has clarified that free plugins can be on the store, but other than that, I have more agreement than disagreement with your concerns.

I don't want to be the guy who opposes my own success. Perhaps the model Brandon has mentioned is the correct one and a year or three from now I’ll laugh at how silly I was at the concerns.

However, here is my primary concern. I don't like subscription software. I like the model where I pay a license fee to use the software in one context. And I say this as both an end-user and a developer. This translates well to websites because a new license is required for each new website. This is how recurring money is made in this model, people use your thing, it's a must-have, so they use it on the next project. And then the next one, then the next one.

I want customers to have the peace of mind that they pay the licensing fee for one website, and that version will always work for that site. If they want the next major version on that site, they’ll pay the upgrade fee (should I choose to charge for it). And if they want the software on the next site, they pay the licensing fee.

So, my current stance is that while I like having the option of the subscription model, I also want the option to charge once per-site, and to charge for major upgrades.

[carlcs]

@masuga you will still be able to install plugins from private repositories:

1. using SSH keys
   https://getcomposer.org/doc/05-repositories.md#using-private-repositories
2. listing them on Private Packagist or using Satis
   https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md

[wbrowar]

@tjdraper This is just my opinion: In most situations I don't love the subscription idea, but here I think the tiers help bring the cost down enough to make it cheaper for the plugins you frequently use. There are great plugins I don't buy now because they're $99 (one-time), but to get a 5-license bundle for $149 ($99 1.5), I could certainly go for that. Yes, I'd have to pay for them again, but it would take more than 3 years to have the cost of the subscription ($149 3 = $447) be greater than the purchase of 5 one-time licenses ($495). There are probably holes in this logic, but the gist is it could actually be cheaper to go with P&T's plan.

I'd love to see a cheaper price than $49 to support super small plugins, but that's not a deal breaker. I get that P&T is probably factoring the $49 minimum into their own business model.

To @AbbeyDesign's point, having a way to transfer the license off of my subscription would be good. If a client could update it to their own billing info, then do they pay full price?

[carlcs]

@clowerweb seems like you can strike through some more points in your list! 😉

• All plugins must be on the official store, so they can't come from third party sources anymore

Not true, plugins can still be sold elsewhere.

• No more flat-priced plugins, all plugins must follow a subscription model

No flat-priced plugins in the official store, but still a possibility for 3rd party stores.

• Plugins MUST be installed via Composer or Packagist

If I understood correctly there will be 3 ways to install plugins. Via the Store (uses Composer in the background), directly using Composer or by registering the modules via config/app.php.

• Plugins must be hosted as public/open source repos on GitHub or Bitbucket, unless you pay for a special Packagist license to access your private repos

See my above answer about other ways to install plugins from private repositories.

[mattstein]

Minor addition @carlcs: it looks like you can set up a manual hook with Packagist for just about any repository (thinking GitLab, Gogs, etc.)

[nateiler]

Is Craft CMS / Commerce moving to the same model? Yes, Craft v3 is now publicly accessible, but can we expect to see the same licensing model with Craft CMS / Commerce? If Craft becomes a 'subscription' application than the expectation is clearly set for plugins.

As a producer:

My gut is telling me the upper tier 6-25 seems a bit broad. A $200 plugin could be installed on 25 sites and the producer receives $400 ($500 less 20%). 25 licenses to support vs 2. I guess it depends on the type of plugin and expected volume. My expectation is the single license cost will increase to cover the volume discounts ... which might be counter productive for smaller shops that don't have the volume of bigger agencies.

As a consumer:

The cost of (most) plugins are nominal when you look across an entire project. Yes, there are exceptions, but if we are unable to justify the cost of a plugin than the project needs to be re-evaluated. We also tend to place all client subscriptions under the control/billing of the client so a volume discount may not be applicable depending on how purchases are tracked.

[brandonkelly]

Is Craft CMS / Commerce moving to the same model?

@nateiler Undecided about Craft CMS for a couple reasons, but Commerce definitely will, since it will be sold through the plugin store and must adhere to its rules. (Existing licenses will be grandfathered into free updates for life though, as that is what we’ve promised.)

My gut is telling me the upper tier 6-25 seems a bit broad.

Maybe? Again we are modeling this after a popular pattern we’re seeing in WP Land, which seems like the right starting point. We’ll see how it shakes out.

[ghost]

When we sell website projects, we don't sell the tech (Craft), we sell the business solution. Craft is the software we use to meet that solution, but ultimately the client doesn't care as long as their ROI is good. With the way most plugins are sold we can account for plugin costs in our pricing and the client never even knows or cares what each plugin cost. If the majority of plugins are sold in the Craft Plugin Store with the subscription pricing model, our way of covering plugin costs in our fees is no longer an option for, at least, three reasons:

1. We'd have to eat the plugin costs yearly and lose profits on our maintenance packages.

2. The client would need to agree to pay for whatever plugins we feel are necessary during the build.

3. The client would have to be okay with the nag alert and possible security liabilities if neither of us were willing to pay for a plugin's subscription.

In trying to overcome one of those points, this is what I see.

1. Maybe there's a flexible maintenance package where we'd remain the buyer of the plugin subscriptions and we'd charge the client for them but at a discount (say 10% or so). Giving them that discount through us would be possible since we'd be getting a larger discount for the bulk licenses we'd have. (Or did I misunderstand the bulk rates? Is it per app or per account?) This feels like hostage situation, but it might work. If the client leaves us, they'd have to take those full subscriptions themselves.

2. This is the real kicker for me. It seems rather disadvantageous for a client to have to pay a yearly subscription for plugins that made the developer's job easier and more profitable. I can imagine a client saying, "No, I'm paying you to build the solution. You gave a price, I agreed. I didn't agree on a solution that requires an ongoing subscription or nagging notification." And they wouldn't be wrong. So we'd either have to budget to build all the custom plugins needed, budget for us to pay for the licenses up to x years, or be very clear up front that our development process may force the client into a presently unknown recurring expense. It seems like really bad business to build a site and then tell the client, "Well, we used these plugins because they made our job easier, and now you have to pay for them."

3. This is cheapest, but doesn't seem like a professional solution. But maybe that nag notification can be more subtle and only visible on an update view, not persistent throughout the control panel.

I'm interested in how P&T sees this playing out. It already makes me want to rely less on paid plugins.

At this time, these reasons lead me to be opposed to the subscription model for the Craft Plugin Store. I'd much rather plugins charge more up front and then charge again for major updates as they define them. And also charge for support.

But, please, tell me what I'm missing.

----- EDIT ----- After getting clarification on Slack from @brandonkelly, I can see where an agency/dev would be smart to pass all plugin purchases through their account and pass costs through to clients as they see fit, especially when the agency/dev is using the plugin on 2 or more sites. There are three benefits to this: (1) Agency/dev can bundle other services with the plugin costs adding more value to their offering, (2) agency/dev can make a profit per plugin if they manage multiple sites with the same plugin because of the steep discounts, (3) agency/dev, can stack up credit card points/miles with which to use to go to visit Bend, OR. :)

[damienbuckley]

Am I right in thinking the options for paid plugins will be:

1. Once-off purchase of a single license in clients name, or
2. Purchases of more than one license (of a specific plugin or is this collectively?) in my name will automatically go to a monthly subscription model

In the instance of #1, I'm assuming the plugin store account would have to be the clients from day 1, or will we be able buy them and then transfer them to the client's account?

[damienbuckley]

Its great to see the discussion and openness about this and, in principle, I understand the concept and the reasoning behind it however I'm not so sure that any pricing model will actually solve abandoned plugins and poo support.

Approaching this from the perspective of an agency undertaking projects and/or ongoing maintenance of Craft sites on behalf of clients I tend to agree with most of what @stephencallendar has said above and I don't really see how it is manageable from our point of view, no less where it leaves the client if we wind our business up.

Clients hate subscription-based services. Ultimately I know that most software companies are moving to this model and have to agree with @tjdraper that I personally hate it and these subs are adding up, FAST. Clients are in the same boat - and this features top of mind with them when selecting a platform for their website. I'm not saying this is right - just calling it how we get it from them.

The Shopify App Store is basically what is being proposed here. We don't do a lot but we've been working with Shopify since 2006, developing custom sites initially but more these days setting up theme-based sites. We're Shopify Partners and thus speak to our clients, partner managers - attend meet-ups etc - and more recently started offering a no-strings-attached paid consult for people considering Shopify for their business. This has been very instructive as rather than just speaking to people at the point of already having started using Shopify or needing us to build for them, we are speaking to them before they make a decision about whether to use Shopify or not.

Due to seemingly endless increases in desired functionality on the parts of the clients, there is an increasing reliance upon and use of apps from the Shopify app store to achieve a lot of functionality which in the minds of most clients I've spoken to of late should be part of Shopify core for what they are already paying.

If you peruse Shopify forums & app store reviews, the developing theme (and some anger I might add) is that Shopify is becoming too expensive due to the cost and subscription-based app environment, when, in fact, Shopify itself hasn't really got any more expensive.

To this point we've been able to justify the monthly fee offset against the relatively low cost of entry to Shopify - along with the fact that Shopify provides hosting, updates, security etc.

But, Craft is not in this (low entry cost theme-based) space so ongoing costs become more difficult to justify.

On the surface of it Shopify's growth would suggest this is not hurting them but I'm seeing disgruntlement picking up a bit of traction and requests to move people off Shopify are increasing. To emphasise my earlier point - the ire of the clients and Shopify users is not generally directed at the app developer or at us - it's directed at Shopify as a platform.

Typically when developing sites for clients, these days we're not up against a competitor offering Craft/EE/Drupal - we're up against free: Wix, Squarespace, WordPress etc. I know these are not the same things but educating the mis-informed client otherwise is a constant battle. If we're not careful we simply price ourselves out of the market altogether and increasing monthly fees appear to be poison.

Anyway, just some food for thought.

[nternetinspired]

@brandonkelly Have you considered EU tax law yet? As the merchant of the digital goods (plugins) you need to collect, and submit, the VAT for all sales to customers based in the EU. Crucially, you need to charge it at the correct rate for the country where they are located. With 28 member states, with VAT rates varying from 15% to 25%, this is horribly complicated!

As a developer of digital goods, based in the EU, this is very agreeable to me as it shifts the burden of tax collection and submission away from me. I sell digital goods via a marketplace like Gumroad for this very reason, complying with the regulations is a nightmare.

There's a lot of good info on EU VAT on digital goods here: http://euvataction.org/key-facts/ with a more detailed but harder to digest explanation here: https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/taxation/vat/how_vat_works/telecom/explanatory_notes_2015_en.pdf

[brandonkelly]

@nternetinspired We were hoping France would be putting an end to the EU 😂

But seriously, thanks for the resources. Definitely something we need to look into.

[brandonkelly]

Couple quick updates:

• Yesterday the P&T team joined a video chat with ~50 people in the community to talk about the plugin store, business models, etc.. Worth watching if you feel strongly about this stuff and want to get an idea of where our head’s at: https://craftx.io/hangouts/craft-3-plugin-store (thanks @selvinortiz for hosting)
• We’ve started a Plugin Store FAQ wiki, which we’ll keep updated as the plans evolve.

[brandonkelly]

Embarrassingly, we completely forgot that bulk purchases won't even be a thing for the initial store launch, since all purchasing will be exclusively done within the Control Panel at first. So we are shelving the tiered pricing discussion for another day.

When we do introduce it, we’ve decided it needs to be something that plugin developers can opt into, and choose what their tiers should be on their own.

[damienbuckley]

Great video guys. Allayed a lot of my concerns and was hugely educational in terms of the various business models in the market and how it applies to not only working with Craft but our trade and position within it in general. In my opinion this discussion is totally worth the two hours to individual devs even if you're not too interested in the plugin store directly. Looking forward to more of this kind of thing.

[Saboteur777]

Edit: @brandonkelly I read the FAQ. Didn't read everything about this topic, but

From our perspective, one-time pricing for CMS plugins just isn’t sustainable in the long run.

implies that Craft (the CMS) will be subscription based too. Is that correct?

@nternetinspired 27% in Hungary 😿

[brandonkelly]

@Saboteur777 We haven't decided what to do with Craft CMS pricing yet. All of our arguments for subscription pricing apply just as much to Craft as they do to plugins (if not more so), and it would be awkward to have the CMS be a one-time purchase, but at the same time require plugins to be subscription.

But that said, it would be detrimental to our business if we switched over to subscription pricing overnight (presumably at a discount, as the cost would be spread over 2 or 3 years). So we’ve got some thinking to do.

[MattWilcox]

Lack of one time pricing will be a hard sell to our clients. I am worried about this.

Our clients buy a design service, branding, and working website from us. They pay X and get Y. They do not buy a subscription to a working website. If they need support, they pay for it when they need it. They need hosting? They pay for it as it goes. But the website... should carry on working as is. If they want it updated, they pay for it. But if not, then it just carries on as it was.

Informing a client that there are unavoidable ongoing costs is not a good thing. And what's their experience if they don't want to do this? They get nagged, but it all still works? That just teaches end users to ignore prompts.

It also smacks of forcing one business model onto your users as opposed to another business model. It's different, but not "better".

I'm concerned.

Put another way - we are going to either loose clients because of this, or have to find an alternative CMS solution to fit our client's needs and preferences against subscriptions for our design agency services.

And applying this to Craft itself? Holy shit but no that's not going to fly with our clients, half of which we have to argue strongly out of a free WordPress solution. This seems insanity to me.

We could more easily sell this sort of thing if it wasn't on a schedule. i.e., from a client point of view, knowing they need to fork out X per year for - as they see it - no change at all to their website which is already working properly, is just not going to happen. But if we say "well, you want work doing and it requires a newer version of Craft which has a price of X" then that's a slightly easier sell.