Saturday, July 11, 2009

Status Update for June 2009

This is the latest installment of the status update series, which refers to the month of May 2009. You can see the consolidated updates on our wiki in a status update page.

Status update for June 2009
  • Maintenance packs
    • Openbravo ERP 2.50 MP2 was released to the community on June 30, 2009
    • Openbravo ERP 2.40 MP5 was released to professional subscription customers on June 16, 2009
    • Openbravo ERP 2.40 MP6 was released to professional subscription customers on June 19, 2009
    • Openbravo ERP 2.35 MP13 was released to professional subscription customers on June 10, 2009
    • Note: Openbravo ERP 2.50 Professional Subscription SMB Appliance released on June 15
  • Core enhancements:
    • The following enhancements have been completed and released as part of 2.50 MP2:
      • Ability to generate a provisional Balance Sheet report for open periods (feature request 9069)
      • Ability to search Windows, Tabs and Fields by module (feature request 9022)
      • Support for BLOB data types in DAL (feature request 9313)
      • The publicly usable java classes should be defined and all non-public ones should not be accessible by modules (feature request 9317)
      • Change tab name from 'Salary Category' to 'Cost Salary category' (feature request 9044)
      • Performance: Add infrastructure to VariablesBase class to allow for technical validation of request parameters (feature request 9500)
      • Performance: Use the new ignoreValues features of sqlc to speed up filters with value '%' (feature request 9549)
      • Performance: Ignore the value '%' in select which use like (feature request 9545)
    • The following enhancements are available in the pi code repository and will be released as part of 2.50 MP3:
      • Performance: optimize Product selector on oracle to be faster with many products (feature request 9562)
      • Performance: remove extra request for the MessagesJS in generated pages (feature request 9727)
  • Defects
    • A total of 130 defects have been resolved, with the following breakdown by severity:
      • 12 critical
      • 87 major
      • 27 minor
      • 4 trivial
  • Infrastructure

In addition, the Openbravo Community released the following new 2.50 compatible modules:

  • Fiscal Calendar Enhancements
  • Fiscal Calendar Enhancements Template
  • Report Sales by Month
  • Romanian chart of accounts
  • Romanian language for Romania
  • Romania Administrative Departments
  • Translation: Arabic_Saudi Arabia (ar_SA) for Openbravo 2.50

Finally, we made progress in the following areas that have not yet been released:

  • We also advanced in the definition of the next version of the Spanish Localization pack intended for the Community as well as the Spanish Professional Localization intended for Professional Subscription customer.

Sunday, June 7, 2009

Status Update for May 2009

This is the second installment of the status update series, which refers to the month of May 2009. You can see the consolidated updates on our wiki in a status update page.

Status Update for May 2009
  • Product releases
    • Openbravo POS 2.30 Community Edition was released in production status on May 20, 2009. This is a significant new release with extensive new capabilities; please see the Release Notes for details.
  • Maintenance packs
    • Openbravo ERP 2.50 MP1 was released to the community on May 15, 2009
    • Openbravo ERP 2.40 MP4 was released to professional subscription customers on May 26, 2009
    • Note: Openbravo SMB Network One appliance for 2.40 MP4 introduces an improved approach to apply maintenance packs.
  • New sample modules:
  • Core enhancements:
    • The following enhancements have been completed and released as part of 2.50 MP1:
      • Accounting templates (feature request 8467)
      • Ability to run jUnit test cases from the command line (feature request 8562)
      • Goods receipts Copy Lines window has 'order' label column instead of 'order line' (feature request 8529)
    • The following enhancements are available in the pi code repository and will be released as part of 2.50 MP2:
      • Ability to filter and group by bank account in the Payment Report (feature request 8162)
      • Display business partner in the Payment Report even when not grouping by business partner (feature request 8777)
      • Added PDF capabilities to the following reports (feature request 8474):
        • Bank Report
        • Cash Report
        • Invoice Tax Report
        • Expiration Date Report
        • Stock Report
        • Daily Work Requirements Report
        • Standard Costs Report
        • Production Run Status Report
        • Pending Work Requirements
      • Sqlc-generated data classes are not public unless explicitely declared as public (feature request 9230)
  • Defects
    • A total of 149 defects have been resolved, with the following breakdown by severity:
      • 19 critical
      • 79 major
      • 45 minor
      • 6 trivial
  • Infrastructure
    • Added the following automated tests to the Continuous Integration framework at builds.openbravo.com
      • Database consistency check
      • Module installation test
      • Module integrity test
  • Documentation
In addition, the Openbravo Community released the following new 2.50 compatible modules:
Finally, we made progress in the following areas that have not yet been released:

Tuesday, May 19, 2009

Extend, don't customize

Introduction
Every business is different and every company adopts different business practices. As a consequence, every ERP implementation is different and being able to adapt the software to the customer's specificities is a key characteristic of a good ERP package.

In this area, open source has a clear advantage compared to proprietary solutions thanks not only to the access to source code but also to the free availability of knowledge about the inner logic of the product.

Openbravo ERP, in particular, has been designed and managed considering the need for adaptation as a key requirement:
  • Its model driven architecture enables users to change standard functionality in a very easy manner.
  • The free flow of information available on the project wiki and forums have empowered the community to make changes to even the innermost core part of the product.
This openness and flexibility provides great power to implementor and allows them to customize the product to meet practically any business requirement.

However, as Ben Parker said, "with great power comes great responsibility" and in this case the great responsibility is to your own implementation as it is very easy to abuse this great customization power and change the product to the point where you can no longer afford to upgrade it nor benefit from the improvements made by the rest of the community.
If you are not very careful, it is very easy to find yourself in a position where you are either stuck on a product version that will eventually age and become obsolete or you have to bear the burden of maintaining and evolving the full solution instead of only your code. In both cases, you started with a packaged off the shelf application and you ended up with a bespoke piece of software.

It is important to notice that this danger exists both in open and closed source software. Countless literature has been published on the topic of customizations and upgrade nightmares and the prevailing wisdom is that, for mature ERP packages, customizations should be avoided at all costs. Many experienced implementors also recommend that a vanilla solution should be adopted for the first few months of production usage as many users discover that customizations initially thought essential are in fact not needed.

The problem of excessive customization, however, is much more pervasive in open source software because:
  • Often the open source solutions are more recent and innovative than their proprietary counter parts but not as mature; therefore, the pressure to customize is stronger.
  • Most importantly, the "hacking ethos" of the open source movement makes open source implementors culturally more disposed to implement invasive customizations.
Openbravo to the rescue!
Openbravo ERP 2.50 introduces a set of very powerful adaptation techniques that will allow you to personalize the software to meet your unique needs without the need to customize it.

This approach guarantees that you will be able to apply patches and maintenance packs without impacting your adaptations and minimizes the cost of upgrading from one major version to the next.

The core principle of these techniques is summarized in the title of this blog: as you design your adaptations, you should think of them as extensions and not customizations.

Openbravo ERP 2.50, in fact, introduces support for modularity, which allows you to define and package additional functionality and configurations as extension modules, independently from the core product.

One of the key features of modularity is that your configurations are also defined as extension modules. Because of that, they are kept separate from core and you can safely update the latter without touching you configuration.

Let's see how it works. To start your adaptation process you need to set the system in Configuration mode. You can do that by navigating, in System Administrator role, to General Setup / System Info and checking the box Customization Allowed (see picture below).


This will automatically create a template called "System Customization" and any configuration change or addition that you make will be added to this template.

In this template, you can safely modify the Openbravo core model (the meta-data that describes Openbravo ERP out of the box) and you can add your own model elements, such as new windows and processes. You can also add code-based artifacts such as new PL/SQL functions or Java classes and add or modify their corresponding calling points within the application.

What you can do is practically unlimited and, most imporantly, it is always update safe.

Examples
To illustrate this principle, I would like to consider a few concrete examples.

Let's start with something simple. Let's assume that your adaptation consists in modifying the default screen layout for the Sales Order screen, to change the order of the fields, hide some that are not needed in your business, and rename some labels. After having set the system in customization mode, you would proceed by performing your configuration changes in the same way you did in 2.35 and 2.40 by navigating to the Application Dictionary / Windows, Tabs and Fields, querying the definition of the Sales Order window and modifying its configuration there. Similar to previous releases, to see and test your changes you then need to rebuild the system.
What is new with 2.50 is that, once you are satisfied with your application, you can export your configuration script using the export.config.script ant task and that at this point your configuration is saved in the file system.
If at a later point in time you need to apply a core maintenance pack, you can do so safely because the pack will override the files for the core module but it will not touch your configuration file. Once the system is rebuilt, you configuration is considered once again and automatically applied to the updated core.

This is a much easier process compared to previous versions when your configuration changes were saved in the same files as core definitions and you therefore had to go through a very difficult and error prone merge process to apply the maintenance pack without loosing your adaptation.

Let's consider another example. In this case, we will assume that your adaptation consists in creating a new window. After having set your system in customization mode, you can define and declare the new tables that are needed to support your window and proceed by defining the window in the Application Dictionary. If you are not an experienced Openbravo developer, you can follow the tutorial in the Developer's Guide for step by step instructions.
The concept is very similar to the previous example and in this case as well your adaptation will be saved in a separate set of files and preserved when you apply maintenance.

A difference worth mentioning in this case is that you need to create your new window as a module separate from the "System Customization" template; this will give you more flexibility, including the option of reusing this window in another Openbravo instance without having to share the full configuration; you can even publishing it to the whole community leveraging the Central Repository.

This process can be extended directly to very similar examples, like adding a new report or a new background process. In both cases, you can adapt your system through extensions that are both easy to implement and maintenance safe.

At this point, you are probably thinking that this is quite good for configuration changes and additive extensions but you might be wondering how can you modify core. For example, does Openbravo let you add a column to a core table and a new field to the corresponding window?
Of course, it does. Just create a module and follow this tutorial. The concept is the same and, in this case as well, your changes will be preserved when you apply the next maintenance pack.

You want something very sophisticated? How about adapting the accounting logic to account asset depreciation in a different manner?
This is easy is easy to do. You need to define a module that contains a small Java class that implement your asset depreciation accounting logic and declares it in Openbravo as an accounting template

Impressive, isn't it?

So, what are some of the limitations? Well... they are not many, but the major limit is caused by the fact that the lowest level of modularization is the finest grained software artifact.
This is very fine grained in the case of Application Dictionary elements where you can adapt the software at the level of the individual property. However, it is less fine grained in the case of code, where you can adapt by logical file replacement: you add a module with the new file that substitutes the core one and you repoint the calling points as a configuration.

For example if you need to modify a core report, the lowest level of granularity is the jrxml file and you will need to create a module that includes a copy of the original core report and make your changes there; you then need to change the report declaration in Application Dictionary to invoke your modified report in lieu of the core one.
The consequence of this is that you have now taken the ownership of the whole report and that maintenance changes to the core file will not impact your adapted one.
Depending on the extent of your changes, this might or might not be an undesirable effect.

Similarly, if you want to modify a selector to, for example, add a column in the results table, you will need to create a copy of the full selector and maintaining it from that moment onwards.

In most cases, this is a small limitation and does not cause any significant issue. In a few circumstances, however, it does result in adaptation modules that are too large compared to the desired change in functionality. A typical example is a small change required in a database procedure like C_INVOICE_POST that will require you to own and maintain the whole procedure.

We have been uncovering cases like this working with the early adopters of release 2.50 and our experience has been that we can easily refactor these components so that there is always a clean way of plugging-in your extended logic without the need to take over the full component.

Because of that, I encourage you to contact us if you find yourself in that situation; in most cases, we can work with you and make small changes to core that will make your extension much easier. If you are a partner or a professional subscriber, you can request our assistance through your Channel Business Manager or through the Openbravo Support portal respectively; if you are a community user, you can contact us using the Help forum.

Do you still want to customize?
We strongly believe, and our experience so far confirms it, that using the techniques that I illustrated above, you can meet any adaptation need through extensions rather than customizations.

That said, since Openbravo ERP is an open source solution, you continue to be free to change its code. You need, however, to be conscious that this freedom comes with a high price tag in terms of maintainability.

The only legitimate reason to customize core is when you find a defect and rather than relying on a fix provided by Openbravo, you decide to implement the change yourself. In that situation, we would strongly encourage you to report the defect in the issue tracker and - if possible - to contribute your fix as a patch attachment to the issue. By contributing your fix, you can be sure that it will be included in the subsequent maintenance pack as well as in the next release; this way, when you update or upgrade your system, you will not have to neither merge the code nor reimplement the fix.

In the unlikely event that your really cannot meet your requirements through an extension, first I would encourage you to contact us before considering a customization: we might be able to make a small core change that makes your extension possible.
You should also consider whether the benefits of the customization are really worth the maintenance problems that they are going to cause. Perhaps, you can trade off that functionality in favor of ease of maintenance.

In the end, if you decide that you still want to customize core, you can follow the same approach that was recommended with 2.35 and 2.40: manage your customizations as source code and merge your development stream with our maintenance stream using a source control tool like Mercurial. Even in this case, Openbravo ERP 2.50 will result in a better experience than previous releases and the effort of resolving conflicts will be much lower because:
  1. A good portion of the customizations should be done through modules anyway
  2. The only core customizations are likely to be for code and not for meta-data and merging code is a lot easier than merging the XML based meta-data.
Above all, remember: extend, don't customize!

Friday, May 8, 2009

Status Update for April 2009

Starting from this month, I would like to introduce a practice of sending regular updates to the Community on the recent achievements and progress of the product development organization.
My goal is that, before the 10th of a month, I would publish a quick update of what was done in the previous month.

This is the first installment, which refers to the month of April 2009. I will also consolidate these updates on our wiki in a status update page. The idea is to provide a complementary page to the product road map, where the product road map gives a forward looking view of where the product is going and the Status Update a historical record of the road we traveled.
In this context, I also just updated the product road map to make sure it is current.

Status Update for April 2009

Monday, May 4, 2009

Empowering the ecosystem

The major theme of the recently concluded Openbravo World Conference was "empowering the ecosystem".

Reading this tag line, you might be asking yourself: what does it mean to empower the ecosystem? More importantly, what is an ecosystem? How is that different from the community? Isn't open source about community?

Let's start with some definitions to clarify concepts.

For our purposes, you could define a community as a group of people that collaborate around a common project.
In the case of an open source project, some community members are developers, some are testers, some are users but they all provide value towards the development of the common project.

By contrast, an ecosystem is group of autonomous but interdependent communities that collaborate around a number of loosely coupled objectives and projects.

While the communities that animate an ecosystem are autonomous, they leverage on each other, and the value that they generate and can extract from their work as part of the ecosystem is much greater of what they could generate on their own.

Let's explore this with an example and let's consider one of the most successful ecosystems in the open source space: Linux.

Although Linux is now an OS platform of widespread usage, what users really adopt is not Linux by itself but a Linux "distribution".

Linux, in fact, is just the kernel; it manages processes and memory and provides a few other services that, no matter how important they are, are not visible to users.
Only when paired with other services like a command line interfaces and Unix-like tools, it becomes GNU Linux, the operating system itself.
At that point, you have a naked operating system, but you are still far from the powerful platform that competes with the likes of Windows and MacOS.
To get there, you need many more things; just to name a few: you need device plug and play capabilities, a window manager, a desktop environment, a browser, an office productivity suite, a music player, etc.

Most importantly, you need a repository of applications that works with well with your system. And that is, in my opinion, the major value added of a Linux distribution. It provides a whole system that has been put together for you, tested and validated to be working well holistically, from the Linux kernel all the way up to the last application.

A distribution is a very sophisticated system. Each of its components is developed as an independent project, with its own independent road map, its own code line, its own developers, and its own community of contributors.
These contributors are not necessarily interested in everything that Linux does (perhaps they are not even dedicated to only work with Linux) but only in the specific domain of their project.
Although independent, these communities leverage each other and together contribute to a winning combination that meet each user need.

And here is the power of the ecosystem: none of these communities could have achieved such a winning combination by itself, but as an ecosystem, they are unbeatable.

This ecosystem however is very chaotic. Not only each individual community has its own objectives, but each project brings in its own set of constraints and dependencies and they are not always compatible with each other.
If you were to assemble your own Linux system starting from each individual application, or you simply would like to install an application that is not part of your distribution's repository, you will soon found out that you have embarked in a very time consuming enterprise. "Google is your friend" is one of the most commonly quoted advices in Linux forums and Google will likely allow you to succeed, but only after a lot of searches for missing dependencies or conflict.
By contrast, by sticking to the applications in your distribution, everything is easy and everything works just fine because your distribution provider has gone through the process of vetting all dependencies and resolving all the conflicts for you.

The applications in your repository are proven to be working well together and a Linux distribution allows you to harness the power of the ecosystem without having to deal with its chaotic nature.

Now... how is this relevant to Openbravo?

The most significant innovation of version 2.50 of Openbravo ERP is the introduction of a modular architecture support that enables an Openbravo ecosystem very similar to the Linux ecosystem. In this analogy, Openbravo ERP itself is the core or kernel of the ecosystem and autonomous communities can collaborate on independent value added components that, when put together, can deliver the same level of value as a Linux distribution and make the Openbravo ERP ecosystem an unbeatable platform.

Let me introduce some of the concepts of modularity to better illustrate the similarity between Linux and Openbravo.

Modularity introduces three types of extensions: modules, packs and templates.

Modules are the atomic building blocks and deliver the individual functional extensions. They are the lowest level of granularity and the smallest element of reuse.
At the very least, they depend on Openbravo Core but they can also take additional dependencies on other modules.
Modules can deliver additional business logic, either in the form of additional code or additional meta data, or can deliver reference data.
Examples of modules are:
* a personnel data management window
* an alternative pricing engine
* a set of alerts to send notifications when a sales order is completed for a business partner at credit risk
* the Chinese translation
* the tax setup for France
* an integration with a web application such as the Google Calendar
* etc.

Because modules are atomic functionality and very fine-grained, we also wanted to provide a way to deliver complex solutions as an assembly of modules without forcing users to manage individual modules one at a time. That is why we have introduced the concept of packs, which are a collection of modules.
Example of packs are:
* a human capital management solution, made of modules for personnel data management, employee performance management and vacation management.
* a CRM system, made of modules to manage interactions, leads, opportunities and service requests.
* the French localization pack, made of the French translation, the French chart of accounts, the French statutory reports, the French connectors for electronic banking, the French tax setup, etc.

Modules and packs can add functionality but a very important element of an ERP solution is the configuration that allows to fine-tune the solution for a particular industry.
That is what "industry templates" - or simply templates - are about. They allow to delivered a combination of modules and packs plus a configuration file as a reusable, packaged solution that installs at the click of a button.
Examples of templates are:
* Openbravo ERP for retail
* Openbravo ERP for textile manufacturers
* Openbravo ERP for dental offices
* etc.

Besides extensions such as modules, packs and templates, there are two additional important concepts that enable the Openbravo ecosystem: the Central Repository and the Forge.

The Central Repository is the catalog of solutions where users of Openbravo ERP can look for extensions. Extension developers can publish their extensions in the Central Repository and any user of Openbravo ERP will be able to download it and use it. In other words, the Central Repository provides a very powerful distribution channel to extension developers: regardless of where they are located, how big or small they are, they will be able to reach the global community of users and leverage the full dissemination power of Openbravo ERP, with its 1.2 million downloads and counting.

The Forge provides extension developers with a collaboration environment which includes all the tools to develop an industrial strength software solution, such as a source control system and a tracker. Most importantly, it provides the infrastructure to develop and support an autonomous community around the extension project, including a wiki and a forum system.

Now that your are familiar with the modularity concepts, let's see how they contribute to the creation of a powerful ecosystem.

Openbravo ERP is at the center of the ecosystem, very much in the same way as the Linux kernel is at the center of the Linux ecosystem.
Extension modules complete and enrich the capabilities of Openbravo ERP, providing users with the same feature richness that applications provide to Linux users.
This feature richness is provided by autonomous communities that leverage the Forge as development and collaboration infrastructure and the Central Repository as distribution channel.
Because of the autonomous nature of these communities, we envision that the extension module creation will be somewhat chaotic in nature. Some modules will be complete and very high quality while others will be just started and then abandoned or not fully functional. Some modules will be developed redundantly by competing communities in the ecosystem. Some modules might cause conflicts or perhaps work well together from a a functional perspective but have conflicting dependencies.

This opens the door - and creates an opportunity - for people with the right domain expertise to select modules, validate their quality and fit for a specific purpose and vet their dependencies. This is a role conceptually very similar to the role of the distribution providers in the Linux world.
We envision that this role will be played by our community members who specialize in a specific industry and will be able to provide an industry template for that industry.
Very much like a Linux distribution, an industry template provides end users with a set of preselected modules and packs that have been chosen among the best that the ecosystem has to offer to address the needs of a specific vertical segment. An industry templates enables novice users in that segment to get an easy and safe on ramp in the Openbravo world, without the need to investigate the capabilities and fit of individual modules.
To system integrators and independent software vendors, industry templates provide an opportunity to deliver specialized, high value solutions, without the need to invest in the development of a platform or in commodity functionality.

This is the value we see in the ERP ecosystem and this the way Openbravo empowers it.

Friday, April 3, 2009

Factoids from OSBC

Last week, I attended OSBC, the Open Source Business Conference in San Francisco. This is the second year that I attend this event, and like last year, I found it to be a source of very interesting information and an opportunity to refocus on what really matters for a commercial open source vendor like Openbravo.

The term commercial open source itself was very much debated at the conference. As the open source movement is increasing its market appeal, many traditional vendors are jumping on the open source wagon by simply publishing a version of an existing product under an open source license. Are they commercial open source?

After a very stimulating conversation with Michael Fauscette, Group Vice President of Software Business Solutions at IDC, and Adam Blum, CEO of Rhomobile, I made up my mind on the topic. Rhomobile had recently published a blog post called "The Seven Habits of Highly Effective Open Source Products" and I concluded that a good definition of commercial open source product is:
  1. A product that is offered in open source format
    1. Open source license
    2. Source code available
  2. A credible community with a credible effort to involve the community in the development of the product, as described in Adam's seven habits:
    1. Public source viewing
    2. Common license
    3. Public source code checkins
    4. Public bugs
    5. Public forums
    6. Anyone can contribute
    7. Public, complete and modifiable documentation
  3. Ability to provide the same level of trust and comfort as traditional software vendor do to enterprises adopters. In particular:
    1. Availability of support
    2. Availability of maintenance
    3. Availability of training
    4. Availability of consulting
    5. Last but not least, a "throat to choke": the peace of mind of knowing that if something goes wrong, there is a company behind the software that will take the responsibility to make it work.
I like this definition. What do you think?

Another major theme emerging from the conference is that open source has now graduated and it is widely adopted by companies of all types, and for all types of usage. A session of particular interest was "Open Source Adoption: What Your Peers are Up To" by Jeffrey Hammond, Principal Analyst at Forrester Research.



This presentation, which leverages data from a study commissioned to Forrester by Bull, demonstrates that:
  1. Open source adoption is more advanced in Europe than the US
  2. While adoption is widespread at infrastructure level, it is rapidly moving up the technology stack and, among European companies declaring themselves as open source users, 60% of them have implemented or are about to implement an open source ERP.
  3. This adoption rate is higher than the one for BI, CRM, Content Management and ESBs, which are all categories generally considered more advanced in terms of open source traction.
Isn't this good news for Openbravo?

Saturday, March 14, 2009

Got ideas? Help us drive the future directions of Openbravo ERP

As we are putting the finishing touches on Openbravo ERP 2.50 and we are preparing for its beta release, it is already time to start thinking about the next release.

I am writing this blog post today to announce the availability of the Openbravo Ideas page.

Like we did last year when we started planning 2.50, we would like our Community to help us prioritize the feature candidates and fine tune our development road map. Better than last year, when we used an on line spreadsheet, this year we have streamlined our processes and adopted the marvels of web 2.0 by creating an Openbravo page on User Voice (this was actually a Community suggestion from last year).

All of our most significant feature requests have been exported from the Openbravo Issue Tracker and loaded in User Voice with some default votes that reflect their priorities as we currently understand them.

You may now visit our ideas page and either vote for one of the existing entries or create a new one.
Each user is allowed ten votes and you can vote for ten different entries, assign all your ten votes to an existing entry, or anything in between.

You may vote either anonymously or after login. It would be great if you could login before voting so that we can notify you when we start implementing your preferred idea and involve you in the design and feature reviews.

I look forward to your votes!