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 : [email protected] mob. : +33 (0)6 28 95 36 64 http://www.tuxservices.com 2014-01-31 Raphael Valyi <[email protected]> > Hello Fabien and all, > > On Fri, Jan 31, 2014 at 12:43 PM, Fabien Pinckaers <[email protected]> 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 > > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
