Paid Support Options (2014)
  • One thing that's come up recently has been the need for official Paid Support options similar to how EllisLab does them. I think most add-on devs would agree that support within the add-on community is an extreme problem and one that needs to be monetized in order for this industry to move forward.

    That said, devot:ee is the obvious venue to solve this problem, which leaves the insanely complicated question of "HOW THE HELL DO THEY DO THAT?!?!?". Are we talking abstract hourly rates (X hours at $X), blocks of unlimited time as EllisLab, or something else (or combinations of something else)?

    So. Any thoughts or interest here?
  • Simply put, free lifetime support is not a viable business model. Even desktop apps charge for major version upgrades to every so often to compensate for revenue lost to not having a support plan. When I first got into the add-on game I didn't really understand just how much time is involved, and after doing it for awhile it just makes sense that a support model is necessary. I'm sure 90% of our customers will not understand this need because they don't realize how much time it takes to initially build an add-on, answer emails, debug someone's environment etc. It's a time sink, people :) The low cost of the add-on itself does not cover this time. In fact, at least in my case, the add-on price itself hasn't covered the initial time to build the add-on, let alone support it. This is true in all but one case. Custom System Messages might be profitable now, but only because its been on the market for over 3 years and requires little to no support now. 

    Maybe this isn't a problem for Devot:ee to solve? But it would be swell if they did. In the mean time I've been working on my own solution. Consider this an unofficial announcement: Soon, BoldMinded add-ons will come with a free 60 day support window with the purchase of the add-on (that's 30 days longer than EE itself). After that time, in order to create a support ticket you'll have to have a support plan. Said plan will be purchased on through Stripe. The plan will provide 1, 3 or 6 months of additional support at X% of the add-ons initial purchase price (per month). I'll post something more official on my site once I nail down the details/faqs. 

    I personally think every add-on developer should consider support plans of some sort. Its either that, or we increase prices of add-ons even more to cover time invested in them, but then customers will complain more at the initial cost and potentially not buy the add-on to begin with. At least a support plan provides the option of additional support when needed, but also keep the initial add-on cost respectable.
  • I've opted for a bit of a hybrid of your ideas: raising the prices along with adding paid support. I'm not really sold on the rate you've decided on though, since it's still much less than my time is worth for comparable work elsewhere so am leaning more towards a support ticket quota system (for 1 off requests mostly).

    My concern with a monthly plans is we'll still likely be called on to perform the customers job from time to time regardless of what's involved.
  • One idea I was pondering a while back was subscriptions/club membership. I think that could work for some of the big players at least. ie. $39/month; download all add ons and get support. If you need upgrades/support you need an active membership.

    This would probably only work for those which have add ons that people use on _every_ site .. 

    In any case, I do agree; support is a problem. The second I get a support ticket I've lost money on that sale. If I spend 1 hour on support I might have to sell 10 licenses that do not require any support to make up for it .. so, yeah, not optimal :-)
  • A ticket quota system wouldn't be that bad, but it could also be more confusing? I feel like a flat monthly fee somewhere in the range of 30-50% of the add-ons price is straight forward and simple to understand, and to setup as the developer for that matter.

    A monthly flat plan fee isn't a perfect solution either, but it will help cover some of the additional costs for support.
  • As a dependent of the add-ons, I want the developers to succeed so they can continue making more add-ons and making the existing ones better. There is nothing worse than choosing an add-on that isn't supported very well or becomes abandoned. The relationship between add-on dev and their users who need support is bordering on dysfunction. I feel guilty as hell asking for free support. I would feel much better about asking for support if I was paying.

    Call me crazy, but I also believe EE and most add-ons are too cheap. I've always wanted EE to position itself higher, so enterprise clients were more open to using it, not a commercial alternative to WP. In order for that to happen, the risk of using abandoned or unsupported add-ons would have to be eliminated.

    In order to have a functional relationship, both of these points have to be satisfied:
    • Add-on devs must be paid for their time, period.
    • Customers of the devs must be supported to succeed, period.
    As a purchaser of 50 or so add-ons, I don't really want to have 50 paid support accounts. Tracking whether or not I have support alone would drive me insane. And buying a new support plan each time I buy a new add-on would only compound the problem.

    I would like to see Devot-ee take the lead and offer support plans that customers purchase. The logistics of this would initially be tough, but I think it could work and provide a win/win/win (dev, customer, devotee).

    Perhaps it's as simple as purchasing support vouchers that we can use with the add-on developers who have signed up under the Devot-ee support plan. Maybe it's a bronze plan that gets you X amount of support, and silver and gold plans get you more.

    Obviously, this would require the add-on developers to come together, work with Devot-ee to establish standards and fair compensation, but it seems like a natural fit.

    I haven't crunched the numbers, so maybe it just won't work, but I suspect a pretty high dollar could be obtained for a support plan that covered add-ons purchased through Devot-ee. All added up, and distributed accordingly, the hope would be that the add-on developer is fairly compensated.

  • I'm not an add-on developer, but I can imagine that support is really difficult to do for plugins. I have a few thoughts on what might help you guys coming from a designer/EE "developer"...

    1. If the same questions are asked over and over, perhaps add an easy-to-find FAQ somewhere you can point people to.

    2. Maybe your plugin documentation is lacking, or is too tailored to "hardcore" developers. As a designer that uses EE and a lot of plugins, I appreciate that I can build complex sites without knowing PHP. Sometimes when looking at documentation for certain plugins it goes right over my head with "dev speak". 

    3. Provide working "real-world" examples of usage...commented template code, demos, video, etc. I recently was implementing something new using Low Search and I would say Low's docs are developer tailored, but his example template code he added recently helped me out tremendously.

    Just being honest here, I usually use the same plugins over and over on sites. If I use Wygwam on 25 sites and on the 26th site i have an issue, I expect "free" support. Obviously if a purchaser wants the plugin to do something beyond what it does, I think you should charge for additions. Maybe if you guys do implement some kind of paid support, the purchaser gets a refund if their issues turn out to be a bug or something.

    I hope something can be worked out so all sides are happy, I dread the day my favorite plugins are discontinued.
  • I like the idea of paid tickets of different grades, with discounts for bulk purchases. Each ticket is then tied to a specific support request, meaning the user must think carefully about their ticket before using it - which should improve the quality of the requests submitted. Tickets would expire after a given period, say 1 year.

    Platinum: response within 12hr, with 24hr resolution: $80 / $600 for 10 / $1000 for 20
    Gold:  24hr response, 48hr resolution: $40 / $300 for 10 / $500 for 20
    Silver: 48hr response, 72hr resolution: $25 /  $200 for 10 / $350 for 20
    Bronze: 72hr response, 7 day resolution $10 / $80 for 10 / $150 for 20

    It would be great if the developer could choose which ticket grades to offer and the corresponding base price and bulk discounts to offer.
  • Tickets could also be bundled with add-on purchases.
  • I too like individual support tickets though I'm really nervous about the price examples. I can't stress enough how time consuming some tasks can be so a $10 ticket would still be a nightmare scenario wherein we're still spending hours in a hole.

    As to what MikTheVike said, that too makes me nervous. I think the main problem is that pretty much all add-on devs (that I know of) have extensive documentation with all the criteria he mentioned already but, also as he mentioned, there's a lack of comprehension (and, I've found even lacking a cursory desire to look themselves) on the part of some less technically inclined customers.

    To that I say big deal. This is a technical industry requiring technical knowledge in order to do the job. For sure, it's possible to skate by, resting on ones laurels, staying only within ones comfort zone, but it's certainly not the responsibility of add-on devs to encourage and put themselves out in order to make it happen. Some things are just technical and complicated; dumbing documentation down to the lowest common denominator helps nobody.

    Basically, if the docs aren't good enough, then don't purchase the add-on. Having expectations that, because one doesn't understand the medium one's working in, the slack should be taken up by other, more knowledgeable professionals, is simply absurd and one that no other industry shares.

    It feels like the dichotomy within a vocal minority of add-on customer's mindset is that since they can't build sites without the add-ons, then they have to use add-ons, so it's up to the add-on dev to forever support said add-ons. And, aside from being insulting and plain bad business for the add-on devs, though AMAZING for the customers who rely on said code (who doesn't like free work from others?), it's also illogical, and unsustainable. My feeling is that any and all direct involvement by the add-on dev should be compensated when it falls outside of their support mandate. Yes, even bugs from old customers should be paid for to the dev in question to personally investigate.
  • As a consumer, I'm not sure how I feel about having to pay for all support (though I totally hear you about how much of a loss it is), however I do have a couple notes on the subject:

    If you did do paid support for everything, my preferred solution would be to do it all in one place, either through Devot:ee or another third-party site, and I would only have to pay one monthly fee for everybody. Like $100/mo to get support for any add-on from any developer.

    Second, I'm a huge fan of paid emergency tickets. I'd say 80% of my support requests are things that I don't mind waiting a day or two for, but then there's that 20% of the time where OMG IT'S BROKE PLEASE GOD HELP, at which point you have a captive consumer and I'm willing to pay whatever you want for immediate support.
  • Let's take this dichotomy to other tools; say, GitTower and Keynote. There's absolutely NO way in hell that those developers would personally investigate any issues on behest of their customers. Why is it ok with EE?

    Or, what about contractors? Say, I'm building a house but I'm doing it the EE way by purchasing pieces individually and connecting myself (roofs, walls, floors, etc) and I have an issue with some lumber. The distributors of that material wouldn't drop what they're doing to come and walk me, their customer, through their "technical" documentation or do the job for me. Why is it ok with EE?

    What about building a car? I can order all the parts I need individually and put them together, but Hayne's isn't going to send me a personal rep to help me through the tougher parts of their books. Why is it ok with EE?

    At some point, personal responsibility has to kick in and we all compose ourselves as professionals who can do the job we're hired for. Relying on the good will of others in order to do a job we've agreed to, and accepted money for, is such a bad strategy I find writing this sentence plain awkward.
  • I totally agree with Eric on this. I think most people that use my products would agree that I go above and beyond with support, and almost always do it for "free". I spend hours and hours on this stuff. My add-ons have been available for quite some time now, I have never raised the price, and none of them have seriously critical errors. 99% of the support tickets are involved with third-party add-on conflicts, EE core upgrades, server environments, or a lack of technical knowledge or understand of the problem.

    It also takes time to update docs, and in many cases it's *more* time to update the docs than it is to add features and fix bugs in the code. Consider this, if I had to thoroughly document every single new feature, FAQ, or common question, there would be no new features. I would just be updating docs, examples, tutorials all the time and the people with feature requests would never get answered.

    I as talking with another very well known developer at Peers and he suggested I raise my prices to at least $100 for everything, and only answer support questions 1 day a week. So for example, I spend Wed each week answering support questions and if it doesn't get answered, wait until next week. Have an open chat room and anyone can stop by to answer questions. This obviously would result in push back from existing customers, but my profit with the increased price and less support from those people that think they are too expensive would result in significantly less hours spent on maintaining my products. And to say I need to spell out everything specifically in a license agreement, TOS, support page, etc would go against why I started doing all this to begin with. 

    I am speaking for myself here, but I didn't start writing add-ons to take peoples' money. I do it because it's my passion, and I love doing it. I build software, it's who I am and what I have always wanted to do. But something has to give here in the community and what people expect out of add-on developers. I know if I go out of my way to help someone, that becomes the norm and it's now expected. In the last several months, I seriously have had to quit replying to some requests or intentionally ignore them days while I get work done. People complain, but at the end of the day I need to make money too and the world keeps on turning. I literally had someone tell me this week that I got them fired from their client and I personally "fucked up their project", which is completely not true at all. The same individual also advocates not making any add-ons compatible with other add-ons outside of my control. But how would this even work? I might as well not even get out of bed in the morning. I mean it's 2014, software should be able to integrate with other software.

    So as to a solution... I have no idea. I personally don't like any of the ideas outlined above. I feel it will cost more for me to manage support subscriptions and meet new expectations still wouldn't be worth the money that it brings in each month. It's not even that I mind people submitting issues, requests, etc, because that not it all. It's just following up with each request individually and personally making sure it gets fixed. Sometimes there are 2-4 hours involved here, and that's worth way more than $100 to me so I am not sure a support plan would cover those costs. I will be following this thread as it develops, so hopefully we can come to a global consensus on how to handle this issue. One thing is for certain, people don't want these add-ons and the developers to go away, and at the end of the day, the client should be paying the bill.
  • It's not okay with EE. This culture of expectation was set by EllisLab initially with their forums and was ill-conceived. Most add-on developers followed suit and haven't yet righted the ship.

    Lifetime support for a $50 add-on isn't even worth entertaining or discussing anymore because it's prove unsustainable. Come up with a solution, put it out here and enforce it. Let's see what the market decides.

    As sad as it is to consider, the business model might not be viable. After considering opportunity costs, it may make the idea even more bleak. I'd imagine that add-on devs hate support and prefer improving their add-on and coming up with new ones. If the solution doesn't move the add-on devs back to playing their strengths (developing) and hiring support help, then I suspect the whole thing will eventually crumble and fall apart. 

  • "Like $100/mo to get support for any add-on from any developer"

    So how is that to be distributed amongst the developers?
  • Speaking from the customer end...

    I've never used EE's paid support, I can't, and I haven't needed to.  For me at an institution that's difficult to do payment-wise, and for addons that go paid support would be a disincentive to buy for most.  If the product is either that good or I know its functions well enough to get by with some public options then maybe.

    Instead I would suggest either limited free support like slower reply times or complexity levels.  For example, to tell an addon developer about a bug is kind of support until you know it is a bug.  I would not recommend what Avid does (jumping to audio industry), having support through paid tickets where each ticket costs $x and is a forum topic.  Holy pain in the neck, I just had a few setup questions because you didn't print the MAC address on the Artist Mix!  Anywho...   I would also suggest using versioning more often.  1.x is $50.  2.x is $50 and actually change versions once in awhile.  That's usually the only time I need to ask questions or get help, other than that I hardly use support.
  • To give an idea of how hard it is to make a full-time living off selling EE addons (when most addon developers are down 30-50% globally right now), I have had to resort to investing in my own saas product, Timeblocker. Devotee obviously just did it with Lamplighter. Pixel and Tonic did it with Craft. Jack and Fred with Statamic, and the list goes on. I launched my service this week and people immediately asked if I was abandoning EE. Of course not, but at this rate it can't last forever as sheer business decision. I'll be here as long as we can make it profitable.

    Again, speaking for myself. Support costs wouldn't be as much of a concern for me if sales were consistently raising month over month for two years, then suddenly dropped despite releasing consistent major updates to all of my products. Like I mentioned before, most every add-on developer's sales are down so for me, I would just like to get those numbers back up again and growing again. There was talk in the developer chat today w/EllisLab about the same thing concerning sales. I am not blaming the customers in any way, and certainly don't expect people to "buy more". But the pool of people leaving EE for other platforms outweighs the new people in EE. But the new people in EE cost more to support and require more handholding which goes right back to the top of the thread with the support issue.
  • I'd be more than happy to pay for support. Especially if it helps ensure the longterm success of add-on devs and their commitment to the products they make — which at times feels like it might be just as important to the longterm success of the platform and community as anything EllisLab does or doesn't do for the core product itself. 

    As an add-on consumer, I like the idea of the voucher system that Stephen and Croxton are proposing, but I can certainly appreciate Mithra's point that $10 for certain types of support requests is still problematic. 

    What if instead of having a flat fee for each support request there could be some discretion made by the add-on devs for how many tokens/vouchers/whatever would be required for any given request? Essentially, I submit a support request and along with the initial reply from the dev is a quote for how many tokens this issue will take to resolve. 

    Some requests may require no tokens at all (because they're really just a bug report or requires nothing more than a super simple, quick reply). Some may require 1 token. Some may require 10 (or more). etc. etc.

    And maybe there's an option to select the urgency associated with your request from a dropdown menu. Making your request more urgent wouldn't necessarily ensure it will be resolved any faster, but it's a piece of information the add-on dev could use when determining the number of tokens associated with a given request.  

    It seems like a system like this would provide a framework for a paid model without locking everyone into the same pricing model, which I can imagine would be next to impossible to come to a consensus on.
  • @untrecserv

    I think there is definitely a distinction for all of us between bugs, PHP errors, and environment and add-on compatible issue. In my mind, if someone submits an issue and I can't duplicate it locally, or is specific to their 
    design/implementation, that should be paid. But if people find errors, I know I am always willing to fix those and get a patch out. I will even do some feature updates for free, it helps build up and improve the product. None of us want that to change. It's just every single time we get an issue, we can't duplicate it, and we have to look at their code and data setup to make sure it's correct. That takes time, hours and hours.

    I don't even mind answering questions, giving advice, especially for first-time users. For me the line has to be drawn at anytime I have investigate someone else's code, I should be getting paid adequately for my time at my normal hourly rate.
  • What do I want from an addon?
    1. I expect it to work, and if there's something wrong with it, I expect it to be fixed for free. The same goes for anything I buy.
    2. Because it's an addon for software which receives free updates, I expect similar free updates for my addons so they remain compatible with the software I bought it for in the first place.
    3. I want good documentation so I can just get on with it. I don't want to contact the developer for support - if I need to, it's almost always because the documentation isn't good enough.
    4. I want a one-off fee.

    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'm digging @bburwell's idea of using "credits", and each support ticket "costs" a certain number of credits, depending on the developer's needs.

    This would a) keep everybody's support in one place, like here on Devot:ee, and b) give consumers a predictable price with a single point of sale.

    As far as a payment model, I'd support both XX credits for $XX per month, and the ability to purchase credits a-la-carte. This would benefit both the occasional dev with low support needs, and the big EE shop with lots of support needs, and nobody feels like they're getting shafted.

    The credits system would also enable refunds for support requests that turn out to be bugs.
  • P.S. I also nominate that this new currency be dubbed "Reggycoin".
  • I agree, the credit idea seems like it would work better as a universal option. Allows people to buy credits at once in one place, and spend them freely between devs and they get their cut. I am not sure how it would work in actually, but I do agree it's the best idea proposed so far.
  • I think it's fairly safe to say that bug reports, in the vast majority of cases, are something that most everyone agrees shouldn't require paying to have fixed and would typically fall outside of a potential token (aka Reggycoin!) system. And as with most anything, there may be some exceptions to the rule. I take @mithra62's example above as an illustration of an edge case that might reasonably warrant special treatment.

    I think it's to everyone's benefit to think of this as an issue the community is trying to solve together. Perhaps a paid model isn't the answer. But it's clear that the current system isn't working for a good portion of add-on devs. 

    In my mind, that's not just a problem for those devs, but a problem for the entire community to work through together. We obviously rely on each other to be successful.  So if the devs who are making the add-ons I use are telling us there's a problem with the way the current model is working I'm 100% open and invested in helping them figure out a model that works. 

  • A different solution may be to raise the minimum addon price to the point that offering support with add on licenses would become a lot more feasible.

    It would be a more immediate solution to the problem than creating a support/ticketing system, and far simpler.
  • Just adding my two cents.

    I'd love to see devot:ee house a credit system for add-on support, allowing each dev to set their own credit pricing for one-off tickets or monthly support plans.

    I do think some amount of support should be included with add-ons. With a credit system, perhaps devs could also specify that x number of credits are included with the purchase for help when getting started.

    It's also really important that a developers' docs are of good quality. Not to start a firestorm here, but if you're getting a lot of support requests, perhaps it is time to look into your documentation. I too would share some level of concern paying for support for add-ons with awful docs. This is by far not the norm, but there are certainly some out there that are lacking.

    When it comes to bug fixes, this is one area that I think really needs to be worked on, both with the support of EE and with add-ons. A less-technical user may not know the difference between what is a bug and what is just them not understanding how to use the software. I'm not sure what the solution is here, but there needs to be a way for users to at least ask if something is a bug without being forced to buy support time.

    I also don't see an issue charging for major version updates. We paid for updating from EE1 to EE2 and I'm sure we'll pay again to go to EE3. There's no reason add-on devs have to support the add-on literally forever, so perhaps charging at major releases would be an options?

    And lastly +1 for calling the new credits system Reggycoin!

  • Speaking as a customer for the few times I've needed it support has always been appreciated. I also appreciate that add devs have to make addons pay their way, whether it's a full time job or to supplement other work.

    For me the idea of one off support tickets appeals, certainly if the issue takes an hour to resolve that's money well spent, but if all it takes is 2 minutes for an email reply for a known issue I may feel hard done by! So using a credits based system would probably be fairer all round.

    I'm also thinking that developers should look a charging for new *version* releases, but I can still download point releases for my licences FOC. That should provide a new income stream from people upgrading generally. Of course that relies on developers being fair with releasing point releases and new versions :)

    Regarding buying brand new licences for, personally I like the idea of offering free support for 30 days for a fixed number of tickets, then paid support in whatever format after that. Whether or not a free support period applies to repeat purchases is another question!
  • A quick question to the Add-on Devs:

    What percentage of your support requests are "How do I do this, how do I do that?" questions due to either laziness or just an honest lack of knowledge/understanding from the User?

    What percentage are real bug/error reports?
  • Lots of great stuff here. I'm in the camp that thinks EE and its devs would be better served with higher prices. I'd also be happy to pay for the support I need - but don't love the idea of subscriptions, or paying in advance for things I don't.

    I think EE's updates have trapped devs into thinking that they have to forever upgrade their add-ons to keep up for free, but I'm not sure that's so. There are a lot of people who launch sites and don't do consistent upgrades. I think it's reasonable for devs to include a range of upcoming releases for which their updates would be free, after which point, folks would need to pay to go further. 

    For that reason - I think the Apple argument above is flawed - there's certainly software that charges for upgrades between major OS releases from Apple. Sometimes EE upgrades significantly change the structure of how add-ons work. Why shouldn't people expect to pay for that new functionality/development?

    "A different solution may be to raise the minimum addon price to the point that offering support with add on licenses would become a lot more feasible."

    "If the solution doesn't move the add-on devs back to playing their strengths (developing) and hiring support help, then I suspect the whole thing will eventually crumble and fall apart."

    I agree with both ideas, sadly, in the second case - and would love to see ways to sustain this community and its software. Two more points I've often thought of–would devs consider either:

    1 - Allowing me to simply buy an extra hour of time with the product? Knowing its cost, (at whatever rate) would enable me to package it for the client in an estimate, and make it a much easier sell. I promise to be a good customer, test first, and RTFM. An hour or two up-front during my dev might be all I ever need.

    2 - Charge for an hour (or two) of consulting? Sometimes the help I long for isn't to fix what's broken, but to plot how best to use your tool to implement my solution. Again - the fee for running strategy with you, or getting your take on my plans might save me hours (and hundreds) later if it turns out my thinking is wrong. I'd love the opportunity to pay for that.
  • This is an incredibly interesting discussion; I found myself nodding through most of it. I definitely think add-on devs should get compensated for their support time. That it has taken this long to even have a semblance of serious conversation about it is a bit surprising.

    Like a few others here, I'm the consumer in this scenario and I'll be honest, a monthly subscription is not appealing to me at all, for the same reason I don't pay for EllisLab's support – I don't need support often enough to warrant it (especially now with EESE, which is the first place I look these days before hitting up the dev for official support). Sure, I can sign up and then cancel, but that's actually more effort - yes, I am lazy in that regard. :) That said, the token idea is much, much more appealing (nice work, Brett!). The company of some e-commerce software that I've used in the past used to have a credit / token type system (before they went SAAS) and I felt it was incredibly fair. So count me in for that idea.

    Sincerely hope you guys figure it out. Overall, I think you have most of the community's support. :)
  • I don't like subscriptions for support. I also think "support" should be better defined, first. As mentioned before, there is a distinction between bug reports and questions that lead to feature requests or improvements, and actual support in using the software.

    The former should always be free, even if your license is 2 years old. The latter should be covered by docs. If it's not covered by the docs, it's my job to either educate the 'supportee' or to say "sorry, that's not part of the support".

    Currently, Low Search is the add-on that generates most support. I was getting more and more 'type 2' support requests, about its usage. I reluctantly added the advanced examples (glad to hear it helped), but still got those "how do I do this" requests. So, recently, I introduced what I call "Implementation Aid". I offer my services to implement a premium add-on in return for a one-time fee.

    Now, when someone comes with a "how do I do this" question, I can simply point them to the Implementation Aid service. This will "scare off" some customers, but others will use it. There is a bottom price I use; it must be worth the effort of communicating with the customer, getting the brief, getting to know the environment where it needs to be implemented, invoicing, etc. So usually, pricing starts at half a day.

    For me, this works well. I can still offer free 'type 1' support (bug reports, etc) and for other requests I can still help, but for a fair fee.
  • I am quite late to this thread - a great read! A thought arises: when I look at some of the threads on EE stackexhange, it is quite clear that some contributors know  a heck of a lot about the third party add-ons under discussion - we used to see the same in the old EE forums.

    It would be a pity to see this kind of know-how go to waste while the add-on devs can't find the time or justify the "price" for support.

    Is it totally out of the realms of possibility for support to be unbundled from development? After all, there is a huge "consulting" ecosystem around products (even free ones) like unix, MSOffice etc. The so-called consulting most often really amounts to what we would call support - bug fixing being the exception for us, maybe ... but even there, it was clear from a number of comments in the EE online chat yesterday, that some devs are actually coding workarounds for bugs in proprietary apps (looking at you EE) to get things unstuck.

    I certainly do quite a lot of that for EE, and I charge for it - in my case mostly because the client has no incentive to deal directly with EE - they want me to represent them in that space because I sold them on EE in the first place. I even have some clients who don't want to know what platform(s) I use, they just want me to take responibility, and its up to me to get the price right to support effort required.

    If there were some way of incentivising it, devs might consider subcontracting support for their more burdensome support tasks to other devs who could use the dosh and have the skills/know-how??
  • @lodewijk makes a really great point and judging from some comments it seems the definition of "support" is important here.

    FWIW, what I'm specifically talking about is the type of support where I have to interact with a site. If I have to log in to FTP or the control panel and click around to investigate, personally, I do not believe that should be considered "included".

    Forum posts and quick emails (when appropriate) and other "help yourself" avenues, I doubt any add-on dev is advocating charging for those. Just the personal, "Eric's now looking through template code..." is what I'm talking about.
  • My first observation is that it is not 100% clear what kind of support we're talking about here - from first read I assumed we were talking all support but then saw a tweet from @mithra62 "we're talking about the teaching / doing. Not fixing". These are two VERY different things & it would benefit the discussion to define it more clearly - are we talking about:

    A) Support for bugs / problems getting the addon working or the addon not working as it should?

    B) General help with how to use the addon or with what you can do with the addon?

    In lieu of that clarification here are a few points to consider:

    There's a large divide in the quality of support provided by developers. I've had unbelievably good support from developers of both free & paid addons and alternately extremely slow & very poor support for obvious product bugs and failures from developers of some of EE's most expensive addons. I base my future buying intentions and likelihood to recommend products to others on these experiences.

    Anyone considering charging for support needs to ensure that support is not only timely but professional. There was a suggestion above of support being provided on only one day a week. So from my perspective - I pay for your addon, potentially pay for support for what 'may' be a bug with your product and, when I may be in the middle of a crunch to launch a site, wait up to a week to get a response?

    Sorry but that's just not good enough and I'm surprised it's even been floated. I can imagine my clients' response if their site was down or their email didn't work & I told them I'd take a look at it next week. If we want a professional system in which devs are remunerated appropriately for their services, that has to cut both ways.

    As a couple of others have already suggested, I also would be happy to pay a consultancy fee or whatever (and have done in some instances) for advice / direction on what can be done and how to use certain addons more effectively. I already use & pay a lot for addons and am certain in most instances I'm not getting the most out of them. You guys might know your addons inside out but often forget that the rest of us are using your addons because we're not programmers. Improve your docs (for non-genius-level peeps like me), provide some videos, case-studies and real-world examples and I suspect you'll have less of us asking you daft questions 24x7.

    There's been talk elsewhere about people not paying for licenses and (in lieu of my usual Yorkshire profanity) frankly this annoys me massively. I take a lot of time and administration to MAKE SURE I pay for all of the addons I use no matter how many times I use them as I know you are all to some degree or other in the same boat as me, with families to feed and mortgages to pay. I understand however that not everyone is as honest as I am and sympathise with those losing money through what is theft no matter how you spin it. This does raise the question though - do developers think increasing addon prices and charging more for support is simply going to make this problem worse?

    In relation to monthly subscriptions - everyone is paying more and more monthly subscriptions already and it is increasingly difficult to recoup this from our clients when the vast majority of our competition using Joomla & Wordpress have everything pretty much free…

    The important thing to keep in mind is don't kill the goose that lays the golden egg. No one; EllisLab, Addon devs, EE Designers / Developers or end-users - are going to benefit if the costs associated with using EE become prohibitive.

    Either way this pans out I know I'm in the EE business mainly because of the EE community. I really appreciate the huge amount of help that comes my way from all manner of people and know I couldn't possibly work on EE without it. I try to help out others as much as possible to pay this back into the system and I really hope there is a sensible solution to this which keeps everyone in business and in the community.
  • Sorry, took me a while to get that comment out there. In the meantime some of it has been clarified and I think Lodewijk has what I as a customer consider a very fair and professional approach there. I'm glad to hear about the implementation support as I didn't know it was available. Spot on. Well done Low.
  • I think this is more of a commucations problem than a pricing problem. As an add-on customer I see Devot:ee as the IKEA of the EE community. I can walk in, grab the stuff I need, but have to bring it home myself and install it myself. It comes with a manual so I know how to assemble it (the docs). If IKEA gets a lot of questions about how to get those spotlights in one of their BESTÅ display cabinets, then apparently something is missing in the docs and they should fix that.
    In the case you received two right panels in the box instead of a left and right one, or the screws that come with it are too short, that's a bug and they will fix it for free, as per their terms of service.

    If however a client can barely hold a screwdriver, IKEA offers an assembly service that you have to pay for, obviously. Like the implemenation aid @lodewijk mentioned.

    Everybody knows that buying at IKEA means assembling the stuff yourself, so should everybody know that buying at devot:ee (or just buying third party add-ons) means implementing it yourself and not expecting the add-on dev to help with that for free. If there is a bug or the docs are not clear enough, the developer should fix that, otherwise the dev should get paid.

    So I don't think we need a paid support system on devot:ee. I think the first step is now to educate the add-on customers better about what to expect when buying an add-on and what not. And every dev can have it's own implementation service, should not be regulated by devot:ee.

    - Joan
  • As an add-on dev I agree with most of what has been said:

    - Subscriptions will not be feasible for most customers
    - Bugs/issues are completely separate from support requests
    - Tokens sound good in theory, however there needs to an agreed pricing structure or allow devs to set their own token prices

    I propose the ability for add-on devs to include a link/page of content in the add-on edit screen that answers the frequently asked questions. Devot:ee should put a link to this front and centre when a customer begins to create the support topic (like Github does with the Contributing guide when opening an issue). 


    Another suggestion is after the customer types out the title of their support topic, the user is prompted to check similar topics for the answer to their question (similar to Stack Exchange).

  • Coming from the addon buyers' side, I agree it's important to define what support really means. If it's bugs or incompatibility issues, then I don't think the expectation of free support is unreasonable (if I'm doing my part to make sure I didn't cause the problem in some crackpot way). I also think it's reasonable for the addon dev to look at an issue and respond with "this lies outside of normal free support" and offer a paid consultation. For those of us whose business works on billable hours, it makes total sense to pay an dev for an hour of his/her time vs. the time I'd have to struggle with it.

    I realize I may not fall into the category of user that sparked the discussion, but I think getting aggressive with support as a whole may penalize the good guys more than the abusers.

    Perhaps where devot:ee could fit in would be to try and build a consensus, site-wide policy among devs as to what falls inside the bounds of free support and take some of the judgement calls out of the discussion. Buyers would have the opportunity to know what a reasonable free support request is—even with the understanding that some might still ignore it. Devs could then reference that policy and recommend paid consult where appropriate at his/her own established rate.

    There will always be grousers and grifters, but perhaps having some agreed-upon terms would relieve some pressure points from the conversation.
  • 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.

  • Let me just apologize right now because drama isn't the spark I'm trying to ignite here I can assure you though, I can see how that is what will probably happen:

    What I don't understand is why this topic is so hot and the ExpressionEngine 3 topic is not?

    Not to take away from the plight of add-on devs and their support woes but, and maybe it's just me, there are bigger fish to fry here people!

    If EE3 isn't done right there may just come a day where you're not going to have support issues any longer and you'll be looking back to today wishing you in fact still had them.

    I know, I know! Shoot me for being border line negative, seeing a slightly grim future ahead and feel free to throw tomatoes my way here folks but, f**k, pull your heads out of the sand and take a look around!

    I've heard it said by many a dev that EE/EL is dying a slow death and if you want to continue making money with your add-ons and complaining about logging into FTP once a month you might want to consider rallying for (not against) the future of the platform your add-ons are tied with.

    Either way, changes have to be made because change is a brewing here whether you like it or not; otherwise there is always hope.

    Note: If you all see the future full of rainbows and butterflies by all means disregard this as gibberish and unfriend me on Twitter.

  • Okay, it's been brought to my attention that I might have been out of character and possibly out of line. Letting my emotions get the best of me and what not. Some of what I said is still valid and needs to be addressed though, hijacking this topic to do it probably wasn't the best of choice so, please accept my apology.

    Keeping calm and carrying on :-)
  • @natetronn

    While I certainly agree that EE3 is important, it's also years away. The cannibalizing of the add-on developers is a more immediate problem to resolve, and one that's clearly of importance to a lot of people. Frankly, I can't care about EE3 when it's uncertain I'll be around for EE3 if this support problem doesn't resolve itself.

    More, we're not talking about "logging into FTP once a month" but, and this is just me speaking for me, about 5 times a week, into various sites and servers, for various customers well past any reasonable expectation of support (in some cases *years*). This idea that the support problem is minor is mistaken.

    Just to provide some context, and again, just me speaking for me, add-on dev doesn't pay the bills. Not even close. Yet the support takes up, on average, 20 to 50 hours a week, and WAY more depending on an official release. Add into that actual development to for feature requests, or upcoming EE changes, AND our actual day jobs (of at least 50 hours a week across the board) and things get absurd fast.

    To that last point, it should be noted that quite a few of us devs are literally sitting on updates and releases because we just can't provide the support necessary to publish. For example, Backup Pro 2 has been ready for a couple months now but the nightmare of support requests it's sure to entail prevents me from releasing it. I just don't have that kind of time when I have bills to pay and adult responsibilities.

    As @objectivehtml said; this is a hobby and passion for most of us. We do it because we love it. We want to help the community and provide our add-ons as widely as possible. But when the entitlement and expectations of the customer kills the passion, with no profit as a motivator, as has been going on for so long, many of us are faced with the choice of living an unhappy existence being the whipping boy(girl?) for an entitled few or walking away to pursue our passions and dreams elsewhere.
  • I run an agency who has used EECMS for the past couple of years, we've written a few custom plugins for client work but no (as yet) commercial ones.

    We do lots of custom PHP development for clients, we charge all clients for ongoing support. We charge a fixed yearly fee (around 20% of the development fees), which usually evens out across clients. However, we're able to charge more than a plugin developer would because we're talking about complete websites/solutions rather than an individual plugin.

    We've found some EE plugin developers have been fantastic with their support, going far beyond what I'd expect from developers who are basically selling plugins at a pretty low cost. This speaks volumes about the good developers who are involved with the EE community.

    However, as a business owner I've also been very worried by the seeming crash in support from some plugin developers such as CartThrob and Membrr.

    Personally, I think in the plugin market one-off support fees make more sense than annual fees. There are so many different plugins from different people that it's going to be difficult to get people to sign up to multiple annual support fees from lots of different providers.

    You could model it on a priority support model. Free support could be offered via email, or via something like StackExchange or a forum on somewhere like Devot:ee. This sort of support has no guarantee of response time and has the advantage common issues can be seen by everyone - much as @jworboys suggested.

    Priority support could then be offered for a fixed fee, that could be managed via Devot:ee and everyone could agree on a fixed amount. If I paid for priority support I'd expect a response within one business day, though you shouldn't guarantee resolution times. The fixed fee needs to be enough to deter lazy people who can't be bothered to work it out for themselves.

    I don't honestly think you can sort out a fixed monthly/annual support fee unless there is one unified support team to manage it, which obviously isn't the case for plugins.

    best wishes,
  • @rsanchez, I get where you're coming from but a lot of the time it should be relatively easy for a developer to isolate their addon's functionality * from the rest of the site by providing standalone templates they or their customers could use to debug cases like this? * Yes, I know this isn't always the case.

    If they find the addon works as expected in isolation then it's down to them whether they dig any deeper. If they suspect it's going to be a common issue I'd hope they'd dig a little deeper, after all the customer is also providing their time and help where they can in fixing the issue. If they suspect it's an edge case or a complex setup then they could offer their assistance at their usual hourly rate. Whatever they decide to do though it's their responsibility to inform potential customers of any known compatibility issues or caveats before purchase.

    IMO some developers need to figure out how to provide better support rather than looking to get paid for being bad at it.

    The second I get a support ticket I've lost money on that sale.

    How about figuring out how to avoid getting that ticket rather than thinking how you can get paid for it then?

    Bjørn, I'm not picking on you directly there it's just a quote that struck me.

    Maybe you all need to speak to your customers. Reset these expectations you've set that you'll do this work for free. Wasn't it Mike Monteiro who said recently if you agree to do something for free don't get pissed off you did it for free? Find out how you can help them in smarter ways. Find out their pain. Be responsive rather than reactive.

    Big love.
  • @jamiepittock

    I find your attitude about "relatively easy" and "agreed to free work" extremely troubling. The first is a misguided assumption that only applies to a small percentage of problems and the second is simply unfounded to say the least.

    First, Extensions, FieldTypes, Accessories, CP Modules, all of those can't be debugged effectively using "stand along templates". Making wild assumptions like, "it should be easy" is really out of line and it doesn't solve anything.

    Second, when did we all agree to work for free? Was there a vote somewhere that I didn't hear about? Of course not. Instead, we opted to help our customers where and when we could; this in NO way forces anyone to forever live in that state till death. That's absurd.

    No, the add-on developers tried to help and provide support where possible and some customers took this to mean they were entitled to it forever. Pure and simple. Even with us all here shouting, "IT'S NOT WORKING!!", still, we have the entitlement of "well, you agreed to it" and, my favorite from this thread, "I'll just move to Craft then!".

    Again though, I'm struck by the flow a lot of these issues have:

    1. Customer has project
    2. Customer buys unknown add-on
    3. Customer has issues with unknown add-on
    4. Customer files support request

    Is anyone else struck by how insane that path is? Why the hell are people buying things they don't know or have experience with for projects they're currently working on and expecting it to "just work"? As @rsanchez said, these are Rube Goldberg machine, and our add-ons are simply a single whirlygig among many.

    Where's the responsibility to know the tools one uses, before they use them? And, why are us add-on devs responsible for supporting such a flawed work flow? I feel like, as a professional developer, I would be rightfully derided and laughed at if I took on a Python project without knowing the language when it inevitably blew up; EE, add-ons and the like are no different.

    And, really, I think that's a core problem we have to try and correct. Not knowing an add-on and then needing support is just a flawed approach from the start. How can one assess what's a bug if they don't know the tool versus plain lack of knowledge in said tool? Speaking for myself, the number of times my response is a link to the docs isn't encouraging on this point.
  • @jamie

    You are absolutely right, this is a matter of communication or lack thereof. The onus is certainly on the sellers to be more clear about expectations, not the customers. I get it from the customer's perspective. When I buy something, I want it to just work. I was trying to illustrate to the customers why exactly it is so costly to provide support, and why it is so difficult to provide a product for a modular system that works 100% of the time.

    Personally, I decided it's not worth my time selling addons for EE. Once you put a price tag on it, even a nominal one, people's expectations go through the roof. The amount of stress that comes with that is just not worth it. I'm much happier doing free, open source addons now. No money in it, obviously. But I get to scratch my itch of making something cool at my own pace.
  • Hi Eric - 

    I was responding to Rob's example, where I believe the problem could have been easily isolated. I was being quite flippant but my point was there may be better ways to help yourselves.

    You agreed to work for free when you didn't charge for your services. 

    All the best with it.

  • Crap; I reread my last and realized I didn't touch on the good points from @jamiepittock

    We definitely have to do better on our documentation and managing the expectations of our customers; you're 100% right there. Known issues and problems should be front and center; absolutely agree.

    To those ends, I've recently discovered that devot:ee allows for Sticky Forum posts for add-on forums. I've created 2 posts for Backup Pro so far that should help some customers help themselves a little better.

    1. A quick tutorial on how to debug issues
    2. An overview of how best to get support and where other answers may lie.

    I've also commissioned some video walk throughs of all my add-ons so those customers with visual preferences, instead of reading, can just watch a video on Youtube. I plan on having detailed videos for all my products and Sticky forum posts pointing customers with issues in the right direction.

    Any other suggestions on how us devs can better serve our customers?
  • Just thinking out aloud here but possibly part of the problem, from a customers perspective, is that it's often easier and quicker to ask for support rather than go and seek an answer first. That may be down to many reasons, the inability to know how to get answers, sheer inexperience, or just laziness.

    Maybe the support *process* itself needs looking at, maybe support needs to be funneled...

    a) to help customers find known solutions before submitting a request
    b) to ascertain what sort of support is required, eg bug report, using the addons etc
    c) to ascertain the urgency of the request

    Look at the various helpdesk systems and how they work, perhaps something along those lines may help:

    1. User searches knowledgebase for their problem
    2. User gets a list of known issues, bugs, solutions to browse through

    If a solution is found great, no support needed, but if no solution then present a number of options for the support ticket:

    3. Select what type of support is required?
    a) Bug report (typically no fee)
    b) Help with using the addon (may be charged at $xx per hour, up to dev if charge is applicable)
    c) Other issue (may be charged at $xx per hour, up to dev if charge is applicable)
    d) Select urgency ("urgent" tickets could be charged extra?)
    e) Submit request form

    Of course that takes time and effort to run, but if the knowledgebase part works then that should in theory have a dramatic effect on the number of requests, and make them more managable with the possibility of paid options.

    I'll stop rambling now.

  • It's the "not charging for it" we're hoping to stop for certain support requests. It's obviously a pipe dream to charge for all support and not something I don't we're at all discussing and not something any dev I know wants to do (sounds like a miserable life, being a support monkey and profiting on ignorance).

    I, for one, really like the idea of a credit system for out of bounds support requests. This allows each dev discretion when it comes to which requests should require additional costs and can tailor expectations to their own needs. For me, this may include 2 Tokens (@ $10 a Token)for requests such as where I have to log into a site personally or 5 Tokens where a customer just moved servers and things don't work through their own doing, while another dev may require something else. But it'll allow us to set our own rules which is crucial if something like this is going to work.

    The flip side of this is that all of us devs need ensure our documentation and support tools are up to snuff so customers can help themselves. Things like FAQ sections, full template tag details, Control Panel walkthrus, as many videos as we can make, should all be as thorough and useful as possible. And available; it does no good if customers have to search all over for help.

    We also need to be up front about what support we do offer. While I personally love the idea of pointing to common sense and saying, "I never agreed to that", wrong or wrong (no "right" to it IMHO) the community has developed a certain expectation that we need to ween them away from. For example, on all of my add-on pages I plan on stating clearly what the term of "free and I'll log into that personally, sure!" support is and providing a copy of my license with each add-on. More, and just to cover another base, I'll be creating a dedicated page where I outline the entire support strategy I offer and why. There should be little ambiguity as to the reasoning on this.

    I also agree that the add-ons should cost quite a bit more. If we're still going to be expected to provide free support for certain things that support is going to have to be subsidized. Nobody should ever have to work for free again. Period. If it's not from an upfront cost for stand alone support it'll have to rolled into the initial purchase price. In the spirit of practicing what I preach, I've already increased the price of all my add-ons across the board to account for the initial free support costs.

    Next, everyone has to start taking responsibility for their projects and experience with the add-ons they're using. No longer can customers rely on add-on devs to do their job for them without paying for the privilege. Realize, you are buying code, nothing more. There is NO guarantee that any add-on will work for your circumstance or particular need. The inherent risks involved in what you're doing means interoperability is going to be a concern and there's NO guarantee your 24 add-ons of choice are going to play nice together. You are no more entitled to having Profile:Edit work nicely with any of the 2,000+ other add-ons out there than add-on devs are entitled to expect to be paid for all support requests.

    I do think this would make a great addition to devot:ee too, since they're already central to the add-on eco system anyway. Knowing CartThrob as I do, and Rob, chime in if I'm dumb, it seems like it should be a simple matter of creating a product channel with a custom FT to contain the logic for each support term. Certainly not simple, but doable I think to implement nicely into their existing infrastructure. Plus, it should hopefully provide an additional revenue stream so the possibility of this being a self sustaining revenue stream has to appeal to them.

    All that said, this is very much my own thoughts and I'm completely open to suggestions on how best to approach things. It would really be ideal if the community as a whole could form some sort of consensus that we can all stay within so things aren't fragmented. I know I'd hate to have to go to Low's site for his special and unique support plans, then over to DevDemon for theirs, and over to Bold Minded.

    Any thoughts on how best to go about things?
  • Hey all.

    The answer is not paid support. The answer is "timed" downloads and access to support. You pay for the software you get access to that software and after a certain date you can't get new versions or support. The main issue is supporting old addon updates with new versions of ExpressionEngine. The support problem is related to this "upgrading" and never that much after the original site development. If we were being paid for this, it would be a game changer.

    Devotee and all addon devs can make this change very easily. Devot-ee can simply add a "date" field for us to choose how long the download period is. Simple done, revenue increase, easy to understand for customers. Customers want to update EE and their addons, pay again. Simple.

  • +1 to the above.

    I think this is the way to go, at least it is the easiest to understand for customers and the easiest to implement for devot-ee, I'd think.

    An alternative to the date solution; maybe devot-ee could let devs specify if a new release is a "paid upgrade" or not. E.g. when going from 1.4 to 2.0 one could upload the new version and say that even existing customers will have to pay to get that version (ie. they can continue to download 1.4 but to get 2.0 they'll have to buy a license for that).
  • tldr; +1 to parscale, +1 to tokens that expire

    I'm both a customer and vendor. The token idea ($10 per) seems fair but it'd have to be profitable for devot:ee given how much they'd have to do to make it work. Expiration dates on tokens (90 days) may be the best method for that (think istockphoto). However, if devot:ee doesn't want to invest in creating a token system, then some variation of parscale's "timed downloads" seems appropriate.

    Also, you can ensure people are actually buying your add-ons. Ask for licenses and domains before offering support. Up to devs to check unless devot:ee created an easy way for customers and/or devs to assign domains to licenses that both customers and devs could see.
  • +1

    I think Brad is right. We do need to be able to set dates to downloads. Many Magento developers do this. It frustrated me at first, but it just makes sense after thinking about it.

    Support by my definition is when I need to go above and beyond. It does not include fixing obvious bugs... those should always be fixed for free. E.g. there is a PHP error, or I didn't upgrade a deprecated EE method call etc.

    If I can't replicate a bug in my 2 dev environments, or a bug is a clear conflict with another add-on, or I have to login to someones control panel and debug their site with FTP access, that is considered extra support. I do my best to find and fix conflicts with major add-ons prior to releases, but the fact is there are way too many add-ons to guarantee a conflict free release. If a customer is having an issue with an add-on that I had not tested with, or found an entirely new conflict with an add-on due to how they are using it (again, its impossible to test for every expected use case), then that is considered extra support. This scenario is accounting for more than half of my bug reports for Publisher as of late it seems.

    After reading through the comments I'm reconsidering the monthly support plan, and instead of a token based plan I'm now thinking of a way to better define what falls in the realm of "this requires more money" (see above). 

    How would people feel about instead of a token system the developer can, at their discretion, ask the customer to make a small payment to continue support? For example the bug can be reported, but if I was unable to replicate it locally and require logging into their site to debug it, I can flag a ticket as needing extra payment before I can continue with support.

    Another scenario is a customer having a conflict with another add-on that I have not tested with, e.g. something like Cartthrob or Store, which are huge add-ons that take more than 15 minutes to setup and configure, and its configurations can vary widely from site to site. For that reason I don't have those installed locally so I haven not tested against them, but occasionally I get bug/conflict reports with them so I have to login to their environments. It would not be worth my time to setup the add-on and try to recreate the issue... it could take hours to do that in some cases.

    As a side note, I can't count how many times I've logged into someone's site after being unable to replicate something locally only to find out it was clear user error on their part that was documented on my site or they just didn't even try to debug it themselves. My time is often spent making up for people's laziness :(
  • "Paid consultations" are a great idea that add-on devs should heavily advertise. A lot of customers, especially inexperienced ones, would be glad to pay someone else to "just make it work."

    sjcallender How does giving the tokens expiration dates help with profitability? Even so, doing that just sounds like "subscription" with a different name, and from what I've been hearing from the consumer end is that subscription-based support is a big turn-off. The appeal of tokens is their a la carte nature. It's kind of like when you sign up for cable, you really only want about 10 channels, but you still have to pay for 12 spanish-language channels and 5 christian channels that you're never going to use.
  • @kgrote Expirations would become a small profit for devot:ee as surely some would expire leaving the money in devot:ee's hands. Same with istockphoto; they don't pay out royalties if a customer's credit expires. Expirations don't negate a la carte shopping, just makes it a la carte by such-and-such date. BTW, The 700 Club is quality TV. ;)
  • 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).

  • @armitage

    Sorry, I didn't mean to imply that you had done anything wrong in the thread I linked to. In fact, you are one of the good ones! You asked a detailed question, and then you spent the time to carefully research and debug the issue yourself. And came back to EESE to post your answer for the community, no less!

    I was not commenting on the quality of support provided by CT, but rather using your example to show that what might seem like a bug is often some crazy could-not-be-predicted edge case. And one that could not be solved by some back and forth emailing, but needed an actual person (in this case yourself) intervening and diving deep into the code.
  • Thanks Rob :-)

    I guess I wanted to make the point that given that I was asking someone to look at my code in my own unique circumstances, it was right that Cart Throb should be paid for their time and value to me. Also no matter how much you know about something, there's always going to be that time when you learn something new about it!
  • So a lot of people seem to like the credits idea, but I haven't seen anyone recommend what price they would suggest per ticket.
  • 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.

  • +1 with @lowewijk - if the addon developer feels the support is beyond what should be offered free, bill for it.