Apex Code Development You need to sign in to do that
Don't have an account?
GoForceGo Strategics for using managed/unmanaged package as a startup
I am getting ready to launch a product and I am scratching my head on this one as to how I would go about packaging (managed versus unmanaged) it for my clients.
Here is my understanding of Managed versus unManaged package:
Managed:
1. Clients don't see my code - my IP is protected
2. Once I publish the managed package as released, my engineering won't be able to modify a lot of things - such objects and object attributes in the developer environment. This is clearly undesirable for a startup.
3. Once I create a managed package in a developer environment, my object get prefixed with the unique prefix - even if i delete the managed package, objects retain their prefix.
4. Clients can upgrade without uninstall...
5. Managed beta package is an not an option, since it can't be done in production environment - only sandbox or developer. I am looking for real production customers who will pay me, but appreciate the fact that product might change based on their feedback.
UnManaged:
1. Code is visible to my clients - my IP is unprotected
2. I can freely modify my product in developer environment, downside being that customers have to uninstall the prior release and manually reimport all the data.
Ideally I want a managed package (to protech my IP and enable upgrades). However, I find the prospect of my engineering not being able to modify the objects for eternity a little scary. I understand this is important so that clients can upgrade, but since my product will evolve, I don't want to be locked in early on. Early clients might be willing to uninstall and reimport, if they see newer functionality is worth it.
One option I was thinking was to always maintain an unpackaged version as my golden source code. I can then use this to create multiple managed packages, each in a different developer enviroment, each with a different prefix. So let's say I create release 1 with a prefix "mycom1". My first client installs this - the objects are called mycom1__abc etc...If my client finds bugs, I fix them in the mycom1 and also in my golden source (yucks!). Let's say that I find that I do have to modify my objects. I go back to my golden source and and create a new managed package with prefix "mycom2". I can give this to customer 2....Now I have to fix bugs in three places(really yucks!!!)
Does anyone have any better ideas or is my understanding flawed (I hope so).
I wish I could put beta managed packages in a production environment - I will have best of both worlds in that case!!!
Here is my understanding of Managed versus unManaged package:
Managed:
1. Clients don't see my code - my IP is protected
2. Once I publish the managed package as released, my engineering won't be able to modify a lot of things - such objects and object attributes in the developer environment. This is clearly undesirable for a startup.
3. Once I create a managed package in a developer environment, my object get prefixed with the unique prefix - even if i delete the managed package, objects retain their prefix.
4. Clients can upgrade without uninstall...
5. Managed beta package is an not an option, since it can't be done in production environment - only sandbox or developer. I am looking for real production customers who will pay me, but appreciate the fact that product might change based on their feedback.
UnManaged:
1. Code is visible to my clients - my IP is unprotected
2. I can freely modify my product in developer environment, downside being that customers have to uninstall the prior release and manually reimport all the data.
Ideally I want a managed package (to protech my IP and enable upgrades). However, I find the prospect of my engineering not being able to modify the objects for eternity a little scary. I understand this is important so that clients can upgrade, but since my product will evolve, I don't want to be locked in early on. Early clients might be willing to uninstall and reimport, if they see newer functionality is worth it.
One option I was thinking was to always maintain an unpackaged version as my golden source code. I can then use this to create multiple managed packages, each in a different developer enviroment, each with a different prefix. So let's say I create release 1 with a prefix "mycom1". My first client installs this - the objects are called mycom1__abc etc...If my client finds bugs, I fix them in the mycom1 and also in my golden source (yucks!). Let's say that I find that I do have to modify my objects. I go back to my golden source and and create a new managed package with prefix "mycom2". I can give this to customer 2....Now I have to fix bugs in three places(really yucks!!!)
Does anyone have any better ideas or is my understanding flawed (I hope so).
I wish I could put beta managed packages in a production environment - I will have best of both worlds in that case!!!
Here are some other thoughts, I have been able to glean/put together
1. Since beta managed packages can be installed in sandbox, and sandbox specially in UE almost function as production, that might be another strategy
2. If components of managed package are added to an unmanaged package and uploaded, apparently, the prefix is stripped.
3. Keeping the master version of code/objects not in a DE, but in source code control and push it to multiple developer orgs to create multiple managed packages
4. Keep managed package object model as small as possible early on- you can always expand, you can't shrink!
All Answers
Managed:
- Salesforce will automatically supply you with a Lead whenever someone installs your app
- You have a license record associated to that Lead that keeps track of the status (installed, uninstalled) and the version they are on. If you go from 1.0 to 2.0, you'll know who's on which version.
Unmanaged:I would recommend going with managed unless you have a good reason not to. With a managed package, you can still edit your objects, add new fields, etc. The customers can't, but you can in your DE org and then update the package online.
The decision really depends on the updates you see yourself making. My experience with managed packages were with packages where all objects in them were easily updatable (web tabs, buttons/links).
Message Edited by hemm on 03-27-2008 01:01 PM
For a managed package, my understanding is that I cannot delete an custom object I have published and I cannot modify/delete the custom fields that already existed - I won't be able to do that in a developer environment. i am a little afraid of getting locked down on the data model this early in my product stage.
As as I said, I was thinking about maintaining another copy of the code/data model, but it seems messy with multiple places to update.
Any suggestions, anyone?
Generally speaking, I'd recommend a managed package primarily because of the upgradability and ability to capture the license information. Obscuring your code is good too.
Maybe you should use an unmanaged package with your first few customers that might be willing to deal with export uninstall, re-install and import everytime there is a change. Once you get it sorted out, then move to a managed one. If you start having too many customers, supporting the upgrades will be difficult with an unmanaged package.
What components do you have in your app that you're concerned about? Tell a bit about it's setup and what might be changing and I can give you my 2 cents.
For the most part, I am worried about my object model changing - I might want to get rid of fields or modify them in my object model (e.g check box to a pick list or vice versa) and in an extreme case, get rid of an object..
My package has custom objects, custom object fields, extensions to standard account/contact object, custom s-controls/buttons/links/, workflow rules and a bunch of triggers and Apex classes.
I can also think of changing other things that seem disallowed in a managed package - tabs that appear in my applications (seems like that is disallowed), whether a custom button/link appears or doesn't, along with associated s-control, e-mail templates, and whether some workflow rules should exist.
I know I can change apex code (though not the signature) and the triggers...and that's good.
If I go with unmanaged package, "bug" fixes, I guess I can deliver by pushing code using Eclipse or something I guess, instead of requiring a reinstall of new package.
How painful is uninstall and upgrade for unmanaged packages? - I am worried about reimporting data that involves those look up and parent-child fields - do they have to done manually or can the Ids be retained?
Seems like salesforce exports the Raw Ids.
So if I have a parent custom object, it exports the Ids.
For child records, it exports the parent id.
When importing back, seems like you can't reimport the old ids - it creates them from scratch.
So when importing child records, you are stuck with the task of mapping child records manuallly by replacing useless ids with a parent identifies - the "name" - seems pretty painful.
http://community.salesforce.com/sforce/board/message?board.id=appexdirectory&message.id=156
If I go with an unmanaged package, does someone know how to get around the Parent/Child ID issue I highlighted above?
Just a thought. I'm sure it's harder than it sounds.
When a package is uninstalled, a data backup is automatically generated, however there are many restrictions trying to uninstall and reinstall. These restrictions are listed in the online help and include -
Salesforce converts date fields into date/time fields upon export. Convert the appropriate fields into date fields before you import.
Salesforce exports all date/time fields in Greenwich Mean Time (GMT). Before importing these fields, convert them to the appropriate time zone.
The value of auto number fields may be different when you import. To retain the old values, create a new custom auto number field on a custom object before importing the data.
Salesforce updates system fields such as Created Date and Last Modified Date when you import. To retain the old values for these fields, contact salesforce.com support.
Relationships are not included in the export file. Recreate any master-detail or lookup relationships after importing your data.
Record type IDs are exported but not the record type name.
Field history is not exported.
Any customizations that you made to the app after installation must be recreated.
So trying to do any sort of uninstall re-install is not very practical and would require a large amount of work by your customers.
Managed packages will not be locked down forever; deletion, deprecation, and refactoring are on the roadmap.
Another important distinction - if your application is a native application and an unmanaged package you will not have any controls over the licensing beyond a password on install. For managed native applications the next version of the LMA will allow you create trials, limit the number of users, expire the license etc.
Here are some other thoughts, I have been able to glean/put together
1. Since beta managed packages can be installed in sandbox, and sandbox specially in UE almost function as production, that might be another strategy
2. If components of managed package are added to an unmanaged package and uploaded, apparently, the prefix is stripped.
3. Keeping the master version of code/objects not in a DE, but in source code control and push it to multiple developer orgs to create multiple managed packages
4. Keep managed package object model as small as possible early on- you can always expand, you can't shrink!
In my case, the design (new fields / objects ) are kind of frozen and I expect only the code to change (calcualtions part) so I am left with few questions as below:
1. If I get my package published as a managed package on app exahnge and a customer raises an urgent bug to fix, how much time can it will take to update the package so that the customer gets the updated contents? do I need to go over same process like security etc or It can be an instant update.
2. How do I control and charge my customers with licenseing control on how they install on how many org and setup their payment system.
1. What you can do is create the version, send it to the client to update and fix his issue with it, and then you can trigger the verification process if you must/want verify it.