3

In the context of this question: Can two managed packages utilize common core libraries and other questions concerning managed packages and extensions...

For any two apps that share a lot of code, chances are that — ideally — they are not two apps and so we could and would want to merge them, code-wise.

But then again, the complexity of features has it that as an ISV you may wish to apply different licenses to given feature sets, if only owed to Fancy Feature F developed for a special use-case that did cost a lot of effort to build and is more of an extended feature rather than something you wish to necessarily burden your base-users with, license-wise.

So, the question would be: Can you bind different functionalities of a given managed package to different license types? Does the licensing model for LMA / LMO even support that?

In layman's terms: So, we'd now have App X, which otherwise would have been App A and App B. In order to use the features of what previously was App A, a user could be assigned a dedicated license for A and to use those of App B, a user could be assigned a license for B. To use both, they'd need two (different) licenses for each user wanting to use them. Or perhaps one that combines the two.

I can see how this isn't trivial and so I imagine the platform doesn't cater for it. Would you think it even makes sense to cast that into an idea?

Reading this answer, I find that for any transaction the number of namespaces involved must not exceed 10. So, this indicates that an incremental / bundled license model for a single managed package would indeed be desirable ...and from the perspective of an ISV in general, too.

Improve this question
4
  • 1
    I'm unfamiliar with ISV licensing and haven't dealt much with managing a managed package, so I apologize if I'm completely missing the mark. That said, reading through your post and thinking about it as a metadata package, why would it need to be a new App (i.e. App X)? Can't App A pull in metadata from App B and become a new version App A? I would think your managed package for App A could create a new version which includes all metadata from App B, your licenses from App A would still be valid and you would need to provision licenses for those with App B to use App A. Then deprecate App B.
    – zainogj
    Commented Feb 27, 2016 at 14:16
  • 1
    In part, it would seem to me that the question would be, do YOU want to deal with the complexity it creates for YOU? You'd need to create different versions built in different orgs both sharing code and NOT sharing code. Then have an install script that detects existing code and determines what to install. I don't think it's so much a licensing model as it is a code sharing complexity issue due to namespacing. You'd still be installing a 2nd app (an add-on if an existing customer) for which there'd be an additional license, just more or less code.
    – crmprogdev
    Commented Feb 27, 2016 at 18:49
  • @crmprogdev, the idea here would precisely be to only have ONE (dev) org (and also just one LMO) for ONE managed package ...which would cater for different license types. So, there would NOT be any "sharing" of code, but rather some matrix of Package-License-Types A B C vs. Package-Components X Y Z. As for name-spacing, there would only be one namespace, that of the managed package.
    – tobibeer
    Commented Feb 28, 2016 at 12:55
  • @zainogj, //Why would it need to be a new App (i.e. App X)? Can't App A pull in metadata from App B and become a new version App A?// Sure, that would be another option. I just worded / drafted it differently for "clarity". But your method would equally work. However, what I am not seeing is a way to incrementally expose features of a single managed package through different license types associated with it.
    – tobibeer
    Commented Feb 28, 2016 at 12:58

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .