If you’ve been following any of the work from force.com labs you’ll notice there’s (usually) three ways to get a copy of the apps and tools they build: managed package, unmanaged package, and raw source code. This is where things get tricky, there’s little to no simple, human readable explanations on the upsides and downsides of each unless you dig through almost all of the various developer documentation salesforce offers. In my work at Bluehawk Networks I’ve had extensive experience with managed packages, and my open source and internal salesforce admin work has acquainted me quite well with unmanaged packages. Without further ado:
Managed Packages are the easiest to install and upgrade, they can go right into production orgs (not advised), but more important for any orgs that have their own apex: test code from the managed package can fail and not kill your own deployments. Even better than that the code in the managed package doesn’t count against your 75% coverage totals! The upgrades are usually seamless, with a few catches: existing page layouts won’t update to the new package’s on an upgrade, and new picklist values can’t be added when upgrading a managed package. Both of these can be manually done, albeit with some annoyance. The downside however is the lack of customization in some areas:
- Packaged fields can’t be edited, meaning you can’t add lookup filters, change the number of visible lines on text areas, or change the number of characters allowed in a text field. And neither can the publisher, so asking isn’t going to do any good.
- If you’re building packages yourself be wary: using a managed component will add a required dependency on that package for yours. Think carefully how much you trust the publisher to continue to exist before you forever link yours with theirs.
Bottom line, unless you want to make customizations not allowed by managed packages, or are building packages yourself this is generally the best option. It’s also the only one with support for easy and clean upgrades.
Unmanaged packages are on the other hand much easier to customize, none of the included components are locked in any way, or for that matter even flagged as belonging to the package. You can delete fields, change any of their attributes, add lookup filters, etc. However test failures from these packages will cause your code deployments to fail, and their coverage is mixed in with yours. Once the package is installed it’s effectively as if you had written it all yourself. The next issue comes when (or if) you need to upgrade to a new version: you cannot upgrade unmanaged packages without totally uninstalling and reinstalling it. This of course destroys all the data you created in it, any customizations, profile settings, everything. You can work around this by creating a sandbox, uninstalling it, installing the new version, and then using the IDE to deploy the new components to your org.
Bottom line, if you don’t understand how to deploy from the IDE and ever plan on upgrading these are exceptionally painful. I only recommend them if managed packages prevent something you need to do and you don’t plan on upgrading them in the future.
Last is raw code, this means firing up the IDE, pulling the code down from google code or github and deploying it from there. Despite sounding scary this is actually far easier to manage than upgrading managed packages. Upgrades are almost seamless: check out the new code, save it to your sandbox, and then deploy to production. The biggest downside here is having to have a familiarity with source control tools and the IDE to make it work.
The bottom line
The best choice if you can’t use a managed package and have any sort of interesting in upgrading the application. In the long run you’ll save yourself from ripping out a few chunks of hair if you avoid unmanaged packages.