Conceived: 2009
Implemented: 2009-2011
An open-source project cannot live, nor thrive under a stubborn governance of a single vendor. No matter how nice the sales figures may be, the diminishing community participation in OpenERP has always been a concern.
Plan A has been to convince the heads of OpenERP SA that open-source is their greatest asset, and would only remain so if they learnt to respect the open-source principles.
Now, we are at plan B, which is to evolve this project in a community-led governance model. So far (because I'm not a marketing guy), the name is "F3" as in "3rd feature branch".
Apart from a wide set of improvement patches that have been developed against 6.0 in the "pg84" and "pg84-next" branches (the 2nd feature branches), the goals of "F3" are, in short:
A set of design innovations and technical features of F3 is yet to be written (you know, documentation is that last task we tend to avoid :S ).
Why not Tryton? I get this question often. It has to do with the codebase, which departed from the Tiny API, back then, and would require major porting (and lack of features) from any current TinyERP/OpenERP installation. Still, their work and community model is highly appreciated.
In June 2010, in G-R, I said I would make OpenERP (6.0, then) a better product. My plain word is stronger than some who don't honor their promises (see: release date, features+support, payments).
Let the code speak for itself.
Implemented: 2009-2011
An open-source project cannot live, nor thrive under a stubborn governance of a single vendor. No matter how nice the sales figures may be, the diminishing community participation in OpenERP has always been a concern.
Plan A has been to convince the heads of OpenERP SA that open-source is their greatest asset, and would only remain so if they learnt to respect the open-source principles.
Now, we are at plan B, which is to evolve this project in a community-led governance model. So far (because I'm not a marketing guy), the name is "F3" as in "3rd feature branch".
Apart from a wide set of improvement patches that have been developed against 6.0 in the "pg84" and "pg84-next" branches (the 2nd feature branches), the goals of "F3" are, in short:
- to have an open project, where all contributions will be treated equally (technically bad ones will still remain out!) and all contributors will be awarded for their effort
Note: this means we could have more than one branch, different "series" of the project depending on debated decisions. It is nice to have plurality, rather than a SVN-style "trunk" and stick with bad decisions. - to remain compatible with previous codebase, respect the work all of us have done against previous versions. Also, respect our customers which have had wide installations and integrators that invested in them.
- to have scheduled, predictable releases. A sane release cycle with feature windows, testing periods, release + integration hold-off time. Features shall be predefined, too.
- to be stable. To be business-minded (ERP users expect a rock-solid system, not marketing fireworks).
- to be frank. Open-source is supposed to be free of marketing b**hit. No demo-quality features, only ones that can really stand in production. If we have a bug, we admit it and fix it.
- to be efficient. Both at the final product (pg84-next is already >40% faster than 6.0/6.1) and the way we develop it (right tools, debugging, tests, communication)
A set of design innovations and technical features of F3 is yet to be written (you know, documentation is that last task we tend to avoid :S ).
Why not Tryton? I get this question often. It has to do with the codebase, which departed from the Tiny API, back then, and would require major porting (and lack of features) from any current TinyERP/OpenERP installation. Still, their work and community model is highly appreciated.
In June 2010, in G-R, I said I would make OpenERP (6.0, then) a better product. My plain word is stronger than some who don't honor their promises (see: release date, features+support, payments).
Let the code speak for itself.
Haven't tried your branches, I must say. Some of your thoughts make sense to me, some seem to me a bit contradictory. Example: some good projects have an authority, for example Python. In that case having an authority is good because it is easier to be "beatiful better than ugly, only one obvious way to do it", instead too many features and branches. Also about stability: if we want to have only rock-solid code, that we need someone to throw away unstable modules, leaving the authours in tears. Also, wouldn't being close to the Tiny API clash with the openness you suggest?
ReplyDeleteMore in general, to better understand your point, which big open project would you point as an example of what you'd like to archieve?
Thanks!
lep
>More in general, to better understand your point, which big >open project would you point as an example of what you'd like >to achieve?
DeletePostgres
Not many people can recall the names of this project's leaders, yet it offers exceptional stability (among all open-source) and true evolution (see the 9.2 improvements).
hi,
ReplyDeleteI'm happy to see your initiative, something many of us missed in the past, thus I definitely support your move.
Moreover, I would like to +1 lep's comment, in the sense of deciding about the leadership structure. Even today, there is a leadership controlled totally by Tiny. I'm not sure whether this should be changed or not (actually, every project has a leadership, and most of the time it's a legal organization), but I'm sure that it should be made more transparent, and its decisions should be made more transparent too.
Viktor
Hi XRG,
ReplyDeleteIs there any free OpenERP server where we could test a system before implementing it in its totality..??
Hello, these days I've been in the process of setting up a public server, indeed. You can see an early version of the new Web-UI here:
ReplyDeletehttps://snf-244283.vm.okeanos.grnet.gr:8071/dyn/m/demo1/webui/
although this is likely to change soon (plan to simplify URL and DNS name, more options, upgrade the version etc).