@Ana,
> I don't understand when you say things like... OpenERP needs good python > knowledge to be implemented on production. Well excuse me, that's me who don't see your point: - you are almost the unique OpenERP integrator that didn't learn programming along you functional skills. You are almost the unique exception and you could start a sustainable activity only recently (one year ago you would not have make it, too many bugs). - even with that, you still rely on programmers like us to manage some of your own projects. I mean, We or Zikzakmedia and the other gave you a hand on your projects (Elsenordelmar, Logiscenter... for us). How would you do without engineers? I mean I absolutely do not criticize what you do and I'm happy when we can team together, but what is your point coming here and telling programming skills are optional? They are optional if you pay somebody do it for you, otherwise I don't want to see how you'll migrate your data/version or close you accounting period. I mean this is pretty much when you came here to tell hey folk we can integrate OpenERP in 5 days, and then you Gtalk me during week ends because you are totally lost with data importation and OpenERP bugs, why do you need to come and tell it's so easy then? What the benefit of this, getting a ton of noobs jumping in that will fail their projects and then tell OpenERP is crap? For your customer to pay you even less days for your projects, so we don't have the skilled integrators ecosystem that make the product more mature? > I think is important to define what really the customer needs. There is > miriad of little and medium companies where OpenERP estable release + country > localization modules fill perfectly their needs without needed programing for > them. Of course the smaller the perimeter, the more you can do without coding. Don't get us wrong, coding is not only about creating new modules to meet exotic requirements. It's also very much about only getting rid of the nasty blocker bugs. All versions have critical bugs. On a small scope you can may be find a version that fit your basic needs. On a larger perimeter, like for instance when accounting is required, that's impossible (or do you think we fight on Launchpad bugs just for fun?) I'm suspicious Spain is not where accounting is the most challenging. But I know that in France there were much more issues. I bet @Gavin in the US is totally lost. Now for us in Brazil, we need module such account_tax_include to respect the fiscality (+ a good deal of other modules). account_tax_include have rounding bugs such as this one: https://bugs.launchpad.net/openobject-addons/+bug/510726 Do you really think that's good to tell: hey folk no problem you can go in prod with this out of the box? Well I don't. > Look at invoicing, sales, purchases modules... there is so many modules > related to same area... is imposible managing and being informed about all > published modules and I'm sure there is a lot of duplicated functionality > built. OK, we all agree on this; this doesn't scale at all. And that's one of the reason the community recently have an argument with Tiny because they were giving no direction tho the community: http://n3.nabble.com/Simple-things-we-need-from-Tiny-for-better-bug-planning-management-tc132053.html#none But, the reason why this list is huge, redundant, incompatible is: - Tiny/Axelor put all their modules here, even when they are not reusable at all (just check picking_merge or the verticals). The partners on the contrary keep non reusable modules in other branches or in the addons-community purgatory without polluting too much the main module list. You have here some good modules done for real customers with skilled guys, and you also have some mere proof of concept done by unmotivated /unpaid Indian developers there were doing something else 3 months before and think they will do something else in 3 months... - lot's of the main module do not have the quality we would like. So unfortunately we should patch them in extra modules. Take the addons pos module or mrp_repair module (try to handle RMA with that), so that's largely why so many modules. So, it's important to get it right: our fight is for a decent quality inside the core addons that would AVOID us to create so many crappy one-shot modules (which in turn disperse effort and increase integration cost). This pretty much because we were not sure Tiny was putting enough care into merging back the community refactoring of those core modules that we had all that tensions last weeks and forks were talked about (no serious guy can trust they can do it alone, they didn't had one single full time guy to package 5.0.7, how would they tackle that refactoring job at the yearly major releases like 5.2?). This is also a reason why the Tryton fork has been created. Indeed, lot's of new fancy things were announced, but less than 2 months before the 5.2 freeze, the basic refactoring was not addressed between Tiny and its community, leading the all our questions. For long Fabien have marketed it as a value to have so many modules. Today, I'm asking for house cleaning and stop valuing only the module number. It would be as nonsense as when coders where paid per code line (leading to crappy unmaintainable legacy software). To this respect, I totally share @gavin concern about release management: no, that's nothing serious yet, and that's why I do not recommend to just grab a release. There is no release schedule, 5.0.3 to 5.0.4 was 2 weeks, 5.0.6 to 5.0.7 is like 6 months while 5.0.6 has pretty serious bugs (most of our customers cannot live with them). Release were done without RC (remember I had to cry for a testing period for 5.0.7 because they didn't notify us, however one month later it's not out, Tiny never told why). You better demystify Tiny's work. Lot's of regressions are introduced by them and not trapped by their test suite but rather by partners test suites, such as: https://bugs.launchpad.net/openobject-addons/+bug/511104 Even with such evidences they didn't give attention yet to those life saver initiatives... So yeah, things are far from perfect. However, it's improving and it already can be used under some circumstances, which is very great already and with Openbravo, I believe their is no comparison. I couldn't spot it at the time I wrote the Smile ERP survey paper, but now, instead of OpenBravo, I would rather put Tryton which in my opinion is still far functionally from OpenERP but has a better quality and is closing the gap (if the functional scope + no web client is all right for you, then that might already be an option, in any case those two aspects couldn't be resolved in less than a year, and how close it will come to OpenERP pretty much depends on how Tiny ride its community power and how serious they are about the clean up. > @Gavin: ONE YEAR implementing OpenERP?????? Please call a serious consultant, > pay for his services and sure hi/her will guide you implementing it to start > running in a couple of months with standar functionality @Ana, my understanding is that Gavin is located in some anglo-saxon country (right?). Anglo-saxon accounting is still pretty experimental in OpenERP and is different from our "Napoleonian accounting rules". Serious integrators like Veritos or CampToCamp are dealing with modules such as account_anglo_saxon (and its compatibility), but even them are having troubles (read the community expert thread), the IFRS stuff is not very mature yet either... So it doesn't surprise me too much @Gavin has so many troubles. Here in Brazil, if we were to tackle the localization in one shot, we would have been in pretty similar serious troubles. Now luckily our strategies has been to work for European companies first while polishing the localization, we are finally almost ready, so that's OK for us. All right, I hope everybody can keep his liberty of speech and judgement here, I believe this is one thing open source makes easier and hopefully it makes us more credible too. I'm absolutely not negating the issues with OpenERP, I'm working on them too. And even with so many issues: to me OpenERP is still largely ahead, Tiny has an immensely huge merit to do nobody has ever done, even with millions they never had. Most of issues are slowly being fixed, coding skills are slowly being only an option... You have to think about OpenERP like about Linux, Linux is there since 1990 and recently got some serious backing. You don't defeat SAP in just 5 years with no upfront investment. Also, yes, the situation last week has been pretty hot with some expert community members because of the lack of communication with Tiny (some jump-started on, Tryton, other were talking about a common partner branch that might evolve into a fork if Tiny were still not paying attention to the proposals). I understand Tiny has been under huge pressure overall. The good news is they now set up some really skilled folks to interface with the community (at least the part of it proposing solutions). Let's see where does it bring us. I'm personally OK to give it a try. In any case it's very easy to complain, doing better while truly open source is not so easy... ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=50460#50460 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
