openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

Hello,

A few comments inline.

>> Based on my experience and what I read on the various public forums
>> related to OpenERP, my main concerns regarding OpenERP are the following:
>> 1. Lack of public roadmap driven by the community: 
> I'm coming to the conclusion that they just don't know how to work as a
> team with their partners and their community. I haven't made my mind
> up yet whether this stems from arrogance or something else.


Communication on our R&D effort is one of our biggest weakness.

The main reason we don't communicate more on future tasks is a lack of
resources.

A few point that may help you:
  - We use to define a direction, but not a detailed list of features.
    You can get some insights here: http://bit.ly/15UuGHs
  - The detailed roadmap is presented once a year during the community
    meeting. The next one is here: https://opendays.openerp.com/
  - We use a lean approach for our project management; tasks are defined
    every day and closed a few weeks after. (We do about 5 new tasks
    per day) We don't want to decide (and describe) everything we will
    do one year in advance.
  - Everything we do is public, you can follow commit on the trunk
    branch to check what's being developed. Or you can check the runbot
    http://runbot.openerp.com as we do one branch per new feature.

One thing we will do to improve this is to publish our internal project
management so that everyone can follow our tasks. (we are working on
implementing the OpenERP portal on our own branch)

>> based on this you can decide, whether you can start your ERP
>> implementation based on v7, or trunk. You would choose
>> trunk, if you know that there is a feature being developed
>> on it, that you would have to develop yourself for v7, and that trunk
>> will become the stable vXY in time for your ERP implementation. 
> 
> From my experience working with other Open Source projects you should
> *never* rely on planned features in trunk.  Use the latest public
> release as your starting point and work from there. It's much easier to
> port features from trunk to your stable branch than trying to work with
> a continuously moving target that developers aren't interested in
> keeping polished for every day use.  This applies to all projects, not
> just OpenERP.

I confirm. You should never start a project on the trunk branch.

Even if the new features may look promising, you should not rely on
them. We can change our priorities from one-day to another, we may not
merge a feature that we developed if it did not passed our code/quality
reviews, etc.


>> 2. Data migration between releases: I still can't really wrap my head
>> around how can one release an enterprise application without proper
>> migration support between releases. On our enterprise software projects
>> I don't allow commits that change the DB schema and don't have a DB
>> migration solution from the previous version(s). This migration not only
>> includes the creation of the missing tables, columns ... etc. in the
>> database, but also the semantic transformation of the already existing
>> data. Not doing this, when you write the actual database change is very
>> similar to not code your automated tests when you do a change: it is
>> much more expensive to do it later. I understand that there is a paid
>> service offered by OpenERP AS to migrate existing databases. But it is a
>> closed source process, which is very hard to audit. And we all know that
>> any ERP application is worthless without the data in it. It is also kind
>> of a vendor lock-in, because even if you work with a different OpenERP
>> partner, they can only do the migration either by subcontracting OpenERP
>> AS or by using/improving the community migration scripts, which are
>> still lagging behind for v7 even months after its release.
> 
> I can understand your concerns about this point. I don't much like it
> myself, but we're talking about an ERP system here.  It is such a
> complex beast that I can't honestly see any organization that has done
> any non-trivial customization to OpenERP upgrading with every release.
> So, for me this is not a deal-breaker.

You should read this, it explains deeply why we think this is the best
model:
  http://bit.ly/openmodel

Read at least these two sections in the above link:
  - How does OpenERP see the relationship with the Community ?
  - Why does the Community need Partners, Customers and the Publisher?


>> 3. An alarming lack of consensus on the more technical aspects of
>> OpenERP between OpenERP AS and the partners, most recently demonstrated
>> by the contact_id - partner_id issue
> 
> Yes.  Don't get me started on how much OpenERP SA's attitude towards it
> community really pisses me off.  Especially, because I come from a very
> Open Source mentality where technical merit and the willingness to do
> the work trumps everything else.  In the FreeBSD project, where I've
> been a committer for several years (although I have been dormant for the
> past few), we have our pissing contests and (sometimes) public
> disagreements, but usually in the end we and our users get a system in
> which a combination of the best technical solution and the solution that
> someone was actually willing to implement and maintain won the day.

Within the OpenERP community, we have one big discussion like this per
year. It's like that in any good open source project. And it just
reflects the fact that people are passionate about OpenERP.

In every open source projects, you have frustrations because a few
persons and commit rights and the others don't.

So, it's just a technical disagreement between different people. But the
great thing with open source is that everyone is free to do whatever he
wants. You can always implement your solution in a module.

Please note that, now, main partners agree on the implementation taken
in v7 for partners:
  -
https://docs.google.com/file/d/0B5BDHVRYo-q5aTBHa0xxNmpLSVE/edit?usp=sharing
  - http://bit.ly/10WPN5S

So, we just did our job; code reviewing and refusing some branches if
they are not clean enough.

I understand it can be very frustrating, but it's necessary to ensure a
clear direction in the product.


-- 
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com