← Back to team overview

openerp-community team mailing list archive

Re: proposal to discuss forking of OpenERP GTK client

 

Hello Community.

We in Vauxoo analize very deeply this answer what we will give, and we cant
to share with you our conclusions.

First of all, i must to say, since day 1 we have invested everything in
Fabien's vision called OpenERP,
we work in pro of this this PoV and we believe, when they take a desition
they deeply beleive in the community as an actor in all the proccess.
This doesn't mean we are always agreed, it means we beleive and work on it,
when they fail, we say aloud and they answered to us always.

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.

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.

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.

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.

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@.

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).

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 think, we [OpenERP Sa and
Community] mantain at least 2 more Versions 7.0 and 8.0 the compatibility
with GTK, and after this decide, HTML 5 and a lot of concepts are improved
in v7.0 (and almost all are really extraordinary) are just this "Concepts"
we must test first and not beleive WE have the absolute reason, [This is
one of the issues separate a lot of people from PRivative one], i think we
can make a plan for 3 years of support with constant innovation and the
plan to STOP GTK support, but not from today to tomorrow, IMHO it is a leak
of responsability friend, or at least i feel this with our customers.

7.- About the plan:

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.

PUT HERE ALL THINGS YOU USE IN GTK THAT ARE NOT POSSIBLE ON WEB.


Conclusion: If desition is taken, I support all what OpenERP SA propose,
but im not agreed at all, and we think we must prepare an strategy
correctly, with the support of OpenERP SA, i dont like Forks, they divide
Community and make us weak.

Regards.

2012/10/12 Fabien Pinckaers <fp@xxxxxxxxxxx>

> Hello,
>
> > I am afraid that dropping the official support for the GTK client means
> > that the RPC/webservice API will degenerate and the main development
> > will diverge.
>
> Of course, we will keep maintaining the RPC/Web-service. It's very
> important as OpenERP is often integrated with third party applications.
> It's a very good feature of OpenERP.
>
> We are also improving the protocol to support others authentification
> methods than the plain text login/password. v7.0 will support different
> authentification mechanisms: oauth, openid, ldap, login/password.
>
> We redesigned completly the login/sign up process so that you can create
> users without having to assign them a password.
>
> > Even if we got a "fork" of the GTK-client there are no commitment from
> > OpenERP SA that it will be possible to maintain such thing.
> > Its too tempting to use bells and whistles from web and bypass API and
> > create a mess.
>
> If we want to refocus our efforts on the web, it's not for the "bells
> and whistles" as some pretend it is. For v7.0, less than 5% of our
> developers worked on the new design. Most of our efforts where on making
> everything robust.
>
> The advantages of the web client:
>   - modularity
>   - allows to easily develop features that can be very complex in GTK:
>     touchscreen point of sale, new reconciliation facilities, advanced
>     widgets like many2many_tags, kanban, good integration of external
>     libs (geo-engine of camptocamp, linkedin integration, oauth, ...)
>   - it will allow to go mobile.
>
>
> > Please don't waste that unique position OpenERP has today.
>
> v7.0 will allow an even better unique position: ERP accessible to
> everyone. You will see that the demand on OpenERP will explode and that
> your implementation effort will be reduced a lot.
>
>
> --
> Fabien Pinckaers
>
> _______________________________________________
> 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
>



-- 
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
nhomar@xxxxxxxxxxxxxx
nhomar@xxxxxxxxxx
twitter @nhomar

Follow ups

References