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.

Thinking about past, present and future of enterprise applications

We lived the transition from fat clients to light clients. In the client/server era we had the fat client, there was a great computing power at the desktop, a good graphical interface for enterprise applications, and users become very productive. But the Internet era appeared and we needed our applications to be accessed no matter were: at the office, at customer house or even at home. And then we get used the web browser for the application interface, we lost a little of usability and computing power in the client side but we obtained great benefits: central administration for applications, no need to install in the user machine, hundreds of concurrent users, universal availability where ever the user is located, etc.

Now we are living a revolution in the desktop because we have desktop computers with more computing power and with more graphical power. Operating systems and desktop applications look impressive: Windows Vista, Mac OS X, Beryl OpenGL desktop. But the web applications continue with this lack of usability and visual enhancements. My opinion is that the 75% of the success of a product demo is the look and feel of the application, how sexy is the user interface and how many “eye candy” can you show. And we want the best of the two worlds for enterprise applications: Usability, look and feel, computing power, for desktop side. Central administration, universal availability for the web side. And also we want to go further: to have the ability to work offline and access from mobile devices like smart phones.

There are several players in this arena, these players talk about rich clients and about technologies that satisfy all the wishes I wrote in the previous paragraph. There are a huge amount of proposals and some of them look promising: XAML by Microsoft, Flex by Macromedia, XUL by Mozilla, miscellaneous Ajax technologies, Dojo, GWT, etc. There are impressive demos and screenshots.

My question is: What is the right choice? We feel that users are pushing us to make a decision to enhance their user experience. But for the moment all of these technologies are just emerging and I cannot see a clear winner for the next years. Is it better to wait and see? Or do we have to choose and build our own proposal? This is the world of technology and these are the kind of questions we made to ourselves everyday.