[Discussion] Cripple Custom Apps?

[rmehta]

The question is how do we broaden the contributor base?

As of today more than 90% of contributions are coming from Frappe and that is something we should fix. If ERPNext has to be a great open source project, it should have majority of contributions coming from various contributors.

Most of the new development is happening in custom apps because it is easy and upgradable. One way of driving more contributions is maybe crippling custom apps in some way, so people who customize have a choice of either forking or contributing.

Custom apps are also harmful in the long run. Sometimes the feature gets added the the core, like it happened with @adityaduggal and Employee Loan, your work is waste. By keeping the door open for custom apps, we are showing the developers a wrong image. Its like an mirage - looks nice but it ain’t true!

I understand this may push some people away, but also potentially change the culture of this community to a more contributing one. If we want a monolith, then we should cut of ways of escaping.

This is just a thought, I would love to hear more views from the community.

Edit: This will be balanced by the foundation doing a lot more events to train developers and discuss their contributions and how to make them reach product quality. And also help them in migrating existing customizations.

Edit 2: I think there are other ways we can make contributing more possible. I am sure this is something we will not change in the short run, but yes future decisions will depend on how many users contribute to the core.

[Nathaniel_Bagnell]

Interesting thought! Perhaps instead of crippling custom apps, have it be so that it has to be put into an app-store of some kind. Generally speaking, alot of the custom apps that are developed that I have come across on public repos are specific enough to not meet the needs of many, but are exceptionally vital for those of a few. Those custom apps make all the difference in utilizing ERPNext as a true one-stop software base.

So in summary; crippling may not be the best idea, but perhaps re-structuring the way an app is taken into the ecosystem. E.g., in order to install a custom app, you’d have to push it to an app-store/register the git-repo, and then a token allows it to be installed?

[rmehta]

@Nathaniel_Bagnell

So in summary; crippling may not be the best idea, but perhaps re-structuring the way an app is taken into the ecosystem. E.g., in order to install a custom app, you’d have to push it to an app-store/register the git-repo, and then a token allows it to be installed?

App store is a fail as we see in Odoo

1. Multiple apps doing the same thing
2. Paid apps
3. Developers not updating apps (who takes the responsibility?)
4. Tendency to put things in the app rather than the core
5. Bad experience for users when they need things from different apps that conflict each other

[vivek]

i agree with @Nathaniel_Bagnell,with regard to needing a ticket for installation, this way the core can merge only those apps / code which it thinks is useful for the larger project and can do without those it doesnt need/

[JoEz]

@rmehta I’m not completely sure that crippling the apps and having a monolith system will be the right choice, IMHO developers will be pushed away.

Actually is not quite simple to contribute, code can conflict quite easly (mainly javascript), some code is quite hard to understand on the way it work …no all the feature are well accepted for contribution …etc.

Let’s have an example …in food stores it’s quite common to have multi barcode per single item; in order to implement you need to modify a number of core files in different modules, well not that easy to keep all up to date and bench update safe.

Another example is a revamped job scheduler system; actually is possible to add a scheduler using hooks, but that are limited and all run a midnight expect if you check the time inside the called method; it’s not quite straightforward and for sure could be done in a better way.

So, who will decide if that feature has to be added to erpnext? Foundation is a good guess! But who in the foundation care about this features? I think no one, or really few people.

I think the foundation has to focus on core development driven by a road map, one for Frappe and one for ERPNext, and opening a wide contribution for the feature in it; at the same time let’s have custom app easy to integrate (kind of plug in system), easy to be part of the core if mature and if community really needs that.

So basically i’m for are less monolith system and more for a core and plugin system.

Thx, for reading

[rmehta]

@JoEz

Actually is not quite simple to contribute, code can conflict quite easly (mainly javascript), some code is quite hard to understand on the way it work …no all the feature are well accepted for contribution …etc.

As you start to contribute, you will learn how is a good way to do it. Your hack, that might work in some cases, will fail over a period of time.

@JoEz

Let’s have an example …in food stores it’s quite common to have multi barcode per single item; in order to implement you need to modify a number of core files in different modules, well not that easy to keep all up to date and bench update safe.

You just proved my point. So many people need this feature no? Should it not be part of core?

[ahmed]

I agree to what @rmehta says. To protect the “core” on the long run, more people have to understand the core “and develop it”. If all developers just do apps, then the core will get stuck at one point or the other.

[chdecultot]

Dear all,

I completely agree with the fact that a solution must be found to encourage more people to contribute to the core solution, but I don’t think crippling custom applications will benefit the community.

One of the great feature of Frappe is it’s flexibility and custom apps are one of the main reasons of this flexibility.

As we all know an ERP, is only as good as it can be customized to fit each company’s needs. And I don’t know two companies having exactly the same needs.
Everyone wants to customize it in a very specific way to match its business requirements, but also often its current way of working.

Frappe Framework and custom apps can also be used to build other products, maybe too specific to be integrated in the Core Solution for multiple reasons, but important for niche businesses.

For example, I am currently developing a custom app to handle specifically the patient information and billing for french midwifes. It will be, of course, open-source and available to all, but since it is very specific to a particular line of medical professionals, I wasn’t even able to adapt the application developed by ESS LLP which is also made to address the medical field.
Therefore I don’t think this application will ever be able to be integrated in the core solution of ERPNext (but I am happy to discuss it!).

It is therefore important, in my humble opinion, to keep this feature as it is and to even continue to develop it in the future if needed.

The main question is how to help Frappe’s team build the core solution so that they don’t do 90% of the work and everybody only benefits from it.

I think some members have shared interesting thoughts regarding ways to promote service providers that would contribute to ERPNext in different ways.
An important way to encourage contributions, in my opinion and as some have already said, could be to clarify the roadmap and do workshops regarding the functionalities that are the most needed globally and at country level.

I understand that it is a very complicated job to create such a roadmap, but maybe that can be one of main job of the Foundation.
If all members can provide enough inputs to gather a list of “most-wanted” requirements, maybe the Foundation would be able to take ownership of such a roadmap for the next version and that would encourage all developers to work with the Foundation instead of alone.

If we take the example of the Indian Tax Report (even if the work is already in progress): if the Foundation puts it on the map for the next version, no one would have interest to develop it on his own. Of course some people will only wait for it to be done and will not contribute, but from what I have seen so far, this community is great and I am sure it would not be the majority.

And I am sure that we have very creative people in this community that will come up with other options

[max_morais_dmm]

@rmehta fork or not to fork?

Cripple custom apps, only will incentivate forks, and less contributions!

After our last discussion, I decided start looking with a clean vision for ERPNext.
I completely agree with you, that contributions should be increased, but just cripple custom apps, will incentivate much more forks, and the problem persists, the developers change the codebase and don’t return it to ERPNext, or if it return, needs a lot of polishments.

I’m on that way, as everyone knows, I stuck in v6 because we have put some efforts in some projects into the core of frappe, that limit our upgrades.

Another point is, I just fell that the intention is not just cripple the custom apps, but cripple the contributions?

[JoEz]

@rmehta

As you start to contribute, you will learn how is a good way to do it. Your hack, that might work in some cases, will fail over a period of time.

Well, is not that simple as you could think to contribute because of the monolithic nature would easily end in conflicts.

@rmehta

You just proved my point. So many people need this feature no? Should it not be part of core?

I need the feature, people who run food store need the feature …if you’ll be crippling custom apps how would be possible easily to integrate? ERPNext will be going to loose all that market segment?

I honestly can’t understand why to cripple the custom apps …lets people work, learn, contribute in the way are best for them, keep core software under foundation control.

That’s my opinion, of course foundation will decide

[dhananjay]

I agree with @chdecultot and @max_morais_dmm. Also can we discuss how to come up with a roadmap?

[johnskywalker]

I would also disagree to cripple custom apps. I think there’s another way to encourage developers to push to the core. For me there are alot of good ideas out there, but maybe there are hindrances for devs to push to the core, and the following could be:

1. Conflicts
2. Bad coding practice
3. Don’t really have a background in contributing

My suggestion:

1. have a showoff of custom apps, we will pick apps that will be used commonly. Somehow award the contributor like feature them on the site for a period of time.
2. frappe/erpnext or the foundation will help the devs to let them push it. Help them do the necessary revisions. Teach them the proper way of doing things when it comes to contributing to the core.
3. Sponsorships

[JoEz]

@chdecultot

The main question is how to help Frappe’s team build the core solution so that they don’t do 90% of the work and everybody only benefits from it.

That’s the main point

@chdecultot

An important way to encourage contributions, in my opinion and as some have already said, could be to clarify the roadmap and do workshops regarding the functionalities that are the most needed globally and at country level.

I agree with that as well.

[Pau_Rosello_Van_Scho]

I totally agree with you on the fact that the Frappe team is currently receiving too much pressure to maintain this project (economically and mentally).

Crippling custom apps would totally kill my development… I am not using ERPNext as of right now but rather developing a fully new apps with Frappe that do not relate in any way with an ERP.

Some examples of the Frappe applications that I have developed are:

• Affiliate management app with very segmented communications and special billing (about to finish)

• Application to manage ornithological championships (starting now)

• Home garden automation management (planning)

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

I don’t know when I will be able to do this improvements but crippling apps would totally make me

Apart from PR I will also become a member of the Foundation and donated to the improvement of the POS in case some day I can find a client for ERPNext

Let’s see how we can push this forward!

[Mukesh_Variyani]

There are lot of apps developed by many community members, which may be lying in their github account. Others can use some of their code or whole app, even can contribute to make it more useful. But don’t know where to search for relevant app. So everyone working on a custom client need, have start from scratch, the re-usability of code is totally ignored.

Having everything in core is a good idea, but a developer working on quick fix, may not have that polished code which can be accepted by ERPNext, having it in on common place allows someone else to access it and improve it to make it more suitable to merge it in ERPNext, o/w it will always remain a job of core team to refine/reject the code.

Having an app store will bring all this development work on one platform. Eventually, if the app is merged in core, it may seize to exist independently, but till then, it may provide someone a quick reference/fix needed at times.

[revant_one]

• Custom apps are required for prototying UX - the bazar is up and running for innovator end-user interaction.
• Custom apps drastically change design along with user-developer understanding
• Custom apps are like beta software, Innovators use it.

Drawbacks,

• Prototype/hacks are unchecked by community and core developers
• Changes in core structure has to be closely followed to refactor custom apps.
• Although custom apps can be upgraded after refactoring code, they do not seamlessly upgrade with core product.
• All users wish to upgrade! Customization may stop them from seamless upgrade.

Examples:

mnt_oauth was custom app. I used it to test things with multiple parties. Once everyone on project found the app to be useful, I moved it to core frappe and sent a PR. Now Oauth 2 is very much upgrade friendly! There was a change in module structure where oauth belonged. integration_broker was changed to integrations in v8. All the code refactor was done by Frappe team. No one even noticed any change! I just changed the documentation!

For a customization which used “Contact” and link fields for Customer/Supplier/Sales Partner. The code was re-written when Contact structure was changed incorporating Dynamic Link Child Table.
Result: End-user reported new customer contacts are not shown in v8.
ref old code : refreshednow_erpnext/api.py at 2bd14157ba57ab458f6770d42ba37aa21a7d0fbf · mntechnique/refreshednow_erpnext · GitHub
ref new code : refreshednow_erpnext/api.py at c712bb0e47b2f7b3761922c9f2e304f3274393ef · mntechnique/refreshednow_erpnext · GitHub

We designed a booking system MN Technique LLP
At first it seems very custom process only applicable to one business for reservation of car cleaning and detailing service.

Thinking over it again.

• The feature is generic reservation system.
• Resource is allocated e.g. worker, room, capacity, etc.
• Service slot is scheduled against available resource (with overlap and other validation)
• Sales Order is generated from service.
• Can be used by hotels rooms, cinema/taxi/travel ticket booking businesses
• @gvrvnk @vishdha stitch in time saves v9

To clarify things :

Crippled apps do not mean Frappe framework will stop allowing custom apps.
Ecosystem is completely based on custom apps. Foundation website, hackathon website, etc.

[jpp]

I think the answer is time and there is no one clear solution to it. As stable as frappe/erpnext has become over time, it is still relatively unknown and new in the market and filled with many issues. With that said over time as @max_morais_dmm said, if you cripple custom applications then you will increase the chances of forks and then more scattered frappe implementations will occur.

The solution needs to be on the frappe core team stick to what it does best and continue to contribute to the core, without this the whole project becomes stale and does not drive interest from new users. Why is there lack of contributions? The application and framework is very complicated for many developers who may not be committed to sticking with something still immature or untested. In addition documentation is lacking and this doesn’t help.

Frappe needs to focus on the following:

1. Continuing the core development and resolving continuous issues that are yet not polished or worked out (see github cases that are increasingly open and not resolved)
2. Develop documentation (from the public helps, but it needs to be really pushed by the developers themselves who know the code and product well enough to write about it)
3. Create trust and incentives for new users to continue to use the framework/erpnext. (No one wants to use a stale development project with lots of cases and issues yet to be fixed).
4. Separate a beta/stable release to make sure developers can test new features before committing a big upgrade which usually breaks things.

Over time as more users join and the core development provides a clear roadmap and documentation as well as a decrease in issues, the community will naturally start pushing changes and your 90% contributions may start to move, just like it has moved down from 100%.

[JoEz]

@revant_one

Crippled apps do not mean Frappe framework will stop allowing custom apps.

So, what’s the exact meaning of crippled apps?