Sharing some thoughts on customizations, that are pretty relevant to this ecosystem!
The challenge that a generic ERP system like ERPNext has: special software is better in special domains.
- Creating offers with Billomat is better than doing it with ERPNext.
- Bookkeeping with DATEV is better than with ERPNext.
- Highrise is a better CRM than ERPNext.
- The list goes on …
Without customization that ties all this together and brings forward the strength of central customer data storage ERPNext would have died long ago.
Not sure how “customization” makes ERPNext better than Highrise or anything else. Customization is not product improvement.
Very, very true… for the most part.
However, some organizations function in certain ways and have certain processes that are very different from regular companies, and while over time (especially in ERPNext’s case) there may be updates that help close this gap, for the most part, it is virtually impossible to function without a decent amount of (mostly add-on) development and customization so that the migration/adoption is both cost-effective and actually useful.
I guess product improvements may often start as customizations.
It looks like making the hurdles to transform a customization (which often comes in the form factor of a custom app at the beginning) into a product improvement (aka feature contribution to the core code) less steep would be a project worthwhile.
I (probably due to lack of technical understanding the processes to code for erpnext/frappe core) wouldn’t really know how to approach such a project.
Anything that starts as a customization, remains a customization. This has been my strong experience. There is no incentive to use standard product terminology, coding standards and paradigms.
Any feature addition must be designed from the beginning to be merge friendly else it will be almost double the effort to do it at a later point.