Q&A with Pixel & Tonic. Ep 3: Craft Plugins & Support

Hannah's Photo by Hannah Rowbotham

The third instalment of our Q&A with Pixel & Tonic focusses on Craft Plugins & Support. We discuss T&Cs, what timely support actually is, and the blurred line of where responsibility lies.

We asked:

What is your opinion on plugin developers charging for plugins that are still in beta? Is there anything we can do to restrict that or would you even want to?

Brandon: We’re charging for Commerce and that’s in beta so going against that probably wouldn’t be in my best interests.

It’s actually not the plugin developers fault - they literally have no choice but to charge if they want to release something in the plugin store and it’s still in beta because we have a rule that if you launch the plugin as a free plugin, you are not allowed to add a price to it later.

We don’t think that would be in the best interests of the customers to start using a free plugin and all of a sudden, one day, Craft starts complaining saying, “you need to pay up because you don’t have a license for this yet.”

We talked about ways to go about that scenario and ultimately decided that if a plugin comes out as free then it needs to stay free.

— Brandon

If they want to start charging for it, eventually we’ll add the additions functionality where plugins can have multiple additions of themselves, so if they wanted they could add a commercial “tier” or they can release an entirely new plugin.

Once you’ve got something in there for free you’re committed to keep it free whether it came out as beta initially or a stable version.

— Brandon

Leslie: The plugin store hasn’t existed long enough to know if it’s causing actual problems but we’re for paid betas if people are getting value out of it then they should be paying for that value.

So the question more is: Is it a legitimate beta? What is the developer saying about it? And if there starts being a lot of abuse then that’s something that we would take a close look at and see if we need to change anything.

Brandon: I actually don’t think it’s ever a problem because if something is beta, you’re still able to use it for free on development and if you decide to take that beta software and throw it on production then it’s obviously stable enough for you to use it on production, so why not pay for it even if it’s still technically beta. If you’re using it on production then yeah you should be paying for it, regardless of what its stability is.

What are the T&Cs regarding paid-for plugins and the lack of timely support?

Brandon: We don’t currently have any conditions on plugin developers in terms of what they need to do on the support side of things. It’s been brought up before so I’m not sure if we should adjust the conditions but as of right now we’re viewing the support offerings as the developer’s own decision.

We’re going to make it easier to highlight plugin developer’s plugin policies within the plugin store so it’s easier to find out what you’re going to be getting with them.

As of right now there’s a little more leg work involved; you’d have to click on their website and try to find something there and get in touch with them, so we do want to make it easier to find that information.

But ultimately, if a plugin developer doesn’t have a support policy and wants to release something in the store, and feels like the only way it’s going to be worth it for them to build this plugin is to put a price tag on it even if they’re not ready for supporting it, that’s their choice.

Down the road, we’re going to have ratings and reviews

— Brandon

I don’t think there’s anyone that’s intently not answering support to that level - if they’re going to put a price tag on it I think most plugin developers realise that there is, sort of, an implied contract that they’re going to hope for some levels of support but the vast majority of these plugin developers are just single person freelancers that are throwing something out there and hoping to get a little compensation for it. They all have busy jobs, they all have projects that come up that prevent them from being able to immediately respond to things.

It’s hard because there is that human side to it. Very few of these plugins are being built by huge companies that have support teams.

I mean, what is timely support? One of the things we want to consider for the plugin store are some expectations to set up front and making it easy to find what the Developer's policies are.

— Leslie

Leslie: I got a call at lunch yesterday from someone who signed up for Craft ID who posted a support question and we hadn’t answered in an hour so he tracked down our phone number and called us.

He hadn’t purchased a licence, hadn’t done anything and yet he was expecting us to reply to his question within an hour.

We were polite and respectful about it but even a $300 purchase, as soon as we spend 30 minutes on a call we’ve lost money in real-time. If they call twice we’re continuing to lose money.

Even with a recurring developer fee, the type of support a person like that wants, we can’t provide it. If that person emails us and we get back within 2 days, is that timely support?

Same with the plugin developer, if they don’t respond for weeks I think that’s a real problem. If they’re not getting the 1 business day response, is that an issue? I think it’s an important expectation question, and if there’s a good expectation set then developers can adjust up or down based around an expectation.

For around 150 third-party vendors that are all small, to agree on "this" is timely support at a wide variety of different price points - it’s pretty difficult.

I think it’s more about communicating expectation and a reputation.

— Leslie

We also talked loosely about letting developers sell retainer and support plans directly through the store. A very long term thing, now that we have the store, we might be able to say that these particular plugins follow particular guidelines so they are classified differently. This is a long-haul thing that we’re going to have to figure out how to help people get better at and set expectations better.

Is there any confusion about where your involvement ends and what Pixel & Tonic as a development team are responsible for in terms of the end user?

Brandon: We’ve always had some level of that but I don’t think that has dramatically gone up since the plugin store came out. Certainly we’re getting more installation error support but that is our bad so that’s something that we should be getting.

As far as actual plugin usage though, it’s pretty clear that if there’s a problem with the plugin then you should talk to the plugin developer. I don’t think that has drastically changed since Craft 3 came out.

Leslie: From a developer and agency standpoint, I think it’s pretty easy to communicate that. From an end client standpoint it’s not. And I think that has less to do with the plugin store and more to do with client churn at the agency level.

The bigger Craft gets and the more agencies use Craft, we do see an increase of, “Hey, Club Studio built us this amazing site and then we were dumb and fired Club Studio, now 6 months later there’s an issue with our site. I can’t login to my admin panel, my hosting is down. I installed this plugin but how do I drag and drop it, my page builder is broken” there’s a lot of those kinds of client questions and internally there’s a fairly clear line where we think our responsibility is and communicating that with the client is easy but it doesn’t solve their problem.

I see this kind of question as more of a long-term opportunity of, "how do we work better with the Craft ecosystem to sell the value of retainer plans to end clients as part of the process?" And this goes back to, “Where does Craft sit in the market?”

If someone is taking an enterprise system, generally when they’re planning a project they’re going to take 20% of that total build budget and apply it to ongoing yearly fees most of the time - it’s almost automatic. But in small to medium sized business builds, someone may spend $70k - 100k and not save any funds for the next 12 months for maintenance and support - they spend the entire budget getting the site live.

Maybe there’s an internal developer, maybe there’s not but I think a lot of it is working with the ecosystem to better communicate to clients what to expect and what they need to budget if they need real-time support for the site.

I know that Sam, our Technical Services Lead, he and I and Brandon talk a lot about what would it look like if Pixel & Tonic could offer a front-line plan, or if you subscribed to it and we had certain plugins where we had agreements with those studios, and we’re charging several hundreds of dollars a month to be tier 1 support for that, then for a mid sized business we could provide that sort of support and if it’s a minor bug we could work directly with that developer.

Whether we will actually do that or now I have no idea.

We gotta figure out how to solve our own support problems first.

— Brandon

Leslie: How does someone fix that if they’re not a developer or they don’t have a developer on staff?

So there’s that sort of thing that are more of the problems with the sort of market Craft exists in and that the majority of us serve. I think it’d be pretty interesting to figure out how to get to it but it all comes back to what is that support and who actually does it.

A big part of that is just getting clients used to the idea that if they want support post-launch, you’re going to have to pay someone for it.

— Leslie

It’s not going to be included in the price of your software and if you’re not retaining your agency, do you have an internal staff?

So a lot of that is communicating that up during the sales process and during the production process to help clients and say, “Hey, you need to save some of this budget for after launch so you can hire someone to actually maintain the site for you.”

If a free plugin available for Craft 2 hasn’t been updated for Craft 3, and we’ve updated it ourselves, can we legitimately add this to the plugin store for free or do we need to seek approval from the previous developer first? Does this depend on whether they’ve explicitly said they won’t be updating it? We would like to add it to the plugin store to help others who used it, so are there some grey areas here if the original developer has disappeared?

Brandon: It’s definitely appropriate to try and make contact. If there hasn’t been any response, it depends on how the plugin is licensed. If you’re copying code from the original plugin then make sure you’re doing it within the conditions of the original license. Obviously once it makes its way to Craft 3 you’re going to have to either release that as the Craft license or MIT license so it’s a little bit clearer going forward but who knows what they were doing for Craft 2. In general, I don’t know if this is part of our review process, but proper etiquette would be; don’t give it the same name unless you’ve been explicitly told that you can be the new maintainer of it, and they even do their own announcement saying, “Andrew is going to be taking over this plugin” to publicly transfer ownership over.

Otherwise, if you’re submitting a new plugin and it’s your own thing, even if it’s heavily inspired by a Craft 2 plugin, I would say to pick a new name. You could even come up with an install migration that looks for the existence of data from the old plugin and does your own migration for that data.

A good example of this would be Hacksaw for Craft 2. The developer for that isn’t using Craft anymore and doesn’t have the time to migrate it up to Craft 3, so there’s a couple of different plugins for Craft 3 that implement similar features; one of which is Wordsmith, which basically uses a very similar API for backwards compatibility with Hacksaw. The Hacksaw documentation says that Wordsmith is the spiritual successor to this, and Wordsmith includes that this API is there for backwards compatibility with Craft 2 installations that had Hacksaw installed.

So that kind of situation has happened before and in that case we even had a public acknowledgement from the Craft 2 developer and promotion of the Wordsmith plugin, so that was a really cordial way to go about it. If the plugin developer has fallen off the face of the Earth then there’s only so much you can do.

I would say to just avoid using the same name, make sure you’re giving credit, make sure you’re following the licensing terms of the Craft 2 plugin. If it was a Commercial Proprietary License then you’re probably out of luck there but if it was an MIT thing then it should be as simple as giving credit. If it is MIT then technically you don’t even have to let them know as long as you’re giving credit in your new work then there’s no responsibility on your part to contact them or get any sort of approval.

It’s tricky though.

In summary...

Be sure to check out the other instalments in this series to learn more too:

If you have any questions about Craft CMS, or the web in general, please get in touch [email protected]

Or feel free to come along to the next Craft CMS Manchester Meetup that we organise to hear what's new and meet some of the Craft community.

Ready to get started on that new web project?
Let's get to work! →