Evolving devot:ee: Timed Downloads and Pricing Updates

October 3, 2014
by Ryan Masuga

We’re introducing a new “timed download” feature for add-on developers, and are making minimum pricing and percentage changes.

Developers in the ExpressionEngine community have talked for a while now about how supporting commercial add-ons is harder than it looks, and less profitable than it could (or should) be. There was the thread about Paid Support Options from the short-lived devot:ee forums, and recent comments like the following, from well-known ExpressionEngine add-on developers:

“Simply put, free lifetime support is not a viable business model.”
– Brian Litzinger (@boldminded)

"Supporting Blueprints has become a chore and its sales are not high enough to justify keeping it around."  
– Brian Litzinger (@boldminded)

(Source: "Blueprints is no longer for sale”, Sep 27, 2014)

”Someone has an issue and you have to solve it for them. For free. For someone who bought your product 3 years ago. For $30.”
– Eric Lamb (@mithra62)

(Source: "I Have a Whatnow?”, Sep 23, 2014)

This is a growing sentiment. We see commerical add-on developers just up and leave the market without even telling anyone. Just ask anyone who was a fan of the relatively popular Title Master (look at those reviews…ouch).

We recently spoke with Brad Parscale (@parscale) who operates DevDemon, and he mentioned to us that the majority of their support requests come from users who bought the add-on in question over 18 months before.

ExpressionEngine's market share is very, very small. Even if everyone using a developer’s add-on had a legal copy in use on all of their sites (and we see evidence all the time that this isn’t the case) many developers still wouldn’t be wildly profitable off of sales, and when you throw the amount of time they spend on support into the mix, things can nosedive for them quickly. 

Our new feature for “timed downloads" is meant to help this problem and help support the developers that spend so much time and effort making those add-on that make ExpressionEngine better for us.

How Timed Downloads Work

Here’s what the timed downloads feature means for you, whether you’re a commercial add-on developer or an avid ExpressionEngine user. 

For Commercial Add-On Developers:

There are basically three things an add-on developer would have to do if they want to enable this for their add-on:

  1. Pick a timed download duration (6 months, 1 year, or 2 years)
  2. Set an update price - the price which a user would pay at the end of the download duration to extend the download for that duration again 

We’ll use our own Link Vault as an example. We’ve been selling Link Vault since 2012. So far, everyone who has ever purchased it has gotten support and the ability to download updates whether they purchased it in 2012 or yesterday. 

If we enable timed downloads for Link Vault, we would specify that the user gets access to their Link Vault download for one year after purchase (the duration selection is up to the developer, who can best gauge how much support they need to provide for their add-ons) and then we would determine an update price. Link Vault currently costs $45, so we might set the update price at $20, for example.

With those in place, anyone purchasing Link Vault today would be able to download the current version and any new releases we might put out for the next year for that license…whether we go to 1.3.9, 1.4.0 or as far as 2.0. After a year has passed, that user would be prompted to pay the update price (in this case, $20) for access to continue to download updates for that specific add-on license for another year.

For ExpressionEngine Users:

Keep calm and carry on developing as usual. For example, if you have a copy of Link Vault that is a couple years old, you’ll notice the download link would be greyed out, and you would be encouraged to pay the extension fee to get the latest release(s) and to ensure that we will help you in the timeliest manner, and can easily help you, because we’ll know you’re talking to us about a recent version of the add-on. Is the old version of Link Vault working for you? Well…that’s great! No harm, no foul. Continue to use it for as long as it works for you.

When Will Timed Downloads Be Implemented?

We’ll have it set up so that developers can go in and turn this on and set a duration and update price for their add-ons by the end of the day today. Then it will be fully implemented at the beginning of November 2014. On November 1 we’ll run queries to update every add-on that was ever purchased so that the previous purchase downloads expire from their original date of purchase as if this feature always existed. If you’re an add-on developer and you want timed downloads on your add-ons, you’re encouraged to update your add-ons before the end of October, so that add-ons you sold in the past (and especially those add-ons!) can take advantage of this new feature. You may want to update your commercial license agreement to make note of this.

Evolving the Marketplace

We had previously had requests to implement upgrade pricing, but the logistics of doing it were tough. Timed downloads were a simpler option for us to implement than upgrade pricing would have been. They are different, too. Note that any developer electing to use the timed download feature on their add-on is saying that a user gets access to any version released within the timed download time frame they specify for that add-on, whether it is numerous minor releases or even a major release.

Remember, not every developer might elect to do this. It is on an add-on by add-on basis. Some devs have their own support systems and may never bother with this. We’re simply providing the option - and we would encourage all add-on developers selling add-ons through devot:ee to take advantage of this.

Remaining Viable

Since May 2010 (one year after officially launching), devot:ee has helped numerous developers easily sell tens of thousands of ExpressionEngine add-ons to a worldwide market. We already have some of the best SEO around ExpressionEngine-based searches, and are the #1 unofficial resource for ExpressionEngine add-ons.

We started out our sales cut very low, at 20%. As far as we know, no one else was offering software sales while taking only 20% (outlets like CodeCanyon were taking upwards of 70%). There was little room to move after fees, we weren't clearing much. In fact, before we had a minimum price on add-ons, if someone made a purchase for a $1-2 add-on, we were paying people to buy that add-on. The 80/20 worked for 1-2 people, but the site is such that it needs 3-4 people to properly maintain.

To remain viable, we're moving to a more standard 30/70% split. As everyone is aware, Apple is sort of a standard here. We need to move to a more industry-standard split for software sales in order to continue to maintain devot:ee and move it forward.

Our goal is that developers make more on the new split.  There are two ways we see this happening. One is recurring revenue from timed downloads, and the other is having developers look at adjusting their prices.

Developers, Rethink Your Pricing

We'd like to encourage you to rethink your pricing at this time. Many popular add-ons have raised their prices over time, and our research shows that most people either haven't noticed, or don't care as much as you think they might. Here are some examples or extremely popular add-ons, and how their prices have changed over time:

CE Cache: The most popular caching add-on for ExpressionEngine started out as a $20 offering! It's now $65 and sells just fine. (That's a 225% increase!)

CE Image: This is easily one of the best selling add-ons, and used to go for a paltry $8. It now sells like hotcakes at $22. (175% increase!)

Zenbu: A personal favorite of mine, it used to sell for $39.95 but now sells for $60 (50% increase!) I still install it on every site.

There are numerous other examples. You can do the math based on the prices of your add-ons, but a modest price increase of around 15% or an increase in the number of items sold can make up for the new split. A price increase and an increase in the number of items sold can result in...much happiness. 

New Minimum Add-on Price: $6

There is a new minimum of $6 on a commercial add-on (up from $3). We would highly encourage you to even consider raising this. If you're charging less than $9-10 for an add-on, should it even be commercial? Why not just give it away, or add features that would make it attractive at $9-10? Are you really able to offer "support" for an add-on priced so low? Unless you're selling in real quantity, it's probably not worth your time.

As you developers know, last year we instituted a $100 minimum payout that takes some developers many months to hit (see these two news items for more information on minimum payouts: and This would be less of an issue if the low-end prices were either bumped up to something respectable or simply eliminated.

Goodbye For Now

The last thing we want to see is developers stop selling their ExpressionEngine add-ons (or bail on development altogether) because it’s not worth the time or effort. We hope that timed downloads are a reasonable way to help create recurring revenue so that smart, hard-working developers can continue to pour time into their add-ons. This would also encourage EE users to keep their purchases relatively current, while supporting these devs.

We think that the potential for increased recurring revenue from timed downloads, and potentially rethinking pricing, will allow developers to make as much, if not more, than they currently make.

To recap the timing of everything:

  • Now: Devs can go in and enable timed downloads for any of their commercial add-ons right now (and should do so before November 1)
  • November 1: Timed downloads go into effect for all add-ons, retroactively (see update below)
  • November 1: New developer split goes into effect (first payout with new split will be in Jan 2015 for Nov sales)
  • November 1: Minimum price of $6 goes into effect. On this day we will automatically update the price of any sub-$6 add-on.

As always, if you have questions or comments about these changes, you can leave them here or email us at

Update (Oct 7, 2014): There was some confusion over which add-ons the timed downloads will be applied to. I elaborated in the comments below, but if you don't feel like reading comments, note the following two updates to the 2nd bullet point above:

  • Timed downloads go into effect only on those add-ons a developer has optionally enabled them on. As of this writing, it is an incredibly small amount of add-ons (eleven, or 2.8% of commercial add-ons)
  • This change is not retroactive. Anything you purchase up until the end of October 31, 2014 will not be affected by the timed download option.


Brandon Kelly 10.03.14

Brandon Kelly

Interesting. Best of luck, guys!

“November 1: Timed downloads go into effect for all add-ons, retroactively”

Might want to rethink that “retroactively” part. If someone bought an add-on license with the expectation that they’d be able to have access to it forever, they’re going to be pretty angry when they find out they’re no longer allowed to download it.

Erwin Heiser 10.03.14

Erwin Heiser

How is this going to play out for those of us with multiple licenses? (e.g. for Wygwam alone I have 20+ licenses - I’m sure many devs here have even more). Ultimately the cost gets passed to the client so I’m not *too* bothered, but would like to know how this is going to pan out.

Sneed's Feed & Seed 10.03.14

Sneed's Feed & Seed

Kind of agree with Brandon, here. Reminds me of a Simpsons episode:

“Uh, Milhouse saw the elephant twice and rode him once, right?”

“Yes, but we paid you $4.”

“Well, that was under our old price structure. Under our new price structure, your bill comes to a total of $700. Now, you’ve already paid me $4, so that’s just $696 more that you owe me.”

“Get off our property.”

Damien 10.03.14


I’m really shocked (and angry) at this and if this proceeds will have to re-consider every aspect of my business with EE.

These kinds of retrospective moving of the goalposts with EE are getting really tiresome and never take into account the position this puts us in with our clients.

Brandon is absolutely spot on - that retroactive part is wrong wrong wrong.

If I purchased something with the understanding that updates were ongoing and free and now charged actually this is a technical breach of contract.

You need to go back to the drawing board with that at the very least.

I’ve had a few discussions on twitter this morning with addon devs who think this is a great way to ensure the platform’s longevity whereas in reality the likely outcome is the exact opposite.

I’ve worked in several entirely different industry’s in my lifetime from travelling sales to board positions to now business owner and have seen businesses policy and price themselves out of the market for no good reason numerous times.

No industry ever improved its position and ensured its longevity by repeatedly shafting its customers folks…

Blair Liikala 10.04.14

Blair Liikala

Ouch and yuck, more on the restricted time on downloads than support.

The grandfather rule is quite disappointing.  I hope you reconsider that one.

jdaalder 10.04.14



By applying this retro-actively (the future is a different argument) - you’re imposing this on all addon consumers AND devs, with no consultation, on top of an existing implied contract between those people. 

Apart from being reactionary and quite frankly stupid, you simply don’t have the right to decide this is how it will be for all. 

You should definitely re-think this - paid add on devs should charge for (really) major new versions, and should support the products they have previously sold to make sure they do what they say they do at the very least with EE versions current at the time of the sale and probably even up to say 12 months after.

If they choose to then not support something going forward, they should give 12 months notice.  This is the very basics of selling products, which is what you folks have been doing.  And many countries have basic laws about products required 12 months of support/fixes/warranty because this is precisely what people expect at a basic consumer level.

The minimum you can do here to save yourselves from losing the respect of a huge chunk of the community - who have supported your with $s, links, posts, tweets etc etc for a long time now - is change your decision on the retro-active side of this.

What you do going forward is up to you, but this current plans is balls.

Going forward, you should really look at versions as a sensible charging model, and making add on devs publish their support policies (which should generally be 12 months included at a minimum if you want to be taken seriously).

(The vast bulk of support I have needed from add on devs has been because of very poor documentation for complex addons, or - by far the most common one - bugs in the addons - several of which I have posted fixes to the devs for them to incorporate). 

Dev cycles for some complex sites are longer than 6 months (or even 12) - so you could end up re-paying for addons before you even bloody launch!

I personally expect some sensible add on devs will simply opt out of your approach, and certainly some users will.  You’ll be actively pushing people to direct sales mechanisms.

From following the news around the place, it seems a small group of add on devs - particularly some who have created addons that are in difficult areas (like those that really try and force a change of behaviour on EE, or those that are very much dependent on things outside of EE itself) - have found their support burden overwhelming.  Quite frankly this is the product of their own decisions and their issue.  You look at the flipside - some like Mark Croxton who seems to work tirelessly and does endless free support as a community service, and you find yourself thinking it’s very much a few devs that are the entitled ones, even though that’s precisely the thing they’re complaining of.  If you don’t want to be in products, don’t be - it’s pretty simple.  Or make better decisions about the products you make.  But if you do products, do it right and stand by your product - or suffer the bad reviews you deserve.  And be forced to re-think your business model.

Products are hard - MUCH harder than services. People constantly have a seemingly sub conscious expectation you make something then sit back and watch the candy roll in - well it doesn’t work that way.

You will doubtless see another side of it and be privy to all sort of things us users don’t know, but from the outside this seems a remarkably poorly thought out move.

No issues with your price splits or minimum prices, though.  Entirely your business, and seems reasonable. 

But retro-actively applied time downloads as a charging model after 4+ years, without warning,...this is flat out dumb.

Damien 10.04.14


To follow up on my earlier comments and add to those already aired.

Ryan, you run a great service with both Devot-ee and with Lamplighter but this really is, as jdaalder puts it, ‘balls’. How you’ve possibly come to the conclusion this is in any way, shape or form a good idea is a mystery to me. It demonstrates a disturbing lack of consideration of the ramifications this is guaranteed to have for your customers - site developers.

This whole issue seems to have been borne out from the debate over paid / free support. A large slice of the ‘unsustainable’ claim being bandied around falls back to software piracy. How about finding a way to police or control that rather than penalising honest developers and their clients. No? Too hard?

Let me say this very clearly - I don’t expect free ongoing support for anything. I’ve offered to pay add-on devs for their time when they’ve provided great service or where I feel my requests go beyond reasonable technical support for the product i.e. crossing over into its use.

This is NOT a debate about technical support.

I expect to pay for major new releases of add ons that provide new & valuable functionality - or in the instance of a major new release of EE - i.e. EE1-2 or perhaps shortly, EE3. Thats reasonable.

Switching existing purchases to auto-explode however is another issue altogether.  It is plain stupidity and I predict you’re going to get sued for this sooner or later. Its only a matter of time.

If this must go forward, it needs to be clearly displayed BEFORE purchase which add ons have subscribed to this model so we can make advised decisions whether to support those or not.

I consider this post fair warning for the future but if I start seeing expiry dates on things I’ve bought before today I’m going to be absolutely furious.

Addon developers will lose sales, not gain them. I’m not the only person who is going to reconsider a purchase based on this policy.

They may also expose themselves to potential legalities - changing the nature of a sale retroactively is a breach of contract - both technically, implied and as a matter of goodwill. Its like a manufacturer deciding 3 months after selling a car that every time you service it you have to pay the full as-new price of the car again. Nuts.

Our clients won’t take too kindly to a retrospective change like this and I’m not going to wear it. I transfer licenses to clients on site launch so they hold those licenses. When they come to me about this, I’ll point them (and their lawyers) to you.

I predict Devot-ee is already going to lose sales from this regardless of what you do - this kind of thing damages people’s confidence and will send a lot of people looking for ways to purchase licenses directly to avoid this kind of situation again.  Iv’e bought licenses on Devot-ee occasionally paying more as a matter of convenience in the past rather than go direct. I’m going to have to reconsider that.

Shopify made a similarly ill-thought-out, no-consultation retrospective decision like this a few years ago and (I think on legal advice) had to very quickly backtrack and grandfather all of the free accounts they had prior to the change. It might be prudent to sort this one out before it takes effect to prevent a similar mess.

This is bad for EE as a whole. With the rise of CraftCMS on top of other technical issues with EE of late, this is just one more reason for developers to look elsewhere. Another brick in the wall if you like.

I see absolutely no upside to this at all.

Balls indeed.

MaxLazar 10.04.14


2Damien Don’t think that Craft will have a different story. Most developers is from EE world. With EE add-ons support experience. Many of craft cms add-ons already have information that this add-ons will be a commercial as soon as craftcms marker will lunch.
As developer who have lot of free add-ons for EE, I will publish only commercial add-ons for Craftcms (or add-ons with premium). And definitely no free support.
You tell that you ready pay for support, but 99% of user is not. Most people want free quick 24x7 support even for free add-ons. I do not make public any of my new add-ons for last 2y, just because it become not possible to spend so much time for free support (hundreds hours and about 80% of q is not really related to add-on).

jdaalder 10.04.14


Yep Craft will encounter the same issues although hopefully they’ll be clearer from the start, and some will have learned lessons.

But this isn’t really about Craft, or even EE for that matter - it’s about devot:ee

If you don’t want to do support - don’t sell.  Release on github, say clearly no support, accept pull requests and respond to issues if you want to.  Basically, learn to say No.  But say no to addon *sales* then too.

If you do want to sell, support properly, develop something that IS supportable, price it sustainably, and let the market decide to buy or not. 

I absolutely DO want timely support for something I have paid for that doesn’t work as advertised - and that I can properly show does not work.  And if I get a response saying ‘it works here, must be your server’ - I can live with that (unless I can prove otherwise of course).  That’s quite different from unreasonably asking for free support for something for free.  (Although many times it’s people finding issues that helps improve things for everyone and is the very heart of OSS and community).

And document the living hell out of your work, paid or not - and the vast bulk of your support burden will go away.  This is by far the biggest failure of most complex addons.  Look at Low/Squarebit for examples of really good work.  Then look at some of the others - the documentation is well out of date, or flat out missing in many cases, or written just awfully.  If you do it well, 95% of your response can be - ‘see here’.  And mostly you won’t even do that as most people buying are devs and know how to read and puzzle things out a bit.

Benjamin V 10.04.14

Benjamin V

I get most of these changes….for future purchases.
It will then be a choice wether you agree to new terms or not.

But applying this retroactively, thats just wrong…seriously wrong.

johnniefp 10.04.14


My gripe with the Devot-ee implementation is they’re locking me out from downloads, that’s just plain wrong.

This has all come about from a support perspective not a product perspective. Yes there are @rses that ripoff devs by distributing addons but why should the honest pay extra to compensate for the behaviour of thieves?

If anything you should be locking customers out from support not the product they’ve purchased. (By all means charge again for major updates, no problem there at all.)

@devot-ee you really need to rethink this, it’s not a solution.

Damien 10.04.14


Hi Max,

I was simply using Craft as an example. Could similarly been WP or Joomla.

Craft appears to have been borne of and as a solution to many years close scrutiny of errors made in and around EE. I’d be very surprised to see P&T make the same mistakes.

Again and again for good measure - this isnt about support - this is about having ongoing access to the products I bought under that understanding; nothing more, nothing less.

I’ve said it repeatedly - charge me for support - but don’t take away what I’ve already paid for.

If piracy is killing your living then that is something that you and Devot-ee would do far better to address than penalising legitimate users who DO pay for your lunch…

If your documentation is such that you have a constant stream of people asking you how to use your addon, theres a lesson there…

If you’ve failed to put sensible and easy to access systems in place for users to access and pay for your help with installation etc; there’s another lesson…

If your addon breaks every 5 minutes or if after having had prior access to expressionengine updates still doesn’t work on release, there’s a lesson there too…

Don’t blame your customers for your coding, documentation or failure to secure your product from piracy properly.

Max, don’t think I’m directing any/all of this at you directly - I’m not.

I admit I’m fuming about this, sure, but your (and others) efforts as a developer & contributions to the community ARE appreciated so don’t think that isn’t the case. The last thing we need are good developers hanging up their mouse because they think this is an ‘us and them’ situation in which they are not valued.

Conversely, the last thing addon developers, Devot-EE or EllisLab themselves need is site developers deciding this is just too hard and taking our business elsewhere.

jdaalder 10.04.14


You really should make it MUCH clearer above this is all opt-in on a per dev/addon basis. 

Damien 10.05.14


Devot:ee October newsletter

“The sky isn’t falling (despite the reactions of a few)”  Paying Customers…

Wow. Just wow.

Jérôme Coupé 10.06.14

Jérôme Coupé

My 2 cents: if me or my clients bought an add-on expecting to have access to download it, we expect it to stay that way. I see blocking access to downloads (essentially what timed downloads are) as a really bad idea.

That being said, I am more than happy to pay for major upgrades to an add-on or to pay for dev support time.

1. Major updates / versions: neither me nor my clients had any problem paying a nominal fee for an upgrade from EE1 to EE2. Use the same model for add-ons. Develop a new version. Warn clients that it is coming. Sell it and stop active development on old version after x months. To me and clients it’s a clearer model that timed downloads. With those, you could release an add-on, maintain it without adding new functions for 6 months and then make clients pay again.

2. Support: make it a separate purchase by either selling support tickets or by having two licenses: a cheaper unsupported one and a more expensive but dev supported license.

3. Like others I think you might run into problems with the retroactive part of this.

aelvan 10.07.14


Agree on the retroactive part. For agencies who have active maintenance contracts with former clients, this is a cost that we will have to absorb somehow. There’s no way you can go back to the client and say; “Hey, those licenses we bought, that we said were one-time only.. Sorry, you have to pay that amount every six months.” Great way to ruin whatever trust the client had in you.

Interestingly enough, this will also create a competitive advantage for addon developers who choose not to use timed downloads. Given the choice between two addons that has pretty much the same features, you’d be a fool not to choose the one without timed downloads. I’m not sure if this is the kind of environment we want to create for addon developers?

And, time will tell but, I don’t think the problem in the EE community is the pricing, or the pricing model. It’s the fact that the addons are built on a fragile foundation that results in addons that break on every… single… EE (point!) release. Generating huge amounts of maintenance work for developers, and support requests from users. Blaming the user and placing the cost on the user, for the failings of EllisLab, is just a sh*t move that solves nothing.

Ryan Masuga 10.07.14

Ryan Masuga

There’s a lot to respond to here, so let me make a couple quick statements for the tl;dr crowd and then try to answer everyone on down the line:

1. We’ll nix the retroactive part. It wasn’t the right thing to do.
2. This is something a developer had to enable on a per add-on basis, and it is entirely optional for them to do so.

I think that clears up most issues. Now let me elaborate a bit.

However you look at this issue, the fact remains that developers are doing some unfortunate things:

1. Not releasing things that could be commercial
2. Failing to support their current add-ons
3. Leaving altogether (While I’m on that point: can someone contact BlendIMC to see if they’ll open source Title Master? They won’t return my emails.)

This has to change somehow. This isn’t an unusual pricing model - we use activeCollab and get upgrades for a year every time we renew it - if we renew it. Sometimes we don’t have to or don’t want to bother. But, that’s understood from the outset. So, again, the retroactive thing is out. We’re not doing that.

Right now, of the 392 commercial add-ons sold on devot:ee, timed downloads are set on 11 of them (2.8%). We’ll clearly designate this next to the buy now area. We would expect that the update price would be a fraction of the original price - 25-50%, but that’s up to the developer.

The earliest you would ever have to “pay again” for an add-on that is opted-in to this license method would be June 1, 2015, and only if:

1. You bought an add-on on Nov 1 2014
2. The add-on has a timed DL set, and it was set to 6 months
3. Even then, that’s only if you need to update that add-on

In a real example, a couple weeks ago we had to update a site we built in late 2011. We updated about 4-5 add-ons that needed to be updated (we didn’t update anything that was working just fine). I felt a little guilty going into devot:ee and just downloading the latest version of each and updating them. I purchased them three years ago. The developers don’t see a dime from us for any of the work they added to their add-on over the past three years. I would have had no problem giving the add-on devs some money for these updates - we would have rolled it into the invoice to the client anyway.

Bottom line is, this is an option. Some devs have stated they’re not going to use it (Pixel & Tonic via Twitter) and that’s fine.

One upshot of the development we did for this is that due to some of the changes we had to make, we’re a little further down the road of being able to implement UPGRADE pricing, which would be another option for devs to use, for example, when they have a major version release. This ain’t easy to do (we would have done it by now if it was) but we’re a little closer. At that point, add-on devs would have three options:

1. Timed Downloads
2. Set a major release that requires an upgrade charge
3. Don’t do a damn thing

I’m getting a little ahead of myself on the upgrade pricing, so I’ll stop there on that subject.

One thing that was brought up in the comments above was paid support. If there is a way that devot:ee can help facilitate that, we are all ears:

If the above doesn’t satisfy you, I’ll now go through the comments up to this point (puts on protective gear):

Brandon Kelly: Thanks! It’s one pricing model. We’re dropping the retroactive thing.

Erwin: P&T have stated that they won’t be using it, and retroactive is dead, so you would only have to look at add-on purchases going forward - and again, only on add-ons where this is enabled.

Kristen, Blair Liikala, Benjamin V: Retroactive is out.

Damien: Retro is gone. and as you wrote: “…it needs to be clearly displayed BEFORE purchase which add ons have subscribed to this model so we can make advised decisions whether to support those or not.” Totally agree with you. We’ll mark the add-on page in a way that you would know this was part of the deal for that add-on so you can do what you want to do at that point. No blindsides. (I still maintain the sky isn’t falling!)

jdaalder: As I can’t reiterate enough for those folks just scanning: retroactive is out. Thanks for your comment re: price splits and minimum prices. We thought those were totally reasonable.

Also, this quote of yours bears repeating: “If you do want to sell, support properly, develop something that IS supportable, price it sustainably, and let the market decide to buy or not.” Well said.

MaxLazar: Thanks, I think! I understand why you haven’t released anything in years. We develop add-ons here we could potentially release, but we’re reticent to do so.

johnniefp, Jérôme Coupé: Retroactive is out, so nothing you’ve ever purchased to this point will be subject to a timed download. We’ll mark any of the fraction of add-ons using this so you can avoid them in the future, if you wish. Also, see above comment where we’re better positioned now to offer major update upgrade pricing, which I do think more devs would take advantage of if it were possible.

aelvan: Retro is out, and it’ll be clear which add-ons have this enabled before you make a purchase.

I hope this comment helps clear things up. It’s not my intent to do things that would make it awkward for me to go have a beer with anyone in the EE community.

If there’s anything I didn’t cover or anything that still isn’t clear, let me know. However, this thread has hit the limit for calling me “stupid” so make sure to select a different adjective first to keep things fresh.

I’ll update the article above regarding the retroactive part to clarify for those people who aren’t going to read the comments.

jdaalder 10.07.14


Thanks for the response Ryan.

Much clearer, and a better decision now i.e. no retro-active.

I fully get where the issues come from, but I just think if you need to make a change make it a clear move for the future, and don’t try and change the past - as it’s clear you’re now doing.  And I can choose per addon whether the new conditions suit me or not, so that seems fine to me.

I still suspect the market (and I) to expect some free support/bug fixes for actual issues for some time after a purchase and the major version model is a clearer, easier more natural one - but the main thing is clarity and choice I guess.

Damien 10.07.14


Appreciate the response Ryan and I for one think its a solid decision. I still have my reservations about timed downloads but at least now I (and my clients) have a choice and going forward as its been noted by others, the market will decide on those add-ons and their terms.

Now that is cleared up, perhaps we can have a more informed debate about how things can be progressed for the future to ensure that add-on developers can make a living and support their add-ons professionally. Its in all of our best interests and the overarching debate is really only just beginning.

Can I simply ask that add-on developers please please take into account that as site developers, more or less 99.9% of the time, we are the middle-men between you and our clients and try to see how changes like this could put us in difficult or impossible positions.

If I can sell it I will but if it is something that is clearly unreasonable, my clients are going to see it the same way. I’m not going to lose those clients, I’m going to ditch those add-ons or if needs be, the CMS entirely,

I think upgrade pricing is entirely reasonable and can be explained and sold-on by site developers as are major ExpressionEngine releases. It is predictable and consistent.

There’s been some comments that some of our business models are to blame for the negative reaction here but speaking for myself, it should be noted that my business model works very well for add-on developers too.

For every maintenance plan I sign with clients, I install: Backup Pro, Updater and Lamplighter. I have a paid Lamplighter account. Thats a lot of value for you guys, right? and actually, do I need any of those particular add ons really? If I’m not maintaining my clients’ sites ongoing why would I give a toss if they had backups or were up to date? Timed downloads of point releases however, make that business model untenable.

In that instance, what is worth more to you as add-on developers - the small amount of revenue you get from me doing 6-12 monthly updates with timed downloads or the additional sales outlined above with me keeping clients up to date and on-board with EE?

This way, clients will pay for major upgrades. They will also stick with the platform giving me the opportunity to offer new features as we go forward and sell more of your add-ons. The debate isn’t perhaps as clear-cut as it at first seems.

Don’t kill the goose that lays the golden eggs…

I absolutely see the need for paid support, particularly for implementation and am happy to engage in any discussions around that. Take a look at the services that Low and Joel Bradbury offer in this respect and also the terms under which Mark Croxton has just set out his stall with commercial version of Stash. Tell me that doesn’t make sense…

From my point of view its a no-brainer - implement a complex add-on like Stash etc etc for a nominal fee? PLEASE TAKE MY MONEY.

@Ryan - this does clear things up and I would hope despite how heated & passionate things can get, we never have the situation whereby anyone should feel awkward having a beer with people in the Community because its a great community.

I’m only here arguing ferociously because I could see the downside for everyone involved and because I care. When I or others are no longer here bitching loudly anymore, you’ve likely got a bigger problem…

Now lets get our heads together and solve this stuff.

You must be registered member to comment. If you're already a member, log in now, and if not go register (it's free and easy!).