openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #02588
Re: Install Decision
Hello,
I am very glad for this thread, because I was going to start a very similar
one myself. Please excuse me that this email has become longer than I
expected.
I am in a very similar position to Hassan. Please allow me a short
introduction of myself:
- I was following TinyERP / OpenERP development from about 2005. This
basically means that I played with most major releases for a few days, but
back then I did not have an immediate need for an ERP. Now, we are planning
to implement an ERP in our company, and OpenERP is one of our main
candidates.
- I also followed and tried other open-source ERP software like Compiere,
ADempiere (was enjoying the famous forking debate in real time on their
forums) and OpenBravo. I also checked out Apache OfBiz, which seems to be
more like a framework to build on, not a complete ERP package that you can
take and customize -- although I realize that the barrier between
customization and building on something can be fuzzy.
- During my 10 years as an IT professional I was working as a developer,
architect and project manager. I worked on embedded systems (e.g.
proprietary mobile phone software, Android system development and porting
to new platforms) and as the lead architect of multiple enterprise
applications, like a CRM system for a specific market.
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:
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.
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.
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.
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.
Obviously, if we go for OpenERP, we will act like good citizens of the
community by contributing back our own changes (we will have to do some
significant changes around the project and hr modules to support our use
cases). We will probably contract with one or more partners to do some of
the work, but we will also have to build up internal development and
operations capabilities because an ERP affects almost all aspects of a
company and one of the reason going with open-source is to avoid vendor and
service provider lock-in.
I am very interested in how you see these issues: both OpenERP SA and the
partners, people already using OpenERP in production, and people still in
the evaluation phase.
Thank you and Best Regards,
Gergely
2013/4/20 Stefan Rijnhart <stefan@xxxxxxxx>
> On 20-04-13 16:42, Stefan Rijnhart wrote:
>
>> OpenERP is still governed by a single commercial entity and no other
>> party has access to the official branches.
>>
>
> In so far as that was not clear from the rest of my post, I meant to say
> 'no other party has *write* access to the official branches'.
>
>
>
--
Kis Gergely
ügyvezető / CEO
MattaKis Consulting
Email: gergely.kis@xxxxxxxxxxxx
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622
Follow ups
References