Limit the life of purchases... project pages moving forward with 5.7
Permalink
So this thread just came up as someone was PM'ing me wondering if there really weren't going to be upgrade fees on a 5.6 theme he was considering buying when/if it became 5.7 ready:
http://www.concrete5.org/index.php?cID=648484&editmode=...
It surprises me to see both wagdi and growthcurve saying that upgrades are a required thing that people get for ever. Is this something we actually said at some point? I can imagine having that thought in the heady days of '09 (I'm sure we'd all agree I have all sorts of ideas) but did I put that in writing somewhere that I'm missing? I don't see it in our code submission guidelines nor in our commercial license. Rights to infinite upgrades for free seems pretty out there, even for me.
Meanwhile in the conference room on the whiteboard of high impact low cost things to do, right in the #1 slot, i have:
"Marketplace gets you 30 days license and ability to open support ticket. After 60 days no release license project page non-sense, no support - just buy it again to ask a new support question. Create infrastructure to sell updates. Make project pages transparant"
This seems like software 101 to me. It's either SaaS where you're paying every month (Adobe, salesforce), or there's a new version every year or so that you're likely going to need/want (microsoft2013, quickbooks2014.) Both get you some type of recurring revenue, which is important.
The way we have things now is the worst of all worlds. You can get support for ever, you can release these licenses and re-use them for ever. It's also become clear that people have wildly off expectations on what a project page really does and what its for. There's a lot of weird policy emerging for sites that one person built 3 years ago and vanished on. I'm not sure it should really be our job to keep track of a purchase from 3 years ago to make sure you get the benefit of all new work for no cost, and somehow decide who should be joined to which project page.
I do get that it's hard to expect people to upgrade the core if it might break their add-ons. I can imagine addressing that with the infrastructure we have in place without giving the upgrades away for free... Some thoughts for moving forward with 5.7...
1) You don't get to project pages any more. They're confusing for the average joe. They still exist and function similarly, but they're not a place we'd let you easily navigate to and wonder how to remove URLs from your found locations page, release licenses, or manage members.
2) If you are within your own site's dashboard and have access to get to the extend site pages, you by default should be allowed to assign licenses to that project page. Instead of forcing people to remember what concrete5.org account they made that project page with and whatnot, we just add whatever licenses you buy in the off site browswing experience to that project page, period. There's some token work Andy and Korvin are discussing that makes this okay.
3) Support, pre-sales questions, questions & discussion all go away on marketplace pages. Instead there's a shiny "Get Help" button that gives you a field to ask questions. Before you post, you have to choose what type of help you're getting:
o... Just a sales question, haven't bought it yet.
o... A technical question but it has been well past 30 days since I bought this.
o... A support ticket, I purchased this within the last 30 days
[drop down with licenses < 60 days old and a "buy again for support" item at the end]
all of these populate a single forum area where devs can have a nice single spot to look at everything.
perhaps that forum is still accessible to casual site visitors through another link, and we make it clear that your support tickets are public.
4) There's a model to sell an update added to the version management stuff in the PRB.
5) There's a check on the upgrade button in 5.7 where we go through all the add-ons listed and see if we know something will break - again with some PRB tweaks.
Thoughts?
http://www.concrete5.org/index.php?cID=648484&editmode=...
It surprises me to see both wagdi and growthcurve saying that upgrades are a required thing that people get for ever. Is this something we actually said at some point? I can imagine having that thought in the heady days of '09 (I'm sure we'd all agree I have all sorts of ideas) but did I put that in writing somewhere that I'm missing? I don't see it in our code submission guidelines nor in our commercial license. Rights to infinite upgrades for free seems pretty out there, even for me.
Meanwhile in the conference room on the whiteboard of high impact low cost things to do, right in the #1 slot, i have:
"Marketplace gets you 30 days license and ability to open support ticket. After 60 days no release license project page non-sense, no support - just buy it again to ask a new support question. Create infrastructure to sell updates. Make project pages transparant"
This seems like software 101 to me. It's either SaaS where you're paying every month (Adobe, salesforce), or there's a new version every year or so that you're likely going to need/want (microsoft2013, quickbooks2014.) Both get you some type of recurring revenue, which is important.
The way we have things now is the worst of all worlds. You can get support for ever, you can release these licenses and re-use them for ever. It's also become clear that people have wildly off expectations on what a project page really does and what its for. There's a lot of weird policy emerging for sites that one person built 3 years ago and vanished on. I'm not sure it should really be our job to keep track of a purchase from 3 years ago to make sure you get the benefit of all new work for no cost, and somehow decide who should be joined to which project page.
I do get that it's hard to expect people to upgrade the core if it might break their add-ons. I can imagine addressing that with the infrastructure we have in place without giving the upgrades away for free... Some thoughts for moving forward with 5.7...
1) You don't get to project pages any more. They're confusing for the average joe. They still exist and function similarly, but they're not a place we'd let you easily navigate to and wonder how to remove URLs from your found locations page, release licenses, or manage members.
2) If you are within your own site's dashboard and have access to get to the extend site pages, you by default should be allowed to assign licenses to that project page. Instead of forcing people to remember what concrete5.org account they made that project page with and whatnot, we just add whatever licenses you buy in the off site browswing experience to that project page, period. There's some token work Andy and Korvin are discussing that makes this okay.
3) Support, pre-sales questions, questions & discussion all go away on marketplace pages. Instead there's a shiny "Get Help" button that gives you a field to ask questions. Before you post, you have to choose what type of help you're getting:
o... Just a sales question, haven't bought it yet.
o... A technical question but it has been well past 30 days since I bought this.
o... A support ticket, I purchased this within the last 30 days
[drop down with licenses < 60 days old and a "buy again for support" item at the end]
all of these populate a single forum area where devs can have a nice single spot to look at everything.
perhaps that forum is still accessible to casual site visitors through another link, and we make it clear that your support tickets are public.
4) There's a model to sell an update added to the version management stuff in the PRB.
5) There's a check on the upgrade button in 5.7 where we go through all the add-ons listed and see if we know something will break - again with some PRB tweaks.
Thoughts?
If there were support ticket 5 packs, instead of having a paywall in front of the Add-On download, I would move some of my other packages into the marketplace. Although, I could very likely be the only one who would be into that idea.
EDIT: To combine with @myTooq having those 5 packs cover a 3 month period which contains access to previous tickets is perfect for me.
EDIT: To combine with @myTooq having those 5 packs cover a 3 month period which contains access to previous tickets is perfect for me.
It all sounds good to me (especially being explicit that support is for a limited amount of time).
In terms of having the "one support forum" either be public or private, I very much prefer if they are public... both as a customer (it lets me see what the support is like on an addon, which can definitely impact whether or not I purchase it) and also as an addon developer (both because it cuts down on future support requests because prior issues that people have had can be googled on and found, and also because it makes me look better if I provide good support... which I think should be encouraged).
And thanks for not raising the marketplace split to 60/40 :)
-Jordan Lev
In terms of having the "one support forum" either be public or private, I very much prefer if they are public... both as a customer (it lets me see what the support is like on an addon, which can definitely impact whether or not I purchase it) and also as an addon developer (both because it cuts down on future support requests because prior issues that people have had can be googled on and found, and also because it makes me look better if I provide good support... which I think should be encouraged).
And thanks for not raising the marketplace split to 60/40 :)
-Jordan Lev
This is the right direction to go in...
I've personally always liked that consumers have been able to search support archives to see if they can self-help themselves. I've personally found an answer to a question I've had and did not have to send a message to the developer because of it.
I 110% agree with you Franz that the support timeframe should be limited and additional payment should be made by customers for support after 30 days. That would make a MAJOR difference to my bottom line as I get at least between 5-12 enquiries per day which usually require more than 1 line to answer. As such, that time could be better spent developing new add-ons & themes that will actually make money.
Since we got tired of answering the same questions over and over I ended up creating a Knowledge Base on my website that we refer customers to frequently for repetitive questions. I'd prefer to have that kind of info stored on the C5.org site. Something a bit more fleshed out than the current 1 page to fit all the possible FAQs on. This would probably put customers minds at ease to get answers before they have to bother the developer. But maybe limit free access to the FAQ for 12 months (from the date of purchase), in addition to 30 days of direct support.
I'd be happy if a customer paid a percentage of the original price to get another 30 days of support (like 75%) so they feel like they're getting better value. And perhaps allow the developer to adjust that percentage globally for themselves so they can choose how much to charge their customers.
Like the 5-pack bulk pricing, doing the same for support also makes sense. Eg. by another 30 days support for $20 or get 60 days support for $30. That kind of this can up-sell customers and generate more revenue. Like the 5-pack bulk pricing, this could be overridden either on the developer level or on a product-by-product basis.
I'd also love to see better cross-selling for other items by the same developer on the actual marketplace page. At the moment it's quite hidden - behind their username - which isn't the most intuitive way for new customers.
This whole issue should really be finalised before 5.7 is publicly released because I can imagine the mountain on support queries that will come through from day 1 and I'd love to avoid that.
Lastly, thank you for capping the increase for the marketplace slice at 70/30 - a very smart move for developers and I'm sure you'll make more money in the long-run from that.
Since we got tired of answering the same questions over and over I ended up creating a Knowledge Base on my website that we refer customers to frequently for repetitive questions. I'd prefer to have that kind of info stored on the C5.org site. Something a bit more fleshed out than the current 1 page to fit all the possible FAQs on. This would probably put customers minds at ease to get answers before they have to bother the developer. But maybe limit free access to the FAQ for 12 months (from the date of purchase), in addition to 30 days of direct support.
I'd be happy if a customer paid a percentage of the original price to get another 30 days of support (like 75%) so they feel like they're getting better value. And perhaps allow the developer to adjust that percentage globally for themselves so they can choose how much to charge their customers.
Like the 5-pack bulk pricing, doing the same for support also makes sense. Eg. by another 30 days support for $20 or get 60 days support for $30. That kind of this can up-sell customers and generate more revenue. Like the 5-pack bulk pricing, this could be overridden either on the developer level or on a product-by-product basis.
I'd also love to see better cross-selling for other items by the same developer on the actual marketplace page. At the moment it's quite hidden - behind their username - which isn't the most intuitive way for new customers.
This whole issue should really be finalised before 5.7 is publicly released because I can imagine the mountain on support queries that will come through from day 1 and I'd love to avoid that.
Lastly, thank you for capping the increase for the marketplace slice at 70/30 - a very smart move for developers and I'm sure you'll make more money in the long-run from that.
You might consider 60 days for support and licensing rather than 30/60, I think it would be easier, not make a difference to developers and will sound better to the buyer.
I'd like to see the help forum be read only to everyone, not how it is now only to people who have purchased the add on.
But I still think if it's not licensed it shouldn't work!
I'd like to see the help forum be read only to everyone, not how it is now only to people who have purchased the add on.
But I still think if it's not licensed it shouldn't work!
Well it would be perfect if any developer can choose the support timeframe themselves. Let's say I want to support my products (if we talk about the updates) for a year time for the price i sell. Why shall i limit this to 30/60 days in my case?
Also it would be good if we can price the support for each product ourselves and sell it as additional item for the product. So customers buying initial license can choose extended support and upgrade options as well or buy product support/upgrades afterwards.
Just something similar like what is done here for example http://ecommerce.aheadworks.com/magento-extensions/follow-up-email....
Also it is not very much convenient to have many support questions going through the PM messages so here I would think of letting customers ask "general" or "presales" type of questions via support tickets as well without a need to buy - so the idea offered is great!
Also it would be good if we can price the support for each product ourselves and sell it as additional item for the product. So customers buying initial license can choose extended support and upgrade options as well or buy product support/upgrades afterwards.
Just something similar like what is done here for example http://ecommerce.aheadworks.com/magento-extensions/follow-up-email....
Also it is not very much convenient to have many support questions going through the PM messages so here I would think of letting customers ask "general" or "presales" type of questions via support tickets as well without a need to buy - so the idea offered is great!
I have a few points to make - coming from the perspective of someone with a very low volume addon in the marketplace and as an active developer / user of other addons.
1. The main thing I love over Concrete5 compared with Wordpress is that the addons work. With Wordpress you can try 5 different plugins before you get one that works and when you are billing out your time it's easy to spend $200 worth of time trying to get a free addon that actually works. This is where the main value is to the buyer. I also like that the licenses are reasonably priced and uncomplicated. I would rather see the price go up a bit across the board than have the licenses get more complicated.
2. People have to be able to upgrade to the latest version of C5 regularly. You can't encourage an ecosystem where people stay on old C5 versions becuase they don't want to pay $10 for an image gallery addon. It needs to stay easy for people to upgrade, otherwise it's the poor old web developer and web host who have to clear out all the haxx that get in from outdated OS software.
3. I'd be happy with 30-60 days support but I feel that the support period should not start until the site hits the production server. Personally I'd feel slighted if I bought an addon and the support period expired before I even got to use the thing - especially if I was reporting actual bugs rather than PEBKAC errors. Many sites I work on can stay in dev mode for 6 months before the client has their content ready to go.
4. I think upgrades should be separate from support. If you have a customer who never needs support, let them have the upgrades. If they want support, they can pay for it outside the free period.
5. License lockdown is fine, it should be bound to the site rather than the developer.. There needs to be a way to change the license to a new domain when a site changes domain (as opposed to transferring the license to a different site).
6. 30/70 sounds fair.
7. I like support forums being public so others can search for existing issues, that way you get an answer in minutes rather than a day and no effort on the part of the dev.. And you can judge the dev on the quality/speed of their support too.
Great to see this discussion happening. Keep up the good work.
1. The main thing I love over Concrete5 compared with Wordpress is that the addons work. With Wordpress you can try 5 different plugins before you get one that works and when you are billing out your time it's easy to spend $200 worth of time trying to get a free addon that actually works. This is where the main value is to the buyer. I also like that the licenses are reasonably priced and uncomplicated. I would rather see the price go up a bit across the board than have the licenses get more complicated.
2. People have to be able to upgrade to the latest version of C5 regularly. You can't encourage an ecosystem where people stay on old C5 versions becuase they don't want to pay $10 for an image gallery addon. It needs to stay easy for people to upgrade, otherwise it's the poor old web developer and web host who have to clear out all the haxx that get in from outdated OS software.
3. I'd be happy with 30-60 days support but I feel that the support period should not start until the site hits the production server. Personally I'd feel slighted if I bought an addon and the support period expired before I even got to use the thing - especially if I was reporting actual bugs rather than PEBKAC errors. Many sites I work on can stay in dev mode for 6 months before the client has their content ready to go.
4. I think upgrades should be separate from support. If you have a customer who never needs support, let them have the upgrades. If they want support, they can pay for it outside the free period.
5. License lockdown is fine, it should be bound to the site rather than the developer.. There needs to be a way to change the license to a new domain when a site changes domain (as opposed to transferring the license to a different site).
6. 30/70 sounds fair.
7. I like support forums being public so others can search for existing issues, that way you get an answer in minutes rather than a day and no effort on the part of the dev.. And you can judge the dev on the quality/speed of their support too.
Great to see this discussion happening. Keep up the good work.
Thanks for the update Franz.
Retaining the 30/70 split is great news and gives us huge encouragement that the marketplace can still thrive for all. Thanks guys, looking forward to pushing on with some exciting new development for 5.7.
Support - I am not too concerned as to whether the support policy runs for 30 or 60 days; however I think the expectation levels of customers needs lowering in some cases. Whilst we are all for helping the community/customers where we can and we pride ourselves on efficient and timely support - requests such as 'give me the code to build some unrealistic feature in to your product or my client will not pay me and I can not use your theme' is way outside of what we can maintain. It does not make sense commercially or for the community as a whole.
We see it as support should include; getting set up, trouble using any features and bugs. What do you guys think? The amount of time we waste trying to come up with warm and fuzzy replies on the back of these type of support requests, in an attempt to not offend or upset the customer, is time better spent developing new products for the marketplace, helping out in the forums or testing in the PRB.
Perhaps a generic reply to these type of message 'Thanks for your message - unfortunately this type of request is not supported within the regular support policy...... please either submit your question to the general forums or ask the developer to quote on the bespoke work...'
Obviously we can reply with whatever we like but having some consistency across the marketplace may better appease potential unhappy customers.
Cheers
Andy
Retaining the 30/70 split is great news and gives us huge encouragement that the marketplace can still thrive for all. Thanks guys, looking forward to pushing on with some exciting new development for 5.7.
Support - I am not too concerned as to whether the support policy runs for 30 or 60 days; however I think the expectation levels of customers needs lowering in some cases. Whilst we are all for helping the community/customers where we can and we pride ourselves on efficient and timely support - requests such as 'give me the code to build some unrealistic feature in to your product or my client will not pay me and I can not use your theme' is way outside of what we can maintain. It does not make sense commercially or for the community as a whole.
We see it as support should include; getting set up, trouble using any features and bugs. What do you guys think? The amount of time we waste trying to come up with warm and fuzzy replies on the back of these type of support requests, in an attempt to not offend or upset the customer, is time better spent developing new products for the marketplace, helping out in the forums or testing in the PRB.
Perhaps a generic reply to these type of message 'Thanks for your message - unfortunately this type of request is not supported within the regular support policy...... please either submit your question to the general forums or ask the developer to quote on the bespoke work...'
Obviously we can reply with whatever we like but having some consistency across the marketplace may better appease potential unhappy customers.
Cheers
Andy
Well done on sticking with the 30% commission and stating long term commitment to it. The uncertainty of the position of developers has been harmful to the community and now I can see the overall atmosphere becoming positive again. .
Good riddance to the project pages. Having yesterday spent way too long mapping licenses I had in stock or from my own addons onto a new site, the whole process of doing that through the project page was ridiculously slow, fiddly and lethargic.
As others have said, there needs to be a way of delaying the start of a support period until an addon is installed or used. If someone buys a bundle or 5-pack, they may be just stocking up on something that could be useful, keeping some of the purchase aside for a future project, or buying all they need for a big project up-front. They need to be able to split such purchases between sites.
While I like the concept of long term upgrade pricing for addons and themes, I think it also places a strong obligation on the core team to ensure that future versions of concrete5 maintain compatibility with older versions of addons and themes. Either that, or you will be pulled into long term support for multiple versions of the core. As a developer, I anticipate getting more reviews giving less than 5* driven by users frustrated about having to pay for support when they notice a glitch at >=31 days.
[EDIT - I like @formigo's idea of a generic 'not eligible for support' reply we can activate quickly by clicking a button]
While implementing support pricing, you could also have an optional model of zero price for a marketplace item, but pay as soon as you ask a question. The availability of such a model would facilitate greater use of 3rd party code that is GPL licensed in addons.
I like the combined question/discussion/support/bug report workflow. I would also like to be able to re-classify posts made if the user clicks the wrong box. When a support item is closed, I would like it to be blocked forever from re-opening. Many users, once they have started a support request, continue to use that thread for completely separate problems because its easier than starting a new support request.
There will also be users who send a PM rather than use the support mechanism because they just want a friendly chat and to ask a bit of advice on the way. Maybe all this redevelopment of the support mechanism will just move the same old problem to a different place.
In general, all question/discussion/support/bug report posts should be publicly visible. Making them all visible and easier to search would cut down on the number or repetitions of the same or similar questions and let new customers see in advance how responsive support is. Nevertheless, there are also customers with legitimate reasons for wanting to post a question in confidence. So perhaps we can leave it up to the customer to tick a box if they want the post/thread to be private, and allow developers to override that later (as with the categories).
Good riddance to the project pages. Having yesterday spent way too long mapping licenses I had in stock or from my own addons onto a new site, the whole process of doing that through the project page was ridiculously slow, fiddly and lethargic.
As others have said, there needs to be a way of delaying the start of a support period until an addon is installed or used. If someone buys a bundle or 5-pack, they may be just stocking up on something that could be useful, keeping some of the purchase aside for a future project, or buying all they need for a big project up-front. They need to be able to split such purchases between sites.
While I like the concept of long term upgrade pricing for addons and themes, I think it also places a strong obligation on the core team to ensure that future versions of concrete5 maintain compatibility with older versions of addons and themes. Either that, or you will be pulled into long term support for multiple versions of the core. As a developer, I anticipate getting more reviews giving less than 5* driven by users frustrated about having to pay for support when they notice a glitch at >=31 days.
[EDIT - I like @formigo's idea of a generic 'not eligible for support' reply we can activate quickly by clicking a button]
While implementing support pricing, you could also have an optional model of zero price for a marketplace item, but pay as soon as you ask a question. The availability of such a model would facilitate greater use of 3rd party code that is GPL licensed in addons.
I like the combined question/discussion/support/bug report workflow. I would also like to be able to re-classify posts made if the user clicks the wrong box. When a support item is closed, I would like it to be blocked forever from re-opening. Many users, once they have started a support request, continue to use that thread for completely separate problems because its easier than starting a new support request.
There will also be users who send a PM rather than use the support mechanism because they just want a friendly chat and to ask a bit of advice on the way. Maybe all this redevelopment of the support mechanism will just move the same old problem to a different place.
In general, all question/discussion/support/bug report posts should be publicly visible. Making them all visible and easier to search would cut down on the number or repetitions of the same or similar questions and let new customers see in advance how responsive support is. Nevertheless, there are also customers with legitimate reasons for wanting to post a question in confidence. So perhaps we can leave it up to the customer to tick a box if they want the post/thread to be private, and allow developers to override that later (as with the categories).
+1 !
Great to see some progress on these matters!
A bit of repetition but to add my own points here:
Likes:
- 30/70 split
- Paid long-term support
- Ability to sell upgrades (e.g. a completely new v2.0)
- Project page clearance
- Locking the license to only one project
Dislikes:
- Users not being able to update add-ons after they update the core (breaks one of the major promises of the c5 marketplace: the add-ons work, no matter what)
- Encouraging of closed discussions instead of open discussions (if I understood the points correctly about the "Get Help" button, not sure if I did)
- Joining of support and general forums into one place
For the paid support, there should be a way for the customers not to feel ripped off if the support does not cover their question. E.g. when asking a new feature to the system. Should there be a button "not covered by support, refund support ticket" for instance?
For the paid upgrades, I like this idea very much. In my opinion it should work somewhat similarly to adding a completely new add-on to the marketplace. I.e. version 1.0 will continue its existence as a supported version for 5.6 and version 2.0 will continue its development as a completely "new add-on" for concrete 5.7 that gets all the shiny new features. And there isn't an upgrade path from 1 => 2 without buying a new license.
The above would also be in line of the Franz's "Software 101" education.
For support, as few have already said here, it would be lot better to provide as much open information to the customers as possible in my opinion. This might lead to some people not needing the support at all. And those who need would pay for it (after the free period). I also hope developers can price their support time individually.
For the "get help" button, I really like the current structure of a separate support forum and a general forum. While the general forum is not usually utilized as much as it could by the marketplace customers, I have always tried to point out customers to point their general questions there so that they would be public for all. Also, there have been some cases that the customers have done something that is beyond our support and they have posted their process results to the general forum. Also, if you look at other paid software product out there, there are usually "community forums" and "support channel" as separate sections. Would it be better to make the split between these two clearer to the customer? Or maybe the priced support strategy would already help in that...
I would also like (as I mentioned earlier in the PRB/marketplace improval thread as well and as pointed by @formigo in this thread) if there was possibility to create more than a single documentation page. E.g. "setting up", "FAQs", "Tutorial Videos", etc. up to the add-on maintainer to decide which pages to add there.
I share the worries pointed above by @Johnthefish about upgrades, reviews from upset customers who could not get support after 30 days and up-front purchases regarding these suggested policies.
For support policies, I don't like forcing the required support to cover "set up" in all cases (a point by @formigo above). I can understand that is required for the easy-level add-ons but some expert-level add-ons might need e.g. server setup or something not related to the add-on which is unreasonable to ask for the price of the add-on. We are also planning to release a quite complicated add-on to the marketplace with great documentation but we wouldn't want to end up spending hours to help everyone to set it up if they are too busy to read the docs. This is also my experience of some support requests, just not reading the docs because it's "easier" to as a question.
Compare this to a situation where anyone can download and install Magento for free but getting it set up and working requires you to know the system or get familiar with the docs or hire someone to help you out. And in the concrete5 marketplace case, the natural path would be to ask support from the original developer. It would be actually great if it was possible for the customers to post support threads for free e.g. in case they notice a bug in the system but if it goes beyond the add-on not working properly, they would have to pay for it. I'm just not sure how easy something like that would be to built into the suggested support payment strategy.
From my own and our company's perspective, this would be the way we would go with most add-ons if it was possible: did you notice a bug in the system? - Feel free to report it for free and we'll fix it for free. Do you have trouble understanding the setting at the X page of the dashboard and how to get it to work? - Read our docs or pay us to help you out.
While I stated the "locking of the license" in the likes part, I'd also like to point out that we own some licenses that we only use for internal development. E.g. development of our own add-ons and binding them into 3rd party add-ons. It would be a shame if we needed to buy a new license every 30 days for any bug fixes that might be caused by an update of a 3rd party add-on.
And we also own some licenses that we never needed (e.g. karma prizes). Some of them might still come handy in some future project but I guess this falls into the same "upfront purchases" category pointed before.
But, I wouldn't want or need to get any free support for the upfront purchases or development licenses after a long time the license was granted to us. It would just be nice to have the possibility to use them if needed.
A bit of repetition but to add my own points here:
Likes:
- 30/70 split
- Paid long-term support
- Ability to sell upgrades (e.g. a completely new v2.0)
- Project page clearance
- Locking the license to only one project
Dislikes:
- Users not being able to update add-ons after they update the core (breaks one of the major promises of the c5 marketplace: the add-ons work, no matter what)
- Encouraging of closed discussions instead of open discussions (if I understood the points correctly about the "Get Help" button, not sure if I did)
- Joining of support and general forums into one place
For the paid support, there should be a way for the customers not to feel ripped off if the support does not cover their question. E.g. when asking a new feature to the system. Should there be a button "not covered by support, refund support ticket" for instance?
For the paid upgrades, I like this idea very much. In my opinion it should work somewhat similarly to adding a completely new add-on to the marketplace. I.e. version 1.0 will continue its existence as a supported version for 5.6 and version 2.0 will continue its development as a completely "new add-on" for concrete 5.7 that gets all the shiny new features. And there isn't an upgrade path from 1 => 2 without buying a new license.
The above would also be in line of the Franz's "Software 101" education.
For support, as few have already said here, it would be lot better to provide as much open information to the customers as possible in my opinion. This might lead to some people not needing the support at all. And those who need would pay for it (after the free period). I also hope developers can price their support time individually.
For the "get help" button, I really like the current structure of a separate support forum and a general forum. While the general forum is not usually utilized as much as it could by the marketplace customers, I have always tried to point out customers to point their general questions there so that they would be public for all. Also, there have been some cases that the customers have done something that is beyond our support and they have posted their process results to the general forum. Also, if you look at other paid software product out there, there are usually "community forums" and "support channel" as separate sections. Would it be better to make the split between these two clearer to the customer? Or maybe the priced support strategy would already help in that...
I would also like (as I mentioned earlier in the PRB/marketplace improval thread as well and as pointed by @formigo in this thread) if there was possibility to create more than a single documentation page. E.g. "setting up", "FAQs", "Tutorial Videos", etc. up to the add-on maintainer to decide which pages to add there.
I share the worries pointed above by @Johnthefish about upgrades, reviews from upset customers who could not get support after 30 days and up-front purchases regarding these suggested policies.
For support policies, I don't like forcing the required support to cover "set up" in all cases (a point by @formigo above). I can understand that is required for the easy-level add-ons but some expert-level add-ons might need e.g. server setup or something not related to the add-on which is unreasonable to ask for the price of the add-on. We are also planning to release a quite complicated add-on to the marketplace with great documentation but we wouldn't want to end up spending hours to help everyone to set it up if they are too busy to read the docs. This is also my experience of some support requests, just not reading the docs because it's "easier" to as a question.
Compare this to a situation where anyone can download and install Magento for free but getting it set up and working requires you to know the system or get familiar with the docs or hire someone to help you out. And in the concrete5 marketplace case, the natural path would be to ask support from the original developer. It would be actually great if it was possible for the customers to post support threads for free e.g. in case they notice a bug in the system but if it goes beyond the add-on not working properly, they would have to pay for it. I'm just not sure how easy something like that would be to built into the suggested support payment strategy.
From my own and our company's perspective, this would be the way we would go with most add-ons if it was possible: did you notice a bug in the system? - Feel free to report it for free and we'll fix it for free. Do you have trouble understanding the setting at the X page of the dashboard and how to get it to work? - Read our docs or pay us to help you out.
While I stated the "locking of the license" in the likes part, I'd also like to point out that we own some licenses that we only use for internal development. E.g. development of our own add-ons and binding them into 3rd party add-ons. It would be a shame if we needed to buy a new license every 30 days for any bug fixes that might be caused by an update of a 3rd party add-on.
And we also own some licenses that we never needed (e.g. karma prizes). Some of them might still come handy in some future project but I guess this falls into the same "upfront purchases" category pointed before.
But, I wouldn't want or need to get any free support for the upfront purchases or development licenses after a long time the license was granted to us. It would just be nice to have the possibility to use them if needed.
This is a very important discussion and people here are making very good points.
The most important thing about buying add-ons in concrete5: quality. As someone else pointed out, the most important thing which makes it easy to sell the idea of paid add-ons for a customer is the quality of the add-ons.
If a customer needs some feature on their site and I would give them a price estimate what it would cost for me to built something like that or find a similar add-on for example in WordPress, it is important that I can sell the idea of purchasing an add-on.
To this date it has been very easy because the quality of add-ons in concrete5 is very high. I have rarely found an add-on which does not work at all or is broken somehow. And while I have had these also, I have always gotten support from the developers.
This needs to stay and it is very important for small companies which might not get customers with large budgets.
I am all for the idea that support is limited to for example 30 or 60 days. But I think customers should not need to buy the whole package again. Maybe they could just buy an extended support package for some percent of the original price. I think this would also help the sales of support packages. Some customers might think that buying the product again is a rip off. But if they would get a discount for just buying a support package, I think it would be easier to sell.
Also there could be upgrade packages for larger version jumps in add-on. I think for example an upgrade from 1.1.1 to 1.1.2 in a add-on should not be paid. But an upgrade from 1.1.1 to 2.0 could be.
One example: I bought one licence to a PHP product outside of concrete5. It had 6 months of free upgrades. After six months there came a new version and we noticed that the whole product was broken in Internet Explorer 11. Now our update period had ended and we had to purchase the whole product again just to fix this bug in the product. I think that is very bad.
About the public market place. I think it's very good that the add-ons have as much public information as possible. When browsing through different add-ons and trying to decide which add-on I am going to buy, browsing through the support requests and all the information about the add-on is very important to me when making a decision if I am going to buy the add-on for a client.
If am going to sell the idea of buying an add-on to a customer, it is very important that they get a good image of the add-on. And if I have as much information as possible about the add-on, it makes it easier to decide which add-on suits the customer the best.
Also the public support is important because not all add-ons have an active developer who gives support for the add-on. And you still might find help to your problem from the public discussion even though the developer is not active anymore.
This is also important because not many competing products have paid add-ons. For example many clients know WordPress and they know that you can get add-ons for free. So it is important we can make valid points why it is better to pay for an add-on than pick WordPress and get add-ons for free.
To this day I haven't had one single add-on where I would have needed to ask for a refund. But if I would make a bad decision about an add-on, and it wouldn't do what I promised for a client, I of course would have to ask for a refund. And these I think we should avoid at all cost.
I am not sure about transfering licences. I can understand that it would be good to lock down licences to one site. But I have had situations where it was necessary to transfer license. One example is that I was developing a site and made heavy changes to it. Then the site started to act up. I decided to install a second version of concrete5 and transferred the license to this clean install. I could test the add-on again on a clean install and found that it was acting the same in a clean install of concrete5 as it was in my old installation. So I could just transfer the license back to the main development site and continue working.
One thing I would like to also raise as a discussion is that could there be a possibility to install add-ons for free as demos for example for a day or something like that? Many add-ons offer demos but not all of them. And not all add-ons offer enough screenshots for you to make a decision of how well the add-on works in your case. It would be wonderful if you could install a demo version of an add-on for example for a short period time and if you like the add-on, you could just buy the whole license for it. This would be also very good for the non-technical clients where you could demo the add-on to them before asking if I can buy the add-on.
The most important thing about buying add-ons in concrete5: quality. As someone else pointed out, the most important thing which makes it easy to sell the idea of paid add-ons for a customer is the quality of the add-ons.
If a customer needs some feature on their site and I would give them a price estimate what it would cost for me to built something like that or find a similar add-on for example in WordPress, it is important that I can sell the idea of purchasing an add-on.
To this date it has been very easy because the quality of add-ons in concrete5 is very high. I have rarely found an add-on which does not work at all or is broken somehow. And while I have had these also, I have always gotten support from the developers.
This needs to stay and it is very important for small companies which might not get customers with large budgets.
I am all for the idea that support is limited to for example 30 or 60 days. But I think customers should not need to buy the whole package again. Maybe they could just buy an extended support package for some percent of the original price. I think this would also help the sales of support packages. Some customers might think that buying the product again is a rip off. But if they would get a discount for just buying a support package, I think it would be easier to sell.
Also there could be upgrade packages for larger version jumps in add-on. I think for example an upgrade from 1.1.1 to 1.1.2 in a add-on should not be paid. But an upgrade from 1.1.1 to 2.0 could be.
One example: I bought one licence to a PHP product outside of concrete5. It had 6 months of free upgrades. After six months there came a new version and we noticed that the whole product was broken in Internet Explorer 11. Now our update period had ended and we had to purchase the whole product again just to fix this bug in the product. I think that is very bad.
About the public market place. I think it's very good that the add-ons have as much public information as possible. When browsing through different add-ons and trying to decide which add-on I am going to buy, browsing through the support requests and all the information about the add-on is very important to me when making a decision if I am going to buy the add-on for a client.
If am going to sell the idea of buying an add-on to a customer, it is very important that they get a good image of the add-on. And if I have as much information as possible about the add-on, it makes it easier to decide which add-on suits the customer the best.
Also the public support is important because not all add-ons have an active developer who gives support for the add-on. And you still might find help to your problem from the public discussion even though the developer is not active anymore.
This is also important because not many competing products have paid add-ons. For example many clients know WordPress and they know that you can get add-ons for free. So it is important we can make valid points why it is better to pay for an add-on than pick WordPress and get add-ons for free.
To this day I haven't had one single add-on where I would have needed to ask for a refund. But if I would make a bad decision about an add-on, and it wouldn't do what I promised for a client, I of course would have to ask for a refund. And these I think we should avoid at all cost.
I am not sure about transfering licences. I can understand that it would be good to lock down licences to one site. But I have had situations where it was necessary to transfer license. One example is that I was developing a site and made heavy changes to it. Then the site started to act up. I decided to install a second version of concrete5 and transferred the license to this clean install. I could test the add-on again on a clean install and found that it was acting the same in a clean install of concrete5 as it was in my old installation. So I could just transfer the license back to the main development site and continue working.
One thing I would like to also raise as a discussion is that could there be a possibility to install add-ons for free as demos for example for a day or something like that? Many add-ons offer demos but not all of them. And not all add-ons offer enough screenshots for you to make a decision of how well the add-on works in your case. It would be wonderful if you could install a demo version of an add-on for example for a short period time and if you like the add-on, you could just buy the whole license for it. This would be also very good for the non-technical clients where you could demo the add-on to them before asking if I can buy the add-on.
I don't think unlimited free upgrades for customers is a good idea. It's not the typical arrangement for "commercial" software. The customer pays for the software to do a job, and it does just that. As the environment changes (c5 core changes) new features might become available, some things could break, but it's not the add-on developer controlling that. He has to do more work, to make sure things run smoothly so there should be compensation for that.
I like the idea of a fixed period (like 6 months or so), but allowing developers to choose their own terms will give more flexibility in the marketplace and customers can choose what will work for them better. Some developers buy an add-on to save them time, but will customise it anyway. So they don't care about long support periods. But a newbie does care that they can get free upgrades in the future.
I like the idea of a fixed period (like 6 months or so), but allowing developers to choose their own terms will give more flexibility in the marketplace and customers can choose what will work for them better. Some developers buy an add-on to save them time, but will customise it anyway. So they don't care about long support periods. But a newbie does care that they can get free upgrades in the future.
I've just been scanning these replies which all look very thoughtful and will get a thorough read in a bit. That being said, I'd like to push for consistency in policy for the benefit of our customers. It'd be healthier for everyone for us to find times we can agree to as a "marketplace" rather than defaulting to 'everyone choose your own' as an open source inspired compromise.
just a quick thought to help drive this great conversation...
—
Sent from Mailbox for iPad
just a quick thought to help drive this great conversation...
—
Sent from Mailbox for iPad
I agree with @frz at the end of the day it should one consistent policy.
A lot of what I'm seeing here seems to be two different issues.
1. Selling the source code
- Paid Upgrades
- Length of time for updates
- Length and method of access to download
- Assigning to sites(change or not)
- Recurring or one time fee
2. Supporting the customers
- Public or private support threads
- Length of time for support
- Level of support(setup, bug fixes, customization, code modification)
- Per support ticket or time period(30/60 days)
Not sure what that means, but figured a quick summary might help.
A lot of what I'm seeing here seems to be two different issues.
1. Selling the source code
- Paid Upgrades
- Length of time for updates
- Length and method of access to download
- Assigning to sites(change or not)
- Recurring or one time fee
2. Supporting the customers
- Public or private support threads
- Length of time for support
- Level of support(setup, bug fixes, customization, code modification)
- Per support ticket or time period(30/60 days)
Not sure what that means, but figured a quick summary might help.
RE: @jb1.
Coming back to the two models for software that @frz pointed out: recurring fee or one time fee. I don't think recurring fee is very good for a product you get a somewhat "physical" copy for your use although it would make more money to the add-on vendors, including us. As @frz pointed out, you only pay once e.g. for Windows 8 and get free updates to it (e.g. security and bug fixes). And older customers are able to buy "upgrade package" for upgrading Windows 7 to Windows 8.
I think monthly/recurring fees fit into the service model (i.e. SaaS) but not that well to licensed products. But I'm all in for the free support for a limited time + paid support after that, that's very reasonable as we're not talking about adding any fees to the the licensed product itself.
I think this is the closest to the model I see as beneficial for everyone (thinking about the customer as well).
Like if you sell software/devices which can handle some specific media formats or contain chips that implement functionality that is under patents, you pay a fixed fee by the device to license these "features" to your software/device. I'd see this as a closer reference to the marketplace software than software under a recurring fee. People should be able to keep their sites secure and up-to-date without paying any further fees. I believe it is not healthy that if there is a major security vulnerability fixed in a concrete5 update, people upgrading to that version should re-license all their add-ons on that site.
We don't mind supporting our add-ons for free if there are normal upgrades to the core, e.g. 5.6.1 => 5.6.2. But once it's a bigger overhaul which really requires more work (e.g. 5.6 => 5.7), then it's reasonable to ask a payment for it.
Coming back to the two models for software that @frz pointed out: recurring fee or one time fee. I don't think recurring fee is very good for a product you get a somewhat "physical" copy for your use although it would make more money to the add-on vendors, including us. As @frz pointed out, you only pay once e.g. for Windows 8 and get free updates to it (e.g. security and bug fixes). And older customers are able to buy "upgrade package" for upgrading Windows 7 to Windows 8.
I think monthly/recurring fees fit into the service model (i.e. SaaS) but not that well to licensed products. But I'm all in for the free support for a limited time + paid support after that, that's very reasonable as we're not talking about adding any fees to the the licensed product itself.
I think this is the closest to the model I see as beneficial for everyone (thinking about the customer as well).
Like if you sell software/devices which can handle some specific media formats or contain chips that implement functionality that is under patents, you pay a fixed fee by the device to license these "features" to your software/device. I'd see this as a closer reference to the marketplace software than software under a recurring fee. People should be able to keep their sites secure and up-to-date without paying any further fees. I believe it is not healthy that if there is a major security vulnerability fixed in a concrete5 update, people upgrading to that version should re-license all their add-ons on that site.
We don't mind supporting our add-ons for free if there are normal upgrades to the core, e.g. 5.6.1 => 5.6.2. But once it's a bigger overhaul which really requires more work (e.g. 5.6 => 5.7), then it's reasonable to ask a payment for it.
Hey all,
just wanted to jump in on this...
Seems like everyone is in favor of keeping discussions public, which I would agree is a good thing.
Firstly thinking about support: how about a general gateway button "Contact the developer", which gives a drop down: Feedback; Feature Request; Technical support; Pre sales (not necessarily an exhaustive list). All messages appear in a list for the dev to review. The dev can then either re-categorize or approve a request (or maybe mark as Spam) at which point it is dropped into the correct place. If the user has selected Technical support, then this is where the site would check if they have signed in and whether they qualify for support (in a free period, has paid credits, recently bought me a beer, whatever...)
Regarding the upgrades, I reckon I would like to see that option made available when uploading new versions. So with each new version of a package that I upload, there would be a purchase cost and an upgrade cost. If I don't enter any values, then it is a free upgrade, provided the user has the last paid for version. I would also like users to be able to choose which version they purchase based on this. So - for instance:
ForceSSL V1.0 is free
ForceSSL V1.1 is free
ForceSSL V2.0 is $30
ForceSSL V3.0 is $30 to buy or $15 to upgrade to if you already have V2.0 and only works on C5.7
A user running C5.6 could opt to either download the free V1.1 or buy V2.0. Make sense? Too complicated? It works well in my head ;)
I like free support starting on install date. Go live date would be almost impossible to make work I reckon. And limited to 30 or 60 days is fine. I really can't think of a universal way to charge for support. I think we need it - just don't have any bright ideas on that :)
JB
P.S. ForceSSL is free and will always be free. It was just an example. Can't believe someone actually asked me that based on this thread already! :)
just wanted to jump in on this...
Seems like everyone is in favor of keeping discussions public, which I would agree is a good thing.
Firstly thinking about support: how about a general gateway button "Contact the developer", which gives a drop down: Feedback; Feature Request; Technical support; Pre sales (not necessarily an exhaustive list). All messages appear in a list for the dev to review. The dev can then either re-categorize or approve a request (or maybe mark as Spam) at which point it is dropped into the correct place. If the user has selected Technical support, then this is where the site would check if they have signed in and whether they qualify for support (in a free period, has paid credits, recently bought me a beer, whatever...)
Regarding the upgrades, I reckon I would like to see that option made available when uploading new versions. So with each new version of a package that I upload, there would be a purchase cost and an upgrade cost. If I don't enter any values, then it is a free upgrade, provided the user has the last paid for version. I would also like users to be able to choose which version they purchase based on this. So - for instance:
ForceSSL V1.0 is free
ForceSSL V1.1 is free
ForceSSL V2.0 is $30
ForceSSL V3.0 is $30 to buy or $15 to upgrade to if you already have V2.0 and only works on C5.7
A user running C5.6 could opt to either download the free V1.1 or buy V2.0. Make sense? Too complicated? It works well in my head ;)
I like free support starting on install date. Go live date would be almost impossible to make work I reckon. And limited to 30 or 60 days is fine. I really can't think of a universal way to charge for support. I think we need it - just don't have any bright ideas on that :)
JB
P.S. ForceSSL is free and will always be free. It was just an example. Can't believe someone actually asked me that based on this thread already! :)
I've read through this thread and I agree with everything Franz has stated. I do believe that you should reasonably be expected to provide support for your current package version with your sold license at the time they installed it, on the latest version of concrete5 that the add-on supports. If they want a refund then it's nice that there's no longer a penalty, I wasn't sure if that was entirely legal anyways.
Right now the burden effectively becomes sell once, support until the end of time which honestly isn't very appealing to me, and caused me to pull one of the top 1-30 add-ons by gross revenue(guessing here, but it was north of $25k) of all time from the marketplace, it simply wasn't worth it. For every $20 it was adding on an additional support burden and promise for forever to support it and my time was simply better spent elsewhere.
I'm also not looking forward to when people upgrade to 5.7 and these add-ons that they purchased years ago no longer work. I'm sure Frz is thinking the exact same thing.
That said, I think 5.7 looks very promising with the routing stuff and I really commend Andrew for taking the time to bring it modern.
I'm excited by this post and I honestly look forward to bringing new packages to the marketplace, and with a semblance of scope on support burden I'm more inclined to release things there again.
Things need changed and I think Franz is doing the right thing.
Right now the burden effectively becomes sell once, support until the end of time which honestly isn't very appealing to me, and caused me to pull one of the top 1-30 add-ons by gross revenue(guessing here, but it was north of $25k) of all time from the marketplace, it simply wasn't worth it. For every $20 it was adding on an additional support burden and promise for forever to support it and my time was simply better spent elsewhere.
I'm also not looking forward to when people upgrade to 5.7 and these add-ons that they purchased years ago no longer work. I'm sure Frz is thinking the exact same thing.
That said, I think 5.7 looks very promising with the routing stuff and I really commend Andrew for taking the time to bring it modern.
I'm excited by this post and I honestly look forward to bringing new packages to the marketplace, and with a semblance of scope on support burden I'm more inclined to release things there again.
Things need changed and I think Franz is doing the right thing.
Here's a perspective from a prospective Concrete5 newcomer:
We're sold on the potential of Concrete5.7.
We're told Concrete5.7 is not quite yet ready for production.
If fact no one knows for sure even when 5.7 will be ready for final release.
We were encouraged to start developing in 5.6.
We understand transporting a 3000 page site will take several months.
We need to to purchase a template and several key add-ons for a proof of concept and testing for each page type.
Best case scenario if every thing goes smoothly with the 30/60 day policy that has been suggested:
We pay for templates and multiple ad-ons twice, once now and a second time once 5.7 is finally released, after porting content from 5.6 to 5.7. In which case, we may end up never using the 5.6 theme and ad-ons for a live site.
Probable scenario if 5.7 takes more than several months to released, with the 30/60 day policy that has been suggested:
We pay for templates and multiple ad-ons several times, (1) once initially for 5.6, (2) a second time months later after problems show-up in an actual 5.6 live site. (3) a third time when 5.7 is released a month or two later, and a forth time after redevelopment in 5.7, if problems show up in the newly debuted 5.7 site, not to mention continued purchases for future version upgrades.
One problem is that we are not even 100% sure if either 5.6 or 5.7 will work for our high traffic site (last year we received over 250,000 page views daily). I fear after paying multiple times for all the required licenses on top of investing 6 months of development costs, we may find that 5.7 does not work for us in the end. Not only would we have paid multiple times for the same theme and various add-ons, but on top of that we are also taking a big gamble in being out all that money and time.
A similar issue occurred when we hired a provider to build us a Joomla site last year. It turned out that my 11 year old daughter ended up building a better site for herself in Weebly than what this developer could manage with Joomla! With Joomla, we spent a good amount on premium extensions in addition to the costs of professional developer but in the end nothing to show for it - except a big mess! After another year of researching various CMSs, Concrete5 appears to be the most promising for our needs. However, we would like to avoid repeating our past mistakes.
Charging your customer base every step of the way of the already arduous task of investing and porting to a new platform makes this process even more daunting. I certainly understand the need for developers to have an incentive to continue developing themes and add-ons in Concrete5, but if you implement a price structure that is not attractive to prospective adapters of Concrete5, you could stagnate your potential for growth, and may end up with less overall customers shopping at your marketplace than you could have. I hope you can find a way that is both fair and attractive to your both developers and prospective customers, old and new alike.
We're sold on the potential of Concrete5.7.
We're told Concrete5.7 is not quite yet ready for production.
If fact no one knows for sure even when 5.7 will be ready for final release.
We were encouraged to start developing in 5.6.
We understand transporting a 3000 page site will take several months.
We need to to purchase a template and several key add-ons for a proof of concept and testing for each page type.
Best case scenario if every thing goes smoothly with the 30/60 day policy that has been suggested:
We pay for templates and multiple ad-ons twice, once now and a second time once 5.7 is finally released, after porting content from 5.6 to 5.7. In which case, we may end up never using the 5.6 theme and ad-ons for a live site.
Probable scenario if 5.7 takes more than several months to released, with the 30/60 day policy that has been suggested:
We pay for templates and multiple ad-ons several times, (1) once initially for 5.6, (2) a second time months later after problems show-up in an actual 5.6 live site. (3) a third time when 5.7 is released a month or two later, and a forth time after redevelopment in 5.7, if problems show up in the newly debuted 5.7 site, not to mention continued purchases for future version upgrades.
One problem is that we are not even 100% sure if either 5.6 or 5.7 will work for our high traffic site (last year we received over 250,000 page views daily). I fear after paying multiple times for all the required licenses on top of investing 6 months of development costs, we may find that 5.7 does not work for us in the end. Not only would we have paid multiple times for the same theme and various add-ons, but on top of that we are also taking a big gamble in being out all that money and time.
A similar issue occurred when we hired a provider to build us a Joomla site last year. It turned out that my 11 year old daughter ended up building a better site for herself in Weebly than what this developer could manage with Joomla! With Joomla, we spent a good amount on premium extensions in addition to the costs of professional developer but in the end nothing to show for it - except a big mess! After another year of researching various CMSs, Concrete5 appears to be the most promising for our needs. However, we would like to avoid repeating our past mistakes.
Charging your customer base every step of the way of the already arduous task of investing and porting to a new platform makes this process even more daunting. I certainly understand the need for developers to have an incentive to continue developing themes and add-ons in Concrete5, but if you implement a price structure that is not attractive to prospective adapters of Concrete5, you could stagnate your potential for growth, and may end up with less overall customers shopping at your marketplace than you could have. I hope you can find a way that is both fair and attractive to your both developers and prospective customers, old and new alike.
A very good point.
Perhaps we should make a distinction between updates that are purely for concrete5 version updates and updates that add major functionality.
I wouldn't want the prospect of 5.7 to destroy my customer's confidence in the current marketplace versions.
Perhaps we should make a distinction between updates that are purely for concrete5 version updates and updates that add major functionality.
I wouldn't want the prospect of 5.7 to destroy my customer's confidence in the current marketplace versions.
Here's some current thinking based on this great discussion:
1) All communication should go through a single centralized interface that categorizes it correctly (question, support, etc) and sticks it in a single, publicly accessible forum type area. Marketplace vendors should be able to recategorize them and have some canned answers to make gracious support faster and more consistent across the marketplace.
2) There should be the ability to do something more than just one page of docs.
3) There's a difference between an update to an add-on because of a security or incremental core update and an update to an add-on with feature improvements on its own. It'd be nice if a developer could choose to give away the former while selling the latter, perhaps at a discount. There's no hard and fast rules here but there's a balance we'd all like to achieve in the middle.
4) Support has to be limited but promising only 30 days and delivering 60 isn't the right way to do it. Any number of concerns, but most obviously what about the 5-packs? Perhaps a pay for ticket option would solve this? You buy a license for $x, you get the software and 1 support ticket. Perhaps that ticket should expire as well (like 6 months? Year? not sure on that..) Need more support, buy another ticket for some discounted rate x/2? leave it up to developer?
This gets mkly the ability to give away GPL software and just sell tickets.
This keeps 5 packs something worth buying.
This (if explained properly) seems pretty fair to customers who get 0 support for free when they buy quickbooks.
Am I missing anything?
Can we discuss tickets and if they should be fixed costs across the marketplace, a fixed percentage of add-on costs, or just developer choice?
1) All communication should go through a single centralized interface that categorizes it correctly (question, support, etc) and sticks it in a single, publicly accessible forum type area. Marketplace vendors should be able to recategorize them and have some canned answers to make gracious support faster and more consistent across the marketplace.
2) There should be the ability to do something more than just one page of docs.
3) There's a difference between an update to an add-on because of a security or incremental core update and an update to an add-on with feature improvements on its own. It'd be nice if a developer could choose to give away the former while selling the latter, perhaps at a discount. There's no hard and fast rules here but there's a balance we'd all like to achieve in the middle.
4) Support has to be limited but promising only 30 days and delivering 60 isn't the right way to do it. Any number of concerns, but most obviously what about the 5-packs? Perhaps a pay for ticket option would solve this? You buy a license for $x, you get the software and 1 support ticket. Perhaps that ticket should expire as well (like 6 months? Year? not sure on that..) Need more support, buy another ticket for some discounted rate x/2? leave it up to developer?
This gets mkly the ability to give away GPL software and just sell tickets.
This keeps 5 packs something worth buying.
This (if explained properly) seems pretty fair to customers who get 0 support for free when they buy quickbooks.
Am I missing anything?
Can we discuss tickets and if they should be fixed costs across the marketplace, a fixed percentage of add-on costs, or just developer choice?
"Support" tickets need to stay private to paying customers. One thing that has not been mentioned about support yet is security.
Telling customers that the support forum has public access to anyone else that has purchased the product does not always work. We have customers that will post sensitive information such as admin passwords and FTP info even though we ask them not to. This happens more often then it should. Telling customers the whole world has access to support probably wont make much of a difference. Let's make an effort to keep this as secure as possible. Having support public to paying customers is risky enough. Having it public to everyone including google would be dangerous and kind of irresponsible.
Telling customers that the support forum has public access to anyone else that has purchased the product does not always work. We have customers that will post sensitive information such as admin passwords and FTP info even though we ask them not to. This happens more often then it should. Telling customers the whole world has access to support probably wont make much of a difference. Let's make an effort to keep this as secure as possible. Having support public to paying customers is risky enough. Having it public to everyone including google would be dangerous and kind of irresponsible.
I think that can be solved by having support posts default to public, but selectable to private - meaning exclusively private - not just to other owners.
So when a communication starts and the user decides what sort of communication they are posting, they also decide if it should be public or private.
Perhaps have some intelligence in the post routine to scan for words or phrases like username, password and login and prompt them to double check. (though I don't expect such phrase detecting would be fool proof)
The marketplace developer can then decide to recategorise later including private/public if the original categorisation turns out to be inappropriate.
So when a communication starts and the user decides what sort of communication they are posting, they also decide if it should be public or private.
Perhaps have some intelligence in the post routine to scan for words or phrases like username, password and login and prompt them to double check. (though I don't expect such phrase detecting would be fool proof)
The marketplace developer can then decide to recategorise later including private/public if the original categorisation turns out to be inappropriate.
In my opinion, the simpler, the better. Less options for the user, less logic behind every step of the way, gets us the "new thing" faster and it will be better.
I think the kind of "Before you post" reminder that is currently in the Jobs forum would suffice. Also, if there are any credentials required during the support ticked, first thing we do is we WRITE IN CAPS in the post where we ask the credentials not to post them to the support thread. I don't remember a case where someone would've posted them in the thread after doing this.
I also back @frz's idea of having consistency in the policies, it's much better for the greater good. The suggested points seem all good to me but I'd like to re-raise my own opinion about keeping the support forum and the general forum as separate (which I guess seems to be against everyone else's opinion but just to leave it out there).
I think the kind of "Before you post" reminder that is currently in the Jobs forum would suffice. Also, if there are any credentials required during the support ticked, first thing we do is we WRITE IN CAPS in the post where we ask the credentials not to post them to the support thread. I don't remember a case where someone would've posted them in the thread after doing this.
I also back @frz's idea of having consistency in the policies, it's much better for the greater good. The suggested points seem all good to me but I'd like to re-raise my own opinion about keeping the support forum and the general forum as separate (which I guess seems to be against everyone else's opinion but just to leave it out there).
"The marketplace developer can then decide to recategorise later including private/public if the original categorisation turns out to be inappropriate."
If this is the case three options would be nice to have.
1) Set to completely private (security enhancement)
2) Set to private for paying customers (value for "paid" support)
3) Set to public support forum (FAQs not really considered support and support we choose to give away for "free")
We need to ability to decide what support we want to give away for free and what support we want to display for paying customers. This keeps the value in paid support.
If this is the case three options would be nice to have.
1) Set to completely private (security enhancement)
2) Set to private for paying customers (value for "paid" support)
3) Set to public support forum (FAQs not really considered support and support we choose to give away for "free")
We need to ability to decide what support we want to give away for free and what support we want to display for paying customers. This keeps the value in paid support.
I think it's pretty reasonable to simply build it so a support ticket
(paid) is private, and everything else is not.
best wishes
Franz Maruna
CEO - PortlandLabs Inc
(paid) is private, and everything else is not.
best wishes
Franz Maruna
CEO - PortlandLabs Inc
+1
What if a customer posts a "paid support" question in the "everything else section"?
What if a customer posts a "paid support" question in the "everything else section"?
We need the ability to move posts between various support sections or we are no better off than we are with the current setup. Once we already have that ability, moving between the various public support categories, private support and confidential support is just adding 2 more options in a select menu.
+1
I think addons should be supported the same as C5 supports the core. In order to accomplish this though developers would need to include documentation. The documentation would cover the packages designed purposed. Anything outside its designed purpose would be open discussion (forum fielding). Pre-Sale questioning optional and updates till EOL of the addon.
As far as core upgrading I think so long as that package is supporting the versions, those that have purchased it should get the new updates till EOL of that package name. If a developer doesn't want to do that then they should make a new package which starts the process over again (ex: Myaddon 5.6 and Myaddon 5.7).
In all the software companies I have worked for this is how we handled it.
1) Have Documentation for intended purpose
2) Out of Intended Purpose and outside Documentation is by open forum and community help only unless its a bug.
3) Upgrade and bug fixes till EOL of package name.
4) Change package name if you want to EOL an old and separate a new. Must resubmit new package as a new package to marketplace for approval.
5) Additional support paid option or not offered.
IMO this has always seemed to be the fair and equal balance for both dev and customers. Hopefully I didn't leave out anything.
As far as core upgrading I think so long as that package is supporting the versions, those that have purchased it should get the new updates till EOL of that package name. If a developer doesn't want to do that then they should make a new package which starts the process over again (ex: Myaddon 5.6 and Myaddon 5.7).
In all the software companies I have worked for this is how we handled it.
1) Have Documentation for intended purpose
2) Out of Intended Purpose and outside Documentation is by open forum and community help only unless its a bug.
3) Upgrade and bug fixes till EOL of package name.
4) Change package name if you want to EOL an old and separate a new. Must resubmit new package as a new package to marketplace for approval.
5) Additional support paid option or not offered.
IMO this has always seemed to be the fair and equal balance for both dev and customers. Hopefully I didn't leave out anything.
I was looking for the statement for Franz on keeping the marketplace commission at 30%. Looking at the comments, I think it was this thread or something close to it, but I cannot find it.
Does anyone else have the link?
Does anyone else have the link?
I know I saw it too.. I don't have any record of it. At one point it was 60/40 but I'm pretty sure it was posted that it would maintain the 70/30 split.
It was sent in an email on July 31, 2014
I just forwarded it to you John
I just forwarded it to you John
@hostco, thanks for the email. I probably have that stored away somewhere myself. Just didn't think to look through email, searched the forums and found this thread, then got blinkered and wondered where I was lost.
Confirmed, this will stay at 70/30 where it is today. We talked about bringing it up to both 50/50 and 60/40 but decided against both
—
Sent from Mailbox for iPad
—
Sent from Mailbox for iPad
I know this is an old discussion but I wanted to post my 2 cents from someone who purchases addons and uses the support forums.
As many of mentioned in here I feel that a difference in support level should be dependent on time.
Bug fixes for example should not be limited by time (at least for the life cycle of that version), I would not want to go to a site that is out of the 30/60 day period and have to purchase another license just to report a bug. Most of the time I have already fixed the issue locally and supplying a fix in the support forum. I have purchased paid addons that have bugs in most developers have soon fixed them but if support is limited then IMO the PRB needs to step up a notch or allow unit/acceptance tests to be run on addons to prevent broken packages from being released.
Feature request, again I don't think should be limited. I would not expect all my requests to be actioned but I would always like the ability to suggest improvements/features without the requirement of a license.
Where I think the support time limit should be applied is for help using the addon, tasks like customisation, installation, upgrading those not related to actual problems arisen from bad code.
I'm not saying I would expect support for addons purchase years ago (though I should then be able to remove/release them from my project, especially if they are broken after an update). I think limited support is a good idea but it should be limited for what support is actually there to provide support in using the addon.
As many of mentioned in here I feel that a difference in support level should be dependent on time.
Bug fixes for example should not be limited by time (at least for the life cycle of that version), I would not want to go to a site that is out of the 30/60 day period and have to purchase another license just to report a bug. Most of the time I have already fixed the issue locally and supplying a fix in the support forum. I have purchased paid addons that have bugs in most developers have soon fixed them but if support is limited then IMO the PRB needs to step up a notch or allow unit/acceptance tests to be run on addons to prevent broken packages from being released.
Feature request, again I don't think should be limited. I would not expect all my requests to be actioned but I would always like the ability to suggest improvements/features without the requirement of a license.
Where I think the support time limit should be applied is for help using the addon, tasks like customisation, installation, upgrading those not related to actual problems arisen from bad code.
I'm not saying I would expect support for addons purchase years ago (though I should then be able to remove/release them from my project, especially if they are broken after an update). I think limited support is a good idea but it should be limited for what support is actually there to provide support in using the addon.
You have pretty much summed up how I interpret support of my marketplace addons.
I agree. I've run into an issue where a new release of an add-on came out and found a bug. Frustrating to be requested to pay $60 for support when you bought a 10 pack of licenses and all you had done is upgraded to the new release on a website to find an issue with the new release. In this one case the developer is taking care of things because I contacted them directly about it but that could be very frustrating if the developer didn't fix the bug for free.
My concern, and hence my $0.02, comes from this statement:
"Support, pre-sales questions, questions & discussion all go away on marketplace pages"
As someone who is focused more on building client sites and utilizing marketplace add-ons, it is those mechanisms that can make or break a sale for me. Often pre-sale I can find out about features without having to email the developer to ask what is likely a repetitive question. Looking through closed support tickets often saves me form waiting for a developer response when I run into an issue or can't figure out how to do something I saw in the demo.
From the developer side, this seems that is has potential to drive more email instead of self help. From an end user perspective, it takes away information I use to purchase apps. My preference would be to make sure that the largest possible amount of information about an add-on is available to consumers (and potential consumers).
Thanks,
-Brian