Private Marketplace Add-ons
Permalink 2 users found helpful
I was just thinking about this and wanted to see what anyone else thought. I think it would be a cool if there was a way to make add-ons that you release to the marketplace but are not approved only available to sites registered under your account. That way you or your client could update them on sites you manage. Again this would be more for add-ons that you write for concrete5 but don't quite make the cut for the marketplace. I can see how this would get out of hand, but I just got to thinking about it in regards to an add-on I created that is really useful to me, but probably not good enough for the marketplace. Any thoughts?
Thats an interesting idea, but if an addon works, and isn't messy, then you should submit it to the MP. also, doing that could open all sorts of legal issues,
I see the potential for this idea in the big picture.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
It would be exactly what we need (or a separate Marketplace add-on), anything on the horizon for that idea ?
I see the value in this. Great idea.
And I think Franz has mentioned a desire to have something like this in the past.
However, this has to be done carefully and correctly. As a business, I can't have someones company purchasing ProBlog,and then reselling it cutting me out of the profit loop. That would cripple me, and not allow me to keep making it better and better.
And to assume the best of end users would be really stupid. lol We already see people taking one license and using it on multiple sites. Some people just do not have personal integrity and character to honor developers and support them so they can keep doing what they're doing.
So I love this idea...but only if it's strictly implemented to protect developers. Otherwise...I vote no.
But I believe Franz sees this concern, and possibly has other concerns as well.
ChadStrat
And I think Franz has mentioned a desire to have something like this in the past.
However, this has to be done carefully and correctly. As a business, I can't have someones company purchasing ProBlog,and then reselling it cutting me out of the profit loop. That would cripple me, and not allow me to keep making it better and better.
And to assume the best of end users would be really stupid. lol We already see people taking one license and using it on multiple sites. Some people just do not have personal integrity and character to honor developers and support them so they can keep doing what they're doing.
So I love this idea...but only if it's strictly implemented to protect developers. Otherwise...I vote no.
But I believe Franz sees this concern, and possibly has other concerns as well.
ChadStrat
I found this topic because I was searching for something very similar. My agency develops themes and addons for our clients, and it would vastly simplify our deployment process if we could host these in the marketplace; however, we do NOT want to open them up for the general public to purchase because we want to LIMIT our support load, so we have a very real use case for "limiting" their availability. We have very strict standards and I am confident that we could get each and every theme/addon approved for the marketplace, but we do not want to do that.
Thus, we are looking for a way to "privately" host these Concrete5 extensions. The suggestion in this thread would work just fine. I see that there hasn't been a reply to this in quite some time; are there any plans to implement something here? If not, we are going to have to investigate other deployment options, and although I really do NOT want to look into modifying the marketplace hooks to connect to a separate marketplace that my agency would build ourselves, if we can't hope to have support for this we may have to go that direction.
Thus, we are looking for a way to "privately" host these Concrete5 extensions. The suggestion in this thread would work just fine. I see that there hasn't been a reply to this in quite some time; are there any plans to implement something here? If not, we are going to have to investigate other deployment options, and although I really do NOT want to look into modifying the marketplace hooks to connect to a separate marketplace that my agency would build ourselves, if we can't hope to have support for this we may have to go that direction.
whelp... a couple of thoughts...
1) You can manage your own packages and just install by hand, as you
probably already know. Technically that solves your challenges.
2) If you need to sell these add-ons to your customers, using our
marketplace would obviously introduce some new requirements on our end.
3) If you need to give these add-ons to your customers for free, using our
marketplace would also introduce some new requirements on our end.
Both 2 & 3 sound like a real investment of time in creating and then
managing this for your agency. We'd also get into branding issues. I don't
know how you guys roll, but it's quite possible other folks with similar
interestes are white labeling concrete5 in unique ways. It makes it a bit
awkward on us to have your customers stuck in the middle here. What happens
when someone realizes they don't like their agency, would rather have full
access to the concrete5 marketplace, etc.. Not that these would be specific
issues you guys would have, but if we introduced this as a service it's
something we'd have to plan for.
Also, what's it worth and to whom? My experience has been that charging
agencies is billing the wrong side of the equation as there's not a lot of
margin. Charging your customers for access to a private marketplace seems
unlikely..
I dunno.. No plan here, just sharing why this is kinda a non-starter for us
at the moment. Complicated, confusing, limited value, limited revenue
potential, splits the community up instead of making it larger. etc.
One might suggest that pricing your add-ons high would reduce the support
needs as you tend to attract more savvy clients and you have built in
margin for that time.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
1) You can manage your own packages and just install by hand, as you
probably already know. Technically that solves your challenges.
2) If you need to sell these add-ons to your customers, using our
marketplace would obviously introduce some new requirements on our end.
3) If you need to give these add-ons to your customers for free, using our
marketplace would also introduce some new requirements on our end.
Both 2 & 3 sound like a real investment of time in creating and then
managing this for your agency. We'd also get into branding issues. I don't
know how you guys roll, but it's quite possible other folks with similar
interestes are white labeling concrete5 in unique ways. It makes it a bit
awkward on us to have your customers stuck in the middle here. What happens
when someone realizes they don't like their agency, would rather have full
access to the concrete5 marketplace, etc.. Not that these would be specific
issues you guys would have, but if we introduced this as a service it's
something we'd have to plan for.
Also, what's it worth and to whom? My experience has been that charging
agencies is billing the wrong side of the equation as there's not a lot of
margin. Charging your customers for access to a private marketplace seems
unlikely..
I dunno.. No plan here, just sharing why this is kinda a non-starter for us
at the moment. Complicated, confusing, limited value, limited revenue
potential, splits the community up instead of making it larger. etc.
One might suggest that pricing your add-ons high would reduce the support
needs as you tend to attract more savvy clients and you have built in
margin for that time.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Thank you for such a speedy reply!
In response to your thoughts...
1) This is what we do currently, but managing updates, etc. across multiple clients on multiple versions of concrete5 is much more painful when we are doing everything by hand, which is why we are looking for marketplace integration.
2&3) What we're looking for is NOT a private marketplace only available for "our" clients, but rather a way for me personally to have access to my own "private" extensions w/ unlimited licenses so that I can manage them for any projects of which I am a part in the same way that I manage purchased extensions for those same projects. A bonus would be if I could delegate access to these private extensions to other members of my agency, but it's not something we are pressing for.
Can you see how this would simplify managing/supporting my clients, without having to add a bunch of work on your side?
I suppose a lot of what I am saying is somewhat theoretical since I have not ever added something to the marketplace and am thus unaware of exactly what that entails. One thing we had not considered was using the marketplace but over-pricing the add-ons/themes to increase friction. That might be a very viable option for us, as long as we have unlimited licenses to allocate ourselves. I would assume that happens, but not having listed anything myself, I want to make sure. Would this be the case?
In response to your thoughts...
1) This is what we do currently, but managing updates, etc. across multiple clients on multiple versions of concrete5 is much more painful when we are doing everything by hand, which is why we are looking for marketplace integration.
2&3) What we're looking for is NOT a private marketplace only available for "our" clients, but rather a way for me personally to have access to my own "private" extensions w/ unlimited licenses so that I can manage them for any projects of which I am a part in the same way that I manage purchased extensions for those same projects. A bonus would be if I could delegate access to these private extensions to other members of my agency, but it's not something we are pressing for.
Can you see how this would simplify managing/supporting my clients, without having to add a bunch of work on your side?
I suppose a lot of what I am saying is somewhat theoretical since I have not ever added something to the marketplace and am thus unaware of exactly what that entails. One thing we had not considered was using the marketplace but over-pricing the add-ons/themes to increase friction. That might be a very viable option for us, as long as we have unlimited licenses to allocate ourselves. I would assume that happens, but not having listed anything myself, I want to make sure. Would this be the case?
yeah you can grant free licenses to anyone you want when you own it in the
marketplace.
you can also issue special offers.
I can see how managing your own packages on concrete5.org might be handy, I
hadn't really thought of it in the individual developer mindset. I think we
still would need to look into liability, branding, and cost/benefit issues
on our end - but i dig what you're saying. Just a "my Packages" part of the
my account area...
in terms of pricing; the goal should be to sell something - but it doesnt
need to be to everyone. Pricing something at a million dollars, and using
the PRB process as a way to get free development review on your work would
be certainly frowned upon. Pricing something for a couple of hundred
instead of $15 works well however. You tend to get the more corporate
clients looking to extend their DIY intranet. Generally a bit more
technically savvy and willing to put up with reasonable support processes
as they live with it from many vendors.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
marketplace.
you can also issue special offers.
I can see how managing your own packages on concrete5.org might be handy, I
hadn't really thought of it in the individual developer mindset. I think we
still would need to look into liability, branding, and cost/benefit issues
on our end - but i dig what you're saying. Just a "my Packages" part of the
my account area...
in terms of pricing; the goal should be to sell something - but it doesnt
need to be to everyone. Pricing something at a million dollars, and using
the PRB process as a way to get free development review on your work would
be certainly frowned upon. Pricing something for a couple of hundred
instead of $15 works well however. You tend to get the more corporate
clients looking to extend their DIY intranet. Generally a bit more
technically savvy and willing to put up with reasonable support processes
as they live with it from many vendors.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Fantastic. Thank you for your feedback and guidance. If you ever do roll out this kind of functionality I am sure we will be big supporters, but for the time being you have provided what I think will be a viable alternative for our situation.
Excited to keep moving forward with Concrete5,
Denver Root
Excited to keep moving forward with Concrete5,
Denver Root
Would concrete5 consider approving an addon that provided such 'private marketplace' functionality?
Or would it carry too high a risk of undermining the whole concept of the existing marketplace?
Or would it carry too high a risk of undermining the whole concept of the existing marketplace?
It is highly unlikely that I would want an add-on in our marketplace that enabled access to another marketplace.
I'm cross posting this reply to a PM that started in another thread as well. The background was would we approve and add-on to enable access to another concrete5 marketplace that allowed package dependencies, code signing, and protected code (Intellectual Property/IP).
The initial reply was "nope."
Here's the more detailed answer:
Convince me there's a real need we're not solving and we're always willing to rethink our position on things. We considered package dependencies a long time ago and left it be as we saw a lot of both technical and practical issues with pulling it off gracefully.
As it is we have package deals on concrete5 that are used surprisingly little. If there was an overwhelming need to make this image gallery include that navigation template I'd expect to see developers packing them up as special offers and selling them as a bundle more (or like - at all.) We do have themes that extend ecommerce and problog, but that's about it.
Can I imagine JohnTheFish wanting some of his job scheduling and caching add-ons to require one another? Sure. Can I imagine those add-ons simply being bundled together into one add-on that solves one need I understand? Yup. Can I see a lot of confusion from potential customers around "I bought this and now it's telling me I have to buy that too??" - yes.
While yes I see the appeal to a developer of having "my tools" package that all your add-ons can depend on, no I don't see that as making any sense to my Mom who is just looking for an add-on that works. This is what you see out of WP & Drupal these days, 100's of mini-ecosystems around extensions that provide parts of a better solution that never work their way back into the core. Thesis/WP is very different from just WP..Just because your site is built with Drupal doesnt mean its built with the tools that this OTHER Drupal shop uses, etc..
I wonder about version changes around these dependencies and testing, along with what happens when someone makes a local package name that conflicts. Now I'm not saying these are insolvable problems, but why are we tackling them again? Do you really want to bank on the idea that a change JohnTheFish makes to his sexy new tools package isn't going to impact your add-on when theres absolutely no testing plan in place? I hope not.
Moreover, I think i've been pretty clear that our vision of the marketplace and concrete5 as a CMS is the important shared problems get solved consistently in the core. When we see something that everyone really does want to depend on (for example: the area splitter) we end up building it into the core so everyone can always depend on it being there and working a consistent way (read: layouts). Are layouts perfect? Nope. They're getting pretty awesome in 5.7 though. I see this as a huge part of our role here managing the core. Not that we bang out perfect code that no one else has thought of, rather we see trends and holes that need to be filled (in part because of activity in the marketplace) and then we take the time to build them so everyone can depend on them being there.
Conceptually you have one level of dependencies already with your add-on extending concrete5. Stop and think about the challenges around simply updating a concrete5 install and your add-on with new versions for each. That works the vast majority of the time, but its not without hiccup even today. You're asking us to make that potentially exponentially more dangerous, to solve an issue of developer convenience at best (as I understand it.)
In terms of code signing - I believe our marketplace install process handles that pretty well, 'specially since we don't have dependancies to worry about. In terms of IP issues - well yes - it's an open source project. . I'm happy to give my work away under MIT so you can do what you feel you need to with it. That doesn't mean I need to go out of my way to provide infrastructure that encourages you not share. Same argument I give the people who complain that our suggested white labeling approach still includes a "powered by concrete5" label and isn't as flexible as they'd like. Cool story bro. Feel free to use concrete5 in anyway you want.
Would I approve an add-on that enables access to a different marketplace that has different policies on this stuff? Very unlikely. I had a metaphor about using your girl friend's puppy to hit on hotties at the park but it offended Mike so I took it out. ;-)
The initial reply was "nope."
Here's the more detailed answer:
Convince me there's a real need we're not solving and we're always willing to rethink our position on things. We considered package dependencies a long time ago and left it be as we saw a lot of both technical and practical issues with pulling it off gracefully.
As it is we have package deals on concrete5 that are used surprisingly little. If there was an overwhelming need to make this image gallery include that navigation template I'd expect to see developers packing them up as special offers and selling them as a bundle more (or like - at all.) We do have themes that extend ecommerce and problog, but that's about it.
Can I imagine JohnTheFish wanting some of his job scheduling and caching add-ons to require one another? Sure. Can I imagine those add-ons simply being bundled together into one add-on that solves one need I understand? Yup. Can I see a lot of confusion from potential customers around "I bought this and now it's telling me I have to buy that too??" - yes.
While yes I see the appeal to a developer of having "my tools" package that all your add-ons can depend on, no I don't see that as making any sense to my Mom who is just looking for an add-on that works. This is what you see out of WP & Drupal these days, 100's of mini-ecosystems around extensions that provide parts of a better solution that never work their way back into the core. Thesis/WP is very different from just WP..Just because your site is built with Drupal doesnt mean its built with the tools that this OTHER Drupal shop uses, etc..
I wonder about version changes around these dependencies and testing, along with what happens when someone makes a local package name that conflicts. Now I'm not saying these are insolvable problems, but why are we tackling them again? Do you really want to bank on the idea that a change JohnTheFish makes to his sexy new tools package isn't going to impact your add-on when theres absolutely no testing plan in place? I hope not.
Moreover, I think i've been pretty clear that our vision of the marketplace and concrete5 as a CMS is the important shared problems get solved consistently in the core. When we see something that everyone really does want to depend on (for example: the area splitter) we end up building it into the core so everyone can always depend on it being there and working a consistent way (read: layouts). Are layouts perfect? Nope. They're getting pretty awesome in 5.7 though. I see this as a huge part of our role here managing the core. Not that we bang out perfect code that no one else has thought of, rather we see trends and holes that need to be filled (in part because of activity in the marketplace) and then we take the time to build them so everyone can depend on them being there.
Conceptually you have one level of dependencies already with your add-on extending concrete5. Stop and think about the challenges around simply updating a concrete5 install and your add-on with new versions for each. That works the vast majority of the time, but its not without hiccup even today. You're asking us to make that potentially exponentially more dangerous, to solve an issue of developer convenience at best (as I understand it.)
In terms of code signing - I believe our marketplace install process handles that pretty well, 'specially since we don't have dependancies to worry about. In terms of IP issues - well yes - it's an open source project. . I'm happy to give my work away under MIT so you can do what you feel you need to with it. That doesn't mean I need to go out of my way to provide infrastructure that encourages you not share. Same argument I give the people who complain that our suggested white labeling approach still includes a "powered by concrete5" label and isn't as flexible as they'd like. Cool story bro. Feel free to use concrete5 in anyway you want.
Would I approve an add-on that enables access to a different marketplace that has different policies on this stuff? Very unlikely. I had a metaphor about using your girl friend's puppy to hit on hotties at the park but it offended Mike so I took it out. ;-)
'Private Marketplace' was a very misleading choice of terminology on my behalf and in retrospect a term I should not have used when writing a snap reply. What I meant in the context of this thread was a limited distribution and maintenance tool.
- I did not want to confuse the subject of this thread with the package dependency thread which I see as a completely different issue. If that is going to be solved, I think it needs to be done within concrete5.org.
- I don't under any circumstances want to undermine the integrity of the concrete5 marketplace. The marketplace is a big discriminator between concrete5 and others and one of the big reasons I support concrete5.
Suppose a web shop has some customer specific packages that would never be public addons, just things they use for a few customer sites. A very limited form of the marketplace update functionality would enable the web shop to post updates on their own server and then customers to update those private packages.
My comment on risk was that perhaps even such limited private update functionality could carry the risk of being abused to set up outside marketplaces.
- I did not want to confuse the subject of this thread with the package dependency thread which I see as a completely different issue. If that is going to be solved, I think it needs to be done within concrete5.org.
- I don't under any circumstances want to undermine the integrity of the concrete5 marketplace. The marketplace is a big discriminator between concrete5 and others and one of the big reasons I support concrete5.
Suppose a web shop has some customer specific packages that would never be public addons, just things they use for a few customer sites. A very limited form of the marketplace update functionality would enable the web shop to post updates on their own server and then customers to update those private packages.
My comment on risk was that perhaps even such limited private update functionality could carry the risk of being abused to set up outside marketplaces.
I will comment further on the subject of dependencies in this thread:
http://www.concrete5.org/developers/pro-accounts/community-leaders-...
(because I don't want to confuse between these issues further)
http://www.concrete5.org/developers/pro-accounts/community-leaders-...
(because I don't want to confuse between these issues further)
FYI, it seems that access is limited to the link you provided above...
My experience has been most web shops would want to actually make sure those updates didn't break their client sites by installing and testing themselves. Alternatively they would want to simply NOT update anything that was already working. Just having a client see an "updates!" button, only to press it and then get a frantic call from the client that they broke their site with an update that they thought was safe sounds less than awesome.
The idea that something came from concrete5.org today implies a level of safe "Workiness" that I'm very eager to continue to deliver on as the project grows.
I do see these two issues as one discussion: "should the marketplace integration be more complicated and powerful than it is today?"
My take is no.
In the context of "does this make the marketplace more compelling to consumers", I don't believe that package dependencies or private marketplace integration helps.
The idea that something came from concrete5.org today implies a level of safe "Workiness" that I'm very eager to continue to deliver on as the project grows.
I do see these two issues as one discussion: "should the marketplace integration be more complicated and powerful than it is today?"
My take is no.
In the context of "does this make the marketplace more compelling to consumers", I don't believe that package dependencies or private marketplace integration helps.
