Dolibarr: Dolibarr is using 2005 PHP code, in 2018

[ChangePlaces]

I'm completely new to Dolibarr, I've just spent some time looking at the core code of 8. There are a number of _major_ issues which render Dolibarr unusable and unmaintable in 2018. This is not a "modern" ERP / CRM.

• SQL code and template code and logic are thrown together. This is a fundametal no-no since... about 2005
• Use a template system, They're a big thing for a reason. They need to be used. This will allow people to develop skins 100x more easily, which will put more themes in the marketplace etc
• As horrid as it may seem to French people, English is the global language. Directories, comments and variable names need to use it as you're not coding for yourself. Even dolistore should have English as the first language.
• There are many problems that have already been solved by external libraries, this is what composer is for
• Not having any symfony components is a bit of an issue - all worthy PHP projects are using Symfony components because they work. Not to be cool. They have a large community base actively working on solving specific problems and trying to solve them yourself just isn't cool anymore.
• Modules need a separate directory to be put in. I don't think anyone wants to copy third-party code into the project root due to malicious code overwriting core system files.
• A router is needed so all code is handled from one file, to stop code duplication and to enable controllers to handle grouped functionality in one place (making the codebase instantly understandable)

Yes, this will need major refactoring, I'm sure it'll also mean people will have to learn new skills, but to be honest, Dolibarr is not a modern codebase. I'd love to help contribute to Dolibarr, but I simply can't advocate putting code in the htdocs, something I haven't done since about 2005

I understand I'm going to be shot down for this, probably even have this closed / deleted but I have written this and have taken time to contribute to the Dolibarr project. I would like to contribute though, just not to the current spaghetti code

[torvista]

No doubt the developers are fully aware of modern methods and don't need someone to explain what is needed.
Dolibarr is what it is. A legacy project with a long history and the inevitable historical baggage that comes with it's roots as a french project. Major architecture changes mean major disruption for users on upgrades and so must be managed very slowly.
As far as I have seen, most users are really just users and do not modify much, judging by the few contributors here. So, architecture changes that don't improve functionality would seem pointlessly disruptive.
Dolibarr is not perfect by a very long way, but as far as I have found, it has greater functionality than similar projects, and if it doesn't, I can modify it relatively easily with my limited php knowledge.
In the end, the functionality is what matters to 100% of the people. If it works but is messy underneath the hood, that matters only to the very small percentage who need to go there, me included.

The facts are that in 2018 Dolibarr is being used and is being maintained, so that detracts from your otherwise valid comment.

I would have preferred to invest my time and contributions in something more modern too, but my skills are limited and I have found nothing better that worked out-of-the-box.

[mwelters]

@torvista Totally agree !
I also searched other projects for usability and decided for dolibarr BECAUSE it is functional and the code is easy to understand.

@ChangePlaces This is Opensource !
Fork it and show us a way to the enlightment of object-oriented modern component based Programming !

[dolibarr95]

Hi all!

8171 #6198 #2868

Welcome @ChangePlaces (sincerely)! If you have ideas/suggestion just make a PR.
Dolibarr have been created by french users, so of course there is some french. But as you see we try to speek english (google translate helps lol). There are dolibarr forum in other langages.

[ChangePlaces]

@dolibarr95 hi, most of the videos I've been watching on youtube have been in french and I've relied on the broken auto-translated subtitles youtube provides! It's do-able, but is still a barrier to learning and importantly understanding dolibarr. I see the drive to get a course created for dolibarr which is a great idea, but will this be a good idea as it'll get more critical eyes on the codebase which could point out the same things and drive people away from dolibarr?

@mwelters But here's the problem - why would anyone want to fork the code, when it's going to need completely re-writing and re-structuring from the start? It would need too much work for it to be a fork!

I would love to make a PR, but everything would need changing - I don't have enough dolibarr system knowledge to even begin and as I'm a consumer on the search for an ERP which will need lots of additional code changes I would not feel confident using dolibarr as a long-term strategy.

It works for some people who want to make a change here, a change there, but that's only a small part of an audience. Business processes are unique to every company and it'd be nice if dolibarr could accommodate this.

[torvista]

I understand that investing time building your custom code on top of a codebase that you are not happy with, seems a bad idea.
But one has to look in detail at the project as is (i.e. the develop version, not the released version) and evaluate how much it is really lacking from what you actually need, and balance that against spending much more time on a better-designed ERP that needs a lot more work to get to the same point.
After much research several times over the last five years, I came to the conclusion that Tryton was the best, but I don't have the time or inclination to learn and modify it, when I already am competent with php/mysql from working with my online shop.
One has to factor in the time and effort required to get to the end-point of production-ready code.

Dolibarr does not need a course to learn how to use it. If it did, the GUI needs to be fixed to solve that.
Every time I have found something poorly explained, I have updated the language file...to aid my employees, and updated the wiki where appropriate.

[PMickael]

I'm totally agree with @ChangePlaces , I also open a issue a few weeks ago about commits, the first things to begin with, it to make a real commit usage, it's a not CTRL+S shortcut, you need to think of what you do, and more-ever fix things over the time, I update some part of the code for my own needs, and new updates introduce new code problem/syntax, like as simple as choice between space and tabs which is actually a random pick depends of the weather of the day 😄

And I think there is a big gap between users versions, I tried to stay as much as possible to the latest version, but it's really complicated because I don't have the time to look at all this random commits to see if I will not break like VAT module which was not working properly in ~6.0 => ~7.?.? and fixed now (I think, I don't test all the case)

All the problems point to commit usage, it's not possible to make a code review if things are not correctly commit.

[Thunderstr1k3]

Cheerio folks,
I just stumbled across this thread. I totally agree with @ChangePlaces. Dolibarr has a great usability on its surface, but as a matter of fact, it lacks features - just like any other ERP System. As a software developer I tend to write necessary lines, but french code is a show stopper. Though I had french in school for almost a decade it is impossible to read the code fluently as one has to switch between languages every few seconds. Seriously, being french is nice and all but no excuse for a messed-up code.

Since I really like how dolibarr is designed, I would volunteer for assistance. @ChangePlaces Shall we? Anyone else?

[nielsdrost7]

I'm currently helping to get an invoicing application into a new version (PHP of course), but I could help with this application as well, maybe even intregrate invoicing into Dolibarr.
When everyone agrees on development environment, coding standards (phpcs), I'll help where I can, just ping me (set up a slack channel, would help)

[cfoellmann]

I am also evaluating ERPs at the moment and on the surface dolibarr looks very promising to me but I definitely need to add some extensions. A bad codebase will cost me more time and my firm more money.
But if the project leads are on board with evolution of the codebase like: consistent coding standards and replacement of French with English "code"; I might be able to sell the project to my bosses

@nielsdrost7
👍 coding standards (phpcs)
👍 slack (or sth similar)

[nielsdrost7]

So I've created an organisation : dolimodern. i've committed 4 repo's:

• docker-dolibarr (and docker-doli which is a fork of someone's docker-setup for dolibarr)
• original dolibarr
• modern dolibarr built with laravel and split into modules. View files are set up, controllers need to point to the view files.
  If you guys want to build things in Symfony, you're more than welcome to grab the view files (blade templates). They're basically just html, since this is the very beginning of transferring Dolibarr to a more modern setup

[UnderDogg]

@ChangePlaces @cfoellmann on my local PC i've converted the database into something workable. I've generated models, views, controllers, migrations, seeders (using factories)
I'm willing to convert it onto a laravel project if you guys really want to.

I can't do things and then find out that you guys want to make the new version with Symfony.
I 'very added you both to the organisation, so you can edit all those repositories and make commits to them
@Thunderstr1k3 I added you as well (invited)

[BebZ]

Hello, just a "noob" question :
What makes you think Dolibarr code or fuctionnalities are better than other ones like TinyErp, Axelor, or else... Did you already try to read other code like Axelor's one ?
It seems on other platforms they've put as much as possible functionnalities, but they can make only minor upgrades because they are stuck with coding standards/platforms.
Dolibarr seems more free from platforms/ strict coding standards. Isn't it ?

[UnderDogg]

Tinyerp and Axelor are made in different programming languages, so it's more difficult to make changes.
There is almost no way to compare these 3 products.
Coding standards: when Dolibarr was invented coding standards didn't exist or barely existed. That's why the new effort needs to start with the information we have (coding standards is one of them)

[PMickael]

@UnderDogg a new codebase from scratch doesn't sound like a great idea, because I don't think that we get enough mind ressources on this.
Maybe a cleanup of what exists will be a start we do not actually need to use a framework to do that, we just need to get access to the codebase but it's seem's to be complicated...

If you want to start a new CRM ok, but it will not be dolibarr anymore

[jtraulle]

On the same page with @PMickael ... A hard fork and complete rewrite from scratch seems absolutely unreasonable and will fail like the few forks before that.

[cfoellmann]

I also don’t see a future for a rewrite.
It costs to much manpower. Starting something new is great but something so complex will take a long time until it would be usable for the users of an ERP system.

I am not sure what route we are going to take. Even if we pick up dolibarr.
Main plus for me was php and MySQL and with a commitment to cleanup and „translations“ it might still be a viable option.

[dolibarr95]

[hregis]

For my part, I consider Dolibarr as a framework, it's up to us to improve it.
Make a break in the engine will generate a lot of problems!
See Prestashop who has made a break in its mode of operation, it involves fees to the user!
Dolibarr is an ERP/CRM! A cut would be fatal!
We made a fork, which is no longer a fork, because completely rewritten in NodeJS + MongoDB
https://www.tomanage.fr/

[dolibarr95]

@nielsdrost7
https://www.dolibarr.fr/forum/15-retours-dexperiences-utilisateursintegrateurs/64477-dolimodern

[UnderDogg]

Guys it's ok, it was just an example. I took all of Dolibarr's HTML files and did put them in a template, so you can generate templates from the Dolibare source code that you want to improve.
I just read the opening post and when you look at the repositories you see the examples.

• grab the docker environment and run it in the usual way.
  You guys probably want to improve the current Dolibarr sourcecode and that is perfectly fine.
• unfortunately all information is echo'ed right from the source code (the 2005 way, the title of this topic). When you want to do it in a modern way, you want to make templates (views). If you look in dolimodern you will see all those views.

I wish you all the best of luck with improving the current sourcecode

[hregis]

it's possible to reinvent the wheel,
but why reinvent the wheel when we could improve it? ;-)

[cfoellmann]

I really like @UnderDogg s drive.
If we can iterate and keep everything backwards compatible it could work.
Improve „everything” under the hood and keep it running for everyone invested in the project.
We have to keep in mind that using an erp System is a long term investment and you need to give the users (enterprise) the peace of mind to be able to rely on it for years.

If we could move everything to php 7.2 (+5.6) + horizontal scalability via docker it should be a good idea.

The templating system (MVP concept) while keeping extensions working “for now” in parallel should be a good move!

I hope this discussion keeps going. And keep it civil people!!

[hregis]

the 9+ version of Dolibarr does not have any problems with php 7.3!
The VMC can be broken down into many concepts!
The rules are there to follow a road, but is it the right road? ;-)

[cfoellmann]

I looked at the code and it is a horror. Especially when you do not understand ANY French!
Rewriting something like the templating would require touching a large portion of the code base. Ergo many of the French “elements” can be replaced.
An English code base would allow more people to contribute

[jtraulle]

Maybe it is possible to progressively transition from French to English in existing codebase (without the need of hard fork). If this is done one module at a time with the appropriate SQL migrations, it should be doable ... What do you think ? On the other hand some core modules are tightly coupled and should be refactored together ... One other major problem that I can think of is about preserving compatibility with the existing external modules ecosystem provided by various developers ...

[hregis]

@cfoellmann
I develop on Dolibarr since 2005, it is a French project at the base, so inevitably there is French!
We modify little by little the code to put English from everywhere ... without integrating bugs !! ;-)

[torvista]

I wish Eldy would comment on this...as there is a lot of energy, time, effort and experience being wasted just in this thread as it is in a vacuum.
I think my first posts are still relevant.

[ChangePlaces]

It's interesting to see this thread come alive again, and I think it's provoking some interesting discussion.

@torvista an ERP needs to be easily modifiable to fit into business workflows. One size does not and can not fit all. In addition, your other point that other people don't contribute to dolibarr is probably because the code is a mess, not understandable (both because of French, and no real order / sequence to the code).

@UnderDogg I don't think a hard fork is appropriate. There are 777 issues. If you restart, you're going to be fighting those issues and creating many more. Also, symfony would be a smarter choice. Laravel is too opinionated for its own good.

@dolibarr95 : I'm sad to see the bitchiness and catty attitude from you towards those trying to help an aging project into the 21st century. It could breathe life into dolibarr and open up many new doors. e.g. having an all-English code base would allow many other people to wittle all those issues down to a smaller number. Everyone would prosper here.

Phrases like, "it is what it is" and "it works for me", and "I don't want to change it much" are not good enough and are the bain of advancing past the fear of the unknown. Imagine having a codebase with plugins... and how other developers could develop their own plugins to add new features and even opensource them for dolibarr to use.

Well-planned, thought out changes to the code base would make no difference to the end user what-so-ever and could be planned over a period of time with people helping out where they can. Database changes could be handled effortlessly with migrations, and doctrine would make this a breeze. Some of the earlier commits would be horrid as a simple change would have to encompass so many files, but over time this would improve.

It needs support from core developers who have an intense knowledge of the system and a community wanting to help. It seems like 50% of this is met so far!

[hregis]

@eldy
Eldy wants to keep maximum autonomy from external libraries, and maintain compatibility with devices for the blind peoples! Dolibarr is already a Framework! It must be changed little by little! No break in the code!

[torvista]

other people don't contribute to dolibarr is probably because the code is a mess, not understandable (both because of French, and no real order / sequence to the code).

Well that is your opinion, but my opinion is that most people who start using Dolibarr are small business people who are not aware that the code is not built on a 2019 framework.

When I started preparing it for my business and started digging into it, yes there is a mixture of french and english, but that that is only to be expected and it makes no sense just to rename things unless that is part of a code improvement: if it is not broken, don't fix it. There are plenty of things that DO need fixing and they should have priority.

As I said before Dolibarr is a large project with a long history and lot of legacy code. I have no doubt the developers would love to change it all overnight but that would destroy the user base who do not have the skills to manage a big bang/breaking upgrade.
But, a detailed roadmap from the developers to detail how they ARE going to move the project codebase forward is, I think, solely needed, to better focus a discussion such as this.

Where real developers as yourselves are showing interest, the project leaders should be jumping at the chance to include you and guide your efforts to where they think they would be best employed.
Their lack of comments is not encouraging....

[hregis]

@torvista
Think again! it's encouraging !
I had doubts a few years ago and a fork was born ...
but the evolution of the Dolibarr code is such that it makes you want to contribute!
Dolibarr moves fast and well!
it must be considered as a framework!
A base that allows you to create what you want!
an external module can use the technology we wants!

[dolibarr95]

bitchiness and catty attitude from you

@ChangePlaces the picture is a joke sorry if i hurt somebody here..and I just invit nielsdrost7 to comment in the forum in a specific topic about his work.
;)

[dolibarr95]

@ChangePlaces about videos...
As I said here : https://www.dolibarr.fr/forum/12-howto--aide/62681-wiki-dolibarr-org
My objectiv is a perfect wiki (full documentations, screenshots...). I've got my opinion about videos, mooc, and other platforms...but this is not the right place to talk about it i think.
:)

[PMickael]

Core dev team right now :

[FHenry]

@UnderDogg I give a look at you code, nicly done, install it, but I always get 404 page not found of laravel framework, maybe welcome or home route lead to nowhere ?

[dolibarr95]

:) It could be nice if can @nielsdrost7 present/talk about his work :
https://www.dolibarr.fr/forum/15-retours-dexperiences-utilisateursintegrateurs/64477-dolimodern
or create a topic in the englis forum

[UnderDogg]

@FHenry interesting, can you go to /ownercp? Or /projects? I'll take a look as soon as I can
@dolibarr95 on my way, I didn't have an account and my French isn't that great, so I need google translate
I did some replies on the forum, I hope they understand

[ChangePlaces]

I can't create any issues in doli modern, so here goes as a potential roadmap overview:

0/ It's been a while since I've looked at the code base (been busy creating my own system) but if unit tests do not exist, they need to be written. No one like writing them, but they always uncover things that are broken)

1/ A familiarity with the current issues should be noted. You may come across solutions as you touch the code base.

2/ the current codebase should be converted to english as a priority. this can be done with online translation if necessary, but I'm sure there are enough native speakers here to help. At this stage, it should not translate table and field names, but should include where necessary: comments, filenames, variable names, class names. Comments should be done first. The easy part. Next, a good IDE will replace the names across the whole project (though they are not perfect, so a commit should be done after each variable / class change just in case). Care should be taken to avoid changing things that are not related to the current change. This is where core committer support would help, but, beggars / choosers etc. This is not an easy step as care and attention has to be paid to the renaming of the variables / classes. When all tests pass, all's good.

From here things will get a little fuzzy. It's possible to merge twig templating into the system with the current code base (Symfony doesn't enforce the MVC paradigm) and get the same output. Templates would have to be created and move the necessary logic in to either twig language, or in to controllers and then pass the data to the template (depending on how complex the data is). Sub templates for things like tables and other view can be crafted and pulled in by other templates when needed. This would simplify templating by 100 times!

A single index page will use a "router" to know where to pass the request to. This will be passed to a controller which will pull in the necessary data then calling the templates. The codebase from above should be able to be wrangled from many different files that call the above templates into several single-concept controllers. It's handy to have one set of controllers for the user views, and one set for the API.

The API is not to be left behind, the controllers in symfony can easily output json data (simply return $this->json($data)) and should return the same data as currently. This will need to be 'bodged' in places, as changing the api (if necessary) to english names will be reserved for later as it'll be a breaking change.

Then, models can be created using doctrine and then integrated into the above View/Controller system. This allows annotations to create the meta data of the database. Here, table names / field names can remain the same (it's invisible to the common user). As changing field names can be a breaking change (e.g. 3rd party code which interface directly with the database for private stats etc would break). It would have to be reserved for a major version change.

---

Each of those steps can be broken up into 100 different steps, but for a general overview it's a start.

Project structure is important, e.g. in the current code, to install plugins you're overwriting code unknowing what it's replacing it with. Huge security hazard. By putting modules inside a 'module' directory, will prevent this. Although not a priority at this stage, it'd be possible to separate the modules into separate projects so they can be installed as necessary by the user.

I remember reading about the background of dolibarr and how its developer/s received support from the french government. I'd assume if you're not being told to make a change, because the boss is happy, then why bother wasting energy changing it?

[altatof]

Am i the only one to think that an ERP is made for users and not for developers ???
Dolibarr is very popular and i dont understand why some guys want to break it into pieces...
if you want to play on your own, just start a new project but please dont waste our time !
if you want to improve dolibarr and follow the lead, you are welcome.

[ChangePlaces]

please dont waste our time

who asked you to "waste your time"? Improving the codebase will mean more people able to contribute which equals more features, better code, fewer issues with the code and hopefully fewer bad attitudes towards change. Essentially the changes would be invisible to 'you' the end user, but as you're on github you're more than a 'user'.

if you want to improve dolibar...

That's the whole point...

...and follow the lead, you are welcome.

From a development point of view, there is 'no lead'. The code is an awful mess that only some people can contribute to, and oh, I'm repeating myself again

[altatof]

ok for improve; not ok to throw it all away. and yes i'm a developer and i know that what i develop is for end users not for developer pleasure. and last more, french is one of the most spoken language around the world ;-)

[cfoellmann]

I think we should return to a more productive discussion!!

@altatof About the reach of French for _users_ (people) you are right but if you were to measure the language skills among developers you will get a different picture.

i know that what i develop is for end users not for developer pleasure
Your result is for the end user but in an open project you do have to consider how your work is impacting your fellow devs/contributors

[ChangePlaces]

I'v'e just re-read down this thread from the start and noticed a few things:

• @eldy removed the "bug" from the title of this issue and sees it as "code enhancement",
• there are a series of vocal 'developers' who are aghast at losing the French contained in this code as if it's some sort challenge to national pride,
• there are issues going back to (at least) 2015 about re-organising this code base which have either been closed, or are still open, either way no action has been taken.
• no support from core team at all.

The last point is a concern. If they don't advocate clean code, then I dread to fear what undetected issues are happening. 777 issues is a lot for any project and the core team / person should be jumping on the chance of improving the codebase. But they are not.

As it stands, it's unmaintainable, impossible to merge into any business practices, impossible to read (even for french nations), and I would rather exert my energies to other, more productive situations. I've seen this before with Drupal (such a complex code-base no one could understand it except core dev team) which now is mostly symfony modules, and prestashop (core dev is offensive to people who point out issues with the code) which has serious security issues, and more.

As I wrote elsewhere, without core team support, any large changes to the codebase will be impossible and a waste of time as it'll be fighting them as they'll want to modify their code, not the improved code.

It's a shame so much energy has been in this thread.

[torvista]

no support from core team at all.

THIS is the FIRST issue that needs to be resolved, anything else is irrelevant/wasted effort until there is some conversation/signs of life from them.

[cfoellmann]

@ChangePlaces thanks for the summary.
I am totally with you on your results.

In my quest to find an open ERP system written in PHP Dolibarr was more or less my last hope and on the outside it looks promising but due to the issues @ChangePlaces listed above it is not looking like I can go with the project.
Since I come from the WordPress world I know a lot about doing the "not-standard" way or hard to convince maintainers. But WordPress is a project with huge legacy support but high quality releases. Despite what modern projects say about it it is dependable and promises long-term stability.
That is what I was hoping to find in Dolibarr, too.

[cfoellmann]

777 issues is a lot for any project

The 147 open pull request show an even more grim picture. PRs that just waste away will discourage contributions and hurt an OPEN project. Open source is a choice that need to be actively engaged!!

[cfoellmann]

Me again 😉

I know that the French are very protective of their language BUT I dont see why changing the codebase to English exclusively is sooooo bad!?
In the current state a French-only speaker does NOT understand the code because comments and code are partially English (whatever the ratio) and an English-only speaker does NOT understand the code either because of the Frensh portions.

So my question: What good does it do to reduce the group of devs able to contribute?

[altatof]

it is not to be protective of a language or another; personnaly i dont care if the invoice table is called "invoice", "facture" or anything else; the fact is that end users dont care about it and want to have an ERP that suits their needs, whatever language or framework is behind; we have a good ERP that works with lot of users, and lot of coders at this time. So if you want to make it evolve, just do it by making PRs ;-)
By the way, this kind of thread (troll ?) comes back every year or so, but i did not see many real contributions apart from discussions from those who initiate them.

[torvista]

I think the comments in french are irrelevant...I have seen they DO get changed when the file is updated, but really there are more important issues than that. You have to accept the history, don't use it as evidence the project is bad because there are non-english things in it, that is very arrogant.

I think the code/variables named in french is a minor irritation for non-french speakers...but changing them globally is major disruption...it can be done, but for what real improvement?
It does not mean the code is bad.

BUT:
777 issues...unresolved, although the great majority are probably fixed...but who knows, yes it shows a lack of interest, professionalism AND a lack of pride!

147 PRs left for dead...yes it shows a lack of interest and yes, discourages contributions.

No comments here from the development team...in fact IS there a team or only Eldy?...it shows a lack of interest.

Sad, it makes me drag my feet about developing this.
Like many others. I am hoping something else appears...but you know it won't, not overnight, to compete with the features Dolibar has: that takes years of development.

[cfoellmann]

for me the "bad" code (if it is or not) and legacy is not the major part giving me pause here.
I love refactoring, modernization and code review but I learned my lesson in the past. Nothing is worse than sending PRs and getting back nothing. It will bug you every time you look at your open PRs list on Github.

If there was official movement here I would be more than happy to get my bosses to sign of on starting to evaluate Dolibarr further.

[ChangePlaces]

I'm going to go ahead and unsubscribe from this thread. Bon voyage!

[eldy]

Dolibarr has (when i write this post) 138 open PR on 8291 closed. On the 138 PR still open, nearly 95% have an answer with a comment or a github tag, so Dolibarr project has a rate of PR without answers of around 10 PR on around 8000 answered and validates. Only 1.25 % of not answered PR !
This is probably a the best rate among any project of the same size (more than half a million of line of code if we count only the core code excluding any external libraries).
Of course, we can always do better. But with a such good answer rate, it is difficult for a project that is 100% managed by a huge internationnal community to do better (most project have a rate higher than 5% of unanswered PR).
So, any idea are welcome. New features of Github, more strict development rules, automation tools added frequently helps us to make this rate each time better, but the 0% is probably something we will never reach.

10 years go, the project was 100% french. Contributions to migrate to english are always welcome (English is official language for any new contributions, this was decided 10 years ago). We are also on the good way for that. Currenlty, 90% of code comments in v10 and 70% of fields in database are already in english. And after each version this rates are better. Currently most developers that does not speak french (more than 50% of the community) say this is not a priority for them, but we plan to reach the 100% despite that.

[BebZ]

Dear all, I would follow Eldy... And his pace!
if you would be here since 8 years, I bet you would respect his way to go without all these standards every lazy loves... At last it's not the framework who corrects... It's mainly the Guru, the Yoda... Or the one who deeply knows the code!
As an user and/or a company that didn't find everything wanted in llx_tables... but that has looked already eeeevrywhere for better... I didn't find aaaanything better than "self controlled code" ...

2cents for those who want to "change p(l) ace", ur welcom !

[PMickael]

@eldy any idea, then like everyone here ask for the same things, get team access on this repository like any other open source project to be able to make big upgrade on the codebase, not by PR.

With this access we can discuss in Github team discussions tab about what's next and let people that want to contribute be able to.

[cfoellmann]

@eldy thanks for joining this discussion. I hope you are not offended by "all this". Even if the tone might be not nice in some places it shows that people (want to) care.

I am with @PMickael in some way. Extending the maintainers list might give the project some momentum.
Maybe a modernization like @nielsdrost7 can be evaluated in the dolibarr organization (dockerization) and in branches in the dolibarr repo.

Is there a chat for dolibarr? Like Slack, gitter, or sth similar?

I have to say that @eldy's comment on replies on PRs and issues showed me that my thinking was flawed. Thanks for getting into this issue @eldy

[torvista]

What about a plan of action for the ~800 unclosed issues?
Reducing that to less-scary total would go a long way to calming the nerves of people thinking about using and developing Dolibarr.

[jonbk]

I would like to add my point of view on this.

The issue is two years old now, and I've the impression that an agreement is impossible between legacy developers on Dolibarr and guys who want to rewrite it.

First of all, I would like to start with: Dolibarr is GREAT, and I would like to thank all of you who contributes to it since it started in 2005. Especially @eldy and @hregis who are still here, almost 15 years later. You guys did a tremendous work and can be proud of this product used by many people (including mine for several customers). Really, GREAT JOB! 👏

Now here is my developer experience on the projet. Each time I develop a feature for a customer, I try to stick the most closely to the core for maintenance purpose. And each time, I found it difficult to retrieve the files where the targeted function is, what dependencies I need, how to include it (include() hell). It's difficult to handle the HTTP flow of the request: many and unconsistency data in $__SESSION, getpost() function which is awful in my opinion (you want a GET or a POST parameter, not a function who choose for you where the parameter is.). Security is a mess: constantly adding checks in each file. Add to this the many ways some pieces of codes are written for doing the same thing in different files, modules,... Creating third party module is HARD, despite the module generator, there are many files with verbose code just for create a manifest of the module. In addition, it requires to block an ID of the module on the wiki page, to be sure that two modules are not in conflict. This is clearly not a convenient and secure way to do that...

I could list many more examples, but that is not the goal.

All these observations lead me to the following conclusion. Dolibarr is a great and useful tool, but deserve much better today, and could be an even better tool if we engage a refactoring project around it. I personally think that such a tool which contain sensible data, should be more solid and with well tested functionalities, in order to be opened to many more contributors and increase sensibly the notoriety of the project. This could be a great business opportunity for many people to propose a very solid framework to public.

To achieve this vision. A major refactoring is, in my opinion, requiered. We should establish standard/guideline chart who every developer should respect. The contribution of a framework like Symfony (which is the perfect candidate for such a projet in my opinion) could be incredibly beneficial for such an initiative (HTTP flow, security, MVC structure, Service injection, Twig and Forms, Debug Profiler,...).

The danger for me is to see Dolibarr slowly die because of lack of contributions (if @eldy leave the projet, we're dead). Legacy contributors should accept that because of the success of their tool (which is NICE!) , they have to federate a biggest and various community to ensure the sustainability and success of Dolibarr in the future. And start coding on a solid codebase is a requirement of this.

Maybe we should create a direct messaging account on a tool like Slack, for starting discuss about how we could engage such a projet around the actual Dolibarr, hand in hand, together.

I hope I didn't offend anyone. I just want the best for Dolibarr, and this is my personal opinion, who appears to be the opinion of more and more developers here.

Dolibarr is great, and we should pamper it!

Thx.

[jtraulle]

Thanks @jonbk for this genuine and balanced review :+1:

I share the same thoughts.

I think even some "Legacy contributors" share your point of view (I hope so) but we need to be realistic about the feasibility of such a huge project. This is really, really hard because of the existing ecosystem (external modules that rely on the existing architecture, really tight integration between existing core modules etc.).

Some things could be however easyly (sort of) achived in my opinion like

• [ ] using namespaces and autoloading instead of includes, require, require_once
• [ ] using composer for managing and locking dependencies versions

BUT, I want to say that this is something completely feasible. Others opensource projects has already started this long and difficult journey. I think particulary about PrestaShop that is in the process of migrating to Symfony components / Doctrine entites and Twig template for the backend (this is the good thing about Symfony, it is possible to use only some components and engage in a refactoring project one step at a time). So this can be achieved step by step, one module after another.

[jonbk]

@jtraulle I would be glad to discuss about this, but in a more convenient way like Slack. Is there any possibility to open a Slack account for Dolibarr contributors ?

I do not know who tag for this request ? Who is ine charge of managing community tools ? @eldy ?

[jtraulle]

There is already a Discord server here https://discord.gg/gCM77Yy

There is also a slack that has been created on dolibarr.slack.com (see this related issue https://github.com/Dolibarr/dolibarr/issues/12028) but I do not have an account on here and the invite link is expired.

If we go for Slack, we should pass the Slack for Non Profit organizations to lift limitations of the free version (only available history for the most recent 10 000 messages). It worth noting that even when validated, workspace is limited to 250 free members).

Another option is Keybase that is free for teams of all sizes.

Not sure who is in charge of managing community tools but, yes, @eldy is the project lead/maintainer

[jonbk]

Disord is OK for me, I join 👍

[eldy]

Communication tools are currently managed by the Dolibarr association that is not affiliated to development core team (even if some people are part of two)

[geri777]

I would really love to see this project more sucessfull! It is the only relevant ERP system using PHP. For me the most important issue is the bad documentation. My suggestion would be: create Youtube tutorials (in English) starting with:

• Installation
• Basic Setup for an imaginary business like a cookie store.
  
  
  
  • Product Setup
  
  
  • Bank Accounts / Financial Setup
  
  
  • Customers and Vendors
  
  
  • Stock
  
  
  • POS to sell a product
  
  

The current videos on Youtube are a) outdated and b) in French and c) don't cover most parts a user needs to know to start with Dolibarr.

[dolibarr95]

Hello
Join us in the forum and share your point of vue and ideas :
https://www.dolibarr.fr/forum/t/tuto-video/23095

[egils-consulting]

For my part, I consider Dolibarr as a framework, it's up to us to improve it.
Make a break in the engine will generate a lot of problems!
See Prestashop who has made a break in its mode of operation, it involves fees to the user!
Dolibarr is an ERP/CRM! A cut would be fatal!
We made a fork, which is no longer a fork, because completely rewritten in NodeJS + MongoDB
https://www.tomanage.fr/

This link is now dead, which proves the point of difficulty making a hard fork.

[egils-consulting]

What about a plan of action for the ~800 unclosed issues?
Reducing that to less-scary total would go a long way to calming the nerves of people thinking about using and developing Dolibarr.

I took a stab at the issues today. We are now down to ~540, but a lot of those are stale and discussion and feature requests.
Here is some statistics on the issues:
261 bugs open (only ~76 have been opened after v12 was released and my estimation is that only ~20 of the earlier bugs are lingering bugs also present in v12)
5 bugs need more information (only 2 relates to v12)
The rest are feature requests and discussions issues not labeled correctly that have not been closed automatically yet.
This is really not that bad for a project of this size and complexity IMO.
Horray for Dolibarr!

[egils-consulting]

I have now labeled all remaining issues. No issues without labels should be left. Lets squash some bugs!

[Foorack]

@jtraulle

There is already a Discord server here https://discord.gg/gCM77Yy

Yes, but that is entirely in French. Contributing to this project is very difficult when not speaking that specific language, and it discourages a lot of developers worldwide from helping.

[cfoellmann]

@Foorack I am with you.
The slack fell through. But I would use the discord if there were some "management" to provide itnernational channels. (I am not sure how those are called in Discord)

[Foorack]

@cfoellmann

But I would use the discord if there were some "management" to provide itnernational channels. (I am not sure how those are called in Discord)

Yes, that is possible. You can have language-specific channels, commonly by appending "-en" or "-fr" after the channel name. It is also possible to create Categories of channels e.g. "English discussion" and "Discussion en français". This needs to be made by moderator with sufficient permissions or server owner.

[cfoellmann]

@Foorack
The problem is not the technical aspect. It is the engagement of non-French speakers. Just like you said it discourages devs from contributing.
These channels need to advertised on the official homepage and forums so "normal" visitors know these are available