Wednesday, February 20, 2008

Openbravo community plans for 2008

Year 2007 has been a tremendous year for Openbravo. During this year we focused our community efforts on adopting the best processes and methodologies for Openbravo ERP development.

Our communication and transparency has been greatly enhanced including: publishing and updating our roadmaps, setting up IRC channels and having regular chat meetings, start using mailing lists or the blogging and Planet efforts. Another accomplishment has been in the documentation area. Openbravo ERP started as a home grown solution for enterprises and its documentation was modest. Openbravo community have been working hard on extending the Openbravo documentation. Still many efforts are necessary but a good progression is made every week.

During year 2008 we plan to focus on providing a better infrastructure for people developing Openbravo ERP and POS, and also, for people working on Openbravo related projects, like plugins, verticals or localizations.

Let me give you some highlights of our planned services:
  • A better Wiki. Building on top of our Wiki we plan to add more exciting functionality: enable users to rate articles, activate the discussion pages to allow people to comment on already existing articles, a better category system, better integration with other Openbravo news sources using RSS.
  • New forums. This is has been a long request from our community: to have a better and more powerful forum system.
  • New bug tracking system. Our current bug tracking system at SourceForge has many limitations. We have been evaluating different solutions we would make a decision soon.
  • Single sign for all the community services enabling users to authenticate once and gain access to the resources of multiple community systems.
  • Openbravo Forge. Starting with Openbravo ERP R2.4x series, to be released in June 2008, it would be more easy to develop and deploy plugins, verticals and extensions. The objective of Openbravo Forge is to provide hosting services for projects of Openbravo contributors and to boost collaboration between the different efforts. Services like forums, source control, bug tracking, news publishing or file downloads would be provided.
This is the direction that we are working and we hope that it would happen during 2008. We are focusing first on the new bug tracking system and Wiki and then in the rest of the services. We ask you please to be patient. Any feedback on these plans this is really appreciated.

Anyone willing to provide additional services or resources to help to build our community is more than welcome.


Raphaël Valyi said...

Hi Jordi,

BTW, I noticed that lot's of bug corrections in the bug tracker don't include cross references to the corresponding SVN changes. Please could you ensure those are made? It's very important indeed to see them in order to gain good readability on which build may or may not have the listed regression. It also learns your community about what kind of resolutions have been made for what kind of bugs. Thanks and keep it great.

Also, IMHO, I would rather make Green or OB platform architecture a higher priority than community services. Indeed
I think there is no point in trying to get community contributions when the platform is not good enough to make third party developments integrates smoothly and effectively. And even if you get some contributions, they might be a wasted effort once a better platform allow a higher level of functional modeling (like BPM instead of harcoding processes flags in pl/SQL, like ORM generated webservices (like TinyERP or Ofbiz) rather than hand written webservices).

Let's take an example, take TinyERP, they get way more community contributions for much less money invested (they didn't even raise funds yet and the CSS of their web site stink totally):,com_mtree/Itemid,111/

I think it's due to the smart ERP platform they provide: it's really modular and fine grained (OOP Design, no pl/SQL).

So my point is the platform quality is more important than the money you put to try to drive third party contributions.

Still, as long as you can sustain the two efforts, I'm happy. In any case, we still see lots of value in OpenBravo, marketing power included. So keep it great.

Best regards,

Raphaël Valyi.

Jordi Mas said...


In order to understand which bugs are fixed by which subversion revisions have a look to the commits log, where the bug fixed is inidicated.

All the architecture documents and code that we have done for Openbravo Green is published in Subversion and in the Wiki.

During the last months we have been very busy working on the 2.3 and 2.4 releases. Now we are really focus on delivering Openbravo ERP 2.40.

After Openbravo ERP 2.40 is released, we are going to try to accommodate resources for Openbravo Green, come up with a tentative roadmap and keep working on it.

Best Regards,


Raphaël Valyi said...

Hi Jordi,

thanks for your explanations.
Still, you said:
"In order to understand which bugs are fixed by which subversion revisions have a look to the commits log, where the bug fixed is inidicated."

-> I'm Ok with that and that's indeed 50% of the needed information. Still, it's also very good, and usually done this way in big IT companies to have what we call a "cross reference": meaning: inside the bug tracker: when you close the bug, you say what are the corresponding SVN commits.

Here is an example of what I mean:
6270 is the cross reference here.
Unfortunaltely only a few OpenBravo bugs seem to be managed this way currently.

Indeed, here is the usual workflow: you notice something strange using OpenBravo, say with PostgreSQL and suspect a bug. You look after that in the bug tracker and find a bug that seems to correspond to your problem. Then it saids it's fixed. Cool, but what SVN version should I upgrade to get it fixed? Is my version supposed to be fixed already and is that an other bug or the bug has been closed mistakenly?

By adding that cross reference. It will takes really less time to any community member to grab the corresponding SVN revision and test it against the bug scenario. Otherwise you really have to try to understand yourself the origin file to then look after the SVN logs or update by dichtotomy, but that's way too much hassle to hope to much community feedback this way.

And considering the whole complexity of OpenBravo I think this is really important you lower the contribution and test barrier to the maximum to get the maximum feedback and hopefully build a rock solid product.

BTW, at we are indeed waiting forward that 2.40 version. We see it as more competitive on the PostgreSQL side and in general stability. Hope it will rock and we can start business arround it and contribute the feeback you could then expect. We are quite confident, good luck.


Raphaël Valyi