Sharing some thoughts on customizations, that are pretty relevant to this ecosystem!
5 Likes
The challenge that a generic ERP system like ERPNext has: special software is better in special domains.
Our example:
- 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.
1 Like
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.
3 Likes
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.
I would agree on that. But it seems developers of various skill level allmost alls seems to prefer to start on a custom App level. I guess because it seems to be more easy to contain the actual feature.
Then (and that seems to be the big hurdle many don’t manage to take) most people stop in that status. So the question is what can be done in order to either educate people how to start development in a merge-friendly way, or to make the transformation Custom App > Core Code less difficult/labour intensive.
6 Likes
A newbie dev POV.
I agree on the main idea of the post, that all of the community developers using Frappe should ideally be contributing directly to the core for the project to survive. However, I think it is a bit too optimistic to expect newbies like me to produce code of comparable quality to that of the Frappe team, ready to be merged into the main branch.
I have been studying Frappe for almost five months and I still don’t understand, how 90% of the platform works. Lacking and somewhat outdated docs are not helping, lots of the links to the docs on this forum are broken, core devs rarely answer forum questions. Really the only way of learning I have is reading millions of lines of source code and days of tracing the code in the debug mode.
As a newbie dev, nothing I would love more than to have an actively maintained and up to date reference to the framework (like this one: https://doc.qt.io/)
Yes, I understand why all of that is happening and no way am I blaming you, I understand that it is a tremendous task (there is a reason tech writers are paid so well), but no matter how much I want to contribute (I still did, though 
), I can’t until I learn how.
5 Likes
Infact the goal of the post is not to solicit contributions, but to make people aware of the long term problems in customization. If you were to take another platform where it was impossible to customize, then there might have been external work arounds, same should be considered for ERPNext.
Yes I agree contributing production level code is extremely hard and at this point it does not make sense to accept sub-standard contributions. Maybe it is always going to be like this unless there are other strong organizations that build the capacity.
1 Like
@rmehta honestly (I know you won’t like this), I think that it will become much easier if erpnext is divided up a bit, not like odoo, but rather have a core of erpnext app (just accounting, crm, and other things that are for almost all businesses), and put other modules into individual apps. it doesn’t need to be as split up as possible (like odoo), just separate.
this would actually help make contribution easier (because it’s no longer monolithic/less intimidating), and will give better control over what goes in to a single instance (reducing size and largely reducing the need to hide lots of modules for users: “hey! we’re a retail store, why does it say agriculture!?”), among multiple other benefits.
5 Likes
I’d like to second this.
Some organizations use ERPNext because they can customize it.
There will be clients who will insist on changing how the core works through customizations to suit their business needs. Of course, if these are features that “Everyone” can benefit from, it would probably be good to design it in a way that it can be merged to the core.
But if these are changes that are true/applicable to the client’s use case only (eg. Additional Workflows, additional doctypes because the company has additional forms, etc.), then these will most probably stay as customizations.
I think one thing that should be addressed is how to lower the bar for contributions, or how to at least make contributing less intimidating as @chabad360 has mentioned. 
2 Likes
@rmehta First, for me, a “customization” means modify something inside ERPNext app and the only way to keep everything update is fork+merging.
If you mean that I agree with you.
If instead “customization” means a custom app that filling a gap in ERPNext, I don’t agree at all.
I give you an example of why a custom app can complete ERPNext and satisfy my needs.
My point of view comes from business needs, from someone that needs things done.
Our company has to rely on certain features because these added features are the “last hope” if ERPNext can’t do something and if my workflow cannot be adapted to ERPNext only.
As you can see, we follow the way of adapting ourselves to the ERP, and we did it.
Customize only if really there aren’t alternatives…
We are a manufacturing company that shipping by containers overseas. Probably we are not “common case” but I am also sure that we are not so small niche…
This put us in the middle between a workshop and a logistics company. We have everything when we need to do manufacturing, but a pretty basic logistics module is missing.
For me a basic logistics module means:
-
Incoterms management (FOB, DAP, DDU, DDP, etc)
-
Embark/Arrival Ports because of this kind of shipment are not door to door
-
Airport List (IATA/ICAO codes)
-
Items logistic info (dimensions, volumes, inner and outer carton info management)
-
Sea/Air Freight Shipments documents management (input and record all those documents needed/provided by Customs Agents like Bill of Lading, Letter of Credit, Shipping orders and so on)
How can use ERPNext without any custom app?
Simply I can’t…
So, I had to commission this app development to a developer in order to fill the gap in ERPNext
If my customization is a custom app, I agree with @vrms, and is easy to understand if this customization follows some basic principles can become a proposal for a standard feature of ERPNext
1 Like
Even though I kind of get your point in general … all the above looks like perfectly common and likewise feature enhancements that would be valuable to anyone. I don’t see why a Custom App is needed for the usecase you gave here.
1 Like
Because today ERPNext (I am in production with 11.1.x) doesn’t support these doctypes natively
If the module maintainer agrees @nabinhait , I would like to open an Issue in order to check if there is any chance to add these features in version 12.
I agree to contributions to be made less intimidating by sharing the load but not compromising on the result. ERPNext is used by many round the world and one mistake could result into many people getting affected and then requiring to find developers who can contribute to fix the issue urgently.
I think the contribution bar is set right, and it may be rather increased, but the sharing of the load to make it easy. Or maybe, layering the contribution by having custom apps as layer 1, then consolidate common ideas into layer 2 custom apps, then after multiple users using it, merging it into core after sufficient due diligence would take us a long way.
That also means that we need a public repository of layer1 custom apps, layer 2 custom apps, and then use current github repository develop branch to merge things into it.
I do not know how this 3 layered approach can be done using core updates, specifically for showing the idea into a custom app and then filtering of common features into layer 2, and finally after public demand moving into core.
The layer 1 and layer 2 custom apps could later be removed completely once it is merged into core.
Just my 0.02
5 Likes
if I may suggest, why not try merging it into the erpnext app?
make a separate branch that will be modified to make it merge-able, and give it a shot. if it works, then move add a pull request. if not, um… try harder 
@chabad360 my Python skills are pretty basic, but I accept the challenge. At least i try to contribute back as soon as possible.
I got a quick read at contribution guidelines, but in general, proposals where start?
From this forum and then open an issue on GH?
I need to involve a module maintainer before starting?
Maybe are stupid questions, but who is newbie in contributions maybe need stupid answers in order to follow right procedures
I would start by making an issue on github and mentioning that you’re working on it (add a link to your repo if you’d like). then make a branch in your repo dedicated to making the app more generic (if necessary) and to making sure it can merge safely into the erpnext app. once that’s done you just open a PR, and mention it in the issue.
I’m over generalizing, but this is basically the process. if you want you can even involve your dev (I believe @bkm has his developers contribute to the core on his time), this would probably accelerate this whole process a bit, and make easier for you.
2 Likes