cms 🚀 - Official Plugin Store

> Posted by Christian ([email protected]) 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 on 31 Jan 2017

> Posted by Matt Wilcox ([email protected]) 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 on 31 Jan 2017

> Posted by Florian ([email protected]) 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 on 31 Jan 2017

> Posted by Julian Kovalsky ([email protected]) on 2015/03/19 18:25:13 +0000

Woo hoo. A year from now seems so far.

angrybrad on 31 Jan 2017

> Posted by Nate Iler ([email protected]) 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.

angrybrad on 31 Jan 2017

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

brandonkelly on 11 May 2017

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)?

tjdraper on 11 May 2017

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.

brandonkelly on 11 May 2017

@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

wbrowar on 11 May 2017

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:

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.)
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).

brandonkelly on 11 May 2017

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

wbrowar on 11 May 2017

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.

davidhellmann on 11 May 2017

👍7

@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?

steverowling on 11 May 2017

@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

narration-sd on 11 May 2017

@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).

carlcs on 11 May 2017

@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 :)

davidhellmann on 11 May 2017

@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.

narration-sd on 11 May 2017

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?

mmikkel on 11 May 2017

@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.

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?
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 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?

dennisfrank on 11 May 2017

👍13

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 on 11 May 2017

👍5

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.

brandonkelly on 11 May 2017

👍1

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.

narration-sd on 11 May 2017

👍2

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:

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.
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

brandonkelly on 11 May 2017

👍1

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)

wbrowar on 11 May 2017

👍2

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?

ryanmasuga on 11 May 2017

@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.

brandonkelly on 11 May 2017

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?

aelvan on 11 May 2017

👍18

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

gisu on 11 May 2017

@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).

carlcs on 11 May 2017

@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?

ryanmasuga on 11 May 2017

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.

clowerweb on 11 May 2017

👍9

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?

AbbeyDesign on 11 May 2017

👍3

@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.

tjdraper on 11 May 2017

👍13

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

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

carlcs on 11 May 2017

@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?

wbrowar on 11 May 2017

@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.

carlcs on 11 May 2017

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

mattstein on 11 May 2017

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.

nateiler on 11 May 2017

👍2

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.

brandonkelly on 11 May 2017

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:

We'd have to eat the plugin costs yearly and lose profits on our maintenance packages.
The client would need to agree to pay for whatever plugins we feel are necessary during the build.
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.

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.
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."
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. :)

ghost on 12 May 2017

👍6

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

Once-off purchase of a single license in clients name, or
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 on 12 May 2017

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.

damienbuckley on 12 May 2017

👍3

@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

nternetinspired on 12 May 2017

@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 on 12 May 2017

😄2

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 on 12 May 2017

👍1

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.

brandonkelly on 12 May 2017

👍4

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.

damienbuckley on 13 May 2017

❤1

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 😿

Saboteur777 on 13 May 2017

@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.

brandonkelly on 14 May 2017

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.

MattWilcox on 15 May 2017

👍7

I’ve been giving this some thought over the weekend and I wonder if maybe what would satisfy me is this:

The reasoning mentioned as to why updates can't be stopped when the subscription runs out is because you can't stop composer updating in the background. But this is only partially true. You could not stop a user requiring any version of an add-on they want. HOWEVER, composer.json can be set to a specific version of a dependency. Perhaps the thing to do when a subscription is canceled and runs out is to offer the users 2 choices:

Re-purchase the subscription to keep getting updates, support the developer, stay safe, don't get the nag, etc.
Set the version in composer.json to the latest allowable (the version that was current when the subscription expired).

This does not stop developers manually changing things in composer.json, in which case, they should get a nag in the CP (honestly, with that sort of provision in place I would be okay locking that plugin out until they pay, I do that now with my own licensing: if the plugin license key is invalid or is not authorized on the domain, you are locked out until you fix it).

This allows for the subscription model and ongoing developer plugin revenue model, while still also allowing a way for the website to freeze at a certain version with the peace of mind that what they purchased will continue to work as is (all things being equal).

From what has been said and talked about, I don't expect this will be particularly well received or implemented, but it seemed worth mentioning.

tjdraper on 15 May 2017

I'm trying to think of analogies to get across how unpopular subscriptions are going to be with our clients - especially for the CMS itself.

Imagine commissioning a new house from an architect. The architect submits designs, you agree, the house is built... and that's it. You are done with the architect. Now, if you want changes to be made, you may call up again and expect to pay for those changes - they are out of scope. But you don't expect to pay the architect each year as long as you live in the house they designed for you.

You wouldn't bat an eye at "subscribing to ongoing services" such as electricity, or water - which equate to hosting perhaps. But that's because there are obvious reasons for this. These are things consumed as time progresses. They are consumables.

Software that is already doing everything you need it to do is not a consumable in the mind of clients. Software that has bugs in it that need fixing is a defect in the original software, in the mind of clients. Software that offers new features... that's something that may be worth paying for.

What you're saying with a subscription model is that in order for you as an architect to earn enough money for your lifestyle, you need to be paid continually for the work you did... OR you're saying that "your house will fall over if you don't pay me each year for that work I did that time".

But you don't need to look far to see how unpopular subscription models are for people that have software that works as they want already. Look at Adobe. I don't think there are many people out there that enjoy subscribing to Adobe products; and even if they do, they get the sense of value about it from getting nice new features every now and then. They aren't thrilled to be forking over money each month to have bugs fixed. Especially bugs that they never notice. Which is the vast majority of bugs.

That's not the same for website's built on Craft. The client isn't going to get new features out of Craft updates, because we as the design agency have to implement any new stuff. All Craft updates are to 99% of clients is potential for new features. That's not worth subscribing to.

MattWilcox on 15 May 2017

👍3

Software that is already doing everything you need it to do is not a consumable in the mind of clients.

This is the crux of the issue, I think. You’re right! (In the minds of clients.)

Our point is that this is not based in reality. There is no such thing as web software that is “finished”.

OR you're saying that "your house will fall over if you don't pay me each year for that work I did that time".

This is much closer to reality (perhaps without the mafia tone). Not because someone will sabotage the work, but because you built the house in the middle of the Sahara Desert, and the landscape is constantly changing (to go with your analogy).

So we think it’s time as a community that we start facing reality, so the Craft ecosystem doesn’t suffer from the same fate as other CMSes that kept their heads in the sand.

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.

In general I’d challenge this. The vast majority of the CMS landscape has moved to subscription (even WP if you count plugins (and you should)). There may be exceptions, but this is the way the world is moving (and for the most part has already moved). You may not like it, but there are very good reasons for it that benefit end-users just as much as developers in the long run.

brandonkelly on 15 May 2017

I think the point is it's no longer a sensible strategy for agencies to 'build once and forget'. Unlike a house, the foundations your website sits on, the needs of it's inhabitants and the services it consumes may change dramatically from year to year. If you don't maintain it, it's only a matter of time/luck before it falls down. I do think it's time to have that conversation with your clients about ongoing maintenance; as well as protecting your client it gives you an opportunity to make regular income that will support your own business.

That said, I do agree this is going to be a tough sell for a lot of agencies, especially at the low/mid end. We already provide maintenance plans for our 'enterprise' clients, but smaller clients, not-for-profits - I'm really not sure. Would be nice to have the option of pay once as well as subscription.

croxton on 15 May 2017

Our point is that this is not based in reality. There is no such thing as web software that is “finished”.

That's only true in your mind and from the perspective of the developers of software. There is very much software that's finished from a client's perspective. The thing is websites will not fall over if left alone. We have seven, eight year old sites still going, and never had an update. I'm not proud of that and we try and discourage it - but there are stubborn clients that don't pay and don't receive updates... and you know what? Their sites still work.

I know the modern thing to do is have SAAS hosting and constant updates etc... but many clients don't. And they don't because it's more stable and more predictable and they simply don't need the updates. How then do you say to those people they should pay for things they aren't consuming or benefiting from? If things aren't breaking, why should they pay anything more? If they're not getting new features, why should they pay anything more?

I totally agree that it's in everyone's interest to have healthy profitable ecosystems... but the client doesn't care about that. Whatever happens, the crux of the issue is: how do you get an end client to feel good about spending money? I can tell you it isn't by saying the website they already have working will continue to work "if things like their OS get updated". They'll prefer not to update the OS. And I'd agree with them. They'd rather pay if and when something is needed. Not as a hedge against it possibly being needed.

Again; it is not an opinion - we will lose clients if we tell them Craft is a subscription based CMS. The moment that happens at least some will insist on WordPress - I am telling you this from the coal face of working with end clients.

MattWilcox on 15 May 2017

👍1

IMO, the only way you're going to get clients happy to spend money is to offer new features in exchange for money. Subscriptions don't do that. Paid updates do.

Subscriptions are getting a bad rep - ever listened to Roderick on the Line? That's a non-tech person who's "not going to get another damn eel attached to my body; no I do not want to pay £5 per month for the rest of my life for some shit I already own".

I should also point out, our agency strongly avoids plugins where possible because we don't trust plugin developers to be as reliable as the core developers. Been burned too many times by poorly written plugins or plugins that become relied on and then disappear. The problem with EE was you needed a dozen plugins to get anything workable, and holy christ if they'd been subscriptions... Well, you'd have got around to Blocks a lot sooner I'm sure.

MattWilcox on 15 May 2017

Unlike a house, the foundations your website sits on, the needs of it's inhabitants and the services it consumes may change dramatically from year to year. If you don't maintain it, it's only a matter of time/luck before it falls down.

That's two different models.

The old model, where you let it age until it breaks... that's the one client's get. That's the one they understand. That's the one they automatically see value in paying for new things.

The new one, where the only reason the site stops working is because you updates something somewhere else and now it's not compatible... that's not one they get. And for the majority of clients who's needs do stay the same and don't need maintenance... it's a dud argument. And I'm not joking - the majority of our clients over the last decade have not needed constant updates and their needs haven't changed during one design. When their needs have changed enough for that to be an issue they need a re-design anyway.

MattWilcox on 15 May 2017

👍2

I do think it's time to have that conversation with your clients about ongoing maintenance; as well as protecting your client it gives you an opportunity to make regular income that will support your own business.

If wishes were horses. We offer these services. Very few clients choose to go for it, and when that bites them in the ass later down the line they're happy to pay one off fees to get the issues resolved.

The trouble is, this subscription concept is somewhat like insurance. It's an insurance against possible problems. Well, the thing with insurance and 'possible problems' is lots of people think "well, it's not like I'm driving my car far, I know how I use it, it's only ever the school run, and I keep it away from most dangers - I'll just take the mandatory cheapest thing and hedge my bet" - and that works out fine for most people. They don't actually need insurance. Except for the legal requirement to have it.

MattWilcox on 15 May 2017

👍1

Sure we have those too - very cost conscious and would hate subscriptions. It would be nice to have the option to cater for both types of client, or I think Craft will lose the low end to WP, EE etc (which may or may not be a good thing for P&T).

croxton on 15 May 2017

👍4

I completely understand the thinking behind a subscription based model for plugins and updates. In the nature of software nothing is finished and if things are standing still in a changing landscape then they're in effect just decaying. However, I have to agree with the opinions regarding subscription concerns here.

It will be a very tough sell and it will be harder for freelancers and smaller agencies who can't buy in bulk and who don't have the revenue streams to pay for another subscription service. Sometimes you also don't have the luxury to walk away if someone refuses to pay you a monthly service charge for something they don't understand (the sell is quite often hard because they don't see any tangible benefit despite explaining until you're blue in the face). Using the analogy of a house in the Sahara desert, the clint can see if it's being eroded one sandstorm at a time and will pay to get it fixed. In the digital space a lot of people feel lost and don't _get it_. The visual people among us need to see some tangible benefit for what they're paying for.

I'm also a little concerned that the model is being based on the huge marketplace that is WordPress. There is talk of all the bulk discounts, discussions with plugin developers, and references to targeting businesses I do get the feeling that the sole developers and smaller shops are being overlooked.

I've heard a lot of the discussion in this thread and the Slack channel and I'm still not sure exactly how this model will work in terms of whether this subscription is intended to be taken on by the agency, the client, what happens when clients move on, how it will work if plugin developers are allowed to set their own tiered pricing (as has recently been stated) etc, etc. I'm sure a lot is yet to be decide and clarified but either way it does sound like it would place an added administrative burden on the developer/agency.

All in all I can see that a lot of people could very well be priced out of the Craft market by the insistence on a subscription model which doesn't work for everyone. We're also competing against a lot of people offering WordPress, Drupal, Umbraco as alternatives for a lot cheaper and without ongoing subscription charges. There is already a battle to introduce Craft amongst the better known players in the game as well as a rise in website builders and hosted solutions of all kinds. If you force a subscription model and maintenance contracts into the picture as well then a hard sell can almost become unsellable in a lot of cases. Surely there can be an option for one-time purchases which is working so well at present?

ijy on 15 May 2017

We have seven, eight year old sites still going, and never had an update. I'm not proud of that and we try and discourage it - but there are stubborn clients that don't pay and don't receive updates... and you know what? Their sites still work.

@MattWilcox Yikes! In all seriousness, do what you can to get those sites updated. Either they have already been compromised and you’re just not aware of it, or they’ve been lucky so far.

We have been told by a very reputable security team that Craft is one of the most secure off-the-shelf CMSs they’d ever seen, and yet in the past year alone we’ve fixed 12 security issues, one of which we even had to mark as a critical update because there was a zero-day exploit. Security is no joke.

We understand that this is not a comfortable conversation to have. Watch the hangout video if you haven’t already; we talk quite a bit about this. But it’s not unsurmountable.

Client threatens to move to WP? The WP ecosystem is way ahead of us on this front. (And subscription pricing for WP plugins aside, please don’t built a WP site without a maintenance contract that keeps them up-to-date; too many agencies/freelancers have learned that lesson the hard way, dealing with the aftermath of a compromised site!)

That said, I do agree this is going to be a tough sell for a lot of agencies, especially at the low/mid end. We already provide maintenance plans for our 'enterprise' clients, but smaller clients, not-for-profits - I'm really not sure. Would be nice to have the option of pay once as well as subscription.

@croxton If priced right, subscription pricing can actually be easier for SMB than a one-time fee. Even if in the long run they’ll end up paying more, a lower monthly/yearly fee is better for cash flow than a large one-time sum.

brandonkelly on 15 May 2017

@MattWilcox curious - in your model, who pays for hosting of the website?

dwhoban on 16 May 2017

Something that seems to keep being missed in this discussion about WP / Joomla etc (which is what clients generally refer to) is that those sites are a low bar to entry - typically they are cloned sites using themes. There may be ongoing fees involved in some plugins but I'd certainly never heard of it in relation to WP until now.

The reality is that WP theme sites go for $3k and under. Throwing a subscription on top of that may not be a big deal. Craft is not in this market - at all. Craft is custom design/dev territory. I know we ballpark Craft at AUD10-15k so realistically we can't consider any comparison with if people pay for addons with WP. And that's before we start talking about clients who are being pitched Wix/Squarespace by _agencies_ at networking meetings. I shit you not…

I watched the hangout video and it was super-instructive and gave me a lot to think about however I still see this being a tough sell for the smaller shops like ours. It's all well & good if you're an established agency, your average site is $30k (a figure knocked around in the video), and you have a queue. That's not us and I imagine there are plenty in the same boat.

I also agree it's the higher value clients who have less issue. Most of the clients who spent over $10k with us on EE or Craft are on maintenance plans. Under $10k - none.

I also have Textpattern sites in the wild which are 8 years old, and fine, so it's not fair to suggest that Matt is entirely wrong with this. You can't force people to spend money, unfortunately.

I think if the new model comes in and if _once-off purchases cease_ we will be faced with this dilemma:

1) Pitch Craft, explain the monthly impost, sell the benefits
2) Pitch EE (or whatever your alternative CMS is) as not having the ongoing costs*
3) Pitch Craft AND other CMS, explain the differences in cost models, allow the client to decide

we spent years selling easily against everyone else on the basis of NOT having ongoing monthly fees and it was extremely effective. Times have changed though and this is no longer the case.

I suggest for the busier, more expensive agencies, with deeper-pocketed clients for whom every sale isn't life or death, option #3 is most likely. For everyone else I suspect #2 will be the default due to not wanting to risk losing the sale and client. I don't see many scenarios where #1 will be the default position as I suspect it is now.

Either way, if the once-off purchase cease, I for one will need some serious help and advice from P&T in how to sell it. The video was a great discussion and did touch on this, and I recommend everyone watch before commenting further. I'm worried also but we all have other options so I'm trying to keep an open mind at this stage.

@brandonkelly in the hangout video, Leslie was asking for some case-studies. I'm more than happy to open up our books with this if it helps. Who/how should I send stuff to?

damienbuckley on 16 May 2017

@damienbuckley Thanks for the feedback. You make a good point contrasting typical WP project budgets to Craft - worth considering.

@brandonkelly in the hangout video, Leslie was asking for some case-studies. I'm more than happy to open up our books with this if it helps. Who/how should I send stuff to?

[email protected]

brandonkelly on 16 May 2017

👍1

Thanks to everyone for all the amazing feedback over the past few days. We mentioned in the hangout but worth repeating, we honestly feel that we have the best community in the world.

As much as we believe that subscription pricing is absolutely the way to go, at some point realism needs to take priority over idealism, and I'm thinking we will need to compromise a bit here.

We'll take a second look at the Sketch/JetBrains/Atlassian/etc model, where you pay for updates/support on a yearly basis, but you can use whatever version you’ve already got forever. We can probably get around the Composer issue by making the plugin store its own Packagist repo, which takes subscription status into account (which would also make it possible for us to support private Git repos). That still leaves the security concern (we really don't want to block access to security updates), so maybe we still allow build updates (the Z in X.Y.Z) after a subscription lapses, so devs have a way to go back and patch old versions if they feel like it's warranted.

And as for support, we already plan on making it easy for devs to quickly check plugin licenses by email, so they can reference that before answering support tickets (or even integrate their help desk software with a license status API).

brandonkelly on 16 May 2017

👍6

@brandonkelly I wish we could convince clients to pay for us to update their sites. Honestly I do. I'm totally with you on why, and how important it is. But this is exactly my point... almost no client, no matter the size, has been willing to pay a subscription fee to us to do so. At any price point, and we have gone really really low. It doesn't matter. They will not subscribe to that sort of thing.

I really hope this sinks in for you; you're not having to convince developers. You're having to convince the end users who pay the money - and they are a very different group of people.

MattWilcox on 16 May 2017

👍2

Also; we have had clients complain that sites stop working after five years and argue the toss that they shouldn't need to pay for us to run updates on that website just to get it running again today.

Clients are not tech people. They do not think like us, and it is really hard to get them to understand the value of updates if they aren't seeing new features on the front end of the website. They don't care about CMS updates, they don't care about bugs - bugs are things the CMS doesn't do properly that they already paid for it to do properly (in their mind).

We've tried educating clients about that over a decade, various people, in various ways, with most of our clients. It just doesn't work 90% of the time. So you leave things alone and end up with a website that's running 5yrs old software on 5yr old OS's on 5yr old hardware... and a very happy client. And when it breaks? Then we charge to fix. We've had clients where we have said for years that they need a new website, their software is end of life, we can not offer support of any kind if it goes wrong. Clients that have business' running off those sites... they still won't do it. And that's not an isolated example of one persnickity client either. I could point to a number of them.

The crux is this: clients don't see websites as consumables. They're deliverables. One shot jobs. It's only when new functionality is desired that they see additional payment as justified.

@dwhoban - in our model the client pays for the hosting. Hosting is literally a separate line item from the website. The website is the deliverable, complete and working. Hosting is up to them - they can go elsewhere or they can host with us, but it's a separate transaction.

MattWilcox on 16 May 2017

@MattWilcox @brandonkelly Same issues here Matt. We try to sell "maintenance" packages to clients and maybe 5% or less actually pay for them. Hosting is a completely separate item as clients can host anywhere (even though most host with us). You can't really bundle maintenance with hosting. We have offered to keep sites up to date for almost nothing and clients still won't pay it. They feel the finished product is a deliverable and that is the end. It is a really hard thing to sell when clients do not fully understand the value. But we all have to remember that clients are owners, managers, sales people, etc but they are not developers. They just don't get it.

bgarrant on 16 May 2017

Here is my opinion...When you buy a plugin for version 2.x they should work for version 2.1 to 2.999 without extra cost. I can see having to pay again for a plugin update to version 3 of Craft. No subscription pricing though. Clients will never pay that.

Maybe a discounted price if you have the 2.x version to update to the 3.x version would be fair. That way it is not free and we can approach the clients about the 3.x upgrade and explain Craft is FREE to update but the following plugins cost $x.xx.

It should be a global discount as well. Maybe 30% off for updating any plugin in the store to the 3.x version.

bgarrant on 16 May 2017

👍1

I honestly think that subscription is a bad fit for CMS'd. Period. End story. The crux is, end users won't do it at any price.

There is nothing wrong with the "old school" method of having a plugin or CMS that's paid for in one hit, then only receives security updates. Release new features behind a new version every 6-12 months. That is a model clients understand, appreciate, and will pay for.

Perhaps the problem is being looked at the wrong way around. It isn't that subscriptions are a great way to support developers (which it isn't if no one will pay the subscription), but that developers should not be rolling out continuous feature updates for free.

Look at where end users do pay subscriptions for software... it's only in places which leave them no other options anymore. The problem Pixel & Tonic have is that there are plenty of other options for a CMS.

Google Docs and Office are only successful as subscriptions because the alternatives don't share the compatibility that business' require. But people as individuals don't use those services, they buy software and keep using it until it literally doesn't work anymore.

And even Adobe is suffering because people have bolted to other solutions that don't require subscriptions (Sketch etc) and yet Adobe is an unassailable cornerstone of the huge majority of creative and design agencies. Even they resent subscribing.

MattWilcox on 16 May 2017

👍2

And even Adobe is suffering because people have bolted to other solutions that _don't_ require subscriptions (Sketch etc) and yet Adobe is an unassailable cornerstone of the huge majority of creative and design agencies. Even they resent subscribing.

First, Adobe isn’t suffering. What they pulled off with CC is pretty impressive. Their users may not love it, but they pay it, the world keeps spinning, and Photoshop & Illustrator keep getting better.

And Sketch? They’re on subscription too. Different model – the price only buys you a year of updates, but you can keep using what you’ve got if the subscription lapses. That’s the exact model I just said we’ll take a second look at in my last comment.

Paid upgrades is undeniably the traditional sustainable pricing model, but there's a reason the entire software industry is moving/has moved away from it, in favor of subscriptions: it sucks for developers, and results in bad software. Why? Because developers are incentivized to be constantly thinking of new features that will sell, rather than giving them the space to focus on under-the-hood improvements that are even more important.

We would rather incentivize developers to improve their plugins’ security, performance, and stability. The way to do that is with a subscription.

brandonkelly on 16 May 2017

Adobe boils down to ransom plain and simple and I would hardly call it a success. They own the market, there are no alternatives and they shoved this down everybody's throats. Though we're testing things like Affinity, we are still stuck with Adobe.

With that said, Adobe does not charge me per project and in the ~30 years of using Adobe, I have never had to use a plugin to make it function.

I get the whole subscription argument, and it's not a pretty pill to swallow, but pricing will be key to determine if we can keep moving forward with Craft.

AbbeyDesign on 16 May 2017

👍1

@brandonkelly In your Craft CMS and Craft Commerce subscription conversations, are you considering keeping the current one-time price repaid yearly or lowering it?

ghost on 16 May 2017

@stephencallender TBD, sorry..

brandonkelly on 16 May 2017

This whole discussion is really the decision of Brandon and the team. We can all add out thoughts and suggestions, but in the end they need to make money to keep Craft moving forward and the fantastic CMS that it is. Whatever the future holds for Craft core pricing, we will not know but please grandfather the existing ones that purchased with the understanding of "lifetime updates". We have even advertised that feature to get Craft clients coming from EE so please keep that benefit.

Subscription based models are a dangerous game. You can lose client and market share quickly going down that road. End clients do not want to pay subscriptions. They don't get it, they don't care, whatever the reason....they don't want to pay them. I think it will be a hard sale to get small business to start paying subscriptions on top of hosting, development costs and Craft licensing fees.

Don't forget the little clients that helped make Craft a success.

bgarrant on 16 May 2017

👍1

Whatever the future holds for Craft core pricing, we will not know but please grandfather the existing ones that purchased with the understanding of "lifetime updates". We have even advertised that feature to get Craft clients coming from EE so please keep that benefit.

_If_ Craft core pricing changes, we absolutely will grandfather existing Client/Pro licenses into free updates.

brandonkelly on 16 May 2017

👍3

@brandonkelly - Adobe have the whole industry over a barrel, and that's why subscriptions have been a financial success for them. But talk to the people paying the subscriptions - you will be hard pushed to find anyone who's happy about it. I could pass you over to our accountant if you like, lol! The fact that Sketch etc have any success at all in the professional industries (rather than only with hobbyists) is down to Adobe's decision to move to subscription only. For all the loveliness of Sketch and other software, agencies didn't use them until Adobe went subscription only. Because we needed PSDs, because everyone else worked with PSDs. Moving to a subscription model where you couldn't use Adobe software at all unless you were paying the monthly fee was enough to prompt some smaller business's and agencies to move from Adobe. It wasn't the quality of competition software. Larger agencies are still over the barrel, and put up with the subscription. They don't see it as a benefit. I could even say that a fair few people in our company actually dislike getting rolling updates, because Adobe keep fucking up our workflows. Hell, the new New Document prompts are awful, they cost us time and money. We've turned them off. They're often anti-features.

I don't think there's a problem with the "subscription" model that you're proposing, which Sketch uses, where you get to use the version you had before the subscription lapses. But that's because it is really not a subscription at all, it's the old "pay for what you got, pay more later to get more" model.

But I am saying that for the vast majority of our clients, that first payment is the one and only payment you'll get. They won't continue to subscribe. Meanwhile, the term "subscription" will have put their heckles up immediately, and we'll basically have to say the following to get them back on board with Craft:

These are optional subscriptions, if you subscribe the plugin (or CMS) will continue to receive bug-fixes and new features as you use the software. If you don't subscribe, it's effectively a one-off fee you'll pay and you won't receive updates other than critical security ones. We recommend you subscribe, but if you do not everything will still work as it does now.

I am telling you what almost all our clients will choose to do in that scenario.

Here's the thing; the whole industry is struggling to force subscription models onto buyers as an answer to profitability problems. To do it with any success they're forcing the issue. There's this idea that stagnant software is bad - and technically it is. And an assumption that developers need to continue developing their software for quality not features - which is debatable because it boils down to whether enhanced quality is something end users will pay for.

The assumption that end users must want to buy updates is at fault. They generally don't. They only care when something breaks or there are new features that they need. No software house is going to change that.

Users think of it like buying cars. They bought the car, and they really don't care about next year's version and what it can do or what safety improvements it has over theirs. They're happy with the car they bought. If their car has a safety problem, they expect the manufacturer to call it in and fix it and it not to cost anything because they got sold a broken dangerous car.

Some people go on the "subscription" model where they get a new car every three years as long as they pay X per month. But that's not everyone, that's people that have the spare money to pay constantly. A lot of people pay once and drive that car until it pops.

MattWilcox on 16 May 2017

👍1

I don't think there's a problem with the "subscription" model that you're proposing, which Sketch uses, where you get to use the version you had before the subscription lapses. But that's because it is really not a subscription at all, it's the old "pay for what you got, pay more later to get more" model.

Our hope is that the model encourages more agencies to pitch maintenance/retainer contracts to their clients, for several reasons stated previously, so we will continue thinking of it as a subscription to updates. But if you don’t like the word “subscription”, fine, don’t pitch it to your clients. Let’s stop beating the dead horse now :)

brandonkelly on 16 May 2017

My point is that we already pitch that stuff for maintenance contracts. Almost no one bites. But we always pitch - why wouldn't we, it's money in our pockets and peace of mind for the client.

MattWilcox on 16 May 2017

👍1

First of all, thanks to Brandon, Leslie, Brad, and other P&Ters for opening this discussion up to the community and listening to feedback. I've found it really helpful and interesting.

In general I'm totally supportive of any steps towards accomplishing P&T's stated goals of making plugin and license management easier, increasing end-user security, and making sure development is sustainable for developers while also affordable for clients.

Brandon's latest comment is:

We'll take a second look at the Sketch/JetBrains/Atlassian/etc model, where you pay for updates/support on a yearly basis, but you can use whatever version you’ve already got forever
...
maybe we still allow build updates (the Z in X.Y.Z) after a subscription lapses, so devs have a way to go back and patch old versions if they feel like it's warranted.

I'm personally a big fan of this model. I think clients and developers have an existing expectation that most downloadable software installed at a certain version will continue to run indefinitely without further charging (which I know you said was how it would work). That seems to be what many in this thread are pushing for and I think it's reasonable.

I also think developers need to be charging ongoing fees to provide ongoing services. That's why I like the idea that you pay, get something like a year of updates and support, and then have to continue paying yearly for any additional years of updates and support. If you don't pay you lose updates and support but not access to run the latest version you had access to. We buy our Atlassian software that way and it works well. It's also how many plugin developers already implicitly charge, with a time-limited support period and paid major upgrades. And developers can be free to offer a free minor version of an old version if they want to address a very serious, but old, vulnerability. That's what Microsoft did last week by releasing security patches to some old OSes.

I think it's admirable and smart that P&T wants to make sure plugins stay secure and developers are compensated to keep them secure. That helps the Craft community and internet at large. But I also think there's only so much that can be reasonably done for clients that won't prioritize budget for that.

Thanks again for allowing us to give feedback on your decision. I'm looking forward to seeing this!

mrw on 16 May 2017

👍13 ❤8

The Envato marketplace works like the Sketch/JetBrains/Atlassian/etc model as well. I really like this model and we often will re-up a support period if we are having an issue. Here is their little sidebar bug for reference. The plug-in represented here costs 24.00 dollars regularly, you save money by renewing early, and to renew support after the 6 month default period it comes with costs 17.50 - interesting pricing structure to say the least. Having support renewals is not very cut and dry and as I think about it I guess it isn't 100% a good 1:1 for Craft because it assumes that a client would want direct plug-in support when it is probably the developer who really uses that. I guess the better term is really updates/support... as Brandon has mentioned!

screen shot 2017-05-16 at 4 18 54 pm

theskyfloor on 16 May 2017

It's been great to see the level of insight, expressed from each person in the community on this discussion.

What a small voice has kept mentioning to me is the word 'continuum'. That a way to answer everyone's needs is somewhat individually, because each of us are at some point in a continuum of employing Craft, and of what we can expect to successfully offer our appropriate customers.

What might our continuum of engagements look like, at strategic points, identified by level of commercialization -- with all appreciation of other contributions and measures?

Deep 'enterprise level'-and-profitable consultative and developmental relationships, such as Craft itself and more established agencies very positively look to have with size- or topic-significant customers, such as national marketers, direct corporation clients, or political campaigns.
Smaller but wide-service agencies with a full-spectrum sales capability, basing themselves around Craft as a platform both for its technology and its very valued practices.
Designers and developers often contracting to agencies and sometimes to their own customers, making choices on opportunities as to which areas of the possible to contribute in, on a per-project basis.
The very important sea of individuals who use and contribute often surprisingly to Craft or its support and projects, whether out of personal interest or on a path of growing into abilities or connections to make something of an income, as the potentials accumulate.

Looked at this way, it seems clear that Craft benefits well from each of these partnerings, and that setting things up so each of them has appropriate opportunities is going to give the best picture overall.

Especially listening to what persons here have been saying, it would be only the first tier and some of the second who would be at all able sell any variation of a subscription -- because only their customers are able to appreciate the importance of a solid, safe, and forward-progressive platform.
To continue to encourage everyone from the least-commercial onwards, to go forward with the great contributive community and its feelings which Craft most unusually has, must be of great value -- in the business-attentive sense as well as that we like it.

What are some points that might support this view?

a. Going for the gusto, if you have the necessary, as far as real consultations and developments with well-to-do customers. I think Craft has had visions of its own future in this area, and I think I would really encourage this. People who know they need individualized and add-on attention are usually quite willing to pay its real costs; it was ever so, and in the corporative language of today, it is to pay for 'talent'. If we know that there are actually many kinds....

I feel that this avenue for getting Craft's future assured, by its own consultancy and by payment for acknowledged privilege from partner agencies, is maybe the key thought missing at the moment, from the entirely sensible as well as intuitive drive to 'do something about the visible future'.

Consulting speaks for itself, and will be a fine driver of new abilites for Craft, its innovation. The part about partner agencies means their taking of responsibility they will appreciate as much as their significant customers, to price in an ongoing support for the Craft platform as part of their maintaining, upgrade, and innovation budget line item to the customer.

You can fill in blanks about acknowleging such sustaining partners, but I think in the sense of the unusual Craft culture in particular, they shouldn't (and wouldn't want to) be made exclusionary to the larger community. This was a problem definitely with a past company we will remember. More responsibility taken, more recognition -- but not more privilege, save for specific contracts with Craft's consultancy side. As an approach....

b. So, in essence, larger players _will_ pay subscriptions-in-principle, and also specific contracts will pay for innovation that builds the product for the larger community.

It occurs to me that some intermediate customers might be willing to take on some size of ongoing payments -- as an option, to support the platform.

A soft sell here, then, not attacking subscription-resistance, but rather suggesting in the way that 'big boys and girls' do contribute to things that strengthen the software industry depends on, using as open source as the big example. In a reverse-judo sort of way, this might help with take-up of own maintenance plans also? We can but try....

c. Encouraging that immense resource by now of the greater Craft community, I'd think as before that the _mechanisms_ for the Store (and anything else around Craft) should be open to anyone -- as I believe is already agreed. People should be able to deploy their plugins in a safe and simple way, thus ever reducing Craft's own support burden.

How they charge for them...is then the matter of thought as we know. I somehow can't see personally how a one-plan-for-all can work on this, if really very much appreciating the thinking about establishing a baseline to up plugin long-term dependability and quality. Again, we have experience.

I wonder if a self-certifying framework could do the trick? You agree to a certain level of Craft-authored guidelines, to achieve a certain 'stamp' in the store. Then pricing, including possible maintenance plans (that only as a subscription, and optional) can follow appropriately. That Craft authors the requirements means their so-often good thinking gains the benefits necessary for themselves, and good for everyone.

A continuum can then be fit, from free-entry/experimental-community-support offerings, to full-on commercial plugins as we understand them, to individualized-corporate-paid-support enterprise packages.

Allowing those last on the store might be a way both to publicize what you did, and also to benefit the original developmental customer by spreading out thus minimizing their future costs.

d. Going to stop here, as no doubt this is long enough -- and I am warming to the feeling of how this community discusses things. Older dogs can indeed learn where we didn't expect to...we find out!

I'd like to close with one specific, among the many nice things that might be said for Craft themselves, in the reflections on that simply great online discussion. I've already complimented what we all recognize and appreciate in Brandon's actual front-end leadership, in the principles he and Brad have been making so solidly thoughtful and present in all the Craft experiences. As an 'older guy', and a friend, I get to do that, I think....

With this, something I particularly found to ground the many facets of talk, and add to what was satisfying, was how Leslie came forward this time, so that we could understand much better what his thinking is, and natures then of its influence.

I had a much better feeling afterwards, including the sense of histories being recognized; and freed thus, what the futures now can hold. Thank you, Leslie, and for the Craft team approach of recognizing, bringing in, each of the voices.

-- Clive

narration-sd on 17 May 2017

❤1

In case anyone missed today's Plugin Store FAQ update...

How will licensing work?
When you buy a plugin license, it’s yours to use forever, however access to updates will be cut off after one year, at which point you will have the opportunity to buy another year of updates for a renewal fee.

Personally this feels like a great outcome to the discussion and it has been a wonderful process to witness unfold. Thanks to everyone involved, great to see everyone's point of view listened to!!

putyourlightson on 17 May 2017

👍8

How much will the renewal fees cost?

It’s up to the developer, but we will recommend somewhere between a 50-80% discount on the initial license fee.

The decision to allow the initial and renewal costs to be different (and developer-controlled) is a BIG DEAL in my view. (I'm all-aboard the "normalize subscriptions as _the_ go-to plugin biz model" train. This will make it _way_ easier for me.)

THANK YOU!!!

michaelrog on 17 May 2017

👍4

I think that model makes total sense and is fair all-round. Good discussion. Good result

damienbuckley on 17 May 2017

p.s. I'm assuming what's meant by access to updates will be cut off after one year is that the _easy one-click updating in the CP_ wouldn't be available if your subscription isn't active, but _technically_ one could still update manually via Composer?

(That'd make sense, in context of previously mentioned technical constraints. In those cases, I could envision the "Update Plugin" button being replaced by a "Renew Subscription & Update Plugin" button, or something along those lines.)

michaelrog on 18 May 2017

That model feels fair for everyone and one that we can sell our clients on. Great stuff, thanks for the discussion :)

MattWilcox on 18 May 2017

👍2

p.s. I'm assuming what's meant by access to updates will be cut off after one year is that the easy one-click updating in the CP wouldn't be available if your subscription isn't active, but technically one could still update manually via Composer?

Nope, we came up with a way to prevent Composer from updating past the licensed version: the plugin store is going to be its own Packagist repo, so it can factor in the plugin’s license status before telling Composer which version to update to.

brandonkelly on 18 May 2017

👍2

I've gone back and forth on how to potentially offer a free version of our plugins for certain use cases. It sounds like the existing store will allow plugins to be free and allow us to offer a Free Trial option of a commercial license. Both good options.

However, I'm not sure that I've seen a discussion of how to give a plugin with a commercial license an option to be free in some instances. Whether this is supported out of the box or not, one way to approach it could be to allow a commercial plugin to make itself free if the free version of Craft, Craft Personal, is in use.

Giving commercial plugin the option to be freely used with Craft Personal could be a nice baseline for Craft to judge whether a commercial plugin has a free option or not, and, if a commercial plugin desired to restrict any features, it could take extra steps to check for the version of Craft that is installed and display the user an upgrade message in a plugin.

BenParizek on 13 Oct 2017

👍1

@BenParizek this may seem an easy win in some ways, but I think it precludes an important case.

What about a non-profit, etc., which benefits from Craft's support in having a higher level license that they need? Or one which could have a similar permission from the plugin provider?

My feeling is that it should always be possible to permit registered plugin users to be granted free use.

This shouldn't be a big demand on design, as the ability's requirements should already be there with the Free Trial feature, no?

narration-sd on 14 Oct 2017

@narration-sd Here's a breakdown of the distinction I'm trying to make:

Free Trial - let a user test a plugin for free for a limited number of days
Free License - let a plugin developer take action to issue a free license to a user for an unlimited amount of time
Free Version - let a plugin developer offer a license for a full-featured version of a plugin for an unlimited amount of time, with the ability to restrict the user from certain types of use (such as using it on different versions of Craft or using advanced features)

I'm not taking any issue with Free Trial and Free License options. They are essential and enough to get started with. My interest is the potential for a plugin developer to easily grant a user free access to their plugin (with conditions) without restricting the time it can be used for or requiring all features to be granted for an unlimited amount of time.

BenParizek on 14 Oct 2017

@BenParizek Ok, this framing of what you want makes sense.

My point would be that Free Version should be its own permiso, enacted by the developer, and not tied by the Store to a particular license level of Craft. The ability to do that could be part of the developer-enacted permiso, when desired.

narration-sd on 14 Oct 2017

A Badge on each installed plugin would be nice :)

davidhellmann on 6 Dec 2017

@davidhellmann now that the Plugin Store actually exists, let's post new feature requests as their own issues, thanks!

brandonkelly on 7 Dec 2017

👍1

Done ప్రచురణ

ghost on 3 Jul 2018

Cms: Official Plugin Store

Most helpful comment

All 95 comments

> Posted by Christian ([email protected]) on 2015/03/09 00:49:13 +0000

> Posted by Matt Wilcox ([email protected]) on 2015/03/10 18:54:52 +0000

> Posted by Florian ([email protected]) on 2015/03/13 06:38:29 +0000

> Posted by Julian Kovalsky ([email protected]) on 2015/03/19 18:25:13 +0000

> Posted by Nate Iler ([email protected]) on 2015/03/11 14:29:14 +0000

Related issues