openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Fabien and all,

On Fri, Jan 31, 2014 at 12:43 PM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:

>
>> *Fabien said:* for migration, use OpenERP Entreprise !
>>
>
> Yes, here is why I am convinced it's the right way to build a sustainable
> business:
>
> 1/ partners that resell OpenERP Enterprise sees new versions and upgrades
> as new business opportunities (you can offer new features, ...)
> 2/ companies that do not use OpenERP Enterprise sees migrations as a
> painful process that costs a lot and they try to avoid it. They stick to
> old versions until it becomes a nightmare to manage (exactly like in the
> SAP world where customers have to switch and leave their solution after 7
> years)
>

We basically agree with this vision and migrate our customers instead of
supporting them forever in the past. We even don't sign projects for people
who aren't convinced they will need to upgrade. Some of them like Anevia or
Adaptoo come from v5 and will make it to v8 using the Enterprise migration.
It was really painful at v5 time, but it's much smoother now fortunately.

But it's also important customers are aware of the full cost of migration
because it still cost quite a lot of days to us integrators to migrate,
test OpenERP SA migration, even with the enterprise. And you have to think
that when you change the data structure so much between versions (I'm not
telling you shouldn't, I'm certainly in favor of making OpenERP more
professional and we all know where it comes from so evolution is required),
it still cost us days to figure out the changes and adapt the
customizations and community modules, migrate their data etc... So it
certainly weights in the TCO and that should be transparent in OpenERP
marketing, not hidden.


Why am I telling this? Because both in France and Brazil where we work. #1
problem is not the lack of people interested in OpenERP. Not at all!
#1 problem is too many of these people think it would be easier than it is
(or cheaper than it is).

Then with people not aware about the costs, 2 things happen:

1) you have the foolish newcomers who sign whatever project. Then they die
or stop their OpenERP partnership quickly. That's largely what happens when
you see there is only 2 or 3 active partner left here in Brazil (one is
told to be dead) when you sold more than 15 partnerships here and had more
than 10 active partners:
https://www.openerp.com/partners/directory/BR/Brazil

2) And you have the guys like us, who grow, but refuse 80% of the guys
contacting us because they have illusion about the cost of the project. And
at the same time, because of this market irrationaly, we grow slowly; it's
slow to hire and train new guys.

And please don't try to tell the other guys would broke because of the
training. To prove you it's not I just played the game with the
certification, passed it last Monday and got it with 89%. If we are still
in the market where others are not, it's probably because we aren't that
bad at doing it. Imagine if they broken with doing the R&D investment,
imagine the challenge for us assuming 95% of the localization R&D cost and
still playing the AGPL game of publishing everything unlike many
competitors..

So, I'm here only trying to convince you that transparency is everything we
need to move OpenERP forward faster for everybody.



> And here are the result in the long term:
>
> 1/ partners with OpenERP Enterprise have customers that evolve with the
> software. You can propose new features every year, your bugs are fixed and
> pushed in the stable branch, ... They are able to deliver more and more
> values to their customers through new versions, bugfixes that are ported in
> the stable branch, ...
>
> 2/ Those that try to do everything by themselves don't do too much
> migrations as it's a painful and costly process [0]. They do their own
> hacks to deliver something but it's not a good quality enough [1] They
> usually have customers running on old versions on OpenERP and have
> difficulties to deliver more services to them. Most of legacy code ends up
> not evolving anymore [2]
>
> [0] Why is it cheaper to go through our own services? because we share the
> effort on thousands customers. We build a great platform once, strong
> process with people that do migrations every day and become very good in
> that. In the future, we think we will be able to migrate (code+data)
> localisations module for just 50 EURO (because we divide the cost amongst the
> total number of customers). This is a real solution to the sustainability
> problem of localisation modules in some countries.
>

Now Fabien have a real problem with your way of presenting this.

let's face it: OpenERP SA employees almost never invest time in improving
these community modules. Nobody from OpenERP SA invested in entering the
OCA reviewer team either and nobody is helping in the reviews.
That's a fact. Please prove me I'm wrong pointing where are all these merge
proposals to improve these community module you claim to support.
If I take the Brazilian localization for instance. Among 1000 commits, only
one little refactor commit came from OpenERP SA. But I could take many of
such examples in the vast majority of the OpenERP modules.

So what kind of service are you going to offer to these customers if you
claim you migrate community modules while it's not you developing them. Are
you going to produce forks of these community modules on the fly that will
be badly integrated with the versions maintained by the community?
If you permit me, I won't go in the detail about the guys you once sold you
would migrate the Magento connector at v6 time (remember Thorsten?).

Seriously Fabien, we are trying it hard to support your business model at
Akretion and if everybody were selling as many Enterprise contracts as us,
you would probably not need to borrow money from investors. Just a
reminder, I think in 2009 I sold what was inside your 5 first ever
Enterprise contracts. We sold among the larger Enterprise contract of South
America (not Middle one guys), we are selling a new one just this week, so
let's don't make it look we aren't playing the game.

But, still, we need to stick to the facts.
It's perfectly possible that in the future OpenERP SA plays a more
important role in maintaining community modules and localizations. But that
kind of claims will be credible only when it will have started at least in
some ways. So please get your employees at OpenERP SA try to follow a bit
the evolution of these community module, do their merge proposals and then
that kind of claim will start to look credible. Otherwise it's just like
sorrysap.
By doing that, OpenERP image would also probably improve that and would
could then afford saving on your marketing expenses (
https://www.openerp.com/jobs/job_be_marketing_manager )


>
> [1] Why I think a DIY approach or OpenUpgrade is not a good service?
> Because a new version is around 200 man*days of preparations to develop a
> clean migration system. Our service, for one specific version, becomes very
> good after we have migrated 100 customers because it's very complex to
> detect all the small details required for a clean upgrade. If you do it
> yourself, you will miss most details and you will detect bugs every week
> during 3 months after the migration. Not a good service for a customer.
>

This is absolutely true. But I think OpenERP SA has its responsibility in
not informing people how hard the job is. Also, if OpenERP was less feature
driven and more grounded in peer review as many other open source projects
do, the design of new features would probably be right sooner and migration
would certainly be easier, not only for the final customers but also for
OpenERP SA (that is you would have a larger market).


>
> [2] One year after the release of the v7 ,in countries where we don't have
> that much OpenERP Enterprise, account modules are not ported to v7 yet. Can
> you imagine asking your customer to wait one year if he needs to evolve?
> This is not a good service.
>

For sure this is not. But how is responsible for this situation? All the
integrators in all these countries? Only them? A bit easy to be true...

When you make major changes like in the partner model with so little
upfront communications about the changes, this is certainly among the
consequence to expect. I was ranting about that (and trying to make
advocate for smoother migration) at that time exactly because I was
anticipating the business consequences that will have and that the business
model would be even harder to support for the few guys surviving these
cataclysms (like us).


> Just have a look at the module graveyard of modules from v6.1 that are
> still not ported to v7. If everyone would have a maintenance contract that
> allows upgrade, OpenERP would not have such sustainability problems.
>

Also this is not only with the community modules. If you look at OpenERP SA
graveyard of dead modules there are quite a lot of them too (bi, etl,
mysql, report designer, base_module_record, dia RAD, wiki, early eshop...).


>
> *But:*
>>
>> 1- I use OpenERP community module to be able to have OpenERP that can do
>> the job for my french company (Services on OpenERP, OpenSource ..)
>>
>
> Everyone uses community module.
> And our migration services are organized to work on top of this
> efficiently.
>

Agree.


>
>> 2- I have no OpenERP entreprise now, because when they do a migration,
>> they migrate the core, and deactivate other modules. but how can you
>> migrate crm.meeting to calendar.event if community module add some date on
>> it ? how OpenERP take care of this ?
>>
>
> No, that's not what we do.
>
> We give you a database where the core is upgraded and your modules are
> still there but you have to continue the migration on your own modules. (or
> we also have a service where we cover 100% of the job, for just 800 EURO per
> 1000 lines of code).
>

Agree, but not with the idea of OpenERP SA migrating these community
modules themselves in a sustainable way (see my upper comment).

And also, in any case, projects like OpenUpgrade are very important to
support the migration of the community eco-system. We need the same kind of
tools that OpenERP has to migrate community modules because we face the
same evolutionary challenges and it's extremely important projects like
OpenUpgrade exist and be serious.


>
>>
>> How do you manage this ?
>> By migrating I think: migrate code, view but also Existing Datas.
>>
>
> Yes, our service covers everything:
>   - upgrade of the code (code, adaptation to new report engine, ...)
>   - migration of the data
>   - tests
>   - plateform to automate the process so that you can replay it when you
> want
>   - unlimited bugfixes tickets related to the software or the migration
> service.
>
> Oh, and it does not cost anything to upgrade! You can even ask us to
> upgrade a v6.1 customer in v7 just to organize a demo to him to sell him
> new features:services. Even if you are not sure he will upgrade, you can
> ask us to upgrade; just to test.
>

That would be if we were selling a crude OpenERP without any added value.
That would be we would be doing the same job as your OpenERP SA: we would
be competing with you.

But, if we are here, and survived all these years OpenERP wasn't yet mature
out of the box, it's exactly because we built added value services atop of
OpenERP core and fortunately we aren't competing with OpenERP SA trying to
sell crude OpenERP without extensions.
So unfortunately these extensions do have a cost to migrate and contrary to
what you just said, I think it's very important to be transparent on that.


All right, hope it doesn't sounds too harsh. In any case, I think it better
people give their views and adapt their policies instead of increasing
incomprehension faking it's all all right.

Overall, despite raising these divergences we are rather happy with the
OpenERP product and with working with OpenERP SA. We are just trying to
improve what we think are the current bottlenecks of the business.

Finally, congratulations for v8, it's really yet a huge step forward for
OpenERP and that will certainly help all of us moving OpenERP forward.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com