The Official ExpressionEngine Add-on Store
News and General
As announced at ExpressionEngine Conference a few months ago, we’re launching an add-on store. The primary goal is to make the search for additional functionality a fun and simple experience for end users. The secondary, but also critical goal, is to provide improved visibility and marketing for add-on developers. Our plan is to roll things out in an iterative manner that starts delivering value to the community immediately. Here’s the order we plan to deliver:
- Add-on Directory at ExpressionEngine.com
- Selling commercial add-ons in the Directory
- Directory visibility in the ExpressionEngine control panel
- In-app purchases and updates of add-ons within the control panel
Steps 1 and 2 are almost ready. Days/weeks, not months. This will provide immense value to everyone finding ExpressionEngine now that it’s open source. We’ve noticed traffic and attention from sources we never had as a commercial CMS , and we want those people to see not just the benefits of the CMS, but a robust, modern, and inviting ecosystem.
Steps 3 and 4 need more infrastructure and have more moving parts. In fact, it could be that we skip 3 and go straight to 4, or it could be that with your help we see value that could delivered in smaller interim steps. Either way, your feedback and participation in parts 1 and 2 will have a big influence in how the in-app part takes form.
We’ve already heard from some add-on devs that our move to open source has had a dramatic effect on the adoption of their tools. Just imagine how much further that will increase and grow when there is a clear, official, beautiful add-on store benefitting from all the traffic at ExpressionEngine.com. I’m getting a bit starry-eyed because I’ve wanted to do this for such a long time, so I’ll digress. Let’s talk about the details.
There are hundreds of add-on and application marketplaces out there, and nearly every model has been tried. Here’s what we’re thinking currently, in no particular order:
- Free and commercial add-ons. Users should not have to visit multiple sites to discover compelling add-ons.
- Add-ons must be compatible with the latest version of ExpressionEngine to keep a listing. Perhaps a 30-day allowance for major version changes? Since development happens in public, the actual time allowed for developers to prepare is much greater than 30 days. But it is critical for users confidence in the ecosystem that they aren’t waiting months or even years for vendors to ensure compatibility. This will also organically weed out abandonware.
- Stripe only
- This will keep things simple since vendors and customers are international. EllisLab will be the merchant of record, the appointed agent for sale and download of add-ons.
- Developers will be paid a commission immediately.
- Payouts to developers should be instant, and uses Stripe Transfer. This avoids the challenge (or even impossibility) of selling products on a single transaction from vendors in different banking markets.
- We will collect and pay sales tax and customer VAT, and absorb those costs.
- We will handle responding to chargebacks in your behalf.
- If issued for a reason related to the vendor, we will reach out to you for comments to help respond to the bank.
- If the chargeback sticks, we will apply a balance to your account in the amount of the original commission. We’ll eat the chargeback fees, though.
- We have a lot of experience dealing with chargebacks and identifying fraud that snuck past our preventative measures vs. frustrated customers, who may not have even reached out to try to resolve their grievance. While they are rare, we jump on the latter as an opportunity to gain customer loyalty by how we handle it.
- “Editions”, providing feature-differentiated versions of a single product, allowing for easier comparison and product management.
- A good real-world example would be Freeform, with “Express”, “Lite”, and “Pro” editions.
- You could also use this to offer a Free tier or “Trial” version (no time-limit at present).
- Bundles, which should enable two great options for end users:
- More convenient and cheaper way to buy add-on families from a single developer (EEHarbor Mega Pack comes to mind)
- Curated “suites” of related add-ons that are useful for specific types of sites that help site builders succeed more easily.
- One-off or subscription-based pricing. Subscription products can have a monthly or an annual renewal.
- A hands-on review process. We won’t be conducting full reviews of add-ons, but some basic things like checking spelling, verifying image quality, quickly checking an add-on for potentially malicious code, etc. This means more manual work for our team, and brief delays in some instances between a vendor’s submitted update and it going live in the store. But this helps retain the highest quality in listings and the overall add-on market.
- Commission payout will be 75% for most add-ons. The 25% that we keep will cover the above fees, taxes, and the marketing and operational costs of the add-on directory. We want to be able to reinvest time and resources to regularly improve the store. We don’t want a set-and-forget marketplace for a passive revenue grab that quickly grows stale. This needs to be an active, constantly improving aspect of our growing ecosystem, and that requires a significant investment.
- We want to reward vendors’ hard work before and after the sale that creates customer loyalty.
- Commission increase to 80% for add-ons that reach $100,000+ in gross sales for the previous rolling 12-month period.
- Commission increase to 80% for add-ons that are certified by the ExpressionEngine team. Certification would be a separate service that would include a security, performance, architecture, and UI audit that would have both recommended and required changes to receive a certification.
- Commission increase to 85% for Subscription-based add-ons with > 1 year retention. We sink significant resources to market your product to try to get the initial sale, but if a customer is still using a subscription-based add-on a year later, that was all you. It’s your hard work that kept that customer, so we drop our fees back to only cover overhead.
- We want to reward vendors’ hard work before and after the sale that creates customer loyalty.
- All sales are subject to the ExpressionEngine.com refund policy, which is like most marketplaces with downloadable software: No refunds*.
- *Except when we issue a refund. We apply reason rather than be dogmatic about policy. These are very rare and would apply a balance to your account in the amount of the original commission transferred. We’d also work with you to help avoid the refund, and provide customer feedback that can help avoid requests in the future.
- No ban on selling your add-ons on your own website or elsewhere, but the price cannot be lower than what’s offered in the ExpressionEngine store.
- No out-of-band in-app purchases to unlock features to circumvent add-on store fees. Since we’re building a mutually beneficial platform whose growth directly benefits your add-ons, we don’t even feel like this would be a thing. We’re each invested in the other’s success. But it’s happening in some other marketplaces that have higher fees, so it makes sense to be explicit up front and avoid potential drama for everyone down the road. As you’ll see below we also plan to enable IAP to unlock trial versions with a native solution.
- Reviews & comments. This is a launch-critical item. Customers rely on reviews even after doing significant research. It gives confidence in their decision and is often what finally motivates a sale. Further, it keeps the quality of the entire ecosystem high, and signals to end users that quality is important to everyone, and that their risk is being reasonably mitigated.
- Generic names are reserved to avoid customer confusion and potential collision with native features are or might become part of the core CMS (e.g. “Maps”, “Templates”, “Notifications”, “Forms”, etc.).
- Any data collection performed by your add-on must be clear. If your add-on processes PII (personally identifiable information), you should use
consent.requestsin your add-on. This is should not must, but we will be indicating GDPR-compatibility, so it could impact the market perception of your add-on if you do not. - Free add-ons that use ads to support development must be tasteful and restrict their display to their add-on’s own control panel views. Not sure if this will be an issue, and I acknowledge it’s subjective, so if we see an issue we’ll try to work with you to remedy it instead of just rejecting the add-on.
- Rich product detail pages. If you don’t already have one, you should consider a high resolution 1:1 aspect ratio icon (which will also be in the directory). Besides a description, feature list, and screenshots, consider writing 2 to 3 powerful benefit statements.
And what we’re working towards in the future (some will come much more quickly than others):
- Sale pricing
- Coupon promotions
- Upgrade pricing, both between major versions, and between Editions
- License reporting and validation, e.g. being able to see if a customer requesting support has a qualified license, as well as having easy visibility into license usage, including a single license being used on multiple installs, by whom, and where.
- As part of in-app purchases, unlocking features from a Free version.
- Support for your add-ons in the ExpressionEngine forums. We have plans for the forums to add features making engagement and issue resolution fun and easy. We’re not going to recreate Stack Exchange or a full help desk, but a vibrant public forum with resolved issues helps users self-serve on problems they’re having with improves their experience and reduces the amount of time you spend answering questions.
- In-app support for your add-ons. We’re currently working on a support add-on for our own needs that could be extended so that site builders / operators can get support from all vendors used by their installation right inside their control panel.
- Automate validation and content testing for the majority of the things we currently want eyeballs on each time.
- Similarly, having some aspects of managing your add-on listing completely self-service. We won’t need to review coupon promotions or sales that you want to run, for instance.
- Potential ad network integration across the control panel to help democratize the funding of free add-ons.
Phew the above certainly isn’t exhaustive or inflexible, so now I’ll turn the mic over to end users and add-on vendors for comment and questions. Thanks!
Wow let me be the first to say well done, excellent, fantastic, awesome… 😊
Everything looks good and well thought out, but here’s a few things from me, you’ve probably covered some of these:
The ability for me to tag addons to a development/staging domain, probably only necessary for commercial addons
Have you got any arrangements in place for addons puchased at Devot-ee, or other vendors who will use the new store, to transfer purchase data/licences?
I’m a little concerned about “free” addons being able to use advertising in the CP for a couple of reasons:
how will any injected ad scripts be safe, we all know ads can be a hell hole for malware
clients seeing ads would look kind of tacky, especially if they’ve spent a lot of money developing their site
how about using a donation facility, via the store, for “free” addons?
- Can developers keep a “previous” version available, in case a site can’t be upgraded to latest straight away?
Looking forward to this, thanks DJ!
Potential ad network integration across the control panel to help democratize the funding of free add-ons.
Would this be from a 3rd party adtech/surveillance outfit? If so I would be very wary of this due to the risks, not just to developers but to clients as well. the last thing you need is some scummy ad injecting keylogging into the CP. I’d far sooner have a fully controlled environment that’s run by Ellislab
I’m a little concerned about “free” addons being able to use advertising in the CP for a couple of reasons:
I share your concerns, which is why I don’t want to leave it out of the discussion. I’m wary of an add-on submitting as free and supporting itself with ads via an ad network. If we were to allow that at all, I imagine it’d need to be iframed and other protections to prevent any mucking about in the control panel—intentional or unintentionally. I’m a little nebulous on how policy and implementation might shape up around that, but it’s happening (outside of our ecosystem) and I’d rather include it in discussion of our plans now, instead of as a reaction at a later date when a developer submits an add-on doing that.
The second point about a potential ad network integration I think is a bit more musing / down the road, and I’d imagine something like that would be fully under first-party control. But I am rather interested in coming up ways that allow monetization and reward for developers’ work that isn’t necessarily tied to direct payments or donations.
Just my thought process there.
The ability for me to tag addons to a development/staging domain
Can you clarify what you mean?
Have you got any arrangements in place…to transfer purchase data/licenses?
Not currently, though we’ve had a few conversations with developers who have brought it up on their own. One vendor had suggested the number of affected people at this moment in time might make it feasible to just use coupon codes to redeem for a replacement / discount license in the new store when it comes time to upgrade. Definitely would like to hear your perspective on it.
Ad supported addons
I’m totally with the idea of allowing developers to have a chance to get some sort of recompense for “free” addons, that said I personally think ads are rather tacky and “unprofessional” given that EE is a high grade/”professional” CMS. Another thing, an addon that displays ads isn’t exactly “free”, rather “ad supported”, there is a difference and that would need to be reflected in the listings.
I do like the idea of donations. I’ve done this before on occasion, sent the developer some beer money as a thanks for a free addon that helped me solve a difficult problem.
Alternatively how about a one time payment option, e.g. pay a small one time fee and have unlimited access/use of that addon? Might not be that attractive for a simple plugin, but for an addon that’s a bit more complex I’d go for that.
If ads are viable then yes, they must be 1st party controlled. Even iframed ads from 3rd party vendors are a risk.
Apart from ad supported and some sort of payment mechanism I can’t think of any other options, at least within the store process.
EDIT: with ads you’d have to be careful what ads are shown to any particular client. Imagine showing them an ad for a competitor, a NSFW ad, or targeted ads that could embarrass someone.
Tagging addons
- much the same as EE and Devo-tee do/did it, with each licence you add a domain name where it will be used, plus staging domain if applicable.
- this helps us see what licence is used where so we assign the correct licence number in the CP, and upgrade the correct one when it’s due.
Licence transfers
- it’s not a deal breaker, but it’s nice to have as much licence info in one place rather than scour numerous sites getting the info, if only to save time. If you purchase lots of addons (I have well over 250 licences a spread across various dev’s sites, and adding another 5 this week!) it’s handy to have most of them in one place, and I’m only a one person freelancer, imagine how many larger agencies may have.
- coupon codes sounds like a good plan during the transition.
- I appreciate that with such a major change you can’t cater for everything, so anything that helps is better than nothing!
Very much looking forward to this happening.
Although Devot-ee is awesome and some Developers’ site are great at providing/selling plugins (Solspace, CartThrob, EEHarbor, BoldMinded), having everything all in one place (like Magento does) will be even better.
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. Although I push for my sites to be upgraded to newer versions as soon possible, they can hang around on older version for months/years. I still need plugin support for these sites, so should be able to access older plugins/plugin versions if I need them.
Ads in Addons? You people must be kidding.
Have you seen how shitty the Wordpress backend looks sometimes, when they have 20 different addons installed and each of them displays “TRY THIS” … “BUY NOW” … “GET MORE” … ?
I still hope that open sourcing EE will lead to more functionality that does not require an addon to be purchased, like a useful text editor field type or finally a usefull image upload-resize-crop-dostuffwithit-something because paying 80 USD every time for something like Anseln (which is fine, don’t get me wrong) is kind of rediculous.
Either an addon is free, or it isn’t. Even considering having ads in Addons will lead to a LOT of now free addons being “ad supported”. No, thank you. EE has always been a professional CMS and ads have no place in the backend. If you want to make money with your addon, set a price. If the addon is good enough, people will buy it.
The minute there are ADS in my backend I’m going to comment out all the ad related parts of an addon.
A few of my initial thoughts… but first, thank you for doing this.
No ads, please, even for free add-ons. It’ll cheapen the experience, and someone will find a way to abuse it. I would prefer that EL maintain complete control of the display of add-ons so there is a consistent experience when browsing a list of add-ons or viewing an add-on detail page. Devot:ee allowed basic HTML in places, and it got out of hand and people started customizing their pages to make them louder to stand out. I was guilty to a small degree in that (but mostly b/c they stopped caring about the site or adding features to help add-on devs).
20-30% cut is expected, but hurts. For an indefinite amount of time I can expect to see a drop in revenue unless I raise my add-on prices, which honestly I have to consider doing to offset the cut. For Publisher, that is a $50-60 loss in revenue per license sold, which is not a small amount and adds up very quickly.
How much are you charging for the service to verify add-ons?
I’m undecided on the license transfer option. On one hand it would be great for the buyer, but on the other hand it means I would be all in on the EL store, which is something I think I would like to do, but TBH we haven’t seen anything yet so I can’t fully commit to that. 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. I don’t make updates to my support site often, but it is nice to be able to make a change at will that suites my needs. Relying totally on a 3rd party to manage my support site features and functionality is a leap of faith after having managed my own for some time now.
Commission increase to 80% for add-ons that reach $100,000+ in gross sales for the previous rolling 12-month period
Did you mean “add-on developer”? Because I would be shocked if any single add-on is anywhere near $100k a year in sales.
I think the Apple Mac Store / iPhone App Store has a 70/30 split for developer revenue (or something like that), so I think that type of structure works well for everyone. It’ll help put more back into the EE project in the long term too I should hope.
And also, I reckon you guys (and other devs) are going to be shipping LOADS more licences in the coming months/years, with this new Open Source EE / Add-On Store setup, once the user base grows swiftly. Although I totally understand your worry about shorter-term drops in revenue.
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 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.
I think the Apple Mac Store / iPhone App Store has a 70/30 split for developer revenue (or something like that), so I think that type of structure works well for everyone.
True, but there are other factors.
We’re operating at a much smaller scale. The App Store has millions (billions?) of users. Also, app devs went in knowing a 30% cut will be taken, so they can price accordingly. 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.
App Store apps require very little to zero support. Yes devs may get bug reports, but I bet for the most part if a $1-$3 app doesn’t work for someone, they just don’t use it and don’t bother to submit a bug report (I’ve never submitted a report or feedback for any app I’ve purchased). Apps also have, for the most part, a very known playing field. They don’t have to worry about different server configurations, just a few models of a device. Their apps also operate in a completely sandboxed environment and have little to no communication with other apps. This is definitely not the case with CMS add-ons. Sooooo many things can go wrong with an add-on that is completely unrelated to the add-on itself. Apps generally don’t have to worry about user error either (e.g. bad template code). Most of the add-on cost goes to continued support, and if the quantity of sales go up, more support tickets come in. Then we’d be getting 30% less in revenue, and more time spent doing support. Eventually in the long run it may even out if the quantity of sales is exponentially higher than it currently is then 30% may not be as noticeable, however the increased support will be noticeable. I’m not an iOS dev, but I bet the amount of support they per app they sale pales in comparison to what a CMS add-on dev has to deal with.
edit: I’d actually like to know if someone with experience in iOS App dev and EE add-on dev can weigh in on this. It may not seem like a big deal, but I think there is enough difference in the two that 30% does not mean the same thing in both ecosystems.
I’ve been thinking about the commission change at $100k sales, when the previous 12 month period reaches that.
- if your addon is $200, you’d need to sell 500 off to reach that at an average rate of 1/2 a day
- if your addon is $100, you’d need to sell 1000 off to reach that at an average rate of 2/3 a day
- if your addon is $50, you’d need to sell 2000 off to reach that at an average rate of 5/6 a day
- if your addon is $25, you’d need to sell 4000 off to reach that at an average rate of 10/11 a day
Initially at least they are quite high numbers to achieve, especially for cheaper addons. Of course if EE usage skyrockets then that will offset things, but that’s “if” not “when”, the increased rate of adoption should happen but it may be gradual and it could take some addons years to reach the target. Plus the more licences a dev sells support costs rise in parallel.
Possible solutions
- existing developers who join the store before a cut off date start on a preferential tier, say 80% commission, incentivise devs to join up early to get the ball rolling
- devs joining after the cut off date start on the standard 75% commission
- licence renewals paid out at say 90% commission, the logic behind this one is that they are renewals so EL don’t have additional costs for marketing/review etc
- there’s also the option of basing commissions on volume (total sales) and not $ value
Just wanted to hop in and thank everyone for the early and quick feedback; I don’t want to stifle conversation, and some of the questions raised might be best answered first from the perspective of customers and developers, so I’m going to let this continue to incubate before sharing more of my thoughts. Thanks!
Transfer of addons from developers store and devot ee will be a requirement by customers.
This is very exciting. I’m especially keen on the “License reporting and validation” to encourage customers to buy one license per site and check that users making a support request have a valid license. 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. This might be a good way to fund free addons as well.
Any data collection performed by your add-on must be clear. If your add-on processes PII (personally identifiable information), you should use consent.requests in your add-on. This is should not must, but we will be indicating GDPR-compatibility, so it could impact the market perception of your add-on if you do not.
We have been using EE for many years for our clients’ websites, mostly located in Europe – and I cannot stress enough how important it is that the GDPR guidelines are respected, as more and more clients are setting strict standards which otherwise prohibit the use of the software.
As an agency we are VERY happy about the official Add-On-Store, because devotee is not really developed or maintained for some time – and is not a good platform to find or compare plugins.
EL’s desire for “Rich product detail pages” is also very important for us: Since ExpressionEngine is not very well known here in Europe, we have to convince many clients to use it first. If the required plugins are badly or unprofessionally advertised and documented, this has a deterrent effect on our customers - and they would rather use Wordpress. Because the ease with which you can find and install plugins from Wordpress has become the benchmark for many.
Many thanks to EL for the necessary “Push for size and professionalism”, because from the feedback of our clients, who ultimately make the decisions in favour of or against a system, we notice that the market is divided between fewer and fewer systems – and ultimately the installed base and thus the market share is a crucial factor in their decisions.