openerp-community team mailing list archive

[Nicolas Jeudy <njeudy@xxxxxxxxxxxxxxx>]

Agree with this. thank Raphael

Migrate a customer database is :

- Migrate core (OpenERP Entreprise)
- Migrate extra module (Extra OpenERP SA or community)
- Test, review and support our customer because it's not juste one click
approche. (Extra partner services ..)

so it is not "*does not cost anything to upgrade*" like fabien said I think.

Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : njeudy@xxxxxxxxxxxxxxx
mob. : +33 (0)6 28 95 36 64
http://www.tuxservices.com


2014-01-31 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€ (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€ 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
>
>
>