Indeed, this is an important reminder.
I'm guilty as much as anyone of working on new features without fixing enough broken code.
But, as you may know, it's relatively easy to get paid for working on new features while it's nearly impossible for bug fixing..
On the other hand, the Dolibarr codebase suffer from an old and intricate coding structure that don't help fixing bugs efficiently and keeping them that way.
IMHO, even before squashing bugs, it needs a big overhaul of its internal structure.
From the top of my head, here are the issues I'm constantly fighting with :
- Inconsistent coding style (cf. Florian post)
- Relatively Inefficient bug tracker. (Personal opinion)
- Classes inconsistency and missing a lot of utility methods. (See next point)
- Duplicated code all over the place that should be factored into the native objects. This makes maintenance a nightmare.
- Inconsistent API with half french naming and all.
- Not using parameterized queries and field tested database drivers such as PDO.
- Not using a internationalization/localization toolkit such as gettext
- Legacy libraries with bad design decisions (Yes, I'm looking at you PDF documents)
- I forgot a lot of other issues.
I wanted to keep that discussion for the DevCamp but since I already opened the pandora box, here's my thinking:
As you stated, Dolibarr is now a mature piece of software.
Since removing code is the best way to reduce bugs, maybe it's time to start a disruptive 4.0 development cycle with ambitious objectives and set everything else on maintenance only mode.
Here's what would be my go-to list:
- Unify coding style (PSR preferred here because it's community driven, clearly defined and sees massive adoption).
- Reduce codebase by redesigning objects and nicely factoring existing code.
- Fully embrace OOP and other modern PHP features.
- Parameterized SQL queries and unified database driver (PDO).
- English only code and comments.
- Gettext translation support.
- Get rid of legacy libraries.
- Break the API, yes, let's break it bad for the greatest good, it's a new release after all.
- HTML5 pages.
- Document, document and document (With better discussions on API design, code comments…).
- Rolling releases with automatic updates? Ok, maybe it's too much for now!
Yes, this is a lot of work but it won't be doing itself if we don't set the goal.
Oh, now, I should get back to coding new features I'm being paid for…
Cheers,