I understand addon developers need an appropriate income, but all this talk of billing for support? Seriously? I'm not on my own in moving away from EE because of where they've gone with support - do you addon developers really want to do the same?
Sure, if someone is being lazy, bill them for the work, but if it's because your documentation isn't good enough, that's your own fault. At least EE make up for their crap support system with really good documentation so the vast majority of us never need to pay for it.
@mithra62 - If you want analogies, how would you feel if Apple refused to fix a security flaw unless you paid for extra support? You wouldn't like it, because it's expected they do it for free when you buy the phone. Their pricing model accounts for that, and so should yours. I think what some of you are failing to see is you're no longer developing addons for extra cash, but instead it's more important to you than that so you need to improve your business model. I'll hazard a guess that charging for support ain't gonna work...
@objectivehtml - Sorry, but you can't complain about support if your documentation isn't up to scratch.
@stephenslater - I agree. Considering the work that needs to go into these addons, I think a lot of them are selling for too little.
@mithra62, @MikeTheVike - There are some addons we just can't do without (and perhaps should be part of the core software), so we purchase them numerous times - and, yes, we expect them to work and we sure don't expect to get stung for it later when a developer refuses to update it because they cocked-up their pricing strategy. It's all part of the curve - some developers get it right and turn it into a successful business, most don't because they can't transition from developer to 'seller of addons' (sorry, can't think of a better word there).
@objectivehtml - Didn't most of the guys you speak of just get fed up with EE and want to create something better? I'm thinking Statamic and Craft. That's an issue with the core product, right? Maybe solely creating addons for EE just isn't a viable business model anymore? Was it ever? I've no idea.
I think the problem is much deeper than pricing models. What makes EE so great is also what makes supporting it so difficult. It's a non-themable, modular CMS, and every site is a bespoke combination of custom templates and add-ons.
With many bug reports, I can't discern user error (misconfiguration, a bad coupling with another addon) from an actual bug. Each bug report is a potential hours-long time suck. I don't know going in whether it's my bug or theirs.
And what if it is a "bug", but it's only revealed in a very edge case scenario that affects few others, do I really have to eat the 3 hours of debugging I just had to do to find out there was a compatibility issue between CartThrob and Publisher?
The expectation from the "addon buyer" that "I expect it to work, and if there's something wrong with it, I expect it to be fixed for free" is too idealistic considering the context. You (our customers) are building a one-of-a-kind Rube Goldberg machine, and our add-on is a whirlygig.
Addon support for EE requires developer-to-developer consultation. Giving that away for free is madness. This is my perspective as a former commercial addon developer.
The second I get a support ticket I've lost money on that sale.
I'm not an add-on developer, but I do run a business, which I'd suggest accounts for most people who have contributed to this discussion. One thing I know for sure is that support has a cost, so I have no issue with paying for support, and I would support the idea of a universal 'currency' to buy whatever support levels are on offer from individual developers. I would also support Brad's suggestion about putting a time limit on downloads, or more specifically, limiting 'inclusive' updates to the current branch only.
How many of us would build a website and say to a client that support is included forever? I can't imagine there would be many - yet we've come to expect it of add-on devs. I do know though that if we include instructions against each field on our publish pages, and provide clients with documentation, we're much less likely to be asked questions with obvious answers - so our cost of supporting that client falls. Documentation matters a lot and no doubt heavily influences whether someone buys this add-on or that.
Whether an individual developer works for free or not - thats up to them, but its important to distinguish 'going the extra mile' against doing something for no gain. I personally think as an industry, we do too much work for free (for the love of code usually) and this is a healthy discussion for the long term future of the community. No-one likes extra cost, but with solid documentation and support, we should be able to demonstrate the value to clients and pass the costs on to them. Ideally with a little bit of margin in it for us in between :-)
@Eric - I totally understand your frustration about people buying add-ons and not know what to do with them. What worries me here though is everyone has to start somewhere - otherwise you'll never attract new clients, right? No one can live off existing clients alone as thats not a sustainable model either. I can quickly understand whats going on in Structure, but it could take several projects before I realise Cart Throb has a great feature I should be using. Thats where the docs, screencasts, tutorials, examples etc. all come in.
@Rob - your 2nd post relates to my Stack Exchange question. In the end the issue turned out to be totally unrelated to Cart Throb. I've used Cart Throb on several projects and would say I'm reasonably experienced with it. However, having tried to isolate the issue, I couldn't, so I turned to the community for any ideas. These were helpful but didn't solve the problem. So I contacted Cart Throb, arranged a support session and paid for it in advance. Some might say I should have realised what the error was myself, tried harder to isolate it or even understood more about the product (but getting to know Cart Throb is very different to getting to know something like Matrix) - but we've all been in situations where we can't see the wood for the trees or have a client demanding answers. I didn't mind paying Cart Throb for the help (after all it was our own specific situation) and while Cart Throb may have been frustrated by the support call, they were getting paid for it. I should also add I've been a little wary of the state of Cart Throb too given recent reviews - so they haven't helped themselves here because I immediately doubted the product.
One thing I've never seen on Devot-ee is the option for paid support or implementation with an add-on. This could be a nice little top up for add-on devs, but without this on display, its easy for a buyer to assume free support and therefore grumble when they're told they need to pay for it. Plus, people don't read licences, so make sure its clear up front about whats in and whats not. Cart Throb offer implementation and setup if you buy from their website, but why not from Devot-ee? Perhaps its down to the way sales are distributed - I don't know but perhaps something to consider?
Could Devot-ee classify add-ons by different levels of support offered? So the likes of Low's, Pixel & Tonic's* add ons which are well documented and frequently updated fall into a 'premium add-on' category? This would make it easier to see which add-ons could be relied on to work with current versions, or known caveats. It could also stir a bit of competition within the dev community. I know I'd rather buy a reliable, supported (yes, paid) add-on than build in something that leaves me high and dry 2 EE updates later.
There are plenty of other well documented and updated add-ons, but these 2 just come to mind).
Let me just say I dislike the idea of support credits. How much support does one credit give you? And what if it turns out one credit doesn't cover the support requested, but that wasn't clear to begin with? To me, it sounds like a can of worms, where you can scare away people from buying add-ons, or worse, EE as a whole.
I reckon, if you have to offer support that requires too much of your time, it will be bespoke, and you can approach that on a per project basis. Devot:ee needn't sit in between there.