Changes

A merger can be replaced because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but a little mobilization compared to size of the project (2 half day per week).

A merger can be replaced because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but a little mobilization compared to size of the project (2 half day per week).

On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is an activity which requires a large investment of work). This is where the “bus factor” is located on a community project: on the FDK (I’ll let you see the definition of Bus Factor on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some.  

On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is an activity which requires a large investment of work, several full time equivalent). This is where the “bus factor” is located on a community project: on the FDK (I’ll let you see the definition of Bus Factor on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some.  

For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze and comment on each PR due to the community mode of the project (which is not done in an unconstrained scheduled proprietary projet).

For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze and comment on each PR due to the community mode of the project (which is not done in an unconstrained scheduled proprietary projet).

In short, if you have ideas for increasing the number of “FDKs”, or encouraging actors to convert from business developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that business developer sells their production to customers so we have a large amount of such contributions, but not the FDKs). If we find a “trick” to motivate actors to take on this role in support of the handful of existing FDKs, Dolibarr project will be taken on another dimension…

In short, if you have ideas for increasing the number of “FDKs”, or encouraging actors to convert from business developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that business developer sells their production to customers so we have a large amount of such contributions, but not the FDKs). If we find a “trick” to motivate actors to take on this role in support of the handful of existing FDKs, Dolibarr project will be taken on another dimension…