Openbravo POS 2.00 released

Last week Openbravo released the first version of Openbravo POS under its new name. You can read all the details of the new version in the press release published.

We are very happy with this release and we achieved all the objectives expected. We included nice features like having the localization files in an external folder to allow to add new localizations as a plug-in without having to recompile, new Substance look and feel themes, etc. We also fixed most of the bugs reported in the Sourceforge project pages. You can read the full release notes in the Openbravo wiki. We are also very grateful for the response of the community to this new release. Today Openbravo POS is one of the top 25th projects in Sourceforge and we expect to stay there for a long time. This is something that gives us a lot of energy to continue working hard.

Now we are working in the roadmap for the next release. This roadmap will be published in the wiki pages as soon as it is finished. In the next release we plan to continue with the same objectives and focus in the localization issues of Openbravo POS, to complement Openbravo ERP and to include new features and stability to Openbravo POS. In one sentence, to give to our partners and our community a competitive product in the Point of Sale software arena and, in association with Openbravo ERP, the best open source software suite for SME.

Call for participation in Openbravo POS 2.00 acceptance testing

Openbravo is going to launch Openbravo POS 2.00 in few days. This is the first version of Openbravo POS under its new name and we are asking the community to help us validate its quality before release.

If you are willing and able this opportunity is for you! Notify us of your interest by sending an email to collaborate at openbravo dot com.

The process is going to be very similar to what we do for Openbravo ERP and the process we will follow is the same we used for Openbravo ERP R2.35. Specifically, here is what we are asking:

1. 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.
2. We will give you access to our QA portal, where you can see our test cases for the acceptance test. Please note this will be the first acceptance test for Openbravo POS.
   
3. We will assign you a set of test cases and we expect that you will install the application on your machine, run the test cases and report the outcome in the QA portal
   
4. We will not assign you any bug to verify as we will execute that task internally. Obviously you are free to verify specific bugs that you care about.
5. If you have any questions or doubts during the process, please contact at pablo dot sarobe at openbravo dot com (QA Team).
   

Acceptance testing should start on February, 18th and ideally should last 3 or 4 days.

Please remember that this is going to be an 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. Nonetheless, we do expect you to log all issues you find, including small bugs, as we will fix those in future releases.

Openbravo POS 2.00 is the starting point of a product that we are investing a lot of effort to offer this great portfolio of open source applications for SME. There are important features included and a large list of bugs fixed. We look forward to your participation!

Openbravo POS product launched!

Last week, Openbravo POS has been officially launched as a new member of the Openbravo products family. It has its own product page at http://www.openbravo.com/product/pos/ and the name migration from Librepos is complete. That comes with a new project page in Sourceforge http://sourceforge.net/projects/openbravopos/ and a redirection from the older project pages. I expect that the old members of the Librepos community will not get lost and start working in the new project pages as soon as possible.

Also, I want to remind to the Openbravo community that we have great plans for Openbravo POS and we are working to execute them. The first step is to release the first version under its new name in mid February. Check the road map at http://wiki.openbravo.com/wiki/index.php/Openbravo_POS_roadmap. And a training course will be held in Barcelona in april, in English and Spanish.

Openbravo has acquired Librepos

As you already know, Openbravo has acquired Librepos. I am very happy because now under the Openbravo umbrella, Librepos has more opportunities to grow and succeed. In order to be aligned with all the company products, Librepos will change its name to Openbravo POS, just an aesthetic change that will not change the soul of Librepos.

This acquisition will benefit the Librepos community of users and developers for several reasons. First, the continuation of Librepos is now guaranteed, Librepos will be an independent product of the Openbravo portfolio hosted in Sourceforge, and is and will be open source and licensed under the GPL. Forums will continue actively and there will be frequent releases of Librepos. Openbravo is a company truly committed to open source and believes in the strengths of the community to drive innovation.

Second, I will continue to be involved in the future of Librepos. I am the founder and main developer of Librepos since I published Librepos in January 2005. Now I joined Openbravo as Senior Architect and Librepos is part of my responsibilities. This is also great for me because previously to this acquisition I used to spend my spare time on Librepos, now I will have more time for Librepos, because now Librepos is part of my job.

And third, Openbravo ERP and Librepos are products that will benefit one from each other. Users of Openbravo ERP usually need a point of sale like Librepos and also users of Librepos usually need an ERP like Openbravo ERP. Both products are complementary and making both products run together and integrated in the same environment is a great value proposition for the retail market. It is already possible to integrate Librepos and Openbravo ERP, a solution that offers the possibility to share data between the two applications.

The future looks promising. Now we are working on the roadmap and business plan for Librepos. These plans are very ambitious and will be published as soon as possible. For sure, the most demanded features of the Librepos community will be included, and you can participate in these plans creating new feature requests and creating new bug reports.

Documentation for Librepos has been in the past the weakest side of Librepos. Now we will integrate the current documentation of Librepos in the Openbravo's wiki and will work to expand this documentation to achieve the best quality.

We are also planning a training event on December 17th - 18th for Librepos. This training event will be held in Madrid, Spain. This training event will be in Spanish but the material of the training will be in English. The details of this training will be available soon in the Openbravo web training page.

I look forward to meeting you in this first training of Librepos and discuss with you about the future and the possibilities of Openbravo ERP and Librepos.

Database sources management plans

We think that the database source management plans for Openbravo ERP will offer great enhancements to our community of users and developers. Database structure and data development is very complicated: you cannot develop a database the same way you do with java source code, you cannot use a version control system like CVS or Subversion to track the changes, and you cannot deploy the changes you made into a working database easily. For those reasons we are working to simplify the development and deployment of database changes.

Our main target is to get rid of the two database dumps we provide for Oracle and for PostgreSql in each version and to provide the structure and data of the database in several XML text files that define the sources of the Openbravo ERP database. These XML files must be database independent (they must be the same for Oracle and for PostgreSQL) and must create, when "imported" to an empty database, a working Openbravo ERP environment, in the same way that the current database dumps do.

This way, we will be able to manage database changes in a Subversion repository in the same way as the rest of the Openbravo ERP source files, because XML are, in fact, plain text files. With a Subversion repository, we will be able to integrate the development of new Openbravo ERP functionality in an standard process, commit all changes - including those done in the database - to the Subversion repository, create log changes based on commit comments, link a commit to a tracker entry, create nightly builds based on the last commits of a day, etc, etc...

As an additional benefit, if we have the database schema of two versions of Openbravo ERP described in XML format, with the right tool we can generate a SQL script that upgrades the schema from one version to the next. By that, I mean a SQL script with the appropriate DDL and DML statements (i.e. "ALTER TABLE ...", "INSERT ... ", "UPDATE ..." commands) that upgrade the database.

There are many issues related to database migration/versioning problems, but we do not need to solve them all; we just want to solve the major issue. The problem we are going to focus on is to include all the database changes we make from one version to another, and all the database changes our developers and users do when developing new Openbravo ERP functionality, when fixing bugs, and when customizing for customers... We will release documentation for developers about what this tool can do and what this tool cannot do, and methodology about how to implement the most common database changes a developer needs when developing Openbravo ERP functionality.

Once we are able to create database scripts that upgrade a database from one version to another, it will be easier to upgrade Openbravo ERP installations in production environments, everything at one time: sources and database. To create patches of Openbravo ERP functionality. And to keep a development environment updated with the latest commits from the Subversion repository of Openbravo ERP.

And now, what tool do we think is the best? We are using a tool by the Apache Software Foundation called DDLUtils: http://db.apache.org/ddlutils/ . This is the definition of DDLUtils taken from its home page: "DDLUtils is a small, easy-to-use component for working with Database Definition (DDL) files. These are XML files that contain the definition of a database schema, e.g. tables and columns. These files can be fed into DDLUtils via its Ant task or programmatically in order to create the corresponding database or alter it so that it corresponds to the DDL. Likewise, DDLUtils can generate a DDL file for an existing database.". Exactly the tool we need.

Since DDLUtils only supports tables and not altering data - it only works for the database schema - we are hacking this tool to include support for all the database objects included in an Openbravo ERP database: views, check constraints, procedures, functions, triggers and sequences. DDLUtils support a lot of database engines but we are only adding support of these database objects only for Oracle and PostgreSQL.

We are also adding support to merge data allowing insert, update and delete of data in the corresponding database. This will allow us to upgrade the metadata model of Openbravo ERP from one version to another: Tables, Windows, Reports, etc.

We made a lot of progress hacking DDLUtils and creating the sources XML text files and we expect to release a first preview of the database versioning project soon. We know that there will be a lot of problems and things to polish before the tool we are building becomes production quality, but we are confident that we will be done it in time and that this will be a great improvement for all the Openbravo community.

There is an open discussion of this topic in the following thread of the Openbravo forums: http://sourceforge.net/forum/forum.php?thread_id=1790871&forum_id=549512

Everybody is invited to participate.

Openbravo Green. The next platform.

Green is the codename for the new technological platform of Openbravo. Openbravo Green is built on the strengths of the current release, improving those areas where limitations to the current model have been encountered.

One of the main aspects of Openbravo Green is openness: an open source project, based on proven standards and open source technologies. This will benefit the Openbravo community with a product easier to learn, extend and integrate with other products.

Another important aspect of Openbravo Green is that we do not want to lose all the functionality, developments and knowledge around the current Openbravo platform. We will put all our effort to do the upgrades from previous versions as easy as possible and to ensure the reliability of the upgraded system. In most of the cases you will be able to run the current functionality in Openbravo Green with no changes at all.

I am proud to announce that there is a platform prototype development in progress for Openbravo Green. Currently this prototype is just an example of an Openbravo window that allows to view and edit records of product categories of the Openbravo demo database. In this prototype we are testing all the aspects we want for the Openbravo Green platform: technologies like the Spring framework, Hibernate, Acegi security, Dojo toolkit DWR, and so on. And also we are trying to organize the source code in layers to keep the design of the application as clean as possible. We want to make with this prototype a proof of concept of the Openbravo Green platform and include all the features and requirements we are planning for the Openbravo Green platform. You can have a look at the demo at http://demo.openbravo.com/green/ and if you want to go further you can also check out the source code and give it a try: http://openbravo.svn.sourceforge.net/viewvc/openbravo/branchs/green/

We are very excited with the opportunity of starting a community-driven development and incorporate all the best that you: developers and users can offer to this development. Everybody who want to be involved in the development of Openbravo Green is welcome. We are looking forward to get feedback from our community regarding Openbravo Green. You can follow the discussions in the Openbravo Green forum: http://sourceforge.net/forum/forum.php?forum_id=680521

By now there is a proposal available for reviewing and feedback http://wiki.openbravo.com/wiki/index.php/Design_principles_for_Openbravo_Green until 1st of August 2007. Once the design principles are frozen, we plan to continue with the detailed architecture design documents, which will also be a subject of discussion during a period of time.

See you at the Openbravo Green forum.

Source code quality

When you need to evaluate software products: applications, libraries, frameworks... Open source software has a powerful tool to perform the evaluation: the source code. It is like when buying a car, you see the tyres, wheels, doors, interior equipment and so on, but it is worth to open the bonnet and have a look at the engine.

Inspecting the source code you can learn a lot of things about the software and the team who developed it, if there is a disciplined and intelligent group of people behind that software. The things I usually inspect while browsing the source code developed by third parties are:

• Is the code is well organized? Does if it follows coding guide lines like this one for java or this one for c#?. Can you can understand what the classes and methods do reading the name? Is the code well commented?
• Is the code complex? Is it spaghetti code or not. The code is complex when there are classes very big, methods have many parameters, and contains a lot of lines, classes have a lot of dependencies with other classes. An the opossite, the code is simple if classes are small, methods does not contain a lot of lines, you can recognize well known design patterns, there are not duplicated blocks of code.
• Is the code managed with a version control system and the changes are reflected properly? Does the software have a bug database? Does it provide tests? Does it have a good logging system?

If you are an skilled developer or can ask to one, you can also check more things regarding the source code, but with these three aspects you can have a general idea about the source code quality of a software product. It is impressive how your opinion about the general quality of a product can change before and after inspecting the source code. Is it better before to be tied to a software product, to check also the source code. There will be less surprises in the future.