Skip to content

Beware of the Unmanaged Package!

“Every time an unmanaged package is installed in a production org God kills a kitten.”

I was recently asked to comment on the practice of using unmanaged packages to distribute applications on the Force.com platform.  Apparently claims were being made that this was great news for customers because it provided great flexibility and openness. I’ll make my position clear from the outset that I think this approach is BAD NEWS for customers.

The differences between managed and unmanaged packages on the Force.com platform are very well described here – https://wiki.developerforce.com/page/An_Introduction_to_Packaging but in a nutshell:

Unmanaged packages are bundles of components that provide a simple method to move customizations between orgs together with any associated source code.

Managed packages provide developers with a way to distribute components that can be automatically updated, are licenseable & trackable and prevent changes being made that would prevent seamless upgrades in the future.

For sure there is overhead involved in building and distributing apps in this managed way but the benefits to customers are very clear:

– Managed packages can be upgraded automatically by the provider so upgrades and fixes can be pushed to your org as required. Contrast that with an unmanaged package where, once installed, components have no connection with the org from which the package originated and as a result your provider will always need direct access to your org to make any fixes or updates.

– Managed packages are protected so that fundamental business rules and logic cannot be broken either by accident or maliciously which is something your auditors will appreciate.

– Managed packages support namespaces and versioning so they won’t impact the installation of other packages you may chose to install in your org.

– Managed packages allow you to control access to the application and the application’s data via the standard Salesforce licensing mechanism.

– Managed packages do not count against your org limits for tabs and custom objects whereas unmanaged packages will count against those limits.

Distributing applications via unmanaged packages also represents a significant risk for your provider as all the intellectual property contained in the source code is fully exposed and can be copied, edited and distributed in plain text.

So beware anyone that tells you installing unmanaged packages into your Salesforce org is a good idea.  It may appear to save you money up front because it’s a very cheap although primitive way of software distribution on the Force.com platform but in so doing you are very likely heading down a path to fragile, unsupportable, unupgradeable systems that will become increasingly costly to keep running in the future.

Simply put, if your provider is distributing its “app” via unmanaged packages you aren’t getting a product in any true commercial sense rather you are simply getting a loose collection of customizations specific to your org with many of the costly, high maintenance pitfalls that gave old style ERP implementations such a bad reputation in the last century.

Contact us
See a demo