Monday, November 24, 2008

Openbravo ERP 2.50 introduces modularity support - why should you care?

Openbravo ERP 2.50, freshly released in alpha status, introduces many significant architectural enhancements in our ERP platform. Chief among them is modularity support.

With modularity, developers adding new capabilities to Openbravo ERP are able to easily extract, package and redistribute their extensions. Users of Openbravo ERP, on the other hand, are able to browse public extension in a central catalog, and download and install them from there, very much in the same way that they install browser plugins.

This modularity mechanism overcomes one of the most significant limitations of earlier versions of Openbravo ERP. In those releases, users were allowed and encouraged to change and extend the core product to adapt it to their specific requirements. The problem, however, was that once developed, it was very difficult to distinguish the extension from the core. As a result, it was virtually impossible to manage the extension independently.

People wanting to distribute new functionality were essentially limited to two options:
  1. Build their features directly into core in strict collaboration with the Openbravo core development team and transferring their code under the terms of the Openbravo Contribution Agreement; or
  2. Manage an entire version of Openbravo, assuming the overhead of not only supporting their own extensions, but the full Openbravo ERP base, including core and extensions.

Modularity resolves this problem by properly separating the ownership of software artifacts within the system. Each artifact, regardless of its type (database object, meta data registered in the Application Dictionary, source code, binary library or reference data) is owned by one and only one module. It is therefore possible, literally at the press of a button, to isolate, extract and package in a reusable container any individual extension.

Once packaged, a module is contained in a single obx file, which makes it very easy to transport it and to re-use it in different environments.

Additionally, in case developers want to share their work with the rest of the Community, they can very easily publish their modules to a Central Repository. Other users are then able to browse the Central Repository in search of modules providing features that are relevant to them, and easily deploy them to their environment.

So...why is this so important and why should you care?

If you are a developer, a system integrator, or an independent software vendor, modularity enables many interesting things for you:
  • Distributed development - Developers can now develop and distribute additional functionality in a totally independent manner with minimal interaction with the Openbravo development team.
  • Lower barriers to contribution -  Contributing to Openbravo core is quite time consuming. Core features need to be general enough to be used by different users, in different industries and different geographies; they need to be fully aligned with the current Openbravo architecture and its future directions; they need to be multi-lingual and platform independent; they need to be tested on both Oracle and PostgreSQL; they need to be thoroughly documented, fast and scalable. All of this takes a considerable amount of effort.
    With modules, on the other hand, developers have a lot more control on the amount of investment they want to make. They can choose to do all of the above; or they can do less. They can, for instance, decide to develop a feature that targets only one industry; or to develop it in only their native language; or to support only one specific database. These trade-offs will limit their audience, but that is perfectly OK for a module and, if the modules proves to be successful, it can always be broadened in subsequent versions.
  • Shorter time to market - Core contributions can only be published together with Openbravo ERP, typically in the next version of the product. On the other hand, because modules have an independent life cycle they can be published as soon as they are ready.
  • Global reach for all contributors - Anybody, anywhere, can publish a module to the Central Repository and anybody, anywhere, can download modules from it.
    Thanks to that, module developers in our Community now have a channel to distribute their independent work anywhere in the world, taking advantage and leveraging the global Openbravo Community.
  • Licensing freedom - Because modules are distributed independently from Openbravo ERP, module authors have the flexibility to choose their preferred license. They can distribute their work under the Openbravo Public License, but they can also choose GPL, BSD or any other license. Module authors can even choose to distribute their work under a proprietary license that allows them to commercialize their efforts.
  • Community collaboration - Because modules are published in the Central Repository, all developers in our Community are informed of what others are doing, and can decide to reuse and collaborate instead of restarting from scratch. For example,  an ISV interested in providing an advanced Human Capital Management pack, rather than starting from ground zero, could reuse an existing personnel management module and an existing payroll module developed by other Community members. The ISV could then complete the solution by developing a brand new recruitment module, package, and deliver the whole thing as a single solution pack.
  • Development scalability - As a consequence of distributed development, the Openbravo development team, with its limited capacity, is no longer a constraint to our Community's ability to grow and to advanced the overall value of the Openbravo ERP solution.
  • Drive-by contributions - I first heard this term reading one of Matt Asay's posts and I immediately loved the idea. The concept is that people rarely start a project with the idea of contributing it to the common code pool of the community. In most cases, they just do something because they need it, and the success of an open source community largely depends on its ability to capture and leverage these efforts, enabling people to contribute their work while driving-by, on their way to somewhere else and without getting too much out of their way.
    One of the small but very important features of 2.50 is that Openbravo Core is itself a module, initially delivered in status "not in development", which means that, by default, it cannot be modified. While it is possible to change this default setting, now the natural behavior is to implement extensions and personalizations as separate modules. If later developers realize that what they built is of generic interest and decide to package and publish it, they can do so very simply, by just pressing a button. It's that easy, and it does not require them to plan ahead. They can do it on their way to the implementation project, without having to think twice.
If you are a user, modularity will bring you the following benefits:
  • Broader and deeper functional coverage - Because of the points above, soon our users will be able to choose among a very large set of available modules, which will enable Openbravo ERP to support all sorts of functionality, targeting many different industries and companies of all sizes.
  • Better localization support - We expect that our localization support - a key success factor for an ERP - will dramatically improve. Today every implementation project, in every country, needs to develop a number of custom extensions to meet local business practices. Local legal reports and declarations, connectors to local banks and support for local payment methods are only examples of things that every implementation needs to sort out. Thanks to the drive-by contribution power of modularity, all of these customizations can be easliy published as modules facilitating local communities to leverage each other's work and experience.
  • Lower total cost of ownership and improved ROI - The broad availability of extension modules, some of them packaged as implementation templates targeting specific verticals in specific geographies, will simplify most implementations  to the selection and assembly of pre-existing compenents. Eliminating most of the effort in custom development will dramatically drive down the implementation costs, making the leading  open source ERP solution accessible to an even broader class of enterprises and further improving the return on investment for everybody.
  • Reduced implementation time and faster ROI - Minimizing custom development will shorten the implementation time, producing a faster return on investment for all projects and allowing users to join the revolution and start enjoying the benefits of their Openbravo ERP in a shorter period of time.
Modularity is a very significant step forward in the progression of the Openbravo ERP project. Starting from 2.50, Openbravo, the company, ceases to be the only party with the power and authority to move Openbravo ERP forward. That responsibility is now shared with an ecosystem of users, developers, system integrators and independent software vendors that together form a fully empowered Community, able to unleash the full potential of open source.

For all of these reasons, Openbravo ERP 2.50 is a seminal release for our project. Please help us to stabilize it and quickly bring it from alpha to production status by installing it and helping us with testing. You can also experience the power of modularity by developing a module of your own: simply follow the Developer's Guide and you will be ready in no time. If you are unsure of what module to build, we can even provide you with some ideas.

In any case, do not forget to give us your feedback by posting your comments in the Early Releases Discussion forum.

1 comments:

McDiesel said...

Well done. A carefully thought out long list of reasons. Look forward to using it.