I am starting to learn more about managed packages, and if I'm understanding things correctly only one managed package is allowed per developer organization. Therefore if I had two applications that shared some common code and I wanted to be able to sell them separately, one way to set things up would be as follows:

Approach 1

-----------------

1) Create a dev org which contains a managed package containing common shared code and config -- namespace BASE.

2) Create a dev org which contains a managed package containing code and config specific to app1 -- namespace APP1. APP1 has classes that inherit from and use classes and config contained in BASE.

3) Create a dev org which contains a managed package containing code and config specific to app2 -- namespace APP2. APP2 has classes that inherit from and use classes and config contained in BASE.

Advantages: There is no dual maintenance of code since functionality is cleanly delineated into separate packages. APP1 and APP2 can be installed and sold independent of one another.

Disadvantages: During development, if changes occur in BASE those changes will need to be pushed into the APP1 and APP2 dev orgs. When installing from the app exchange, users will need to be sure to install BASE before installing APP1 or APP2. Developers may find that functionality originally developed in BASE really belongs in an APP (or vice versa), requiring refactoring.

Approach 2

-----------------

1) Create a dev org which contains managed package code and config for BASE, APP1 and APP2 combined.

Advantages: addresses all the disadvantages detailed in Approach 1. Also only one dev org needed.

Disadvantages: Package could grow extremely large as more apps are added. If user only purchases APP1, must find a way to disable their access to APP2 components (or vice versa).

Are there other approaches that I'm missing? Any thoughts on a 'best' design pattern to address this problem?

Thanks!

SandyB