+ Start a Discussion
GoForceGoGoForceGo 

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!!!




Best Answer chosen by Admin (Salesforce Developers) 
GoForceGoGoForceGo
Thanks folks.

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

hemmhemm
Some additions:

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:
  • Your customers can alter your code (s-Controls, JavaScript,etc.).  You will probably be supporting them banging your head against the wall wondering what went wrong only to finally find out that they edited something in your code to "improve things".

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
GoForceGoGoForceGo
Thanks Hemm.

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?









hemmhemm
You are correct about not being able to delete objects and fields.  I guess it comes down to how much you think your design will change.   I'd have to know more about your application and architecture to give you more detailed recommendations.

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.
GoForceGoGoForceGo
Thanks Hemm.

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?










GoForceGoGoForceGo
Seems like uninstalling an unmanaged package, exporting the deleted data and reimporting the data  after a new version of an unmanaged package is installed seems pretty painful

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.



GoForceGoGoForceGo
I look at this old thread on managed package, which confirms some of my suspicions.

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?


GoForceGoGoForceGo
One way I know of getting around the Id issue is to export reports to excel with Name fields - but one would have export each object data manually, one at a time...




hemmhemm
You are in a bit of difficult position as there are benefits on both sides.  Try and get the managed package to work for you.  Some ideas (not validated that it will always work):

  • Create "versions" of fields.  When setting up fields (e.g. "Status"), add a version number to the API name.  Since you can't change an existing field, you will need to create a new nearly identical field with a different API name.
  • Create "versions" of Page Layouts.  When you put out new releases, see if you can rollout a new Page Layout with each release.  This layout will only use the fields for that version.  If you had to change from Status_v1__c to Status_v2__c, the new layout will use the new fields
  • When a new version comes out, the user will get the new fields and new page layouts.  You'll need to instruct them to make maunal profile changes to assign the new layout to people.
  • Create an "Upgrade from x to y" s-control for each version.  Also create a link that invokes the s-control.  You could have a "Upgrade" page layout that only the admin sees.  You could instruct them to add the link to the layout.  When they click it, it runs the s-control that moves your data around as needed.
  • Once that's done, things should generally be the way you want them.  Users see/use the new fields and page layouts and the data has been migrated.

Just a thought.  I'm sure it's harder than it sounds.

GregCGregC
As a general rule unmanaged packages are intended to function as "templates", used for a one time only installation of a package. If you want to want to have tools to manage the lifecycle of a package, a managed package should be used. Managed packages can be upgraded, have license management, and are the focus of where future development will be.

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.
GoForceGoGoForceGo
Thanks folks.

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!


This was selected as the best answer
sfdevnicksfdevnick
GoForceGo, I have the same issue and am thinking that it might be best to go managed, and every so often (year or so) offer clients a major upgrade to include data export, fresh re-install, and re-import. Obviously not ideal, and of course a lot of work, but it does have a certain appeal of simplicity to it.
 
However, the part you say about being able to move components from a managed package to an unmanaged one.. I didn't know that was possible. Where can I find out more about that? I wonder whether you could use this ability to somehow "chain" your orgs with each tier corresponding to a different revision of the application?... But wait, surely only the exact same org that published the managed package can update that managed package, no?   Mmm.. can someone help us think that through.. 
 
Besides the upgrade issue, I have the additional related issue of development work common to more than one app and would like to minimize duplicate work. Had thought about a similar idea - a central hub org of unmanaged work, with satellite orgs converting to managed, etc. Again, though I havn't seen this explicity stated anywhere yet, I assume that only the exact same org that published the managed package can update that managed package..