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:
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:
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.And what we’re working towards in the future (some will come much more quickly than others):
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?
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
Licence transfers
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.
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
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!
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.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.