ERPNext is custom app over frappe framework.
I guess service providers should encourage PR over Custom apps. Cripple apps in this sense.
Custom apps are already crippled in a way. There is limit to customisation compared to forking frappe/erpnext and customising code.
I think the modularity provided by apps is great and it will be bad to loose it for ERPNext appeal.
An app-store managed by the foundation would be ideal : the foundation will assure that apps are quality proof, not redundant with another existing app and maintained.
Foundation will also define the roadmap for applications in store to let them being as generic as possible.
Today, we miss a reference store, each developper has apps in his own github, would be glad to share and having contributors to expand them depending on their needs etc.
For instance, Iâve made a booking app for yoga classes with a web form and management of subscribers : maybe this app already exists or his sister, I would just have to expand instead of creating a new one, but without reference store I started from zero. That way we donât need to worry about breaking existing app or fighting about implementation/functionality, but it wonât help community and must be avoided.
Sure, if your need is really specific and canât be merge in the reference app, foundation will decide if it worth added another app for a special business application or tell you to simply fork it for individual use (and not serve community).
About the Core, I think today developers donât take risks to modify heavily the Core project because integrity and performance are criticals. Tomorrow, it can be possible with foundation agreement.
When the roadmaps and functionnalities will be defined for both Core and Apps, the foundation could make groups/teams of volunteers for development, and then Frappe (or someone who will be responsible of ERP integrity) will review the code.
Sorry, not getting your point âŚwhat should change from actual behavior?
Maybe this is a sign that most in the community prefer apps vs monolith.
I would argue the opposite. Making apps frees the core to move faster and iterate without being dragged down. Does this mean some apps will break, some will be redundant, some will be lower qualityâŚyes. But the upside is lower barriers of entry.
These are the kinds of examples, where if they are publicized more, will encourage people to contribute to core. Yes, Rushabh has said this many times, but helping people see benefits like this will encourage them to contribute.
Overall, the best way to encourage contributions is to advertise them
If someone makes a good contribution (like mnt_oauth), acknowledge it on the official twitter account. Encourage them to write a blog post and post it on Blog. Mention and link to them in the release notes (Mention IAG under Email inbox here: https://frappe.io/erpnext-version-8). I donât believe any of this was done for MN Technique.(Also, the same should be done if Frappe Technologies is the one developing the feature). This makes âresponsibleâ service providers more visible, drives them more customers, will increase their revenue, and they will be able to contribute more. Itâs a virtuous cycle.
Basically, some ideas to encourage contributions
Increase visibility of responsible service providers and good things will happen.
Crippling apps would be like cutting off your own nose to spite your face.
Many apps are company specific. For example, my own company is planning to make an app for specific engineering purposes, that would not be useful to the greater community. In fact, the information used to make the app is classified and would not be released anyways. I think these examples are common and should be considered as well.
While we are on the topic of the app store, this is one area that could be of great benefit to the community. In fact, we could break ERPNext itself into component apps, so that companies that donât do manufacturing wouldnât have to have the manufacturing module, non-schools wouldnât have to have the school specific modules, etc.
I would like to speak strongly against crippling custom apps. In my example, I try to contribute to ERPNext as much as possible, but there are many items that Iâve developed specifically for my company because they wouldnât have relevance to any other user. Being able to customize ERPNext to our specific needs is one of the key features that attracted us to ERPNext and I think it would seriously impede uptake if you werenât able to do that.
For example, I developed an interface with our CAD software so that drawings would automatically get uploaded to the items. In order to do this effectively, I had to hard code in a lot of the rules that we use for naming items. If I was to try to bring it to the core software, I either wouldnât have had the functionality that I need, or it would have taken much longer. Neither option would have been acceptable, so we just would have done it without using ERPNext (which benefits no one).
I think the biggest road block is a lack of confidence in the skills of part-time developers in changing the code and getting it to a polished state that is ready for integration into the main fork, as well as a lack of documentation on how things work, which means it takes a long time to get comfortable with how ERPNext works. In addition, itâs hard to know up front if an idea you have will get implemented into the main fork.
I would suggest the following to help address these issues:
@rmehta, you mentioned that 90% of the features added are from Frappe developers. It might help to dedicate more of their time towards collaborating with outside developers on features. This could be taking features from custom apps and implementing them in the core code (porting them in), or providing suggestions / support on how to implement ideas that outside developers have.
A perspective from a long term open source enthusiast but a non developer
I previously used Odoo. Obviously they now highly encourage apps. There were some apps that were useful and were used to fill in the gaps for my companyâs usage. However there were also bigger apps I required to deliberately disable functionality (ie their very odd usage of âfollowersâ which doesnât work in many business cases).
So there are many types of app. But I ended up with over 106 apps in my Odoo install ! Upgrades took about 10-15 minutes each time ! Although a good number were in community version of Odoo, there were still about 20 paid extras that I needed. This may all be good and well but when you try and upgrade to new major stable version ! Some devs upgrade their apps straightaway, some took about 6-12 months waiting till Odoo version was production ready. Some apps were never upgraded, and I had to remove functionality or find
As a non developer - and please you really need to appeal to the system integrators like me too, who donât code, the benefit of having many useful extra apps in the core can clearly be seen. I was always about 12-15 months behind the latest release waiting for the last app developers to catch up!
Another similar example is Plone the heavyweight but pure FLOSS CMS framework with more in common in methodology to ERPNext. Coded in Python and using Zope. But again I would end up needing many apps to fill in missing functionality for certain key areas of our business. But again same problem, some apps upgraded for latest Plone major release, some too 6-12 months, and some never upgraded. Some I had to pay developers to fix as upgrades went awry but I was stuck with certain object types (similar to doctypes) that did not upgrade. These were all free open source apps too.
So I can see many benefits of loading as much functionality into the core as sensible ie Email Inbox etc for the folks who cannot code their way our of problems at a time of major level upgrades.
Just my two penny worth.
Frappe Framework and ERPNext cannot be all things to people. [quote=âcpurbaugh, post:25, topic:22808â]
Many apps are company specific. For example, my own company is planning to make an app for specific engineering purposes, that would not be useful to the greater community. In fact, the information used to make the app is classified and would not be released anyways. I think these examples are common and should be considered as well.
[/quote]
This makes a lot of sense to me and I think it would apply in many business Iâd be working with too. Especially as systems, manufacturing and agriculture start to adopt more and more automation and automated data-logging technologies, thatâs likely to be a company-specific use case and customization. [quote=âfelix, post:24, topic:22808â]
If all developers just do apps, then the core will get stuck at one point or the other.
I would argue the opposite. Making apps frees the core to move faster and iterate without being dragged down. Does this mean some apps will break, some will be redundant, some will be lower qualityâŚyes. But the upside is lower barriers of entry.
[/quote]
Seconded! [quote=ârmehta, post:1, topic:22808â]
As of today more than 90% of contributions are coming from Frappe and that is something we should fix.
[/quote]
Why? Or what do you see as broken about this scenario? Is this as business issue for Frappe or a community issue? Consider that more (low quality) contributions from the community might actually make for more work for the Frappe team. If anything, I think the monolithic structure of ERPNext and the call for more contributors are are opposed viewpoints. Again, ERPNext cannot be all things to all people.
Thanks all for sharing your thoughts. Will try an reply as many specific points as possible.
I think you will still introduce concepts like âPatientâ etc which will be generic. There may be fields that might not be generic.
So then only roadmap features will be built. But there are so many use cases that will never be fulfilled by the roadmap - and we lose the dynamic nature of the platform.
Worthy goals for devs![quote=âPau_Rosello_Van_Scho, post:16, topic:22808â]
I feel I have not contributed enough back but I have some PR in mind for Frappe:
OAuth scope control
Contribute the segmented comunication
Improve translations
Improve Search
[/quote]
Hope you find time for these!
App store is a bad idea (reasons already stated earlier).
Even if we leave apps as it is, an app store is something we will not directly support.
Not sure if this will work. Look at this app that we are using for our forum, Discourse, you have no idea how many people have contributed what. Contributions are a cultural thing like not littering in public places (extreme example). If everyone else does it, I will also do it, if no one does it, why should I care? There has to be a strong carrot + stick approach.
There are thousands of engineering companies in the world and there will be parts that will be generic which can be contributed.
Wow, I am sure many users would love to have that.
We have github and discuss.frappe.io !
That must have been a nightmare - thanks for sharing this - I hope other people understand this is where we may be heading!
Why? Is this not obvious that a community project means community both gives and takes. I think more than low quality of contributions, it is that developers / service providers are not even thinking in that direction.
I understand that Frappe is a platform and ERPNext is a product. Infact like @revant_one pointed out ERPNext is itself a custom app, so the question of crippling is a false one to start with (all of you can breathe a sigh!)
But I hope this discussion provoked some thinking in the community and more people would think of improving the world rather just improving their company / org.
Yes, end users donât care about contributors. But if I was looking to do a discourse implementation that required support or system integration, the first thing I would do would be to look at who the core contributors are, and which companies are doing the most interesting things with discourse.
Overall, I think this misses the point. The point is to spotlight responsible service providers, which will drive business to them, and which will also give them the resources to contribute more. The point is to create a virtuous cycle. The point is to show those who are not contributing that contributing has more benefits than not contributing.
Culture doesnât just happen - culture is built.
Hi Paul, Iâm in need of an affiliate Management System. Does yours integration into ERPNEXT?
I believe that most of the custom apps should be implemented in the core but it should have options at the app level. For instance âCAD Integrationâ should be implemented but enabled only for the required doctypes by options.