by Paolo Juvara
Openbravo 3.0 is going to be a landmark release for the Openbravo ecosystem for many reasons, ranging from improved functionality to a completely revised platform.
As the first release candidate milestone of Openbravo 3.0 approaches (the target release is July 2010), I would like to take the time to explore one specific area of innovation: the packaging and delivery of the product.
Unlike previous releases, where Openbravo was offered as a monolithic product on top of which users could install extensions, Openbravo 3.0 is going to be delivered as "distribution" of modules. By distribution, I mean a collection of modules - one of which is Core - selected and integrated to achieve the desired functional footprint of the release.
This approach presents several advantages, including a smoother upgrade for 2.50 users and the ability to reuse 2.50 modules in 3.0. The following presentation illustrates the concept.
Leveraging the modular architecture of 2.50, we have been providing extension modules on top of Core. Some of those extensions are technology oriented, like the Seam Integration or the new User Interface Selector, while others, like Advanced Payables and Receivables, are functional in nature. In both cases, these are pre-3.0 features that can be deployed as modules on top of 2.50.
We can continue to release such modular components until we have all the building blocks we need for 3.0.
This is an effective way to add new capabilities but for 3.0 we also need to remove some unwanted features from Core, in some cases because it is obsolete functionality and in other cases because it is more appropriate as a module rather than a core feature.
Removing functionality is tricky: if we eliminate the code, in fact, we take the risk of breaking a dependency for an existing module therefore negating the objective of ensuring a smooth upgrade and the durability of modules. To avoid this problem, we will improve the License Manager capabilities of Core: currently the License Manager is the technology that allows us to distinguish between a Community Edition and a Professional Edition; we intend to enhance its capabilities to allow us to securely hide unwanted features and ensuring that they cannot be accidentally re-enabled. While still physically present, the unwanted features will be for all intents and purposes de-activated.
Leveraging this technology, we can deliver Openbravo 3.0 as a "template" that combines all the desired modules, plus a configuration script that defines the default configuration of the system.
We have already followed a similar approach for QuickStart, one of the professional solutions that we developed for our partners in 2.50 and we will apply the same technique for 3.0.
Using our 3.0 distribution as starting template, it is then possible to add further configuration scripts and provide additional specializations. In this respect, this packaging approach provides a nice balance between the base product and its vertical specializations as both solutions share the same development and distribution approach.
There are some obvious benefits to this approach:
With 3.0 we fully embrace the distribution approach, coming to a full circle and confirming our commitment to build the ecosystem of reference in the open source ERP space.
As the first release candidate milestone of Openbravo 3.0 approaches (the target release is July 2010), I would like to take the time to explore one specific area of innovation: the packaging and delivery of the product.
Unlike previous releases, where Openbravo was offered as a monolithic product on top of which users could install extensions, Openbravo 3.0 is going to be delivered as "distribution" of modules. By distribution, I mean a collection of modules - one of which is Core - selected and integrated to achieve the desired functional footprint of the release.
This approach presents several advantages, including a smoother upgrade for 2.50 users and the ability to reuse 2.50 modules in 3.0. The following presentation illustrates the concept.
Leveraging the modular architecture of 2.50, we have been providing extension modules on top of Core. Some of those extensions are technology oriented, like the Seam Integration or the new User Interface Selector, while others, like Advanced Payables and Receivables, are functional in nature. In both cases, these are pre-3.0 features that can be deployed as modules on top of 2.50.
We can continue to release such modular components until we have all the building blocks we need for 3.0.
This is an effective way to add new capabilities but for 3.0 we also need to remove some unwanted features from Core, in some cases because it is obsolete functionality and in other cases because it is more appropriate as a module rather than a core feature.
Removing functionality is tricky: if we eliminate the code, in fact, we take the risk of breaking a dependency for an existing module therefore negating the objective of ensuring a smooth upgrade and the durability of modules. To avoid this problem, we will improve the License Manager capabilities of Core: currently the License Manager is the technology that allows us to distinguish between a Community Edition and a Professional Edition; we intend to enhance its capabilities to allow us to securely hide unwanted features and ensuring that they cannot be accidentally re-enabled. While still physically present, the unwanted features will be for all intents and purposes de-activated.
Leveraging this technology, we can deliver Openbravo 3.0 as a "template" that combines all the desired modules, plus a configuration script that defines the default configuration of the system.
We have already followed a similar approach for QuickStart, one of the professional solutions that we developed for our partners in 2.50 and we will apply the same technique for 3.0.
Using our 3.0 distribution as starting template, it is then possible to add further configuration scripts and provide additional specializations. In this respect, this packaging approach provides a nice balance between the base product and its vertical specializations as both solutions share the same development and distribution approach.
There are some obvious benefits to this approach:
- Easy upgrade for 2.50 users to 3.0: technically, an upgrade is reduced to the installation of additional modules and a configuration template (of course, there are many non technical aspects involved with an upgrade, but avoiding technical problems already simplifies the challenge)
- Guaranteed durability of modules: all of the 2.50 modules will be able to work in 3.0 as well because none of their dependencies is altered.
- Opportunity to gather early feedback on 3.0: we do not need to have 100% of the functionality ready to start exposing it to our community. In fact, many of the 3.0 modules have already been independently available for several months and went through their own feedback and stabilization cycle.
- Reduced maintenance cost for 2.50: since 2.50 and 3.0 share a common Core, the cost of maintenance will be largely reduced.
With 3.0 we fully embrace the distribution approach, coming to a full circle and confirming our commitment to build the ecosystem of reference in the open source ERP space.
source: http://planet.openbravo.com/
No comments:
Post a Comment