The Official ExpressionEngine Add-on Store

Can we get more clarification on what “subscription” mean?

Obviously more advanced namespacing like devname/addonname would even better

This already exists, you define it in the addon.setup.php file.

I have very strong feelings about prefixing add-ons… basically I’m vehemently against it. I’ve never liked prefixing since day 1 of using EE b/c it immediately tells me the add-on is not native, and I don’t like anything I use in EE to look and feel like a bolt on.

If I were forced to prefix my add-ons right now I’d end up with BoldMinded Publisher, or BM Publisher (no thanks), or BoldMinded Custom System Messages. Doesn’t exactly roll of the tongue does it? Visual display is one thing, but what really bothers me about prefixing is the template tags it forces upon you. Again, {exp:boldminded_publisher:some_action} or {exp:bm_publisher:some_action}. The first is rather long to type repeatedly. The second, especially for a new developer coming to a project and seeing the template code, or maybe even entirely new to EE, for the first time, is going to ask “WTF is ‘bm’?” It’s just another form of bad variable naming in your code. It’s an anti-pattern.

Also, what if an add-on is sold to another developer? Are they supposed to re-name the add-on and force customers to change their template code, or do they have to keep the prefix, which doesn’t match their company name?

Add-on names should be based on first to market. Simple as that. Forcing prefixing forces devs to ignore basic and common marketing/advertising strategy to pick and name that resonates, sounds good, and people remember. If someone wants to make a Instagram plugin and they just call it Instagram, then, well, the next person who comes along should have done their research and picked a different name. That is how the rest of the world works.

As for the reservation of generic names in-case one day EL decides to make a native module of the same name… I sort of get it, but I also don’t like it. It presents too much of a gray area. For example, I’m working on a new add-on that might fall into this gray area, and it sucks to know that I may have to rename it, even though the single word name sounds good and tells the user exactly what it does, in the off chance that EL might in 5 years want to make a module of the same name.

I have to agree with Brian about namespacing and naming addons.

With something like {exp:boldminded_publisher:some_action} as opposed to {exp:publisher:some_action} the amount of extra typing will soon start to add up and take extra time (time is money!), plus it could make templates that much harder to read.

Forcing devs to have a naming convention for addons, please don’t. Keep the individuality. If a name is already taken I’m sure people have enough brain power to come up with an alternative. Leave it up to them to use their own names, whether generic like “Publisher” or prefixed like “Low Variables”.

We’ve noticed traffic and attention from sources we never had as a commercial CMS

Are you able to reveal those sources, if not specifically in a more general sense? Are you able to say something like “we’ve seen an X% increase in usage”? I’m just curious about this statement in general b/c it may lend some insight to where EE is going.

You may have got something planned but having some sort of notification system for addon updates/releases would be useful, you’ll probably be tweeting them but an RSS feed would be very handy as well.

Perhaps even a weekly/monthly email digest of what’s new and what’s changed would be great!

with each licence you add a domain name where it will be used, plus staging domain if applicable.

Gotcha Rob, thanks for clarifying. Hopefully this will be a little easier, as our preference would be to use a license.key file scheme like we did for v3 and v4, which wouldn’t require any user input of long license strings, and would be able to show you where they are currently being used, both dev and live sites.

License transfers…but it’s nice to have as much license info in one place

That’s an interesting point, and one I don’t have a clear view of. I’d like to offer self-serve license transfers, however the mechanism can’t reveal any PII, such as showing you matching users for a particular email address, etc. Perhaps it could just email whatever address you submit, and if the person has an account they can click accept for the inbound transfer, and if they don’t, they can click a link to create an account which would then accept the new license?

I think a big requirement for me (and a lot of other designer/developers) will be to have clear and obvious EE Version support displayed for the plugins.

Absolutely!

Either an addon is free, or it isn’t.

Yeah that’s absolutely true and was poor wording on my part. Ads come with a cost whether it be visual attention, CPU / network resources, and so on. So IF we allow ad-supported add-ons, it’s clear they should be labelled and treated separately from Free add-ons. Thanks for that input, @bigbytes.

How much are you charging for the service to verify add-ons?

It would certainly depend on the add-on, and as a service I’m imagining using a fairly standard hourly engineering fee. Honestly it would probably mean doing a few with a willing developer to dial it in before settling on the best provision of service and reasonable fees. I’m also imagining that such a service might be able to be amortized automatically into an add-on’s commissions to reduce or even eliminate any out-of-pocket expense perhaps?

This also really depends on what the renewal options are (and if there is an equivalent option to what my customers already have, which is every 1 year), and what sort of API is offered to do license checks back on my support site.

Depending on how detailed you’d like to get on what you’d need or want, can you describe what you’d want out of an API for this? If it’s lengthy or would benefit from its own conversation, feel free to start a separate thread for that.

I wonder in EL could have an initial amnesty on Dev fees, to get the ball rolling. Maybe for the first 90 days or something?

I really _really_ like that idea.

We’ve already sunk a considerable investment in this, it’s not realistic nor fair for us to begin operating it at such a significant loss. Let’s not forget that just a few months ago we turned our revenue faucet off entirely and began giving away our software for free. ? Ultimately when we do well, the platform does well, and end users and developers all benefit from that. If a marketplace commission removes your add-ons profitability then yes, I would strongly consider having another look at your price point or variable costs, or both. One way to reduce the costs could of course be to sell exclusively at ExpressionEngine.com. Not operating e-commerce on your own site can save time, money, and headache. But that would be left up to each developer.

As such, a new add-on dev wouldn’t care about 30%, it’s just what they’ve always known, so they’ll price accordingly. To established devs this is a much bigger deal.

Firstly, we’re not asking anyone for 30%. We looked at the marketplaces available by other platforms and think that 25% is pretty fair and competitive, and returns a significant amount of revenue back to the developer.

Second, as an established dev, are you thinking mostly about the impact on your existing customers? Because it might be time to shake off the dust and start thinking about new customers as the majority of your business, as well as how you as an add-on provider for an open-source platform can contribute to the platform’s growth. Continuing to think and operate with ExpressionEngine as a niche product probably isn’t helpful to an add-on dev or the platform as a whole. Before going open-source we had approximately 0.02% marketshare. If we can even just match Drupal or Joomla—both of which are reasonable goals in my mind, as all of those customers can now look at a friendlier, easier to use CMS—that means your audience will grow 250x. Not 250%, but 250x.

and if the quantity of sales go up, more support tickets come in

We’ve been tossing around the idea internally that our team would handle first-line support for certified add-ons, or similar. We’d still have to bounce bugs and more complicated questions to the developer, but perhaps the efficiency and effectiveness we’ve built over the years of providing ticket-based support could be used to help developers reduce their individual support load some how?

Transfer of addons from developers store and devot ee will be a requirement by customers.

We won’t be able to dictate policies to other businesses, but we can certainly do our best. For any new sites or purchases, the question of course is moot, so this is one of those things that even if it’s a problem or is solved imperfectly in the beginning, quickly becomes a rear-view issue.

Could we consider also adding paid support options? Eg the user buys a 1 year of support subscription which allows them to make support requests to the developer for 1 year.

We are definitely interested in allowing customers to pay for excellent support. Long term, I’d like for them to do this entirely in-app, and not worry about what add-on or developer they’re asking. It’s just “I need help!”, submit a ticket inside their own control panel, and our support system routes according to whichever party is handling it. This is obviously not a launch-day feature. ?

I cannot stress enough how important it is that the GDPR guidelines are respected

We’re really proud of the features we built in to ExpressionEngine that not only make it easy for sites to comply with regulations like GDPR, but have usefulness beyond just that. And we know how important that is to users in markets like yours, so we definitely want to make it easy to see and be confident that your whole installation is compliant, even if you’ve added third-party software.

As for the Subscription feature, how do you see this working? Is this supposed to require a continued subscription for as long as you use the add-on, or is it that you get access to add-on updates (and customer support) for 1 year, and once that expires, you can still continue to use the add-on, but no access to more updates (and support) until you renew for another year, etc?

I think that would be up to the developer, no? If the add-on is SaaS, then the former. If it’s just a downloadable add-on that the developer is using a recurring payment model to cover their ongoing development and support costs, then the latter.

If the store starts out with editions, but there’s no ability to switch/upgrade later between them, it somewhat defeats the purpose.

Good point, I’ll have to check with Seth who’s been working on editions to see if that’s going to be available from day one or not.

Or does the EE.com version of the store allow users to buy a license to add-ons that could contain an EE3/EE4 version as well, if they were unwilling to use EE5 yet?

If you include it in your latest-version download, then you could provide older versions. But we will not be allowing the sale of specific distributions that are compatible only with older versions of ExpressionEngine. That’s detrimental to the entire ecosystem, and mostly to the end user.

Does the $100K mark apply to each individual add-on only? Or does it apply to the developer’s entire revenue across all add-ons.

During “Peak Add-on Boom” early in v2’s history, there were a few developers who were achieving this and quite a bit more. For individual add-ons, it was probably less common, but that was my thinking—that if a niche commercial CMS’s third-party vendors could achieve that 8 years ago, then vendors for a modern, open-source platform could much more easily reach that target. If that’s not the case, we can certainly adjust that downward to be a more achievable scenario. But it’s easier to move in that direction than it is the opposite, i.e. if we start that incentive so low that half of the vendors qualify, it would be very difficult to then raise the bar to a more reasonable level. We need to balance the incentives and breaks provided to vendors with our own needs for revenue and the ability to continue to pump resources into the add-on store itself. I think we’ve all seen what happens when an add-on marketplace doesn’t reinvest profit back into the marketplace. So points like this one are with the thought in mind of rewarding the most successful developers who are actively contributing to the overall growth of the platform and attracting customers to both themselves and to the CMS as a whole. It should be a high bar and a privilege, not an expectation, but I don’t pretend to know if the proposed bar is at the right height from the start. Does that make sense?

Add-on names should be based on first to market…As for the reservation of generic names in-case one day EL decides to make a native module of the same name… I sort of get it, but I also don’t like it.

I definitely agree on the first part. I dislike templating with prefixes for the same reasons you describe. And the branding / name of an add-on can be more explicit in that regard than the tags need to be. On the latter part, I can empathize, but we also have to think about what’s best for the platform as a whole. Here’s a real-world example: Maps. There are currently two third-party add-ons that use the name and the tags “Maps”. And that’s a very foreseeable feature that should be represented natively. So there are two separate problems: first, two third-party vendors both want the same single-word and “obvious” name. Second, if/when the base CMS adds any type of mapping functionality for all users—which attracts people to the platform and benefits everyone—if an add-on vendor already has the word “Maps” in the wild, then the first-party feature is the one trying to come up with a less-than-obvious name. How much sense does that make, from the end user’s perspective? None.

This is not about EllisLab wanting to save all the “good” names for themselves. This truly is about what is best for the end user, whose perspective often gets lost in these discussions because add-on developers naturally want to think about their needs and desires first, and first-party can start to treat add-on developers as the primary customer because it’s who they interface with most and are typically the most vocal in the user base. But if we look at the point objectively and consider the end user, this policy is common sense. And that’s why it is standard across every platform, including other markets. Even before Apple offered their own mapping app, Google was not allowed to make an app titled “Maps”, but was “Google Maps”. The only complicating difference in ExpressionEngine is templating and folder names, but the basic need of the end user and logic behind the policy is the same.

For what it’s worth, we’ve been through this more than once even without an add-on marketplace, and it was a terrible experience for end users even when EllisLab and the add-on vendor were fully in agreement with the need for a naming change.

If you have an add-on name that you think is in the grey area, feel free to reach out to us and we should be able to help guide you if it’s a name that would be a reserved word component.

We’ve noticed traffic and attention from sources we never had as a commercial CMS

Are you able to reveal those sources, if not specifically in a more general sense?

The majority of it has been coming from the WordPress community. I think Gutenberg has contributed, so the timing has been auspicious, but in the past it’s been a significant challenge gaining any attention from ardent WordPress users. Not only have they been more responsive to direct efforts to reach out, more are actively seeking out ExpressionEngine and talking about it again. Drupal to a lesser degree, primarily from larger institutions who may have considered ExpressionEngine years ago, but ultimately struck it out due to an open source organizational requirement.

So far there has been an average of about 5x more traffic and downloads than previously, and that doesn’t count GitHub, which we have limited metrics on.

You may have got something planned but having some sort of notification system for addon updates/releases would be useful, you’ll probably be tweeting them but an RSS feed would be very handy as well.

Yep! Long term again, in-app. Short term though an RSS feed sounds great, that way people can choose how they get notified, with a feed reader or with a feed-to-email service, etc. We could even incorporate SMS but I think that’s probably overkill. We would like to get away from Twitter as being the place you need to follow to keep up with ExpressionEngine.

Perhaps even a weekly/monthly email digest of what’s new and what’s changed would be great!

That’s a great idea, and would be another marketing benefit for add-on devs that the ExpressionEngine marketplace is absorbing the costs of.

I was thinking (optimistically) the growth of the EE user base would be 10x over the next 5 years - but if you think 250x is a realistic goal, that would be awesome. :-D

Even if it was 10x-50x I think there is a clear need for Add-on Devs to tweak / rethink how they provide / fund support. I don’t imagine their current support models will be able to handle the increase in demand, and still remain profitable with the current low pricing of Add-ons. I wonder if pay-as-you-go Dev Support tickets might be a way to fund this (like Barrett Newton used to do with CartThrob).

Not 100% sure on this one… but the guess-timated user base figures are food for thought.

Does the $100K mark apply to each individual add-on only? Or does it apply to the developer’s entire revenue across all add-ons.

Some more thought on this one, just from an administrative point of view it feels cumbersome to track different percentages for every single add-on. So any milestones like this will be for the vendor as a whole, just to keep it simple and sane.

Add-on names should be based on first to market…As for the reservation of generic names in-case one day EL decides to make a native module of the same name… I sort of get it, but I also don’t like it.

I definitely agree on the first part. I dislike templating with prefixes for the same reasons you describe.

Tag prefixes should be assignable like the exp_ table prefix is. This would allow the user to use the default prefix or change it to suit their use case. Using your example, if someone installed Maps and used exp:maps:tag in their templates but wanted to switch to the other Maps add-on, instead of their being a conflict, they could set the second Maps add-on’s tag prefix as maps_other and then either use exp:maps_other:tag OR do what they needed to do to make sure the data was migrated properly, then change the first Maps add-on’s tag prefix to maps_old and change the 2nd Maps add-on’s tag prefix back to maps.

The only caveat is that the “default” tag could not conflict with an existing one (or maybe it could - EE could check for a tag prefix collision on install and prompt the user to change one of them).

I was thinking the same thing to not always make the tag name the same as the addon folder name. Just don’t know how difficult it would be to make a change like that.

Sorry I’m late to the game, I’ve been traveling.

The only questions that occur to me now revolve around how trials and downloads and things work.

Right now, for instance, Ansel is a free download and is timelocked. After 30 days, it will cease to function if you don’t provide a valid license key. Ansel phones home to make sure the license key is valid and on a valid domain the license owner has entered.

I like that model very much where the add-on can be trialed and then they can just enter a license key and keep right on ticking.

Any thoughts on this Derek? Will it be possible for me to make Ansel available to download and trial and then they can purchase and be off to the races?

Other than that everything looks to be shaping up quite nicely.

> Payouts to developers should be instant, and uses Stripe Transfer.

Curious how this works, along with the EU’s VAT regulations and whatnot. One of the reasons I don’t sell add-ons on my own site, is the mess that is VAT on ‘virtual’ products like add-ons. I’m happy that I get one payout a month from devot:ee (bank transfer), basically a reseller of my products. So I do business with them, not with the actual end-user/buyer, which lets me circumvent all the VAT hassle.

As for what I’d love to see is the ability to gift licenses, look up valid licenses, possibly transfer licenses from devot:ee to the EL store.

> If you include it in your latest-version download, then you could provide older versions.

So downloading legacy versions is a no-no?

What Low said. Having to do quarterly VAT MOSS returns for digital sales would be a PITA, which would be a requirement if payments came direct from the purchaser rather than the store.

If the store is effectively a reseller rather than facilitating direct sales, then it becomes responsible for collecting VAT from EU customers and strictly speaking would need to register for VAT MOSS in a member state (in practice I understand this is unenforceable if the store is outside the EU, but IANAL).

I think the VAT collection stuff is slightly off-topic but a valid challenge for everyone selling stuff internationally. I’m sure this is something the EllisLab accountants can find out more about it.

FYI: I think you have to complete a 1042-S US Tax Form (or something), as I currently do for my GettyImages account. It’s for non-US contributors to report royalties income paid, and any US withholding taxes deducted. https://contributors.gettyimages.com/HelpArticle.aspx?article_id=4989

As a non-US company, the downside of selling stuff through a US reseller, is that you are at the mercy of the US$ exchange rate (sometimes good, sometimes bad). But basically, I’d agree that selling stuff through a single reseller (wherever it resides) is a lot simpler.