openerp-community team mailing list archive

[Michael Telahun Makonnen <mmakonnen@xxxxxxxxx>]

Hi Gergely,

Just as a data point let me tell you why I've chosen to use OpenERP.

First, I don't have the resources to start and maintain an ERP project
on my own. It's easy to write a custom HR application or a custom stock
application or a custom purchase management application as a one-off
event or even as a once-in-a-decade sort of project. But an ERP isn't
just a bunch of stand-alone applications.  It's all those applications
rolled into one, working as one integrated application. Frankly, I don't
have the resources to create (let alone maintain) something like that.
Building on the work of others allows me to code only those
functionalities that my customers need without having to build the
entire stack myself.

What I've said so far can apply to any Open Source project or ERP.  The
reason that I use OpenERP specifically is because for me it has the best
balance of "complex enough to be useful", but also "easy enough to
customize for specific need"s.  Part of this is the architecture of
OpenERP itself, and part of it is also the nature of the Python language
itself.

Additional comments in-line...

On 04/21/2013 10:55 AM, Gergely Kis wrote:
>  
> 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: 

Yes, this is one of the things that really sucks about OpenERP.  After
watching them on the bug trackers, their public communications, etc. 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.

> Right now, not even the OpenERP partners know exactly what is planned
> for the next major release, how will that be implemented... etc. This is
> very important information, because 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.

> 
> 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.

> 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, which seems to be resulting in 2
> incompatible branches of v7: one maintained by OpenERP AS and the other
> by the partners. I also have to say that based on my experience with
> both enterprise applications and also software development in general,
> the solution proposed by the partners is the better one. The problem is,
> that if you don't want to be "locked in" in the v7 community branches,
> you also have to start maintaining separate trunk branches to make sure:
> - to have an upgrade path to trunk and later stable branches at all times
> - it is possible to merge this branch back to trunk if and when OpenERP
> SA can be convinced that this branch has the better solution, e.g. based
> on the number of actual OpenERP customers choosing this branch instead
> of the official ones. 

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.

> We live in an imperfect world, and if OpenERP had only one of these
> issues, then I would not write this email at all --- we would be already
> working on our ERP implementation based on it. But these issues combined
> make me worry whether OpenERP is the right decision.

For myself I can only say that despite its failings I will continue to
use OpenERP for the foreseeable future because it offers a good
foundation as an ERP for SMEs, but it is also easy enough to customize
for an organization's needs with *very little effort*.  That last part
is very important for me.

Regards,
Mike.