Hi, Iāll share my two cents.
Iām coming at this from a developerās perspective, focusing more on where things can improve rather than pointing out faults, especially since the CRM seems to be in the middle of a big codebase transition.
Overall, the product is very solid and has a lot of features that are on par with competitors. But there are a few key things that should be addressed. For context, Iām on version 8.8.0 working with both parts of the CRM, legacy and Symfony/Angular. Iāve only worked with this version.
- No clear documentation for the latest version
A lot of the documentation on the website is outdated or just wrong. Older versions should be clearly marked as outdated, or the docs should be separated by version. Many times itās not clear whether the documentation actually applies to my setup or not.
- You have to dig deep and already know a lot to customize anything
On the legacy side, itās a lot of digging to understand how things work beyond the simple examples you can find online. Most functions donāt have proper comments explaining parameters, just types, so you end up reverse engineering a lot of it.
The symfony part is not really documented either, but it follows the framework guidelines well, so itās easier to navigate if you know Symfony (kudos for that). The problem is that in many core areas, symfony still reaches into the old legacy system, probably for compatibility reasons. So if you want to extend the system in a future proof way, you need solid symfony knowledge and at the same time you have to understand legacy code.
- The two codebases
Using symfony and angular for some modules and legacy for others is something that should be phased out as soon as possible. Iāve spent a lot of hours just realizing that Iām basically dealing with two different frontends. Some functionality works in one but isnāt implemented in the other, while some legacy backend logic is fully implemented in legacy frontend but not the angular frontend.
In practice, if you need to add a global feature, you might end up implementing it twice in two completely different environments.
- No theming support in 8.8.0
Every boss or CEO wants their own branding and color scheme. I had a request to move the Relationship section above the basic data section in the open record view, and it took me almost a full day of research just to apply a simple css change (disregarding of no proper css selectors).
If not for the open source community then for possible white label clients of suite crm hosted partners.
- Focus on features over extensibility
The beauty of open source is that anyone can contribute, whether itās features, bug fixes, ideas, or plugins. But that only works if the system is reasonably easy to extend. If itās not straightforward to modify or add new functionality, developers are much less likely to contribute under an open source license because itās simply taking too much effort to learn it or do anything proper with it.
This could be one reason why most suite crm plugins are commercial and targeted at companies. On paper, the crm is open source and attractive to companies looking for a free solution with offered paid benefits, but in reality, meaningful customizations can easily end up costing more than some of the paid crm solutions mentioned in this topic.
- Community support and forums
From what I see, a lot of people are simply confused because of the dual codebase. Someone asks a question and gets an answer for either the legacy or the new stack, while the person asking mostly isnāt even aware of the differences. Many answers assume you already understand the version changes and how the entire system is structured, which just adds to the confusion.
This is observation after 8 months of development on one project on a specific version (8.8.0).