Paolo Juvara at Openbravo

Beyond automation with integrated financial and managerial accounting

2011-11-22T15:32:00.001-08:00

One of the benefits of an ERP is the automation of accounting based on operational transactions. Any good ERP would automatically generate accounting based on the transactions recorded in the system, such as invoices, payments, asset movements, etc. This way your organization can focus on execution, while an accounting view of the business is automatically generated behind the scenes, allowing you to produce your end of period financial statements with no or minimal user intervention.

Financial statements, however, can only go so far in supporting your decision making processes and most businesses complement their financialaccounting view with additional measures or KPI (Key Performance Indicators) to support management decisions. Unlike financial statements, these measures are not standardized and vary radically from organization to organization. Examples of KPI include: revenues by product or by customer, expenses by department, customer profitability, etc.

Unlike other ERPs, Openbravo provides an integrated accounting system that combines financial accounting and managerial accounting, facilitating the process of complementing the financial statements with managerial measures while ensuring that these two views are always consistent and easy to reconcile.

With Openbravo, all documents having an accounting relevance generate an accounting representation in a single data store - called the FACT_ACCT table, short for accounting facts - which is a multi-dimensional datamart that allows to report based on any dimension.

The supported dimensions are:

Time (accounting date, further grouped into periods and fiscal years)
Accounting schema (which is the "policy" used for accounting)
Organization
Account (further grouped by nature of the account: asset, liability, revenue or expense)
Product (further grouped into categories)
Business partner (further grouped into categories)
Project
Sales region
Marketing campaign
User defined 1
User defined 2

For financial accounting, you would primarily exploit the account dimension. For example, a Balance Sheet report allows you to report the position of the asset and liabilities accounts at a given point in time, while an Income Statement report allows you to report the activity in the revenue and expense accounts.

For managerial accounting, you would exploit the other dimensions as well. For example you can analyze the data in the FACT_ACCT table to get the following metrics:

Revenues by product categories and periods
Expenses by organizations
Top 10 revenue generating customers
Margin by product
Project profitability
etc.

Additionally, Openbravo 3 allows you to define and implement any KPI using Query List Widgets that allow you to visualize the performance of your company right out of the Openbravo Workspace.

Finally, it is very easy to expose the content of the FACC_ACCT table into business intelligence tools, such as Pentaho, JasperServer or Zoho Reports that business analysts can leverage to slice and dice the data and create charts and pivot tables to support decision making.

If you want to see the Openbravo's integrated accounting in action, check out this short video.

To experience the power of Openbravo directly, you can also visit the Demo Center.

Top 10 reasons why web-based ERP matters to your business

2011-09-29T06:19:00.000-07:00

We live in the golden age of computing, with major trends such as cloud computing, mobility and social network revolutionizing the way we interact with machines and consume information. In this day and age, it seems anachronistic to have to emphasize the benefits of the Internet and Internet computing.

Yet, in the world of business applications, especially for the mid-market ERP, technology seem to have stopped twenty years ago and most solutions on the market are still solidly stuck in the client/server computing paradigm of the '90s.
Traditional legacy ERP solutions such as the Microsoft Dynamics products, SAGE MAS line, SAP B1 all have two tiers client/server solutions with a Microsoft Windows only client app.

These vendors are still promoting this architecture as the best computing paradigm with the excuse that in small and medium businesses all users are firmly tied to the PC on their desk and therefore the Internet does not matter.

In 2011? Really?

We asked Openbravo users what benefits they get from their web-based ERP and here are the top 10 answers:
A web based ERP gives you global visibility in all of your company locations with minimal infrastructure requirements and no IT complexity.
A web based ERP allows you to access your company information anytime, anywhere, from any device.
You can for example connect from the airport on your way to a Board Meeting and verify if that big sale has been closed within the quarter, without the need to travel to or to call the office.
Guess what? You are not forced to choose Windows. If you or your staff prefer to work on MacOS, it works on that too (not to mention smartphones and tablets).
A web based ERP has a single point of maintenance. Single server, single database, single IT team all mean lower cost of operation, maintenance and upgrade and a significant reduction in total cost of ownership.
A web based ERP makes expanding to a new location a breeze as the additional IT investment is minimal. There is no need to deploy distributed servers or powerful PCs in every site; an Internet connection and a standard browser is all you need.
A web based ERP allows all employees to participate in your business process automation, resulting in better data, better visibility and better control. This means more accurate and timely insight in your company performance and therefore higher margins. For example, the sales team can access the invoice and payment history of their customers anytime, anywhere, without having to call the finance department; this reduces the load on the finance team and allows them to do their job more productively.
A web based ERP allows the extended organization - including all employees, suppliers and customers - to collaborate more effectively as they can always be connected to the company's information system. For example, suppliers can view your stock levels in real time and ensure timely replenishment while customers can review the status of an order and see when it will be shipped.
A web based ERP allows telecommuting and increases the morale of your employees. Staffers working with customers at their sites do not need to stop by the office on Friday to complete a time sheet. They can do it from their smartphone on their way home.
A web based ERP allows you to easily integrate external services such as email, analytics or CRM,creating mashups where the resulting combination brings more value than the individual components.
A web based ERP means that you can live the cloud life and not worry about losing you ERP access if your PC crashes or employees losing their laptop with confidential data in it.
A web based ERP allows small and medium business owners, who often have to play the role of the IT guy for their staff to spend their week ends with their family instead of installing and upgrading client software in the company's PCs.

Openbravo 3 is awesome and it is now generally available too

2011-06-14T14:09:00.003-07:00

"Amazing", "brutally powerful", "it rocks", "awesome".

These are some of the adjectives and expressions that early adopters have used to describe their experience with Openbravo 3, since it was launched as a controlled release last February.

Today, almost four months later, we proudly announced that Openbravo 3 has reached the generally available status.

This milestone means that we now consider it our most stable release and we recommend it for deployment for all projects.

Even as a controlled release version, Openbravo 3 has achieved a great degree of success in the field and, after only four months, it boasts impressive statistics:

More than 70,000 downloads
More than 6,000 new installations
More than 200 deployments of Openbravo 3 Community Edition
More than 30 on going implementations of Openbravo 3 Professional Edition

Today's announcement was very special for us and this release was not a release like many others, introducing the latest version of a product.

This milestone is the culmination of our work since the inception of the company and it marks the completion and delivery of our original vision of Agile ERP.

Openbravo 3 is a product that is easy to deploy, easy to learn; easy to use, easy to configure and extend, while still being always easy to update and upgrade.

Unlike other ERPs, Openbravo 3 is a product that enables, rather than impede, business agility. It can be put in production in a very short period of time, ensuring a rapid return of investment, and it can be expanded and modified as the organization needs change after that. It does not consume endless months of management attention during the implementation project. Once in place, it does not freeze in time the business processes of the company, harming its very ability to change, which is the essence of the competitive advantage that many small and medium organizations thrive on.

Most importantly, Openbravo 3 is a product we love and we hope that you will love it too.

An emotional review of Openbravo 3 history

2011-05-02T09:15:00.001-07:00

Have you ever found yourself in a situation where, cleaning up a closet, you finding a box of old photos that you forgot even existed?

I must confess. I am a nostalgic and that is one of those situations where I am prone to overwhelming emotions. The memories start coming back and I start thinking of old friends, choices made and times gone by.

A couple of days ago, I had such an experience. I was answering a question on layout choices in the interface of Openbravo 3 and I started going back and look at the discussions in the UX forum labs.

Eventually, I found the original concept videos and image mockups that Rob Goris published in February 2009.

That's right February 2009, over 2 years ago!

The publication of Openbravo 3 in February this year represents a very significant step forward in the history of the project. The key element of the release is a complete rearchitecture of the user experience, centered around the concepts of user agility and the introduction of workspaces, multi-tabbed UIs, master detail layouts and editable grid.

The feedback that we are receiving from our users in overwhelmingly positive and enthusiastic.

This new release has been a long way coming and, now that it is finally here, it is at the same time interesting, fun and moving to go back and see how the concepts behind it started, were debated and evolved, improving over time since their original form, yet staying remarkably close to the original vision.

I have to take my hat off for all the members of the Openbravo development team and our community members who participated in the design process. Good job guys. Well done.

Announcing Openbravo 3.0 RC6

2011-04-22T12:39:00.003-07:00

I am pleased to announce the immediate availability of Openbravo 3.0 RC6, the fifth release candidate in the Openbravo 3 series.

Openbravo 3.0 RC6 is primarily a stabilization release, including over 130 fixes for issues reported by early adopters of previous release candidates.

Besides stabilization, Openbravo 3.0 RC6 also delivers some further productivity improvements that make the usage of the ERP easier and more agile:

Redesigned Alert window: alerts are exceptions in your business processes (for examples, overdue invoices or late orders) that your Openbravo system automatically detects and prompts you to manage. With the new alert window, investigating the cause of the anomaly, correcting it or dismissing it is a breeze.

Notes: notes is a new facility available on every document in the system that allows you to add textual annotations to your transactions. You can use this functionality to store unstructured information in your ERP. For instance, for example you can add a note to an overdue invoice to document the content of the conversation with your customers in which they promised to send a payment by next week; you can also use it to store a reminder that when you send a delivery truck to a particular customer, they need to call ahead of time so that the delivery gate can be open when the truck arrives.

Openbravo 3.0 RC6 is intended for production usage by early adopters and it is a fully supported release available in all editions, Community, Basic and Professional Edition.

If you are a new user interested in learning about Openbravo and evaluating the product, you should use Openbravo 3.0 RC6. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC6.

If you are interested in deploying Openbravo for production usage in a new project, you should also consider Openbravo 3.0 RC6. Early adopters interested in deploying Openbravo 3.0 RC5 in production are recommended to thoroughly test the processes relevant to their business before deploying them in production.

If you are already in production on an earlier version of Openbravo 3, we advise you to update your system to RC6 at your earliest convenience. If you are in production on Openbravo 2.50 or earlier, we advise you to wait for general availability before scheduling an upgrade.

If you want to learn more about Openbravo 3.0 RC6, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment.

As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.comor discussing it in the Early Releases Discussion forum.

Announcing Openbravo 3.0 RC5

2011-03-22T09:42:00.003-07:00

I am pleased to announce the immediate availability of Openbravo 3.0 RC5, the fifth release candidate in the Openbravo 3 series.

Openbravo 3.0 RC5 is primarily a stabilization release, including over 140 fixes for issues reported by early adopters of previous release candidates.

With over 13,000 downloads since its launch, Openbravo 3.0 RC4 has been a fantastic success and the feedback has been overwhelmingly positive. We are thankful for the help and contributions received from our Community and we hope that RC5 will demonstrate Openbravo's continuous commitment to the rapid and incremental delivery of increasingly stable versions of Openbravo 3.

Besides stabilization, Openbravo 3.0 RC5 also delivers some further productivity improvements that make the usage of the ERP easier and more agile:

Document links: you can now generate a URL that will give you direct access to a specific document. This widely requested features allows you to collaborate more easily around Openbravo documents by sharing references with other people in your organization. For example, a sales person can ask her manager to review a proposal by simply sending her an email with the direct link to the quotation.
The URL is password protected and only people with the proper credentials can access documents this way.
Recent documents: your most recently accessed document are now listed on your workspace for easy access. Now you can easily interrupt your work stream with the confidence that you will be able to resume it later, with just one click.
Searches by date ranges: you can now search documents by date ranges either expressed as absolute values (i.e. from 15-FEB-2011 to 17-MAR-2011) or as relative ranges (i.e. the last 30 days).
Improved keyboard shortcuts: a broader set of keyboard shortcuts are now available demonstrating Openbravo's commitment to both accessibility and productivity.
Faster line entry in grid mode: you can now enter multiple lines more efficiently by either pressing ENTER, arrow down or tabbing through the last field of the grid.

Openbravo 3.0 RC5 is intended for production usage by early adopters and it is a fully supported release available in all editions, Community, Basic and Professional Edition.

If you are a new user interested in learning about Openbravo and evaluating the product, you should use Openbravo 3.0 RC5. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC5.

If you are interested in deploying Openbravo for production usage in a new project, you should also consider Openbravo 3.0 RC5. Early adopters interested in deploying Openbravo 3.0 RC5 in production are recommended to thoroughly test the processes relevant to their business before deploying them in production.

If you are already in production on an earlier version of Openbravo 3, we advise you to update your system to RC5 at your earliest convenience. If you are in production on Openbravo 2.50 or earlier, we advise you to wait for general availability before scheduling an upgrade.

If you want to learn more about Openbravo 3.0 RC5, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment.

As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.comor discussing it in the Early Releases Discussion forum.

A Prince of Asturias Award for the International Open Source Community

2011-03-10T22:33:00.004-08:00

The Prince of Asturias Awards are a series of annual prizes awarded in Oviedo, Spain by the Prince of Asturias Foundation to individuals, entities or organizations from around the world who make notable achievements in several categories, ranges from Art, to Literature, Sport, Technical and Scientific Research, and Concord.

This year, the Prince of Asturias Foundation - the organization awarding the prizes - has invited CENATIC (Centro Nacional de Referencia de Aplicación de las Tecnologías de la Información y la Comunicación) to propose a candidate for receiving the award in the International Cooperation category.

After having evaluated various options, CENATIC decided to candidate the International Open Source Community, defined as all persons and institutions around the world who contribute to free software through a collaborative, open model based on freedom, knowledge sharing, collaboration, meritocracy, and respect for copyright, with actions such as developing , outreach, advocacy, documentation, evidence, organization, marketing support and free software.

Past recipient of the award in this prestigious category include:

2010: The Transplantation Society and the National Transplant Organization
2007: Al Gore
2006: Bill and Melinda Gates Foundation
2001: The International Space Station
1994: Yasser Arafat and Yitzhak Rabin
1993: United Nations Blue Berets stationed in Ex-Yugoslavia
1992: Nelson Mandela and Fredrik Willelm de Klerk
and many others.

Openbravo as an organization and myself as an individual support this candidature recognizing that the International Open Source Community has been an engine of technological innovation and economic growth; in addition, open source has allowed the spread of knowledge around the world, eliminating economical, social, cultural, geographic and language barriers and ensuring the free and unfeathered access to technology for all.

Today I invite all members of the Openbravo Community to support this candidature by:

Endorsing it on the CENATIC site: http://www.cenatic.es/swlppa
Spreading the word through social media (Twitter, Facebook, LinkedIn, etc.)
Inviting your contacts to support this candidature.

As proud members of the International Open Source Community, Openbravo as an organization and myself as an individual feel honored to make our small contribution to larger open source movement. We are also moved and humbled to see open source recognized as one of the great achievements of humanity.

Announcing Openbravo 3.0 RC4

2011-02-22T23:23:00.003-08:00

I am pleased to announce the immediate availability of Openbravo 3.0 RC4, the fourth release candidate in the Openbravo 3 series.

Openbravo 3.0 RC4 is a particularly important milestone as it is feature complete, delivering the new implementation of AD windows, and achieving the full user experience of Openbravo 3.

With RC4, Openbravo 3 delivers on our vision of Agile ERP, with a solution that provides:

The highest productivity: easy to adopt and use, with a powerful user interface, and fully integrated.
Complete business agility: functionally comprehensive, easily extensible with a modular approach, and fully upgradeable.
Sustained ROI: cost effective to be deployed to the extended organization, providing universal accessibility through its web-based interface, and leaving users in control thanks to its open source license.

Future release candidates will be focused on minor enhancements, stabilization and incorporating the feedback received by early adopters.

Openbravo 3.0 RC4 is intended for production usage by early adopters and it is a fully supported release available in all editions, Community, Basic and Professional Edition.

If you are a new user interested in learning about Openbravo and evaluating the product, you should use Openbravo 3.0 RC4. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC4.

If you are interested in deploying Openbravo for production usage in a new project, you should also consider Openbravo 3.0 RC4. Early adopters interested in deploying Openbravo 3.0 RC4 in production are recommended to thoroughly test the processes relevant to their business before deploying them in production.

If you want to learn more about Openbravo 3.0 RC4, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment.

As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.com or discussing it in the Early Releases Discussion forum.

Test drive a preview of Openbravo 3 and experience what people are raving about

2011-01-28T20:47:00.004-08:00

The past few hours have seen an increased Twitter activity on people giving favorable reviews of the new user experience of Openbravo 3.

The new product, with the new user interface, will become available to the overall community in our next release candidate, Openbravo 3.0 RC4, due for release in a few days. The code for this release is publicly available in our source control repository and it is very close to completion; a few members of our community have already been able to test it and are sharing their feedback in the social media.

This is great! And, in fact, we would love to get even more people trying the new product out and giving us feedback.

If you want to check it out and experience first hand what people are raving about, you do not need to be a developer, knowledgeable about code builds, or able to mess with source code repositories.

There is a simple trick to get local access to our latest build without having to leave the comfort of your browser interface. Just follow these simple steps:

Start by downloading an Openbravo 3.0 RC3 appliance.
Login as System Administrator and navigate to the Module Management window (General Setup -> Application -> Module Management)
In the Settings tab, specify that you will accept modules in maturity level "Test" for both scan for update and new module installation actions. The image below shows the relevant fields highlighted in red.Now your system is ready to be updated to our latest version under development.
Return to the Installed Modules tab in that same window and press the Scan for Updates button.
From here follow the normal update process, starting by clicking on the Install Updates Now, completing the installation of the new version and continuing with a system rebuild and a mid-tier restart.
Once you are done, you will be able to login in a preview version of Openbravo 3 and start experiencing the new user interface.

NOTE: at this stage, the client is very demanding on browser resources and we have not completed its optimization yet. Your system will be faster if you use either Firefox 4, Internet Explorer 9 or Chrome.

Keep in mind that this is a preview version, straight out of the tip of the code repository and that it has not gone through QA. You are likely to find instabilities and you should not use it for production purposes.
However, the system is certainly quite stable and it should be more than enough for you to get a sense of the great things that are coming very soon.

Spend some time playing with this product. I highly recommend it and I am sure that you will enjoy it as much as we do. Your feedback is important for us, so please do not forget to drop a line in the Early Releases Discussion forum letting us know what you think.

Track Santa's progress in your Openbravo workspace

2010-12-24T03:31:00.002-08:00

Who said that ERP has to be boring?

With the new workspace and widget capabilities of Openbravo 3.0 you can include all types of content directly in your ERP.

One of my favorite sites for the Holiday Season is the Official NORAD Santa Tracker, that allows children and adults alike to follow Santa's progress with his delivery work. This year, NORAD added a Google widget for the site.

With that and following Rob's tutorial, you can easily add your Santa tracker to your ERP workspace and monitor Santa's deliveries as you monitor your own warehouse shipments.

I wish a Happy Holiday Season to everybody!

P.S.: To people in Spain - sorry, I am not aware of a Reyes Magos tracker yet.

The Amazing Openbravo 3.0 Grid

2010-12-16T09:46:00.002-08:00

Two weeks have gone by since the launch of Openbravo 3.0 RC3, which - with its My Openbravo workspace and support for widgets - was very well received and has already been downloaded more than 4000 times.

Since then, the Openbravo development team has been hard at work on 3.0 RC4, targeted for late January and introducing some of the most significant changes of the 3.0 release: master detail and editable grid.

While you will need to wait a few more weeks to download a packaged version that allows you to test driving these new capabilities, the functionality is already code complete and working in the developers' machines.

We know that you have been expecting these features for a long time, so we didn't want to keep you waiting any longer and we recorded a video that show them in action.

The video is taken out of a development environment and it is quite crude. Yet, it is enough to make you understand what is coming and I am confident you will get as excited as we are about these new amazing user interface.

Let me walk you through it.

The video starts in the Sales Order window that illustrates the new master detail paradigm where you can see the full sales order documents in a single view, without having to navigate to several tabs. At second 4 you can see how the splitter that separates master from detail records can be easily moved allowing you to adjust the dimension of your work space to the data you need to work with: if you are working on multiple sales order headers, you can expand the top part of the screen; when you focus on a single order, you can increase the size of the bottom part of the screen to make sure that all the order lines properly fit.

The video then moves to the Account Tree window that, again, is an example of the master (the chart of accounts) detail (the accounts) pattern. Notice at second 9 how the child tab is immediately populated when a master record is selected and the tab shows the number of records it contains - 1352 in this case - next to its title. This allows you to assess the content of a tab without the need to open it and therefore saving you several clicks while exploring data.

From second 15 to 30, notice the responsiveness of the grid and how easy it is to scroll through it, even when it contains a large number of records. Isn't that great?

Second 35 to minute 1:00 illustrate how you can now not only resize columns - like in 2.50 - but also reposition them in the grid and hide or show them. The best part is that users can define and save their preferred grid configuration so they do not need to repeat it every time they access the window.

From minute 1:00 to 1:45, you can see how filters work and how users can enjoy in the ERP the same power and intuitiveness that they are used while analyzing data using a spreadsheet. Many applications highlight their capability to export data to a spreadsheet for analysis; Openbravo not only does that but it also brings the power of a spreadsheet directly within the application, eliminating the need to export.

The ease of use and productivity of a spreadsheet are also emulated in the edit capabilities, starting from second 1:45. Here you can see how a user can quickly make changes to several records by just moving to the next line, very much in the same way they would do it in a spreadsheet.

At minute 2:20, the demo shows how this type of grid editing can also be used to trigger actions like, for example, changing the status of an order, directly from the grid. Again, this saves several clicks and makes users much more productive.

Finally, from minute 2:45, you can see one of the most powerful features of the grid which allows users to add calculated fields based on the content of other columns. This capability provides a very simple but powerful reporting tool allowing users to fully exploit the data in their ERP to drive decisions in their business.

These combined capabilities transform the way users interact with the system, making Openbravo a productivity tool that not only allows you to record and process transactions in your organization without getting in the way but also to manipulate and extract the full power of the information in your ERP.

All of these features will become available shortly and I hope that you will be as excited as we are with this amazing new grid, coming to an Openbravo implementation near you in just a few weeks.

Stepping into the CEO role

2010-12-09T08:37:00.000-08:00

About a week ago, Openbravo announced my appointment to the role of Chief Executive Officer of the company.

Since the announcement, I have received an enormous amount of congratulatory messages from not only colleagues and partners but from members of our Community as well.
I would like to thank everybody for their wishes and their support.

I step into this new capacity after nearly four years as Openbravo CTO. This new role extends my responsibilities beyond product definition and coordination of community activities and into the management of the overall business around the Openbravo product.

These past years have seen the Openbravo Community reach many significant milestones, including passing the 1.8 million product downloads mark, the registration of more than 12,000 developers in the Openbravo Forge, and the publication of 250 extension modules.

Today, thousands of organizations around the world run their business with the Openbravo free and open source ERP solution.

I credit a good part of this success to the open collaboration and communication process that Openbravo has established with its community, including:

Public road map.
Open engagement on the direction of the product.
Full visibility of the progress of its development process.
Open dialog on the design of upcoming features.
Public source code viewing at http://code.openbravo.com.
Open documentation with a wiki that contains more than 3,000 articles, with 1,300 monthly edits, and servers around 35,000 unique monthly visitors.
A public issue tracker at http://issues.openbravo.com where any community member can view or report issues
Community support not only through forums but also through the #openbravo IRC channel on freenode.net.
Community education with frequent public webinars.
Open community meetings.
A public collaboration space with the Openbravo Forge.
And much more...

This open community engagement will continue and accelerate in the coming months under the leadership of Ismael Ciordia, one of original founders of Openbravo, who - after having spent the last few years focused on the technology of the Openbravo platform - will now step back in his original role of CTO.

On the commercial side, Openbravo will also continue on its established path of defining and executing a sustainable and fair business model that does not divorce open source from professional usage.

One of Openbravo's core values is the belief that no ERP can be successful without a vibrant channel of service providers adding their domain expertise and geographic proximity to the customers. Openbravo is and will continue to be 100% committed to the business success of its partners.

Thanks to this approach, Openbravo Professional Edition continues to show an impressive momentum and we have more than doubled our subscription sales in just the first three quarters of the year.

In the coming months we will continue to provide tools and facilities to our partners to make their Openbravo business practice more effective and to accelerate the dissemination of Openbravo Professional Edition even further.

I am honored and excited to take over the CEO role for Openbravo at this time of expansion.
I am also thankful to every person in the Openbravo Community for their continued support.

Your contribution is the most essential element of Openbravo's success.

Announcing Openbravo 3.0 RC3

2010-11-29T07:22:00.013-08:00

I am pleased to announce the immediate availability of Openbravo 3.0 RC3, the third release candidate in the 3.0 series.

Release candidates are incremental deliveries towards the full 3.0 road map and do not contain the full set of functionality intended for 3.0.

The RC3 milestone contains some exciting new capabilities delivering a completely new experience for Openbravo users. In particular, Openbravo 3.0 RC3 introduces the amazing My Openbravo workspace that provide a portal-like dashboard to Openbravo users.
Using this new feature, users can easily integrate at UI level their Openbravo installation with any other web application, either on their organization intranet or in the public Internet.
For example you can:

Integrate with your corporate CRM system and add a chart showing your sales pipeline for the rest of the year;
Integrate with your organization's web calendar to see all of your appointment for the day;
Integrate with Facebook and Twitter to always be up to date of what people are saying about your company or to update your colleagues on what you are woking on today.

These are only some examples. With My Openbravo, the sky is the limit and you can make Openbravo your primary workspace from which you can start all of your work activities, either in the ERP or in other systems.

My Openbravo renders information in widgets. System administrators can easily configure the default widgets displayed for all users in the system; they can also provide different role based workspaces so that users with different responsibilities in the organization can see the content that is most appropriate to them. Further, individual users can personalize their workspace by rearranging existing content, or adding and removing widgets.

With 3.0 RC3, Openbravo puts the user at the center of the ERP experience.

My Openbravo is only one of the many exciting new features of Openbravo 3.0 RC3, which also includes:

New configurable login page;
Support for modal windows that replace pop-ups;
New styling that renders 2.50 classic windows with the new 3.0 look and feel.

The last feature is very relevant as it demonstrates how a new window built as an extension or delivered as a module in 2.50 looks and behaves when upgraded to 3.0 without taking any action to convert it to the new technology.

Openbravo 3.0 RC3 is intended for production usage by early adopters and it is a fully supported release available in all editions, Community, Basic and Professional Edition.

If you are a new user interested in learning about Openbravo and evaluating the product, you should consider using Openbravo 3.0 RC3. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC3.

If you are interested in deploying Openbravo for production usage in a new project, you should consider either Openbravo 2.50 or Openbravo 3.0 RC3 depending on the time frame of your implementation and your attitude towards both risk and change.

If you are already using Openbravo 3.0 RC2 for production purposes, we recommend that you update to RC3 as soon as possible.

If you are using Openbravo 2.50 for production purposes, you will need to wait for a later RC before upgrading to 3.0.

Early adopters interested in deploying Openbravo 3.0 RC3:

are recommended to thoroughly test planned business processes before deploying release into a production environment;
should be prepared for both UI and functional changes in subsequent releases; future 3.0 release candidates will provide improvements in usability and system operation but will require users of 3.0 RC3 upgrading to those releases to be able to absorb significant changes.

If you want to learn more about Openbravo 3.0 RC3, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment by logging in with user name "Openbravo" and password "openbravo".

We are confident that you will be as excited about 3.0 RC3 as we are. As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.com or discussing it in the Early Releases Discussion forum.

Openbravo and Var Group: bringing ERP innovation to Italian SMBs

2010-11-22T22:30:00.007-08:00

Last September, Openbravo signed a master distributor agreement with our Italian partner Openia. Openia is part of Var Group, a conglomerate with over 30 years of experience in the Italian market and the national leader in distributing solutions and services for the enterprise.

Last Friday, Var Group held its annual group meeting planning the activities for 2011 and I was invited to present Openbravo and introduce it to over 370 people representing all companies within the group.

Var Group recognizes that, in a difficult global economic climate, Italian small and medium companies have been able to return to rapid growth thanks to their agility, innovative spirit and ability to attract new international customers in high growth markets. These companies require IT solutions that match their agility.

Openbravo is the perfect solution for these companies thanks to its native web based interface, rapid implementation cycles and flexibility. Because of these characteristics, Var Group has now added Openbravo to its existing portfolio of products as the perfect ERP to service the needs of Italian small and medium businesses.

Thanks to Openia and Var Group, Openbravo is now coming to an Italian SMB near you.

SMB best practices: AP/AR offsetting with Openbravo

2010-11-19T23:15:00.003-08:00

Suppose that your company, F&B Inc., has a business relationship with a partner called Fairbelts that is both a supplier and a customer.

Over time, you will find yourself making payments to Fairbelts as a supplier as well as collecting payments from Fairbelts as a customer. Wouldn't it be easier cancel the mutual debt off rather than having to move money across the companies? This practice is known as AP/AR offsetting.

Most accountants would frown hearing about AP/AR offsetting as it reduces traceability of cash flows; they would advise you to keep your payables and receivables activities strictly segregated. Some legislations discourage this practice for the same reason and in a few countries this is even illegal.

That said this is a handy practice and many small and medium businesses (SMB) take advantage of it to reduce their collection efforts.

If your legislation permits it, Openbravo, with Advanced Payables and Receivables, allows you to take advantage of AP/AR offsetting without loosing control of your cash flows or your open receivables. Here is how I recommend to do it:

Setup a separate financial account, let's say called "AP/AR Offset Register"
Setup a specific payment method, let's say called "AP/AR Offset" and enable it only for the above account.
Now consider the scenario where you want to use an AP invoice to pay an AR invoice
Navigate to the AP invoice and pay it using the AP/AR Offset payment method out of the AP/AR Offset Register. Name your payment out using the AR invoice number.
Navigate to the AR invoice and pay it using the AP/AR Offset payment method out of the AP/AR Offset Register. Name your payment out using the AP invoice number.
Validate that the AP/AR Offset Register account balance always remain zero.

With this approach:

You do not affect cash traceability because all transactions happen in a separate financial account, without affecting the balance of the real bank accounts.
You have a simple control method: the balance of the AP/AR Offset Register must always be zero.
Everything is traceable. For example, looking at an AR invoice, you can see that it has been paid by an AP offset because the payments associated with it uses payment method "AP/AR Offset". If you want to know which AP invoice is associated with that offset you can look at the payment name.

Let's make a more specific example:

F&B sells $1,000 to Fairbelts and issues invoice AR1 for that amount
F&B purchases $500 from Fairbelts and receives invoice AP1 for that amount
In AP/AR Offset Register, F&B registers a payment out of $500 to Fairbelts; payment is numbered AR1 and it is applied to payables invoice AP1.
In AP/AR Offset Register, F&B registers a payment in of $500 from Fairbelts; payment is numbered AP1 and it is applied to receivable invoice AR1.
AP/AR Offset Register balance is zero.
Payables invoice AP1 is fully paid.
Receivables invoice AR1 has an outstanding balance of $500.
Business partner Fairbelts sends electronic payment of $500 to bank account West Bank Account.
When bank notifies F&B of the payment, F&B records the payment with number "EFT102" in West Bank Account and applies it to invoice AR1.
Receivables invoice AR1 is now fully paid. When users inspect the invoice they can see the payment details:
o Payment AP1 $500
o Payment EFT102 $500

In this scenario, the AP/AR Offset Register balance is non zero only in between steps 3 and 4. The fact that this account is not zero is an indication that there is a AP/AR offset transaction that has not been properly completed. You can use this as a managerial control and monitor that the balance of this account properly reconciles to zero at the end of every cycle.

This is an example of how Openbravo allows smart SMBs to adopt lean business processes while preserving financial control best practices.

Openbravo financial management for universities introduced at HIS user conference

2010-11-12T00:22:00.009-08:00

This week I spent a few days attending the Hochschul-Informations-System GmbH (HIS) user conference in Oberhof, in the German state of Thüringen.

This is not the usual open source or technology conference but it is an event centered around the end users of HISinOne, HIS impressive campus management system for German universities. For the past 18 months, Openbravo and HIS have been working closely to embed Openbravo as the financial management solution for HISinOne and the combined solution was presented at this event in front of nearly 400 IT staff and the administration users coming from most universities in the country.

At this conference, not only I had a precious opportunity to interact in person with many perspective end users of the system but I was also offered a speaking slot and had a chance to introduce Openbravo.

The slides of my presentation are available online. Make sure to read the English transcript of my speech available as speaker notes.

Openbravo and HIS: delivering innovation to university information systems

View more presentations from Paolo Juvara.

Friends don’t let friends neglect their ERP

2010-11-03T13:15:00.011-07:00

At Openbravo, we believe that users in our Community are our friends and we want them to have the best and safest possible experience with Openbravo, regardless of their level of technical or open source expertise.

That, in the end, is what Openbravo Professional Edition is about: extending the reach of the innovation stream delivered by open source ERPs and making it easily consumable by mainstream organizations of all sizes.

We realize that not every Community Edition user is ready to jump to Openbravo Professional Edition. Yet, many of them do not have the time and skills to maintain their open source ERP.

To offer a positive experience with Openbravo for every user and to ensure that no ERP is left neglected, today we introduce Openbravo Basic Edition.

Openbravo Basic Edition is a new subscription service intended for existing Community Edition users who have already experienced the benefits and ease of use of Openbravo and want to reduce the time requirements and cost of safely operating the product.

For a very affordable annual subscription cost - 1 euro or 1 dollar per day for the first 3 concurrent users - Openbravo Basic Edition gives you:

Lower cost of maintenance: with Openbravo Basic Edition you can access packaged Maintenance Packs directly from the application and install them with our click-thru approach, without the need to access the command line, deal with source code, Mercurial, or any ant commands. You reduce your dependency on developers as even non technical users are able to keep your system safe and updated to the latest Maintenance Pack.
Easier adaptability: Openbravo Basic Edition gives you access to Easy Extensible Attributes and enables non technical power users to adapt the information managed by Openbravo to the changing requirements of your business. You can now add additional tabs and fields with a simple, declarative approach, even if you are not a database or development expert.
Additional functionality: Openbravo Basic Edition gives you access to selected commercial modules and allows you to expand the footprint of your ERP to get more value out of your Openbravo investment. The catalog of commercial modules available to Basic Edition subscribers is growing rapidly and today includes more than 40 modules. Among them:

Initial Data Load (available at no cost): A set of automated data import processes to quickly load core ERP data into Openbravo, from a predefined spreadsheet. Using Initial Data Load you can extend your current Openbravo usage to new organization, new lines of business or new product lines with minimal effort.
Professional localization packs (available for an additional fee): professional localization packs increase the local compliance of your ERP by adding managed tax configuration, support for country specific tax reports and local business practices.
Multi-dimensional tax report (available for an additional fee): intended for countries where a professional localization pack is not available, this report allows you to better analyze and extract tax related data and is a valuable tool to assist you in preparing your tax declarations.
Advanced Payables and Receivables (available at no cost): embedded with Community Edition in 3.0 and now available to 2.50 users through the Basic Edition subscription, this module combines the power and flexibility of an enterprise grade financial application with the simplicity and usability of a web 2.0 personal accounting service. Advanced Payables and Receivables simplifies and automates the business processes around the management of financial accounts, from the receipt and issue of payment, to the reconciliation of those events with bank statements.

NOTE: The functional footprint of Openbravo Basic Edition is limited to the 12 functional flows of Openbravo Community Edition 3.0 and excludes the usage of Projects, Manufacturing and MRP.

You want to learn more about Openbravo Basic Edition? Explore it on openbravo.com.

You are not sure which Openbravo edition is best for you?

If you are evaluating Openbravo for an implementation in your business, Openbravo Community Edition is the right solution for you. It allows you to download, install and discover the product with no financial commitment and to reduce the risk of making the wrong ERP selection.
If you are a developer or an end user with strong technical skills and you have the ability and inclination to manage the technical aspects of your system and to develop yourself the additional functionality that you need, Openbravo Community Edition is the right solution for you.
If you have self-implemented Community Edition for your business and you no longer have the time to keep it safely updated or you do not want to keep developing new functionalities yourself, Openbravo Basic Edition is the right solution for you.
If you are looking for a complete and cost effective ERP implemented by professional service providers, Openbravo Professional Edition in conjunction with the services of an accredited Openbravo Business Partners is the right solution for you.

See more details in this edition comparison table above.

As an Openbravo Community Edition user, you are our friend and we will not let you neglect your ERP. Openbravo Basic Edition allows you to get more value out of your ERP while reducing the effort it takes you to maintain it. Go have some fun managing your business with Openbravo Basic Edition.

Three reasons to publish your first module today

2010-10-26T18:48:00.004-07:00

The portfolio of modules in the Openbravo ecosystem is growing rapidly and new modules become available every week.

In the past months I had the opportunity to help many developers publish their modules and I have observed a common behavior: the first module represents a psychological barrier and the first publication represents a sort of voyage of discovery after which people feel more confident and empowered; from the second time on, publishing a module becomes almost a joyful experience.

My advice to every Openbravo developer is to avoid hesitation. If you ever had the desire to publish a module, do not procrastinate: take a piece of simple functionality that you have developed for yourself or for one of your customers and publish your first module today.

There are many advantages in publishing your first module but I would like to mention what I consider the top three reasons:

Get over the learning curve. Publishing a module is easy but there are many small common mistakes that people make. Our experience shows that going through the process once allows you to discover most of the pitfalls; you can become an expert by simply publishing your first module.
Promote your work and become a star. If you are an IT professional providing services around Openbravo, publishing a module is a great way to promote your work in the Openbravo community and to become known among end users and other service providers.
Learn how to generate additional revenues. Many developers tell us that they are not ready to share their work with the open source community because they need to recover their R&D investment. Publishing your work as a commercial module and listing it on the Openbravo Exchange is a great way to accelerate that return of investment; you can now leverage the dissemination power of Openbravo and distribute your work as a commercial solution on a global scale.
If you are not sure that you want to start by publishing a commercial module, start with an open source one and gain a much better understanding of the Openbravo ecosystem; that way, you will learn if commercial modules are for you.

You do not know where to start? Start from something simple and easy. Here are some ideas.

Reports are great examples of functionality that can be easily packaged and reused: if in your implementation you built a custom report to manage a specific process in your business, chances are that other companies might have a similar need. Take that report, package it and publish it as a module. An example of such a report is the Sales by Month Report.

The same thing applies to printed document (sales order, invoices, etc.) which are commonly adapted to the company branding and graphical style; if you developed your printed documents starting from the default document templates introduced in 2.50 MP20, any company specific information (name, address, logo, etc.) should be a parameter to the report and the document itself should be a generic and reusable template. Making your printed document template can help in building a portfolio of templates from which other users can pick and choose for their implementation. An example of such template are the US style business forms included in the US localization.

Alerts are another idea. If you have configured alerts to help you detect and correct exceptions in your business processes (for example: purchase orders overdue for receipts, product out of stock, etc.), other organizations might be interested in that same capability. Duplicate Period Alert is an example of such a module.

These are only some ideas to get you started but many other opportunities exist, including additional windows, processes and connector to web services. Of course you do not need to start with something this simple and in many cases the first modules people publish are quite sophisticated. The important thing is to get going.

Publish your first module today and be part of the fastest growing ERP ecosystem on the planet. Most importantly, have fun with Openbravo!

A user experience pattern for configuration screens

2010-10-19T14:05:00.008-07:00

I like traveling. It gives me a rare opportunity to isolate myself into my thoughts and to explore ideas.

Some weeks ago, on a return flight from London to Spain and while tinkering with the configuration of my Gmail account to setup Priority Inbox, this concept struck me: there is a very significant and important difference in user interfaces for configuration and user interfaces for transaction.

This might seem obvious to you; probably it should have been obvious to me as well many years ago, but - what can I say? - I am not a user experience expert and, when I finally understood it, it was a kind of a revelation.

A very common and always animated debate among business application designers is about information density. In one camp, you have people who prefer information packed screens that allow power users to access all of the information they need without ever having to scroll around or navigate away from their workspace. In the other camp, you have those who favor minimalistic and light user interfaces, free flowing and easy on the eyes, not to scare away the novice.

I have to admit: I assisted to this debate with fascination but I have always been sitting on the fence. I have strong visual preference for light screens with sparse fields; I find them more elegant and easier to digest. On the other hand, I can also see that if your job is to process hundreds of sales orders per day, you really want to be able to do that job as efficiently as possible and having a packed screen with every field and command you need in sight is certainly more effective.

Casual usage with the need to digest information from one side; repetitive usage of well known functions on the other. There is the difference, and in no other place is this difference more relevant than in configuration screen versus transactional screens.

Take as an example your email inbox. Most of us receive hundreds of emails per day and we expect our email application to let us process them as fast as possible. Taking Gmail as an example, your inbox is dense with information on emails, labels, actions, etc. that allow you to read, act upon and classify your messages very efficiently.

Now, look at your email settings page. The options are sparsely laid out and grouped; there is one field per row and to leave plenty of space for verbose field names with inline descriptions of their meaning; there is even space for an instructional video on top of the screen.

The usage of space is not optimized and you need to scroll up and down to see all the options but that does not matter because you are not going to come to this screen very often and, when you do, understanding the meaning of every option is much more important than making rapid changes.

Now, let's move this to the world of ERPs and let's take Openbravo as an example. With a few exceptions for manually developed windows, all windows are consistently generated based on their Application Dictionary definition to be as compact as possible. When Openbravo thought of this design, we had in mind transactional windows and this solution is certainly appropriate for that purpose.

However, in the case of setup and configuration windows, this approach forces developers to choose field names that are short but not very descriptive in order to fit in the compact layout. Take as an example the Tax Rate window where we have a check box named Cascade; any guess of what that might mean and what the implications on your tax calculations are if you check it?

What about the Base Amount drop down where you can choose among four different values? Do you immediately understand what that means?

Admittedly, setting up a tax engine is more complex than configuring your email client but the source of the complexity should be in the domain knowledge required to perform the task, not from the window layout. Also, why compromise?

Wouldn't it be better if configuration screens were to follow a different pattern not focused on space optimization but on clarity of the semantic? Fields could be laid out in a much sparser manner and have long titles with in line description informing users of the implications of the choice they are asked to make; we could add links to additional documentation or, following Google's example, even include some instructional video.

What do you think? Is this something worth pursuing? Should Openbravo consider supporting this type of configuration screens?

Give us your opinion by either posting a comment to this blog or posting your feedback in the UX Lab forum.

208 reasons to choose Openbravo

2010-10-12T22:01:00.007-07:00

Two key reasons to choose an open source solution over another is the vibrancy of its ecosystem of developers and the amount of contributions that project receives from its community. Projects with more contributors evolve faster deliver more value to its users.

Architecture is a key factor in stimulating contributions and projects with a modular architecture have proven to generate a livelier ecosystem than monolithic ones. This is primarily because modular systems allow decoupled and independent development lowering the barrier to contribution.

Openbravo launched its modular architecture in April 2009, when it introduced release 2.50; in less than 18 months the population of available modules passed the symbolic threshold of 200 units.

Today, Openbravo's ecosystem sports 208 generally available modules with a growth rate of 104% in the first 9 months of the year. More importantly, more than 47% of these modules are developed by third party with no or little support by the core Openbravo development team, proving the efficiency of the ecosystem.

While these are impressive numbers, one has to look at the details to understand the value of these contributions for Openbravo end users:

108 modules related to localization in 20 countries; these are not only translations but also accounting rules, tax configurations, tax reports, etc.
45 are functional extensions that expand the footprint of Openbravo to support other business processes
25 are reports that allow to better leverage the information existing within the ERP
7 are tools to simplify the life of System Administrators
6 are vertical features or solutions that address needs specific of sectors such as hospitality, apparel, healthcare, or higher education
4 are connectors to other applications or services
4 are alert rules informing users of anomalies in the data patterns in their business
3 are skins

Another interesting dimension of analysis is the usage, measured in terms of downloads, which illustrated by the three charts below.

Finally, a key value of the Openbravo ecosystem is its continuity: it is very easy to port modules from one version to the next. This is illustrated by the chart below showing that 25% of the modules are already compatible with both 2.50 and the newly launched 3.0.

The next time you are evaluating an open source solution, consider its ecosystem as well. In the case of Openbravo, you will find 208 additional reasons to choose it as your ERP.

Want to be a millionaire? Use online grocery shopping

2010-10-05T01:06:00.002-07:00

Sorting through a stash of old newspapers (do not ask me why I have them...) I stumbled upon a delightful opinion column by Laura Vanderkam, published n USA Today on June 23, 2010, titled "Is time really money? For these millionaires, yes".

The column reported that a study among successful American women entrepreneurs shows that the one thing they have in common is the use of online grocery shopping. While these delivery services are expensive and can add up to $10 per week to your family budget, they allow you to save time and to focus on your business. "You're unlikely to build a million-dollar business spending an hour you could be chasing a $50,000 contract in line at the grocery store in order to save $10", concludes the author.

There is a more general lesson to be learned here: managing a business is tough and you need to maximize the return of all of your assets, including - and perhaps especially - your time; you can spend time trying to save some money here and there or you can focus on doing what you are best at and what can propel your business to the next level.

Reading this article I could not avoid thinking of a commonly repeated statement in the commercial open source community: you can spend time to save money or spend money to save time. This is what commercial open source is about.

Many users are attracted to open source because of its low cost of acquisition. However, successful usage of open source sometimes requires you to invest time to become an expert in the technology, participate in the community and contribute to the project. If you are a developer, or if the open source project is very aligned with the core competency of your business, this is certainly a very wise investment. But if you are an entrepreneur or a manager looking for a tool to better manage your business, that might be a different story.

Commercial open source takes the benefit of open source beyond the strict confines of the open source community and put it within reach of a wider audience of businesses and mainstream organizations. It achieves that by making the software easier to consume and easier to benefit from.

Different commercial open source vendors use different techniques to this goal, but this is the essence of the value that they deliver. In the case of Openbravo, our Professional Edition extends the reach of our Community Edition thanks to:

Exclusive functionality: you can access to a broad set of modules developed by our ecosystem on a commercial basis and that add high value capabilities to your Openbravo system without the need to either develop it yourself or hire a developer to do that for you.
Easier installation, administration and maintenance of the system: our management tools reduce the skills required to operate Openbravo, simplify its administration and reduce the risks associated with making a mistake in the management of a mission critical application.
Support and warranties: the peace of mind that your software is backed by the services of the software vendor and its network of business partners that are ready to help you and make sure your project is a success.

If you are considering deploying an open source solution within your company or if you want to maximize the return of your existing open source investment, you should talk to the vendor behind the project you use and learn about commercial solutions that allow you to focus on what you do best: managing your business.

Improving receivables collections with PDF invoices

2010-09-27T10:52:00.005-07:00

One of my favorite podcasts is Steve Bragg's Accounting Best Practices. Steve is the author of over 40 accounting books and a former CFO of both public and private companies. His podcast covers many topics relevant for an ERP professional, ranging from process best practices, to reviews of accounting technologies, to commentary on IFRS and GAAP.

The podcast has been active for a few years but I discovered it only this past January. Since then I have been both listening to new episodes and catching up on old issues.
Besides being informative, Steve brings a very practical point of view to the accounting technology, providing a good insight in what a CFO expects from an accounting software and often commenting on what worked for him as a user.

In episode 42, Steve discusses how printing invoices in PDF format can improve the chances of collection. PDF invoices have the advantage of being easy to generate and email to customers who receive them in a timely manner in a format that is easy to read, understand and print. In his experience, this simple practice is one of the most effective tools to not only reduce overdue receivables but also to simplify the collection of overdue items. Using PDF invoices, Steve has been able to handle over 50% of overdue receivables with one single email.

As a software professional, I am always surprised by how the simplest things are often the most effective.

This is the one piece of accounting technology that helped me the most

- Steve Bragg

Steve concludes that episodes recommending listeners to buy some PDF conversion software and returns to the topic in a later episode pointing to additional tools, some of which are offered as freeware. However, regardless of the license type and cost, using an external PDF generation tool is time consuming. You need to install the PDF virtual printer, generate the PDF output, archive it and then email it to your customers.

Openbravo offers the ability to generate PDF invoices natively. This feature has been available since the beginning of the project and recently went through some significant improvements. Starting from 2.50 MP20, all the printed document formats (customer and supplier invoices but also sales orders, shipment notices, etc.) have been revised to have clearer and more complete formats. They also support additional parameters allowing you to fine tune the graphical layout of your invoices. What previously required a developer with Jasper Reports skills is now within reach of end users:

If you print your invoices on plain paper or you email them, you can configure whether your company logo appears on the invoice.
Similarly, you can control whether your company address appears on the invoice.
You can print a different logo and address depending on the organization that issues the document.
If you print your invoices on company letterhead, you can control the size of the header margin to ensure the best fit with your existing brand graphic design.

The entire process Steve describes is fully automated in Openbravo. The combination of PDF output features and email capabilities allows you to send PDF invoices to your customers directly from the application either en masse or on a document by document basis. The email message can be based on an email template for a completely touchless process, or can be manually edited to add explanation of complex invoices, further reducing the risk of billing disputes. You can also automatically archive the invoices you emailed and keep an auditable trace of the documents you sent.

If you are looking for a solution to manage customer invoicing and collections, you should give Openbravo a try.

Announcing Openbravo 3.0 RC2

2010-09-17T08:26:00.003-07:00

I am pleased to announce that today Openbravo released Openbravo 3.0 RC2, the second release candidate in the 3.0 series.

This is a very exciting milestone for us because, unlike its predecessor RC1, Openbravo 3.0 RC2 supports onwards updates to both future release candidates and generally available releases.

This means that Openbravo 3.0 RC2 is not limited to evaluation or development purposes only and can be considered for production usage by early adopters in new implementations. As such Openbravo 3.0 RC2 is a fully supported release and it is available both as a Community Edition and Professional Edition.

Release candidates are incremental deliveries towards the full 3.0 road map and do not contain the full set of functionality intended for 3.0. Also, while new functionality has been thoroughly tested, they should be considered not yet proven.

If you are a new user interested in learning about Openbravo and evaluating the product, you should consider using Openbravo 3.0 RC2 as it gives you a closer representation of what is coming in the next months. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC2.

If you are interested in deploying Openbravo for production usage, you should consider either Openbravo 2.50 or Openbravo 3.0 RC2 depending on the time frame of your implementation and your attitude towards both risk and change.

Early adopters interested in deploying Openbravo 3.0 RC2 for new implementation projects:

are recommended to thoroughly test planned business processes before deploying release into a production environment;
should be prepared for both UI and functional changes in subsequent releases; future 3.0 release candidates will provide improvements in usability and system operation but will require users of 3.0 RC2 upgrading to those releases to be able to absorb significant changes.

Users looking for a production deployment in the short term as well as users valuing stability should continue considering our generally available product, Openbravo 2.50.
Upgrades from earlier version of Openbravo (2.40, 2.50 or 3.0 RC1) are not yet supported so existing Openbravo users should wait for subsequent release candidates before considering an upgrade.

On the surface, Openbravo 3.0 RC2 looks similar to 3.0 RC1. However, it introduces very significant changes:

The Requisition to Receipt and Budget to Analysis flows are now supported, completing the 3.0 functional footprint.
The financial flows are based on the latest version of Advanced Payables and Receivables, which include the following new features:

Manual and automatic payment execution
Refunds to customers

The keyboard shortcuts capabilities have been enhanced to support all the new layout components such as tabs, Quick Create and Quick Launch.

Openbravo 3.0 is architected to support modules originally developed for 2.50 and to make it is easy for module authors to support both versions from a single code line. Thanks to that, Openbravo 3.0 RC2 already benefits from a rich catalog of 42 modules, among which:

Initial Data Load
Spanish Community Localization Pack
Spanish Professional Localization Pack
Electronic Invoicing
Multi-dimensional Tax Report

Module authors in our Community interested in making their modules available for 3.0 should stay tuned for instructions to be published in the coming days.

If you want to learn more about Openbravo 3.0 RC2, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment.

We are confident that you will be as excited about 3.0 RC2 as we are. As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.com or discussing it in the Early Releases Discussion forum.

Easier ERP deployment - Why a simplified footprint?

2010-09-13T21:39:00.003-07:00

Since we first published the roadmap for Openbravo 3.0 last January, a few people have been asking why are we focusing on a simplified functional footprint and have decided to eliminate some functionality from the Community Edition.

At Openbravo we believe that every company should have an ERP and that open source offers a great opportunity to disseminate our product and to put great ERP solutions within reach of companies of every size and with every budget.

Our experience however taught us that complexity is our enemy: our open source license allows many people to download and install Openbravo but too many of them still struggle adopting it because of the difficulties they face during the implementation.

For 3.0 we have embarked in a big effort to eliminate complexity. The new interface makes the user experience not only more productive but also more intuitive: with the My Openbravo dashboard users will always have the most important information at their fingertips; with the new navigation they will never get lost in the product; with multi-tabs they will be able work on multiple documents at the same time; with the master-detail layout, they will be able to see full documents in a single window and to reduce the number of clicks needed to perform an action; with editable grid, they will be as productive in their ERP as they are with a spreadsheet; with the new searches, they will be able to easily find and extract valuable business information out of the system.
From a functional perspective, the new financial flows - already available to Professional Edition subscribers in 2.50 through the Advanced Payables & Receivables module and embedded in the Community Edition in 3.0 - blend the simplicity of a consumer oriented accounting package with the robustness of an enterprise grade finance application.

We expect that these changes will increase the successful adoption of Openbravo among open source users.

However, for some areas of the product - and specifically for manufacturing, MRP and project billing and accounting - we had to conclude that a certain level of complexity is inherent in the functionality and that the only way to guarantee their successful deployment is to make sure that the implementation is assisted by a trained professional, such as an Openbravo partner.

Following this logic, we decided that the best course of action is excluding them from the Community Edition and releasing them as zero cost commercial modules exclusively available through Openbravo partners working with the Professional Edition.

Eliminating functionality is always a tough decision and we realize that this can be disappointing to those Community Edition users who are currently leveraging the features we have decided to discontinue in their edition of choice. These users should stay tuned as we will provide upgrade recommendations for them in the coming months and before 3.0 reaches production status.

We are confident that this change will increase the appeal of the product and will allow a much bigger number of organizations to be successful with Openbravo. More companies will be benefiting from our community editions, and clients with more complex needs will be better served by our professional partner channel.

Announcing Openbravo 3.0 RC1

2010-07-09T13:32:00.004-07:00

There are now only a few days left before the publication of Openbravo 3.0 RC1, the first release candidate of the 3.0 series.

In previous releases, such as 2.35, 2.40 and 2.50, we followed a traditional release cycle where all the new features were developed in parallel and, when the last one was completed, we entered a stabilization cycle publishing the software first in alpha status, then beta, to finally get to production.

In 3.0, we are taking an agile and iterative approach. Because new features are added in the form of modules and the overall product is delivered as a distribution, we can deliver intermediate steps towards the final road map at fixed milestones. We refer to these releases as "Release Candidates".

Release candidates are incomplete versions of 3.0, since they deliver only a subset of the 3.0 road map; however, release candidates are in theory stable since they are distribution of modules that have already been through their own stabilization cycle.

Openbravo 3.0 RC1 is the first release candidate of the 3.0 series and, as such, is a very significant one; it the first time that we will deliver a product following this approach and it will give us many opportunities to learn. More importantly, it is the first opportunity to show our progress towards Openbravo 3.0 and start receiving feedback from our Community.

However, Openbravo 3.0 RC1 is largely incomplete as it delivers only 50 of the overall 128 projects - 39% - that are currently scheduled to be part of the final 3.0 core distribution.

Here are some of the most significant high level capabilities included in 3.0 RC1:

Enhanced application layout
Tabbed panels, allowing to open more than one transaction at a time. For instance, users will be able to register a new business partner while creating a sales order, without having to abandon the sales order transaction.
Top navigation

Application menu
Quick launcher
Quick create
Alerts
Profile
Help

New selectors (infrastructure only - new selector adopted in selected windows)
Simplified functional footprint
Improved financial features with the inclusion of Advanced Payables and Receivables
Financial invoice transaction

One significant limitation of 3.0 RC1 is that within each tab, the screen still preserves the 2.50 look & feel. The redesign of the form view as well as new capabilities such as the master detail and the editable grid are scheduled for subsequent release candidates.

The following screenshot previews the 3.0 RC1 look & feel (click for more details):

From a technical perspective, the Openbravo 3.0 RC1 distribution will include the following modules:

Core 2.50
Openbravo Smartclient
Seam
Openbravo Client Kernel
Openbravo Freemarker
Openbravo JSON Datasource
User Interface Selector
User Interface Main Layout
Advanced Payables and Receivables
Orders Awaiting Invoicing
Openbravo 3.0 Datasets
Openbravo 3.0 Configuration

Openbravo 3.0 RC1 will be available for public download from SourceForge, in the Early Releases folder.
This release is intended for evaluation purposes only. This means that upgrades from previous releases to 3.0 RC1 or from 3.0 RC1 to subsequent versions are not supported.
We ask members of our Community to download this release and provide feedback in the Early Releases Discussion forums. Users interested in production deployments should continue to use Openbravo 2.50 instead.

Public status report for Openbravo 3.0 development

2010-07-02T06:52:00.003-07:00

As we approaching the delivery of the first release candidate for Openbravo 3.0, it is time to re-establish our good practice of providing a public release status tracking page.

For those of you who have been following us for a while, in 2.40 and 2.50 we had a handy status tracking that became popular with our community. Since then, we adopted Scrum, which has been a very positive project methodology for Openbrave, but the status reporting has moved to the individual team backlogs and the scrum of scrums global backlog; while that information remained public, it has been very difficult for our community to interpret it and make sense out of it.

To re-establish the good practice of public status tracking, we have created the Openbravo 3.0 status report.

This status page is a good complement to the product road map which can also be used to have a higher level understanding of what we are working on.

How to read this status report
This status report is made of four tabs plus these instructions:
1. Project list
2. Overall status
3. Release calendar
4. Status export

Project List
This tab contains the list of projects that constitute the Openbravo 3.0 release.

Since Openbravo 3.0 is designed as "distribution", made of several modules, one of which is Core, there are different types of deliverables involved in the 3.0 release:
* C: Core enhancements
* MCD: Modules that are part of the core distribution
* M: Modules
* D: Documentation
* I: Infrastructure enhancements
* O: Other
C and MCD deliverables constitute what goes in the base Openbravo 3.0 release; the other deliverables are either optional or indepedent.

Each project is labeled with a color coded status:
* W (gray): waiting for clarification (the scope of the project is not yet clear)
* R (red): ready (the scope is clear but the work has not started)
* S (orange): started (work in progress)
* D (green): done
* N (cyan): not in scope (the project either didn't exist at that time or it is no longer currently in scope)
The current status of the project is reported in the homonymous column. Historical status is reported in the columns on the right hand side of the report; for example, in column "24", you can find what the status was on week 24 of 2010.

Overall Status
This tab tracks projects by week with a break down by milestone (RC1, RC2, etc.). It also includes two burn down chart: one for the overall release and one for the next milestone.
In terms of computation, projects are either done or not done (a started project does not count towards progress on the release). For simplicity, all projects are assumed of equal size.

Release Calendar
This tab lists the targeted release dates of each individual release candidates.

Status Export
This tab contains the overall status in a format that can be easily used to export and import in other applications for further analysis.

Packaging Openbravo 3.0 as a distribution

2010-06-29T21:12:00.002-07:00

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.

Evolution to 3.0

View more presentations from pjuvara.

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.

I have been using in this post the term "distribution" to describe this approach. This is a term that I liberally borrow from the Linux world, where a distribution, like Ubuntu, Red Hat, or SUSE, etc., is a collection of software packages including the Linux Kernel, a window manager, a desktop environment and other software. This model has proven very successful for Linux and a year ago I discussed how modularity could enable the same approach for Openbravo.
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.

Consona acquires Compiere - What about the Community?

2010-06-22T08:30:00.002-07:00

Last Wednesday the open source ERP community woke up with the news of the Consona acquisition of Compiere, one of the pioneers in open source ERP. The text of the announcement can be found here.

Since the announcement, many observers and commentators started a debate on whether this is a victory for open source or the sad demise of one the pioneers of the open source ERP category. Many also speculated on what might be in the store for the product, with most people interpreting the transaction primarily as a technology acquisition.
A recurring theme among commentators is that Compiere failed to embrace its community.

With such a symbolic event fresh in our mind, it is time to reflect on how Openbravo facilitates the development of its own community.

Last year I had commented on Adam Blum's post on The Seven Habits of Highly Effective Open Source Products. An effective open source product must display "a credible community with a credible effort to involve the community in the development of the product, as described in Adam's seven habits:

Public source viewing
Common license
Public source code checkins
Public bugs
Public forums
Anyone can contribute

Public, complete and modifiable documentation"

How does Openbravo measures against Adam's seven habits?

Openbravo offers public source viewing at http://code.openbravo.com

Openbravo adopts a common license with the Openbravo Public License being a common variation of the popular Mozilla Public License
Openbravo offers public source code checkins available either at http://code.openbravo.com, through the openbravo-commit mailing list, or on the #openbravo IRC channel on freenode.net.

Openbravo offer a public issue tracker at http://issues.openbravo.com where any community member can view or report issues

Openbravo hosts and moderates public forums on the Openbravo Forge mirrored on SourceForge.
Openbravo accepts open contribution through a documented process either in the form of extension modules, core contributions or in many other ways.
Openbravo maintains a public, complete and modifiable documentation available in the wiki.

But it does not stop there:

Openbravo offers a public road map.

Openbravo engages with its community on the direction of the product.

Openbravo offers full visibility of the progress of its development process.

Openbravo engages with its community in the design of upcoming features.

Openbravo supports its community not only through forums but also through the #openbravo IRC channel on freenode.net.

Openbravo engages with its community of developers through the openbravo-developer mailing list.
Openbravo educates its community on its latest version with frequent public webinars.
Openbravo hosts monthly open community meetings (see the log of the May session as an example).
Openbravo goes beyond public source checkins and offers public visibility of the testing of those checkins and how they get integrated into the product through our continuous integration infrastructure.

Openbravo engages its community of users through a collaborative QA process supported by an open test case repository.

Openbravo offers a public collaboration space with the Openbravo Forge.

Openbravo hosts and moderates a wiki that contains more than 3,000 articles, with 1,300 monthly edits, and servers around 35,000 unique monthly visitors.

Last but not least:

Openbravo has formalized its commitment to its community through the Openbravo Manifesto.
Openbravo has adopted a business model that does not divorce its Community Edition users from its Professional Edition solutions but embraces the usage of the Community Edition. There is an easy and smooth transition path for those community users that are ready to enjoy the increased benefits of the Professional Edition. Similarly there is freedom of choice for developers and service providers to distribute their development either as open source or with a commercial license.

Openbravo invests a significant amount of resources to provide the infrastructure, the leadership and the coordination around the community. This is part of our DNA and consistent with one of our core beliefs that openness is a requirement to build successful products, and that leveraging the domain expertise of a global community is the only way to build a product that fits the needs of all SMEs.

The results of these efforts are a community that is lively, growing and productive.

Looking at the public SourceForge statistics - which are public and independent -, for the period of May 2010:

Activity ranking: 2
Forum post: 655 (and this does not include any of the hundreds of discussions in the Openbravo Forge other than the core ones)
Downloads: 23,845 (and this does not include the 2,480 downloads from the Ubuntu repository nor any of the thousands of downloads of extension modules from our own Central Repository)

If we consider other data, we can observe that:

The Openbravo community is large and growing, with 10,426 registered members at the end of May and increasing at a pace of over 300 new members per month.

The Openbravo community is engaged giving us feedback on the product, with anywhere between 20 and 30% of the defect and new feature requests reported in any given month coming from the open community.

The Openbravo community is productive, with 361 public projects registered in the Openbravo Forge at the end of May and managed by our community.

The Openbravo community is effective, having produced as of the end of May 161 modules distributed through the Central Repository to the entire ecosystem of users.

The Openbravo community is still young and we still have a way to go before we can consider it fully mature. However, if you are looking for an open source ERP community that is welcoming, lively, engaging, productive and that does not create ideological or practical barriers between open source and commercial usage of the product, you should give Openbravo a try.

New documentation: Setting up your Openbravo development environment with Eclipse IDE

2010-06-14T02:50:00.001-07:00

Openbravo provides a very powerful and flexible development environment, but often new community members find it difficult to setup their development environment. In particular, the correct Eclipse configuration has often been a source of confusion.

Not anymore. I am pleased to announce a very important chapter of the Openbravo Developer's Guide: Setting up your Openbravo development environment with Eclipse IDE.

This is a great piece of documentation that satisfies an important need and it was authored by community member Valery Lezhebokov of Switzerland with the collaboration of Openbravo staff member Iván Perdomo.

I would like to take this opportunity to congratulate Valery and Iván for this great document and to thank Valery for this contribution.

Enjoy!

Openbravo data model documentation

2010-05-19T01:07:00.003-07:00

A very important piece of documentation for developers working with Openbravo ERP is the data model reference description.
This documentation has been available in the wiki since the launch of 2.50 but not many people are aware of it.

One of the cool feature of this reference is the fact that it is an active document that allows you to explore the Openbravo data model directly from the wiki, without the need to open additional tools such as PgAdmin.

Tables are grouped in packages of functionally related entities; for example, all the tables related to invoices are grouped in org.openbravo.model.common.invoice
Each table - for example C_INVOICE - contains a full description of all of its columns
Columns implementing a foreign key - for example C_BPARTNER_ID on C_INVOICE, provide a link that allows to drill through the key to the foreign table
Columns implementing a validation - for example PARTNER_ADDRESS on C_INVOICE, provide details of the validation logic right in the column description
Columns associated to a callout - for example TRANSACTION_DOCUMENT on C_INVOICE - provide a direct link to the source code of the Java class implementing the logic of the callout.

This is a very valuable tool that can save hours of investigation and increase the productivity of many Openbravo developers. Take it for a spin.

Rapid sales order entry with Order Multiline by Phidias

2010-05-08T07:03:00.008-07:00

Do you need to enter sales orders fast? Not a problem with Openbravo ERP and the Order Multiline module by Phidias.

French Openbravo partner Phidias was challenged by a customer that required to enter up to 30 sales order lines per minutes in their Openbravo ERP installation and responded by developing the Order Multiline module.

This module adds a new entry in the Sales Management menu that gives users access to a window that has been optimized to achieve rapid data entry. From there, you can:

Enter sales orders in a single window, master detail style;
Enter a simplified sales order header;
Rapidly add sales order lines, with minimal typing and no need to use the mouse;
Select products by partially entering the product name and letting the system auto-complete them;
Remove any unnecessary order line;
Complete the sales order.

Order Multiline is licensed under GPL v.2 and is available in the Central Repository to any Openbravo ERP 2.50 user.

If you need to speed up your sales order entry, give a try to this very cool module by Phidias.

Web 2.0 for software practitioners

2010-04-22T09:13:00.005-07:00

Openbravo founder Nicolás Serrano and José Manuel Torres just published a fascinating article on software engineering best practices leveraging web 2.0 technologies, using Openbravo as a case study.

The article is available on Computing Now, the portal of the IEEE Computer Society. It will be featured for a month on portal front page.

You can also access the article directly at this URL: http://tinyurl.com/2fl9p5j

Maintenance policy for Openbravo 2.50 Professional and Community Edition explained

2009-12-21T06:19:00.001-08:00

For Openbravo ERP, two of the characteristics that differentiate the Community Edition and the Professional Edition are the life cycle guarantee and the bug fixing guarantee.

Community Edition users are expected to stay current with our product evolution and therefore to upgrade to the next version of our product to receive maintenance.
By contrast, access to packaged maintenance on a stable version for an extended period of time is a commercial service offered as an exclusive benefit for Professional Edition customers. We call this service the life cycle guarantee.

In practice this means that as a Community Edition user, you can expect Openbravo to fix defects that you report but, in general, the defect will be addressed in the development code line and made available to you as part of the subsequent major version. Community Edition users can receive the fix by either upgrading to the next version when available or manually transplanting the fix to their own code line.
For example, if 2.40 Community Edition users were to log a defect today, we will fix it in the 2.50 based development code line and users would either need to upgrade to 2.50 or perform a manual transplant of the code change to their environment.

By contrast, as a Professional Edition customer, you have subscribed to a service that gives you the right to receive a fix for any defect that impacts you directly in the version that you are using. This means that Openbravo will not only address the fix in the development code line but will also create a backport to the stable code line of your version and release a professionally tested maintenance pack. This way Professional Edition customers can consume maintenance without having to upgrade or develop a backport themselves.

In addition to the life cycle guarantee, the bug fixing guarantee ensures that defects affecting Professional Edition customers are addressed in a timely manner and according to specific service level agreements.

The combination of these two services, life cycle guarantee and bug fixing guarantee delivers a very significant value proposition for Professional Edition customers and contributes to the peace of mind that users can expect from a professionally backed open source solution.

Going back to my earlier example, if a 2.40 Professional Edition customer were to log a defect today, not only we will fix it in an expedited manner (the bug fixing guarantee) but we would also backport the fix to 2.40 and release a new 2.40 maintenance pack (the life cycle guarantee). Thanks to this service, the customer would simply need to apply a maintenance pack in order to receive the fix.

In past versions of Openbravo ERP, like 2.35 and 2.40, we have been applying this principle by making the maintenance code repository for those releases private and releasing periodic maintenance packs. The packs are initially publicly available to the whole community and when the release reaches a stable state, they become private and available only to Professional Edition customers.
For example, in 2.35 maintenance packs 1 (MP1) to 5 (MP5) were made available to the Community; at that point we deemed that the release had reached a stable status and subsequent packs - MP6 to MP16 - were made available only to Professional Edition customers only. In 2.40, however, we felt that the product was stable enough from the beginning and all maintenance packs, from MP1 to the latest MP11 (released in November 2009), have been exclusively available to Professional Edition customers.

In 2.50, however, this approach is no longer valid. In this release we introduced modularity support and this allows us to deliver a significant number of functional enhancements as modules, separate from core. Because of this, the development code line for core is very stable and we have not felt the need to create a separate maintenance code line. We think that we will not need to create one for several more months.

Since maintenance happens in the development code line and Openbravo strongly believes that for an open source solution the development code line must be open to the community, how do we provide the life cycle guarantee to Professional Edition customers only?

Up to now, we felt that 2.50 maintenance packs, which are released in the form of a module update, packaged as an OBX file, had to be publicly available. This was both because the release, similar to 2.35, had to go through a stabilization phase (this was a motivation up to 2.50 MP3, after which I would consider 2.50 sufficiently stable) and because we still had to add a number of capabilities to our modularity infrastructure in order to fully support the activity of our ecosystem. We wanted the maximum number of Community Edition users to have access to those capabilities in order for them to be able to easily produce and consume modules.
As of 2.50 MP8 (released on October 30th, 2009) we have completed that infrastructure. We then publicly released an additional maintenance pack, 2.50 MP9 (December 1st, 2009) and from this point onwards we do not see a compelling need to release additional 2.50 maintenance packs publicly.

Therefore, the next maintenance pack, 2.50 MP10, will be exclusively available to Professional Edition customers. System administrators of the Professional Edition will be able to go to the Module Management window, perform a scan for updates to discover the availability of a new maintenance pack and download and apply the update directly from that console (reminder: we always recommend to execute this operation in a test environment before applying a maintenance pack to a production environment).

System administrators of the Community Edition performing the same operation will receive a notification that the access to the maintenance pack is reserved for Professional Edition users and will be invited to acquire a subscription license and activate their system in order to proceed with the update.
Community Edition users in version 2.50 will be able to update their installation to the latest code version by accessing the main Mercurial code repository.

We intend to continue with this approach until the next major version is published. At that point, we will recommend Community Edition users upgrade to that version if they want to continue to receive maintenance. At the same time, as a service to our Professional Edition customers, we will establish a private maintenance code repository and we will backport fixes there allowing them to stay in production on 2.50 for an extended period of time after the release of the following version, while continuing to enjoy the benefits of the bug fixing guarantee and receiving packaged maintenance.

This policy is summarized in the table below.

	Community Edition	Professional Edition
Available from source code repository	Yes	Yes
Life cycle duration	Until the next release is available	Extended guarantee
Available as packaged OBX file	No	Yes
One click update from the Module Management window	No	Yes
Bug fixing warranty	No	Yes

Keeping your core stable

2009-09-25T21:20:00.002-07:00

In my post from May 19 2009, titled "Extend, don't customize", I wrote about the importance of implementing customer specific adaptations in a way that does not interfere with the regular maintenance and upgrade operations. I also described how Openbravo ERP 2.50 addresses this challenge and how, through the thoughtful usage of modularity, users can implement even the most invasive adaptations though extensions.

This argument holds true as long as two conditions are met:

Most adaptations are possible as extensions, without requiring changes to the application itself.
The interface and the semantics of the application are stable and we can be guarantee that any extension that works against a specific version of Openbravo will continue to work when the application is updated to subsequent versions through maintenance packs.

It is my belief that both conditions are satisfied in Openbravo ERP 2.50 and today I would like to describe how we ensure that Openbravo is stable and that that the second condition holds true, leaving the exploration of the first point to future blog posts.

Let's start with some background information.

Openbravo ERP is itself delivered as a module that we call Core. All extensions, both base modules and templates, reference Core. Templates can directly change the attributes of artifacts included in Core; for example, a template can disable a field. Base modules, on the other hand, cannot change Core directly but can influence its behavior by adding artifacts that add to Core; for example, a module can add additional fields to a sales invoice line and consider those fields at invoice completion by adding to the extension point of the Invoice Post process.

In all cases, modules depend on Core to the extent that they reference artifacts that are defined in Core. It is therefore essential, to keep modules working, that Core artifacts are not changed or removed as part of the maintenance of the application. By guaranteeing that, we ensure that users can confidently apply mainteanance packs without the risk of breaking their adaptations.

We call the set of Core artifacts that other modules can reference the Openbravo Public Application Programming Interface or the Public API for shorts.

In other softwares, the term API usually refers to the signature of procedures and modules that can be invoked to execute specific functions. In the case of Openbravo, that definition is too restrictive as the application is meta data driven and, in many cases, modules interact with meta data rather than procedures and classes (actually, in a perfect meta data driven application, all interactions are at meta data level).
We are therefore using the term public API in a more generic sense, referring to all artifacts that other modules can reference in their definition, including:

Web services
Public Java classes and methods
Javascript libraries that developers can use in their manual UIs
All meta-data defined in the Application Dictionary
PL/SQL functions and procedures
Database tables and views

Soon after the launch of 2.50, we completed the formal definition of the public API. You can find the results of this work as part of the Developer's Guide.

Once the public API had been defined, the next step was to guarantee its consistency and perpetuity. This is particularly challenging in the case Openbravo given the very diverse nature of the artifacts it comprises. To achieve this objective, we have developed a tool that compares two revisions of the Openbravo code and performs a number of checks to ensure that there are no changes in the public API that could break already published modules.
For instance, this tool verifies that no mandatory column has been added to an existing table without a default value associated to it because that would break any module that attempts to insert new rows into that table and is not aware of the new column; similarly, it checks for addition of constraints, changes in column names or types, etc. When it comes to the Application Dictionary, the tool verifies that no meta data has been removed as other modules could reference it. It also verifies that the signature of a procedures, functions and methods has not been altered in any way.

With the tool in place, the logical next move was to integrate into our Continuous Integration framework. This way, any possible change that breaks the public API is discovered as soon as possible and in most cases only a few minutes after the developer has committed the change. This early detection system allows us to resolve any inconsistency well before it affects our users.
You can monitor the periodic execution of the API Consistency Check here.

Because the API consistency check is a static verification of consistency, it can only cover the formal integrity of the API at a syntactic level but there is still a small possibility that the API has changed semantically. To cover this eventuality, we have developed another automated test, also integrated in the Continuous Integration framework, that verifies that installing a few representative modules continues to be successful. We are also considering extending this test to cover at every execution a few randomly selected modules among the ones published by our community and possibly to integrate their regression testing as well.
You can monitor the period execution of the Module Installation Check here.

Of course there are always exceptions and, in a few cases, we need to accept small breaches in the API consistency. This typically happens when the API definition is wrong in the first place and we need to tread off addressing functional issues with the API stability. For example, we recently had a case where the product allowed the definition of duplicate accounting periods for the same calendar; this could have resulted in product failures under those circumstances as the accounting engine does not know under which period to post a transaction and the fix was to add a new unique constraint on the period table. Formally, this is an API change but the chances of this change breaking other modules are very small compared to the risk of leaving the defect in, so we accepted the exception.

In general, these exceptions represent very low risk to our consumers.
Whenever they happen, however, we publish them to our community using so that module owners can review them and assess if they are affected and adapt their code accordingly. We do so using as many communication channels as we can to reach the broadest possible audience:

With public API defined and this infrastructure in place, we can guarantee that modules published for 2.50 will continue to work unaffected throughout the whole life cycle of the release.

Additionally, by discovering and publishing API changes we can also ensure that, as we start the development of a new major version, our community is fully appraised of changes in our application and module developers have a very accurate description of the changes that affect their extensions.

In other words, this allows us to maximize the preservation of the investment that our community makes in the Openbravo platform and ensure the health of our ecosystem.

Status update for August 2009

2009-09-13T13:16:00.006-07:00

I apologize for the delay (these status updates are due by the 10th of the month) but here is the latest installment of the status update series, for the month of August 2009. As always, you can see the consolidated updates on our wiki in a status update page.

Status Update for August 2009

Maintenance packs
- Openbravo ERP 2.40 MP8 was released to professional subscription customers on August 20, 2009
- Openbravo ERP 2.35 MP14 was released to professional subscription customers on August 10, 2009

Modules
- The following new 2.50 compatible modules have been released:
  - CIF and NIF validator
  - Inter-company Documents
  - Tax Report Launcher

Core enhancements:
- The following enhancements have been completed and released as part of 2.50 MP4 (Sep 2nd):
  - Support for Extension Points for Order and Invoice Post procedures (feature request 10257)
- The following enhancements are available in the pi code repository and will be released as part of 2.50 MP6:
  - Support for logging in the Eclipse Console 10329)
  - Ability for a module to add accounting support for a new document as part the standard Accounting Process 10265)
  - Adding a format.xml.template 6162)

Defects
- A total of 130 defects have been resolved, with the following breakdown by severity:
  - 9 critical
  - 68 major
  - 45 minor
  - 8 trivial

Infrastructure
- Completed the stabilization of the ERP smoke tests in the Continuous Integration framework at builds.openbravo.com

Finally, we made progress in the following areas that have not been released during the month of August:

Openbravo lead modules:
- We made progress in the development of the following extension modules which are not yet published:
- 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 customers

Status Update for July 2009

2009-08-10T13:19:00.004-07:00

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

Status Update for July 2009

Maintenance packs
- Openbravo ERP 2.50 MP3 was released to the community on July 30, 2009
- Openbravo ERP 2.40 MP7 was released to professional subscription customers on July 17, 2009

Modules
- The following new 2.50 compatible modules have been released:
  - CIF and NIF valiation (Spanish Localization)
  - Tax Report Launcher
  - Inter-company documents

Core enhancements:
- The following enhancements have been completed and 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)
  - Application Dictionary: single record UI pattern (feature request 4113)
  - Disallow to create client record in Client window (feature request 3437)
  - Heartbeat Configuration and Registration windows are edit only (feature request 486)
  - Accounting: Create new Sub-Account per BPartner or Product (feature request 9888)
  - Asset Management: Asset report for depreciation schedule (feature request 9887)
- The following enhancements are available in the pi code repository and will be released as part of 2.50 MP4:
  - Accounting: Add C_DOC_TYPE_ID as a dimension to the FACT_ACCT table (feature request 10002)
  - Accounting: Ability to add additional processes as post actions to the Accounting Process (feature request 10017)
  - API Enhancement: Include getChildOrg() and getChildTree() methods in OrganizationStructureProvider class (feature request 10126)

Defects
- A total of 277 defects have been resolved, with the following breakdown by severity:
  - 17 critical
  - 166 major
  - 85 minor
  - 9 trivial

Infrastructure
- Worked on stabilizing the ERP smoke tests in the Continuous Integration framework at builds.openbravo.com

Documentation
- Good progress on the ERP 2.50 Configuration Guide

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

Chart of Accounts France
Taxes: configuration for France
Translation: French France (fr_FR)
CRM
Phidias Pack Base
Phidias Skin

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

Openbravo lead modules:
- We made progress in the development of the following extension modules which are not yet published:
- 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 customers

Status Update for June 2009

2009-07-10T23:55:00.005-07:00

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
- Added support for POS in the Continuous Integration framework at builds.openbravo.com
- Worked on stabilizing the ERP smoke tests in the Continuous Integration framework at builds.openbravo.com

Documentation
- Completed the ERP 2.50 Developer's Guide
- Good progress on the ERP 2.50 Configuration Guide
  - Completed section on Projects

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:

Openbravo lead modules:
- We made progress in the development of the following extension modules which are not yet published:

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.

Status Update for May 2009

2009-06-07T01:58:00.004-07:00

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:

The following new 2.50 compatible modules have been released:

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

Good progress on the ERP 2.50 Configuration Guide

Drafted section on Pricing
Completed section on Assets

Good progress in the ERP 2.50 Developer's Guide

Completed the Concepts section
Added to the Examples section

Completed documentation on how to upgrade custom code to 2.50

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:

Openbravo lead modules:

We made progress in the development of the following extension modules which are not yet published:

We also advanced in the functional specification for a future Spanish Professional Localization intended for Professional Subscription customers, in particular with the following tax declarations:

Extend, don't customize

2009-05-18T22:19:00.011-07:00

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:

A good portion of the customizations should be done through modules anyway
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!

Status Update for April 2009

2009-05-07T22:04:00.001-07:00

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

Product releases

Openbravo ERP 2.50 Production was released on April 15, 2009. This is a significant new release with extensive new capabilities; please see the 2.50 Release Notes for details.

Modules

The following new 2.50 compatible modules have been released:

Chart of accounts: PGC 2007 General (general Spanish chart of accounts)
Chart of accounts: PGC 2007 PYMEs (Spanish chart of accounts for SMEs)
Translation: Spanish-Spain (es_ES) español-España
Alerts: Accounting (a set of alerts that monitor the proper configuration and execution of accounting processes)
Taxes: configuration for Spain (Impuestos para España)

The following new 2.50 compatible packs have been released:

Localization pack Spain (España)

We also made progress in the development of the following extension modules:

Human Capital Management

Core enhancements:

Improved the Create Invoices from Orders window (feature requests 8173/8175)
Ability to apply price adjustments to a specific order line (feature request 8161)
Improvements in the Payment Report to show the sales representative (feature request 8164)
Ability to create lines from debt-payments in the Cash Journal window (feature request 8468)
Support for early payment discount (feature request 8176)
The above enhancements are available in main and will be released as part of 2.50 MP1)

Defects

A total of 338 defects have been resolved or rejected with the following breakdown by severity:

14 critical
184 major
109 minor
31 trivial

Infrastructure

Launched the Continuous Integration framework at builds.openbravo.com

Documentation

Completed the 2.50 Upgrade Guide
Good progress on the ERP 2.50 Configuration Guide
Good progress in the ERP 2.50 Developer's Guide

Empowering the ecosystem

2009-05-03T22:23:00.001-07:00

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.

Factoids from OSBC

2009-04-03T00:30:00.008-07:00

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:

A product that is offered in open source format

Open source license
Source code available

A credible community with a credible effort to involve the community in the development of the product, as described in Adam's seven habits:

Public source viewing
Common license
Public source code checkins
Public bugs
Public forums
Anyone can contribute
Public, complete and modifiable documentation

Ability to provide the same level of trust and comfort as traditional software vendor do to enterprises adopters. In particular:

Availability of support
Availability of maintenance
Availability of training
Availability of consulting
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 commission ed to Forrester by Bull, demonstrates that:

Open source adoption is more advanced in Europe than the US
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.
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?

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

2009-03-14T12:57:00.006-07:00

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!

My nominations for the Openbravo Community Awards

2009-03-12T05:45:00.001-07:00

This year, during the Openbravo World Conference, Openbravo will recognize some of its most outstanding community members as part of the Community Awards program.

The nomination phase of the awards is now open and I nominated the following individuals.

Best Quality Assurance (Individual): Naveen Chanda
Naveen has been a strong participant in the 2.40 alpha and 2.35 MP4 testing cycles, helping us proving those releases in a number of platforms.
He reported 8 defects, all of which were confirmed.
Best Quality Assurance (Individual): Paulo Leandro
Paulo has been a strong participant in the 2.35 MP1, 2.40 alpha and 2.35 MP4 testing cycles, helping us proving those releases in a number of platforms and validate the functionality, in particular in the Sales area.
Best Localizer (Individual): Kenzo Repole
Kenzo is the localization leader for Saudi Arabia. Besides working on the Arabic translation, Kenzo has been instrumental in developing support for right to left languages and contributing it to Openbravo.
This important capability became part of core Openbravo ERP as of release 2.50.
Best developer (Individual): Ville Lindfors
Ville has been involved with Openbravo for many years now and has contributed countless commits to our core code line, both in terms of defect fixes as well as improvements, with particular emphasis to security and performance.
Ville is also a continuous source of feedback and ideas on how to improve our product.
Best localization (organization): CBT Open
CBT Open made a very significant contribution to Openbravo in release 2.40 by developing, as part of the Italian localization, the withholding tax functionality.
In addition, CBT Open, as Italian localization leader, worked with other Italian community members and Kelyon in particular to improve the Italian translation.
Best localization (organization): Kelyon
Kelyon has been a very active contributor to the Italian translation in particular and the Italian localization in general. Their work in the translation pioneered the processes of collaborative translation and their work has been seminal in the refinement of tools such as Openbravo2PO and the POMerge functionality.
The collaboration between CBT Open and Kelyon is a model that we would like to see repeated in many other geographies.

Please remember to nominate your own candidate and help us creating a vibrant community were active members willing to contribute get the recognition they deserve.

Quick status update on ERP 2.50

2009-03-03T09:10:00.001-08:00

My last blog post was focused on the status of Openbravo ERP 2.50. Since a month has gone by, I would like to give you a very quick status update on where we are now.

Since then, we had to modify our exit criteria to make it more reachable. In particular, we had to put a "cut off" date for the defects that we were planning to fix. We debated this both internally and in the Community and finally we settled with the following exit criteria:

Defects logged up to Feb 13th: 0 critical and major defect, less than 100 minor and trivial
Defects logged after Feb 13th: 0 defects with urgent priority
QA testing completed
Upgrader ready and tested

This criteria gave us a good provision for a) cleaning the backlog of old stuff and b) giving QA the flexibility to request fixes for as many show stoppers they feel are needed and hold the release until they are satisfied with its quality level.

We reached this exit criteria last week on February 24th. Since then, we have frozen the the development code line (Main, using the new Mercurial terminology) and are running various installation and upgrade tests with this final code.

We hope to release 2.50 Beta within this week.

2.50 status update and statistics

2009-02-03T10:40:00.007-08:00

It has been 2 months since we launched 2.50 alpha and I would like to give you an update on our progress in the stabilization process.

In short, it is taking longer than we expected and we still are finding many issues. As you might know from our wiki, our criteria for completing the alpha testing and starting beta is to reach zero critical and major defects, and less than 100 minor and trivial defects combined.

During 2.40, this process took us 8 weeks so we were expecting that it would have taken roughly the same amount of time for 2.50, but things are not going in the same way.

We started the 2.40 alpha cycle on May 23, 2008 with an overall backlog of 278 open defects. In the 8 weeks till July 18th, when we published beta, 357 new defects were logged and we closed a total of 534, leaving the backlog level at 95 open defects, in line with our exit criteria. The historical trend is summarized in the image below.

When we started 2.50 alpha on the November 21st, we had a similar backlog of 271 product defects. However, since then and up to the end of January 2009, 646 defects have been reported and we have closed 684 defects, leaving the current backlog at 233.
The 2.50 historical trend is in the image below and as you can see, 10 weeks into the alpha cycle, the progress is very uncertain and we have been blocked at this level for a while.

How do we justify that? Have we been sleeping on the job? Actually, we made a lot of progress:

We fixed almost precisely the same number of defects per week in 2.50 as we did in 2.40 (68.4 defects per week in 2.50 vs. 66.7 defects per week in 2.40);
We published 9 alpha versions, both in source code format and in the handy appliance format to ease testing
We manned the Modularity Program that supports about 20 early adopters that are actively developing extensions on top of 2.50.

The thing is... the defect inflow has been 40% higher in 2.50 than in 2.40 (65 defects per week vs 45 defects per week) and this is what is slowing us down.

But then... how do we explain this increase? I really do not have a very strong argument to explain it in definitive terms, but I can put forward some theories:

We do a much better job at testing compared to previous releases. In particular, compared to 2.40, our dedicated QA team has grown more than 300%
Our community usage of previous releases has grown dramatically in recent months and many users are stressing the systems in ways it was not stressed before. Of the 646 reported defects, 155 (or 24%) have been reported against a production release.
Our community is testing this early release very actively: 2.50 alpha gets downloaded around 800 times a week (without even counting people who install from sources using our SVN repository) and around 10% of the defects are reported by community testers.

The complete explanation is probably a mix of all the above points. Overall, this means that 2.50 is going to be the best release ever in terms of quality. Our exit criteria, in fact, is not time driven but quality driven and we will not release the beta version until the intended level of quality has been reached.

Because we do not have a time boundary, it is difficult for us to predict the availability date of 2.50 beta. We hope that it is going to be within a few weeks but you can monitor the progress of our stabilization effort live: if you are an iGoogle user, click here to add a Google Gadget with daily update of our progress graph as in the image below.

You can help us in this process by contributing to the testing effort. Please do download our latest alpha release and test it out. You can participate in the Community testing program organized by our QA team provided or just verify whatever feature is most important to you. In any case, please do not forget to report your defects!

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

2008-11-24T05:57:00.006-08:00

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:

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
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.

Openbravo ERP 2.50: The First Step Towards Green

2008-10-20T03:33:00.004-07:00

The production release of Openbravo ERP 2.40 is still fresh in our mind and yet we are already in the final stages of the build phase for the next release, Openbravo ERP 2.50.

2.50 is going to be a remarkable release for many reasons. One of them is that it marks the beginning of the transformation towards the next generation technology open source ERP platform, Openbravo Green.

We have been working on Openbravo Green for well over 18 months. The original New Platform - White Paper and Design Principles for Openbravo Green articles were published in our wiki in early March 2007 and they sparked a very active debate in our Community in the Openbravo Green forum, which was launched a few days later.

One of the major issues with this project was how to tranform it from a concept into a production feature. In fact, a complete redesign of an established platform is always very problematic: from one side, the initial investment required is very high; from the other, the limited resources of the development organization are always pulled towards meeting the urgent requirements of the community using the existing product. In addition to that, if not properly managed, the big bang introduction of a new platform could be very disruptive to existing users who need to learn the new tools and migrate their legacy extensions to the new technology.

After several months of debate, we came to the conclusion that, rather than looking at Green as a discontinuity in our product development, the rigth approach for us was to implement it using an evolutionary approach based on coexistance: elements of the new platform are to be introduced progressively in every release, while making sure that the existing platform continues to be operational to support the existing application.
In other words, we stopped looking at Openbravo Green as a mythical future release, and we started adding capabilities of "the next generation platform" in the normal release cycle.

There are several advantages to this approach:

Early delivery of the benefits of the new technology: every new technology feature that we introduce can provide benefits from day one, and there is no need to wait for the long pole to take advantage of it;
Minimal or no disruption to existing users: since we continue to support our existing technology, our community's investment in the Openbravo ERP project is protected;
Risk reduction: any possible problem with the new technology can be detected and corrected early.

We have since been quietly working behind the scenes to make this vision a reality and 2.50 is going to unveil the first step in our path to Green.

In Openbravo ERP 2.50, in fact, we are introducing many of the foundational elements that were explored as part of the original Green project. The most significant one is the introduction of the Data Access Layer (DAL), which leverages Hibernate to provide a Java abstraction layer on top of the relational datamodel and which provides centralized data access and persistence. While DAL provides a better alternative to SQLC, SQLC will be preserved in 2.50 and all of our existing code continues to use it to access the database. At the same time, DAL can provide many benefits to our users starting from this release, including:

A very productive tool to write Java-based business logic and extensions on top of Openbravo ERP;
A full layer of restful web services that allow to manipulate 100% of the Openbravo ERP transactions;
A way to develop custom user interfaces decoupled from the product back end leveraging either Java or any SOA enabled technology.

Another Green element adopted in 2.50 is Quartz which will replace the home grown legacy scheduler as part of the Process Scheduler project. In 2.50, this project provides a much more robust infrastructure to schedule automatic jobs as well as the ability to invoke any Openbravo process from external systems through web services. For future releases, Quartz also offers a very solid basis to improve the user experience and productivity by allowing scheduling the background execution of any report and process directly from the Openbravo interface.

Finally, in 2.50 we are improving the overall architecture of our platform by allowing the development and distribution of independent solutions through the Modularity project. While this is a topic large enough to deserve its own post, I would like to point out that this is the first step towards the separation between platform and ERP that we had identified as a design principle 18 months ago.

As significant as it is, Openbravo ERP 2.50 is just the first milestone towards our evolution to Green. Future steps include:

The introduction of more powerful abstaction layers such as business objects in addition to relational tables;
The conversion of our legacy code to use DAL instead of SQLC;
The elimination of PL/SQL in favor of Java;
The adoption of a BPEL and human workflow engine;
The introduction of a search engine;
and much more...

How fast can we complete this journey? It is difficult to say. The answer to this question, in fact, depends on how many resources we will be able to dedicate to this technological transformation; that needs to be a trade off with other priorities such as the continued expansion of the functional footprint of the solution and the improvement of the user experience.

If you would like to accelerate our delivery, you can always help us out by contributing to the project.

Starting from today, however, we can be sure that the journey is under way and that, slowly but surely, we will reach our destination.

Status of the Openbravo ERP 2.35 Upgraders

2008-08-25T09:42:00.003-07:00

One of the issues that in recent weeks has been troubling our Community the most is the status of the 2.35 Upgraders, so I feel it is appropriate for me to write a public explanation of what is going on.

For those not familiar with it, the problem is that we have published upgrade scripts (Upgraders) to our Community from 2.35 to 2.35 MP1 and from 2.35 MP5 to 2.40 beta; we haven't however published Upgraders from 2.35 MP1 to 2.35 MP4 nor from 2.35 MP4 to 2.35 MP5.
Effectively, this makes it very difficult for users on 2.35 MP1 to upgrade to 2.40.

We have a stated policy to publish an upgrade script within 2 weeks from the publication of a new release or maintenance pack. Yet, three and half months after the publication of 2.35 MP4, no Upgrader is yet available for it.

First of all, I would like to apologize for this delay and confirm that we do intend to publish these Upgraders; this issue is not the result of a policy change. In fact, we have been working very hard to complete them, but unfortunately we seem to keep running into technical issues that prevent their publication.

As of now, both Upgraders are available to our QA team who is verifying them against various configurations. If everything goes well, we hope to finally publish them before the end of the week. History, however, shows that it is very difficult to predict an exact completion date as any new issue might cause a few days of delay.

Given the importance of the Upgraders to our users, we intend to provide our Community with complete visibility into our progress. For that purpose, we have created a status page on our Wiki which we will update on a frequent basis with progress and any schedule change.

Going forward, we intend to publish the Upgrader concurrently with the publication of a new release. This way existing users will be able to immediately test the new version. We followed this approach already with 2.40beta (this is the reason why the 2.35MP5 to 2.40beta upgrader is already published) and we aim at continuing with this practice for all future releases.

TriMet uses Openbravo POS

2008-07-29T22:32:00.004-07:00

This past week, I was in Portland, Oregon, attending OSCON. The conference was great but one of the best surprises was to find out that TriMet, the local public transportation agency, uses Openbravo POS for its direct sales to public.

With more than 2 million people in his greater area, Portland has been called the greenest city in the United States and the second greenest city in the world. It is also considered one of the cities with the highest standard of living in the US and its public transportation system is one of the things that Portland residents are very proud of.

In August 2007, TriMet installed Openbravo POS - then Tina POS - in its public ticket office to sell tickets and passes to the public. The sales outlet is located in Pioneer Square, in the heart of the city, and houses 5 POS terminals.
The average sale at these terminals is $45 and in the past year they processed more than 100,000 transactions for about of $4.5 million. This represent about 6% of passenger fare revenues for TriMet.

At the time of the selection, they evaluated Openbravo POS against some the most popular commercial POS solutions and our beloved open source application came out on top. The deciding factors were its simplicity, rich functionality and the quality of its code.
The implementation project was very rapid and within a very short period, TriMet had integrated Openbravo with its existing payment service, selected the hardware for the terminals, and was up and running serving its customers.

TriMet was kind enough to invite me and visit the sales office and talk to both the IT and customer service personnel. Everybody is very pleased with the system and the benefits it brings. The transaction time is very fast and people can buy their fares without having to wait in line for too long. The POS is also used to track the inventory (tickets, passes, maps, etc. - many of which are almost cash equivalent and need to be tracked very closely) as it moves from the back office to the individual sales desks; this has greatly improved management visibility and reduced errors.

Every once in a while, somebody that we didn't know before contacts us to share their Openbravo success story and it is always great to discover new users that are making good use of our software. This, however, was a particularly fun and rewarding experience for me and I felt a great sense of pride to see Openbravo supporting such an important service in such a great city.

OSCON 2008

2008-07-27T08:19:00.002-07:00

I spent the last few days at OSCON. What a great show!

I always find it refreshing and rejuvenating to take a few days away from my daily schedule and go to an event like this, where one can see what others are doing. I never cease to be amazed by the many interesting projects and by the amount of innovation that the open source community creates.

In addition, this was the 10th anniversary of OSCON, which coincides with the 10th anniversary of the term "open source software" and it was fantastic - especially for a newbie like me - to associate with the people that were there at the beginning and that made history in the software field.

I attended several events and most of them were remarkable. I found Tim O' Reilly's keynote particularly inspiring; he highlights three challenges and opportunities for the open source community: 1) cloud computing; 2) the programmable web; and 3) mobile open source. These three areas represent the new battleground in the competition between open and proprietary. While there are now increasingly viable open source alternatives to desktop and server application, Tim reminds us how important it is that the open source community succeeds in providing alternatives to these new proprietary platforms.
There is always more than one way to get at one problem and you should always have the freedom to choose.

I also enjoyed the birds of a feather sessions and in particular the two that Pentaho's James Dixon organized: "Commercial Open Source: Deceitful Capitalists, Pioneers of a New Frontier, or both?" and "Open Source Development Using Agile Methodologies".

Another great session I really loved was Meboo's Elaine Wherry's on hiring best practices: "Code is Easy, People are Hard". Elaine is a fun and talented presenter and her presentation was very insightful and a great reminder that software products are a reflection of the team that built them. I hope to see her slides posted on the OSCON site soon.

Finally, Paul Fenwick's "An Illustrated History of Failure" was one of the most entertaining sessions and a great lesson on presentation skills. I think there is a video of this presentation somewhere but I could not find it. If you do, please let me know.

The most valuable take away from this event, however, was the opportunity to interact with people who live and work in the open source community. In many cases, they work on things that are not directly applicable to my area of focus - open source ERP - but they always manage to energize me with their passion, new ideas, and fresh thinking.

Feedback wanted on product priorities and road map

2008-06-02T05:03:00.004-07:00

One of the values at the core of the Openbravo project is collaboration with the Community in all aspects of the product life cycle, from planning, to build and launch.

A few days ago, we published Openbravo ERP 2.40 alpha. While we are still very much focused on stabilizing that release, it is also time to start planning for the next one, 2.50, and we intend to do that in collaboration with our Community.

For that purpose, we just published a forum post to discuss the release candidate features and their relative priorities.

Our feature list is very ambitious and addressing everything on that list would require an effort that is easily an order of magnitude bigger than our actual capacity, so we need to choose wisely.

This is an opportunity to influence that choice by commenting on the list and voice your needs by replying to my post.

I would also remind you that you can guarantee that a particular feature is developed sooner rather than later by volunteering and doing the work yourself. We had several such contributions in 2.40 and we hope to have more in 2.50.

I look forward to a very lively debate on the priorities for Openbravo!

Announcing Openbravo ERP 2.40 alpha

2008-05-23T04:56:00.002-07:00

Today we announce the availability on SourceForge of the public alpha version of Openbravo ERP 2.40.

This new version includes many new exciting functionality that kept us busy for many months and we are very happy to be able to finally show it to our Community.

Among the many enhancements, usability emerges as a main theme. Openbravo ERP has traditionally been a ground breaking project in terms of user interface: in 2006, with release 2.14 we were the first open source ERP with a web based interface; 2007 was another major milestone and with release 2.30 we were once more the first open source ERP to feature a skinnable and Ajax-enabled UI.
This year, we continue on that tradition and, with release 2.40, Openbravo raises the bar again and brings the productivity of the user interface to levels comparable to client server applications. In particular, users can now fully operate the system using only the keyboard and all most frequently used operations are just one click away and conveniently accessible through a short cut. In addition, users can configure their system so that, when they open a window, the focus is automatically placed in the most important field according to their specific business processes; this reduces the number of keystrokes necessary to complete a transaction and dramatically increases productivity. Finally, a new set of icons and a revised look & feel keep the user better informed of the status of the system therefore avoiding confusion and preventing costly mistakes.

Another major theme of the release is improved global operation support. With the enhanced multi-schema accounting capabilities it is now possible to account each transaction according to multiple accounting rules, in multiple currencies and in multiple calendars. This enables organizations with operations in multiple countries to comply with the local accounting regulation while at the same time apply a corporate accounting standard that allows roll ups and consolidation.
Many new features also improve the ease of deploying Openbravo in different geographies. The completely revised VAT module, for instance, allows a much better support for key reporting requirements in many countries such as VAT Registers and Withholding Tax. We are particularly happy about these features as they were developed by a community contributor, Cosmic Blue Team, which demonstrates the power of what a collaborative community can achieve.
In addition, the new International Bank Account feature enables users to out of the box define bank accounts according to their local conventions and therefore it avoids a very frequent customization.

Besides this, there are many other cool new features and you can find the full list in the Release Notes.

Please notice that this is only an alpha version and it is intended for evaluation and stabilization purposes only. Openbravo 2.35 MP4 remains our best version for production usage. In particular, you cannot upgrade an existing system to 2.40 alpha and you will not be able to upgrade a 2.40 alpha instance to any subsequent version.

That said, we do encourage you to download and install this new version and give us your feedback. You can post your opinion and question on the new features in the Early Releases Discussion forum and you can log any defect that you might find in the product using our new tracker system.

We hope that you will enjoy testing this new version as much as we did developing it.

First Community Survey Launched

2008-05-17T23:06:00.001-07:00

At Openbravo, we aim at serving our Community as best as we can.

For that purpose, we have launched the first Community Survey to better understand the background and objectives of our Community Members.
We would really appreciate it if you could spend a couple of minutes filling the survey and giving us, in an anonymous format, some data points on your interests in the Openbravo projects.

Openbravo 2.40 Acceptance Test

2008-04-18T11:21:00.004-07:00

We are in the final stages of the Openbravo 2.40 development cycle and the release is getting ready to enter the alpha phase. We have found a few more issues and decided to do a bit more clean up to eliminate some obsolete code; this will take a couple of extra days and cause a bit of delay compared to my last update, but we are now fairly confident that we should have an installer ready by mid next week.

Since we are now only a few days away from that milestone, it is time to ask for community volunteers to help us with the acceptance test before we open the public alpha process.

If you are interested in participating in the acceptance test, please notify us by sending an email to collaborate@openbravo.com.

The goal of acceptance test is to validate release readiness. In the context of an alpha release, the specific objective is to prove that the product is stable enough for the community to test it and evaluate it. In particular, we intend to test that:

The product installs and works on all the most important operating systems (we will certainly test Linux and Windows but we hope that you will help us in testing other platforms as well; for 2.40, we will also have a Mac installer - any takers?)

The product installs and works against both Oracle and PostgreSQL.

The product can be installed from sources.

All the major flows are in working condition.

The new features are complete and stable.

The process is going to be very similar to what we did in the past for R2.35 and 2.35MP1.

We will give volunteers early access to the installer through a private FTP server. You will essentially receive the release at the same time as our QA team.

We will give you access to our test plans so that you can see what to test (but you can test any flow you like as well).

We will ask you to give us frequent updates on your progress.

If you have problems or doubts during the process, we will respond to your messages using the newly created Early Releases Discussion forum.

We will publish a daily status update on that same forum.

Acceptance testing should start in the middle of next week (as soon as the installer is ready) and last 10 working days. This is longer than I had announced in my previous post because we have reviewed our historical data and saw that we never completed this step in less than 2 weeks before. We will try to beat this date but we do not want to be overly optimistic either.

We look forward to your continued support to our project and your participation in this important test.

Openbravo 2.40 Update

2008-04-04T13:46:00.002-07:00

Last week I was unfortunate enough to travel through London on the next day of the opening of the now infamous Heathrow Terminal 5 and my two bags were among the 15,000 pieces of luggage that got lost in those days. Luckily both of them were eventually recovered and arrived safely home, even if 3 days later than expected.

This experience reminded me of how difficult it is to launch a new complex system. In that respect Openbravo ERP 2.40 is no different and it is also experiencing some delays. We were hoping to freeze our code today, but we had to extend that milestone by two weeks, one of which we hope to recover later on because we now have an automated way of building the installer and we can generate one much faster.
So here is our new schedule:

Code freeze: April 18th
Installer ready and beginning of Acceptance Testing: Apr 21st
Acceptance Testing complete and alpha availability: Apr 28th
Beginning of beta: May 30th
Production: June 30th

I would like to take this opportunity to clarify a bit the purpose and mechanics of the alpha cycle. The goal of this phase is to allow the community to evaluate the new release and help us stabilize it. Since it is not intended for production purposes, we will only support fresh test installation and we do not intend to publish an upgrade path to 2.40 alpha nor one that will allow to upgrade to a production version.

Additionally, during the alpha cycle, the engineering team will be focused on fixing bugs, both backlog bugs from previous releases and new issues reported during the alpha testing itself. Because of that, it is likely that we will release various versions of the alpha release (alpha1, alpha2, etc.), each incorporating an increasing number of bug fixes.
We haven't decided the frequency of these updates and we intend to take that pragmatically, balancing two different priorities: avoid the need for people to refresh their testing environment and allowing them to work on the most stable code available.

Finally, in preparation to this release cycle we will create a new forum dedicated to questions and comments on this new release. We think we will call it Early Release Discussions but we haven't finalized the name yet.
The rationale for a separate forum is to keep separate as much as possible the production version from this early release to minimize the impact on the production users.

OSBC 2008 - Putting Open Source to Work

2008-03-11T01:26:00.002-07:00

On March 25th and 26th, I will be attending InfoWorld's Open Source Business Conference (OSBC) in San Francisco.
This year's theme for the conference is Putting Open Source to Work and I look forward to mingling with some of the best people in the industry to learn their perspective on the topic. The agenda is packed with very interesting keynotes and debates and it is going to be difficult to choose what to attend!

On the first day of the conference, I have been invited to participating to a panel discussion titled The Community Imperative: Building and Leveraging Community into IT. This is a topic that is very dear to me and to all of us at Openbravo as we are aware that our project's success largely depends on our Community.
From the very beginning we put a lot of effort in building a vibrant Community and we learned a lot in the process. This panel is going to be a great opportunity to compare notes with not only representatives of other great open source projects but also other Community members such as system integrators and end users.

Openbravo ERP 2.40 Update

2008-03-06T04:20:00.001-08:00

These days, the Openbravo Development team is working very hard to finalize the 2.40 release and I think it is time to start sharing some news with our Community.

Openbravo ERP 2.40 will be a landmark release from many points of view.

In terms of functionality it introduces many cool capabilities that our users have been asking for. Just to mention some highlights:

Industry Template: this feature will provide the ability to package additional modules (functional extensions) and pre-defined configuration in order to dramatically reduce the implementation costs and time by providing a one-button delivery of everything that is needed to operate Openbravo ERP in a given industry.
Keyboard Operations: this feature will increase users' productivity by allowing them to operate all the essential functions of the product with the keyboard.
Revised Security: this project streamlines the security setup and makes it easier and faster to configure the system in organizations with demanding data segregation requirements.
Requisitions: with this feature, Openbravo completes the support for the procurement processes by cleanly separating the roles of a requestor of goods and services from the role of the purchasing manager who creates the POs.
Multi-schema accounting: ability to account transactions according to multiple accounting rules and currencies.
Additional reports
Much more

For the first time, with this release, you can follow our progress and have a sneak preview of what we are doing. Each project comes with a functional specification that describes what it is about and the progress of the whole release is summarized in a status page, publicly available on the Wiki.
From that page, you can:

View the status of each project.
Access the project documentation.
See if the project has been completed and merged in the trunk, in which case you can start using the feature by connecting to our SVN server and building from sources.

In 2.40 we will also put a lot of emphasis on quality and on cleaning up the defect backlog that we have accumulated over the years (you know, all those small defects... many of them are not that critical and you are often tempted to defer them, but when you put them all together...).
To give you visibility into this process, we have started publishing bug projections where, on a weekly basis, we estimate the inflow and outflow of bugs and we compare the actuals with estimates.
Just a disclaimer on this (I owe it to the team who very bravely published these projections): our estimates might not be very reliable at the beginning but we are confident that they will improve over time; we hope you will appreciate our efforts to continue giving you our honest best guess of what the future backlog will be like; please do not criticize us too much if things do not evolve as planned.

As this point, you might be asking the tough question... when will 2.40 be available? Well... if you are a developer you can follow up as we go and get hold of our daily build now from our SVN servers.
If you prefer to wait for the official installers, here is the schedule as we see it today:

April 4th 2008: Internal code freeze - all features are completed and tested in their own branch and all branches have been merged with the trunk.
April 11th 2008: Installer available and beginning of Acceptance Testing. The purpose of Acceptance Testing is to validate that the release installs successfully in Windows and Linux (our two most popular platforms), works properly against Oracle and PostgreSQL, and that none of the major flows is dead on arrival. We intend to involve the Community in this test but we would like to keep it small and we will probably follow the same process that we used for 2.35 and 2.35 MP1.
April 19th 2008: Acceptance Testing complete and 2.40 Alpha publicly available for download on SourceForge. The purpose of the Alpha cycle is to let the Community evaluate the release and give us feedback on quality and overall readiness. As such, 2.40 at that point we will not recommend 2.40 for production usage and we will continue to position 2.35 as our latest production release.
As you can see from our bug projections, we plan to be very busy fixing defects during the Alpha cycle and we hope that we will be able to eliminate most of our backlog by then.
May: end of the Alpha cycle and begin of the Beta cycle. During this phase, we will aim at deploying 2.40 in production at a limited number of customers with the purpose of validating that the release is successful in live environments. Again, during this time, 2.35 will remain our latest production release.
June: 2.40 will finally become production and replace 2.35. Big celebration.

That's our plan for the next four months. We will keep you updated if anything changes.

Call for Participation in Openbravo 2.35 Maintenance Pack 1 Acceptance Testing

2007-12-20T00:44:00.001-08:00

I do not blog as much as I should but so far it looks like a pattern: once on release naming convention and a few days later on acceptance testing.

Openbravo is just about to launch its first maintenance pack, 2.35 MP1, and we are asking the community to help us validate its quality before release.

If you are willing and able - or if you wanted to participate for 2.35 and couldn't - this opportunity is for you! Notify us of your interest by sending an email to collaborate@openbravo.com.

The process is going to be very similar to what we did for R2.35, but with a few improvements based on the lessons we learned in that exercise. Specifically, here is what we are asking:

We will give you early access to the installer through a private FTP server. You will essentially receive the release at the same time as our QA team.
We will give you access to our QA portal, where you can see our test cases for the acceptance test. Following the experience with the previous round of acceptance testing, we have significantly improved the quality of test cases.
We will assign you a set of test cases and we expect that you will install the application on your server, run the test cases and report the outcome in the QA portal
Contrary to what we did in 2.35, we will not assign you any bug to verify as we will execute that task internally (we think it is more productive this way). Obviously you are free to verify specific bugs that you care about.
If you have any questions or doubts during the process, we will be available on the IRC channel to answer.

Acceptance testing should start today and ideally should last 4 or 5 days. However, as most countries are in the Holiday Season, we plan to extend acceptance testing till January 4th.

Please remember that this is going to be Acceptance Testing, not a full blown QA cycle. The purpose of Acceptance Testing is to validate that an already QA'ed release is good to go and that the last build didn't introduce any major regression (essentially: test the product as it is going to be shipped before your users do to avoid to be embarrassed later).
Because of that, we will stop the release of the maintenance pack only if one of the test cases fails with a significant bug or one of the critical bugs that we thought had been fixed still reproduces. Nonetheless, we do expect you to log all issues you find, including small bugs, as we will fix those in future releases.

So what is 2.35 MP1? It is a stabilization pack that solves approximately 41 of the most severe issues that have been reported by the community and represents a major milestone in Openbravo's commitment to deliver a stable Community Edition that can be acquired and operated in a truly free manner.

We look forward to your participation in this very important milestone!

We listen!

2007-12-14T07:35:00.000-08:00

This past October, I had published a blogpost in which we discussed a revision of the naming standards for the Openbravo releases.

Release names had been a hot topic at Openbravo for a while as our community complained several times that it was difficult to understand them and with that change we had hoped to resolve the problem.
In fact that announcement created further discussions, both as comments to post itself, as well as in other forums and blogs. In those discussions, a lot of very good ideas came up, so we thought of giving it a second try.

Yesterday we published a revised definition of our release strategy and in particular, we adopted a new naming standard. Check it out and let us know what you think!

Call for Participation in Openbravo 2.35 Acceptance Testing

2007-10-18T03:47:00.000-07:00

One of the most frequent requests that we get from our community is an opportunity to participate in the Openbravo quality assurance process.

Well... here it is.

Starting with the upcoming 2.35 Acceptance Testing, we would like to take a small step in that direction and ask for a handful of volunteers to test some of the mechanics. If you are willing and able, you can notify us by sending an email to collaborate@openbravo.com.

Here is what we are asking:

When Openbravo 2.35 code is frozen, we will give you early access to the installer through a private FTP server. You will essentially receive the release at the same time as our QA team.
We will give you access to our QA portal, where you can see our test cases for the acceptance test.
We will assign you a set of test cases and we expect that you will install the application on your server, run the test cases and report the outcome in the QA portal
We will also assign you a set of bugs to verify (i.e. validate that bugs that are supposed to be fixed in 2.35 are indeed fixed)
We will also welcome any other testing that you might be inclined to perform, including verifying bug fixes that are critical to you or your customers.
If you have any questions or doubts during the process, we will be available on the IRC channel to answer.

The whole thing should start early next week (October 22nd) and take 2 or 3 days of your time, if everything goes well (does it ever?).

Please remember that this is going to be Acceptance Testing, not a full blown QA cycle. The purpose of Acceptance Testing is to validate that an already QA'ed release is good to go and that the last build didn't introduce any major regression (essentially: test the product as it is going to be shipped before your users do to avoid to be embarrassed later).
Because of that, we will stop the release only if one of the test cases fails with a significant bug or one of the critical bugs that we thought had been fixed still reproduces. Nonetheless, we do expect you to log all issues you find, including small bugs, as we will fix those in future releases.

What's in it for you? Well... practically not much, but you can be very proud to have helped the community and to have contributed to speed up the release of the best version ever of Openbravo. You will also be able to validate that bug fixes critical to you and your customers are indeed fixed.
Finally, you will also get a mention in our release notes, so there is some glory at stake.

So... why such a small step now? And why accepting only a handful of volunteers rather than the whole community?
Well... this is a factor of where we are in the release. Openbravo 2.3x went already through several rounds of full blown QA testing and 4 public releases (2.30, 2.31, 2.33 and 2.34). So Acceptance Testing is what we need to do next and, since the scope is quite limited, it would not make sense to involve too many people. Also, this is the first time we do this, and we would like to make sure that we can coordinate with a few people before we try with many in order to avoid wasting people's time.

For the next major release, Openbravo 2.4x, we have more ambitious plans which will include a public participation of the whole community, public status reporting, etc. We will be working on the definition of that process over the next few weeks. One of the key outstanding issues is being able to publish frequent releases to the community in order to get frequent feedback on fresh code: at the moment the build process is time consuming and manual intensive but we are working to address that.

If you have good ideas, feel free to post them as comments.

Openbravo Releases

2007-10-16T05:19:00.000-07:00

Today it is exactly two months since I joined Openbravo and I thought that the best way to celebrate is to write my first blog entry.
What will I write about? Well.. Openbravo obviously, but also other topics that might be of interest to the Openbravo community.
And what better way to start than to cover a topic that has been very hot with our community in the recent weeks... release management and release maturity.

When Openbravo 2.30 was released, the project published it as an alpha release but that status was declared only in the news announcement. When we published 2.31, we published it as beta using the same announcement mechanism.
The success of these releases was so overwhelming that, when we eventually announced 2.33, we were not clear enough on whether it was suitable for production purposes or not.

As it turned out, that was a major mistake and that lack of clarity created a lot of confusion among our community. We tried to correct it with 2.34 which was published as beta, but at that point it was too late. The damage had been done.

Through this experience, we learned our lesson and we have now published an updated release policy. All the details are in that document but, in a nutshell, we intend to distinguish between Community Edition, which is intended to be stable and well tested but published twice a year, and Developer's Edition, which is intended to be published very frequently and includes all the latest development, including features in progress.

The Community Edition will go through a stabilization process, moving from alpha version, to one or more beta versions, and eventually to production. At all stages, the status of the release will be very clearly marked both in its name and in the release notes and - by default - users will not be directed to download the alpha or beta releases but the previous stable production release.

It is too late to apply this policy for 2.3x but we will start following it with 2.4x and use it for all future releases. We hope that this policy will greatly help our community by setting the right expectations on production usage and avoid some of the confusions and frustrations that users experienced in the past.

At the same time, the Developer's Edition will allow the community to be involved in our development process and to give us early feedback on the features we are working on. This will give us not only an opportunity to continuously fine tune our product based on your input, but also to reduce the stabilization cycle of the Community Edition.