openerp-community team mailing list archive

["Damian Soriano (Gmail)" <damiansoriano@xxxxxxxxx>]

+1 to Cristian Salamea

The version 6.1 has been lunched long ago and still the documentation
relating web development is scarce and poor.

On Mon, Oct 22, 2012 at 4:36 PM, Ovnicraft <ovnicraft@xxxxxxxxx> wrote:
>
>
> On Mon, Oct 15, 2012 at 3:25 AM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:
>>
>> Hello Nhomar,
>>
>> Thanks for your feedback. My comments bellow.
>>
>> > Said this i proceed to describe our conclusions, because are a little
>> > hard and i want to be sure it is all taken in the correct way, BUILD
>> > TOGHETHER THE BEST ERP IN THE WORLD.
>>
>> You are right, this is the only thing that matters.
>>
>> All our decisions are based on what we think is the best path to achieve
>> the best product ever. We sometimes do mistakes, but I think we proved
>> our direction is good. (especially if you compare to all others open
>> source players)
>>
>> Some decisions may be good to improve the product (and, thus, for future
>> customers) but not as good for existing customers/partners. This is
>> where we may have conflicts. OpenERP SA focus on building a great
>> product but, in some situations, some community members may have reasons
>> to not evolve and protect their existing situation as the change as a
>> cost. (in terms of money, time or personal convictions...)
>>
>> Some example:
>>   - doing an evolution of OpenERP which is not backward compatible: it's
>>     good for OpenERP when it's a strong evolution, but it's bad for
>>     partners that developed modules based on the old model
>>   - stop maintaining some bad modules while refocusing to clean most
>>     used one. It's good for the product as the most used module will
>>     achieve a higher quality but not good for existing customers that
>>     where using the modules we do not maintain anymore.
>>
>> We try to limit these situations (by remaining backward compatible when
>> we can) but sometimes it's not possible. Sometimes, we have to make a
>> decision.
>>
>> To limit the disagreement of the changes due to evolution, we invested a
>> lot in the OpenERP Enterprise service that helps maintaining OpenERP for
>> existing customers (migrations, bugfixes, 4.5 years of warranty, ...) so
>> that they are less subject to errors for the change.
>>
>> As an example, we will still continue to maintain the v6.0 GTK client
>> for 3 years as it's guaranteed for our OpenERP Enterprise customers.
>>
>> > 1.- Fork GTK client is just an option if some points are covered:
>> >     a.- OpenERP is agreed in develop propagating the context in all them
>> > 200 modules.
>> >     b.- OpenERP is agreed with this Fork.
>> >     c.- We have some kind of secure way to offer commercial support
>> > between community memebrs will be in charge.
>> >     d.- OpenERP mantain a minimal backguard compatibility in future not
>> > developing gtk client, developing @THinking@ in the existency of this
>> > fork.
>>
>> b. Of course, we agree. We will not be against a community effort.  (but
>> we will not waste time on it too)
>>
>> In my opinion, that would be a very big mistake and waste of time. I
>> seriously doubt that the community has the time to support this huge
>> development and I am pretty sure that if you go into that direction, the
>> GTK project will be dead in max 18 months. It's far better to join our
>> efforts to make something better rather than splitting our efforts (have
>> a look at what happened to Adempiere, they have 4 clients and the
>> project is nearly dead as none of them was good enough)
>>
>> Community and partners should have better priorities like the
>> localisation in all countries, porting best modules to v7.0, ...
>>
>> d. We will not do that. If we decided to drop the GTK client, it's
>> because it became an obstacle to the evolution of OpenERP. We want
>> OpenERP to evolve quickly in order to be extremely competitive on the
>> market and to disrupt the ERP landscape. As I said, our priority is to
>> build the best product ever, and we don't want to put obstacles to brake
>> this.
>>
>> So, if you fork the GTK client, you should be ready to adapt everything
>> by yourself and not rely on us for this as we will only focus on
>> improving OpenERP.
>>
>>
>> > 2.- From a Commercial PoV, i think we are chetting with this decition to
>> > our customers, in the last Partner Days, Fabien explicitly said they
>> > will not stop mantain GTK client, in 6 month he change his mind, What
>> > will i say to my customers? that they will need invest X thousand dollar
>> > in re-train +1000 users? if i was SaP it should be for me a good news,
>> > but we are not, this kind of moves are the ones make us move from
>> > privative to Open solutions 12 years ago.
>>
>> I apologize as I changed my mind during the v7.0 development. I changed
>> my mind because it's better for OpenERP.
>>
>> The problem with v7.0 is that the required effort is much more than just
>> maintaining the GTK client. I was ready to maintain the GTK but OpenERP
>> evolved so much in v7.0 that the effort is not just maintaining it. In
>> order to make it clean, it requires a full evolution which is a much
>> higher effort.
>>
>> As we don't have unlimited resources, we had to choose between two
>> solutions:
>>   - develop two client which are both half clean
>>   - focus on one client but make it super clean
>> We chose the second option. (and I hope the community will follow as
>> it's better to join our efforts rather than splitting it)
>>
>> Don't forget that we continue to maintain GTK for your v6.0 customers.
>>
>> Also, the GTK/Rich technology started to become a strong constraint that
>> slow down the evolution of OpenERP:
>>   - Available open source libs are very limited in Python/GTK compared
>>     to javascript (gantt charts, many2many_tags, kanban, OAUth
>>     authentification, LinkedIn API, ...)
>>   - The GTK client is based on a quite old code base and requires a
>>     complete rewrite to make it clean.
>>   - Modularity is key for OpenERP. Having modules for the UI is not
>>     just an extra feature. Don't forget that the success of OpenERP is
>>     due to his modularity; we need the same power for the UI to ensure
>>     the success of OpenERP in the long term.
>>
>>
>> > 3.- From the technical PoV, is really hard mantain both clients, but
>> > this is basically because the leak of openess in some dev process and
>> > the leak of SQA, i mean, Today, we have process that don't pass
>> > correctly the context (Unique way to work with both clients), and it
>> > brings a lot of problems, other thing is, the leak of central processing
>> > related to workflows, a lot of thing are hard written and avoid a real
>> > centralized part with the business objects, but BTW other history
>> > problem.
>>
>> The complexity is in the changes, not in the openness.
>>
>> The main issue is that OpenERP still need to evolve quickly to reach a
>> much higher quality. I understand that these changes are complex for the
>> contributors. But these changes are also critical for the success of
>> OpenERP in the long term.
>>
>> If OpenERP is today the best ERP ever, that's because we evolved very
>> quickly. We need to maintain this rythm to transform the ERP landscape.
>>
>> > 4.- I think one of our BEST approach is the fact of have 2 Official
>> > CLIENTS, that allow customers have the good part of both worlds (desktop
>> > and Web), today all our cleints use both clients, because they are good
>> > for @different things@.
>>
>> Yes, this is today. But tomorrow, everyone will use and prefer the web
>> client as it is much better.
>>
>> Seriously, I do not see any advantage on the GTK client that can not be
>> done easily in the web one. May be today it's not perfect but it's just
>> a matter of weeks/months.
>>
>>
>> > 5.- About Backguard Compatibility, at least today, we have 2 years to
>> > migrate customers to 7.0, it must not be done tomorrow, we have 2 years
>> > to convince them that Web is better, BUT, @fabien read very well, This
>> > desition is TAKING OFF 50% of usability of OpenERP, 50% of useability,
>> > already supported by an OpW, im not talking about community, Our
>> > cutomers bought an OPW for Security, Migration and Stability, not to
>> > lose 50% of funcionability, and then we must send our Salesman and
>> > ourself to convince them that Web is Good. IMHO They Buy Support and
>> > Warranty for 2 clients NOT ONE, How do i discuss this argument my
>> > friend? (already said by 2 of my customers).
>>
>> I bet your customers will ask to use the web client as it's simply much
>> better in every aspects.
>>
>> > 6.- About the agument "We prefer mantain 1 very well than 2 bad", Ok, Im
>> > agreed, and i respect this Point of view, but the real situation is that
>> > you dont have 1 very well, because, the real fact is that we dont have a
>> > lot of funcinalities that we had in v6.1
>>
>> I don't think so. Some feature may be missing but they are easily
>> developed as a module. (like tabs)
>>
>> > I think we need some features ABSOLUTLY NECESARIES in V7.0 if desition
>> > is taken to be able to deploy correctly transition.
>> > 1.- Menus ala admin menu (Already in v6.1) we use A LOT this feature:
>> > http://drupal.org/files/images/Administration-menu.png
>> > 2.- Copy and paste to use tree information on a spreadsheet, it can be
>> > solve easyly if we include this feature (not with excel with direct
>> > csv).
>> > You can implement freely as you think is te correct way, but it can
>> > replace the copy-paste just neede to quickly pass to excel y/0 OO.
>> >
>> > http://planet.domsense.com/en/2012/06/openerp-how-to-export-current-tree-view-to-xls-use-web_export_view/
>> > 3.- Print Screen in PDF, Priority 1.
>> > 4.- Print Workflow in PDF, Priority 1.
>> > 5.- I have a question: how do replace the easy way you pass with @Tab@
>> > key without loss layout in web?, this is important too!
>> > 6.- ShortCuts, Priority 1.
>> > 7.- MultiTabs. PLEASE dont ask me develop by myself, i have already this
>> > in GTK and is your desition take off.
>> > 8.- Test the posibility of use ALL the web client without mouse. When it
>> > should be possible, you will think IT IS READY!, after impossible, think
>> > in people loading thousand of records per day, not just in new ones that
>> > will learn quickly.
>> > 9.- If you decide just not mantain, create yourselve the fork and put a
>> > copy with openerp-gtk-drivers permisions to make it official, give us
>> > the power, but i think it is a bad move.
>>
>> 1. This is very easy in web. (but requires a bigger develoment in GTK)
>> 2. probably a 100 lines patch/module for the web client
>> 3. The printscreen is better in web as it works for everything now,
>>    including form views. It uses an @media css through the native
>>    printing of the browser. You can also implement the old printscreen
>>    which is probably a 100 lines patch/module for the web client
>> 4. Already implemented in the debug mode
>> 5. don't understand your question; tabs are the same in web and GTK ?
>> 6. Already implemented
>> 7. We made breadcrum which is an alternative. If you need tabs, a
>>    module is just 100 lines of code.
>> 8. Shortcuts are quite easy to implement in web
>>
>> So, I don't see any reason why we need a GTK. Porting those features to
>> the web is probably a 10 days effort while making the GTK evolve is
>> probably a 30 man*months effort.
>
>
>
> Hello @Fabien, in Gnuthink we are totally agree to just support Web, but as
> i wrote in a mail before, please we need a better technical documentation,
> if Partners & community get this everything will be easiest. Its more fast
> include a new developer to read doc instead read the code (thinking in
> time), so partners and community needs start to migrate modules.
>
> For all partners an community, we can does better Web development, from
> company side is more fast get web developers instead gtk developers and grow
> faster.
>
> Best regards,
>>
>>
>> --
>> Fabien Pinckaers
>> CEO OpenERP
>> Chaussée de Namur 40
>> B-1367 Grand-Rosière
>> Belgium
>> Phone: +32.81.81.37.00
>> Fax: +32.81.73.35.01
>> Web: http://openerp.com
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Cristian Salamea
> @ovnicraft
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>