Openbravo ERP

Some remarks:

That new roadmap sounds reasonable to me, I wouldn't do different if working on Openbravo. Community consultation is a smart move. Compiere is thinking again about more transparency, but not that much, no question here.

Mete,
About the database independance and the 'Green' revolution or revolution:
this is my own opinion, but I don't consider "database independence" is doable for real in the short run. I mean it would be too expensive, they would have to recode their 500 000 pl/SQL lines or spend a lot of time ensuring an other database can run it too. Look at how expensive (how many bugs in the past) it has been to allow PostgreSQL. I think PostgreSQL is enough to support as the free option.

The current added value of Openbravo is those half a million pl/SQL lines of code (mostly from Compiere, but not only) and the concept itself of a free and well supported ERP marketed as a Java technology that attracted investors. If you question those Oracle lines of code that lurk behind the XML files, you question Openbravo itself I think. Mete, also look at OpenERP: they only allow PostgreSQL but they already abstracted the persistence layer and the result is that they are growing very fast now. So I think if Openbravo can achieve such a valuable platform by 2.50, then it's OK and they'll start receiving lots of third party contributions. That's not a big deal if DB2 or MySQL can't run Openbravo yet. Other investors (or thirs party coders) could fund this later on when the project is successful.

As I said, I'm not sure this will work considering the OpenERP competition, but at least I think that is any case the best option is indeed to fix the existing SQL codebase, make it good enough so one can use it blindly, just like say a Linux box, and also provide that new database access layer one can then build on as the new foundation for the future features. I think the Linux kernel is a good example to follow: it's not always well written, it's barely understandable, but as soon as they made it work really well lots of people started using it without needing to understand what happens under the cover. Kernel contributions are only a very tiny fraction of the users mass, still bug reports are more common and they help the core developers for sure. I think if Openbravo can achieve that with the existing codebase, they will succeed.

Granted those 500 000 pl/SQL lines of code won't start using that new platform miraculously, but at least the community might then benefit of an open source viable platform to start build something cleaner and more complete, once you have both the modularity and a persistence layer abstraction people can start focusing on functional code and functional modules can be contributed from all over the world, just like it's now happening with OpenERP modules for instance.

Overall, I think we will seriously look at Openbravo again around October for 2.50. I didn't realize how much work Openbravo would throw in that soon. By the way, I've been happy to see that in developing countries like Brazil were no mid market proprietary ERP fits, Openbravo is already clearly competitive and lots of integrators like Vipware are preferring it over Compiere. I just wish the same happens in France and other western countries too but it looks like it's harder considering the mature and reasonably cheap mid market proprietary offer here. So I think we should wait a bit that new 2.50 platform and clean up make the integration costs drop so it's more doable here. May be it's the same situation in the US and US localization should then not be considered a top priority over platform refactoring, but I'm not sure about that. Some US firms might also be more gutsy when investing, so you know that better than me.

Kind regards,

Raphaël Valyi.