ERPNext 14... What would you like to see?

There’s the third option, that is work together with ERPNext, to dont break the community in chunks that will make everyone more fragile in the longer term! Break the community forking the product is not good for everyone else, except who take the fork initiative!

My suggestion with an ERPNext Community Association is exactly for we join forces and ideas, finding the middle path, like, it’s okay if ERPNext team, doesn’t want BPMN as part of the core product, but, what us as community can do to lead, support and raise this development?

Instead of forking, we can construct an APP for BPMN, and, create new hooks on ERPNext itself to make that integration better. If after get mature, what started as an plugin become, useful enought, to join the core, it always, will be there for ERPNext take the effort for they join.

Let’s look for Wordpress, for example, what make wordpress, is not, but the community around Wordpress that is always releasing new plugins and themes, to make Wordpress better!

As community, we always should be representatives, so, will be welcome, if we work together understanding what need to change into ERPNext, to support USA, Brazil, Italy, Gana etc, in terms of taxes, but we need to work on this, making one small change per time, but an smart change that allow everyone else tap they own local freaking rules into ERPNext.

But I think this is a subject for another thread!


The last two major releases have been amazing strides forward for Frappe. The platform is more open and more flexible than ever. Anyone watching the github repos can see the amount of maintainer energy that has gone into making this happen, so this idea that the core team has abandoned all but their own parochial interests just doesn’t jibe with reality.

To echo @max_morais_dmm, I would love to see another attempt at a community organization, formal or informal. As the Frappe architecture matures, it becomes more possible for the community to deliver major new features, first as apps and then potentially for inclusion in the core. We’ve been working on a few different things at my organization, and it would be tremendous to have a space to share that work.

That’s my hope for v14: an energetic, effective, and organized community exploring new ways for Frappe to grow!


@max_morais_dmm and @bkm

I believe I might not be getting the full picture of what @max_morais_dmm is talking about, if so please educate me more after my write up below.

As it stands I am of the opinion that serves the exact purpose that @max_morais_dmm is talking about. Let me use my own personal challenges as an example.

As most people know I am heavily committed to the retail platform. I tried very much to work with the inbuilt POS but at a point I just gave up.

I partnered with @youssef (A very strong programmer and contributor on the platform ) when he came up with the idea for PoS Awesome. This app was developed and open sourced and is even now one of the recognised apps for ERPNext. Since adoption my mind is at rest as far as retail is concerned.

No one stopped Yousef from developing PoS Awesome, and it is now been used by quite a number of pos users alongside the official PoS Module.

I have witnessed quite a number of very animated conversations amongst community members about some very interesting features, unfortunatly majority of these conversations die midway. Almost none is ever completed.

From my experience in developing PoS Aweeome, it took months of sleepless nights pushing the development and testing envelope until it was ready. I understand that not many community members will be able to devote this time to seeing a mid size project to completion. That is a reality and is not an indictment of any one or group of people. Life must go on.

So what is my point ? If the very extensive community that is already existing here is not able to see many of the wonderful ideas introduced to completion , what will be different if another body is introduced? Will it not be the same busy people that will be part of the new body?

Food for thought. I stand to be corrected if I am wrong.


Oh, you are not at all anywhere near wrong. You had the experience to work with a better developer crew than I did when I first took my crack at fixing POS during the transition from v9 to v10. I spent those same sleepless nights demanding better performance and testing every possible way to break the new versions as they were delivered to me.

My experience was set for failure from the start because I chose to fix the existing POS module. Your experience was really the only one that could have a chance to work because you decided to create a separate app in the frappe framework.

Therein lies the lesson. The developer team is not interested in fixing anything that they themselves do not see as a pressing issue for themselves or their local constituency.

The only problem I see with creating the apps, is there is no guarantee that the framework will not change to defeat your application. The frappe team has no vested interest in making sure your application works in the next version release or even in the next point release.

There were some developers that had built small add-on apps for using the chat function that helped them better organize their internal communications. Then the chat function disappears. At one point there was an integration for Magento shopping cart and a few developers were working with that as their foundation. Now that integration is gone.

The point I am trying to make is that the core system is NOT designed to allow for a permanent application group to continue to build “value” into the system. There is far too much built into the core and the core is controlled by a group that really does what they please with their project. If frappe/erpnext were refactored to strict framework controls that were not going to change, then the exercise of creating the app would not be such a gamble.

Believe me I understand this concept at it’s very core. That is why I chose to try to fix the existing module, because I would know that the work I did would be there in perpetuity. Alas, even that didn’t pan out the way I had hoped. The existing POS module was eventually refactored into something almost useless again and all of my work went out the window. As it stands now, I will be using POS Awesome to fulfill my client obligations for this version update. But I could just as easily get locked into not being able to upgrade my version again if the core changes and POS Awesome is not possible in v14.

A properly structured project would allow for apps to live on through version updates. Frappe/ERPNext is just not structured that way and I am not so sure we as a community can ever get them to stop making our work toward improvements into short lived solutions. They tend to change the core frequently and the ripple effect can be enormous to the app developers.

Please tell me where I might have missed the message here?




I sincereley hope the Frappe Team read your write up and really take the message to heart.

I will refrain from stating my own rants which are totally in line with all you wrote above.

However, my point is that none of the issues will be resolved by another community (ECA) as proposed.

And if somehow the Frappe team does find themselves reading this topic, let me sneak in my own rant,:grinning:

I CURRENTLY HAVE FEATURE FATIGUE ! Can we please focus for now on making each and every feature work well? And can we please maintain version 13 as the latest version til 2023 at least? Maybe we release Version 14 in 2024? As a nice ring to it too.

What would I like to see in Version 14? Nothing …till 2024



I think it’s a mistake to describe the community that exists here as very extensive. Compared to other similar projects, I’d argue that it is in fact quite small. If we narrow things down further to developers who have a decent understanding of the code base, we’re really talking about a few dozen people.

Like in any good open source project, decision making in Frappe/ERPNext belongs to the people who build. While these forums feature a lot of information, very little actual collaboration takes place here. Forums aren’t a great tool for long term engagements towards common goals.

1 Like

@peterg, dont get me wrong, I’m not talking about ERPNext itself, I’m talking about this community!

As developer, as a member of this community, I tried few times, to apply fixes into the product, or sponsor fixes I believe are important, not only to me, but also for the whole community.

Like some issue I’m collecting in Manufacturing have been more than a year

But after many discussions with ERPNext support team, we didnt found an answer for questions like

  • How can we, as community members can sponsor fixes for important things into the product?
  • How can we, as community members can get support to get pull requests merged, in an realistict time?
  • How can we, as community members can work together with Frappe team, to achieve they goals?

What I want to mean by this is, it’s okay, if the product have issues, we accepted this since the beginning, but, don’t have a way to get support, and get things better for the community, is my major concern!

  • To be clear, the answer I got, is “You need to be a partner, and follow partners requirements!”, but what about others?

Also, I did some contributions to ERPNext and Frappé, like Error Snapshots, Title-Links, PrintNode-Integration, BPMN-Editor, and you know what? they didnt survided a major release!


I resumed one thousand of my words!

My point about the ECA, is, how we as community, can work together, to avoid these issues? To make value into the long term, and give part of this value back to the community?

But that is “exactly” what @olamide_shodunke has done over the years with code and app contributions.

The foundation failed to garner any support and yet it was supposed to be officially part of the core team. I am not sure how you generate a different take on the same team effort. I like the concept, but I do not know how you would ever structure it to get the attention of the core developers.

Unless you generate a like minded team of paying “frappe partners” to have a larger voice in the echo chamber of the current development group.


@bkm, I personally didnt know the work of @olamide_shodunke

I knew this, but the idea, so, after that what’s left to support the community, except the community?

  • Probably, having a place where everyone else, can register they custom apps
  • Having a small group of entusiasts that can put some effort to help others in how to make they apps more realiable, more secure, more maintenable, into the long term
  • Having a small group of entusiasts that can put some effort to listen the more important issues raised by the community, and can point attention to these tasks.

It doesn’t worked with foundation, that was under Frappé umbrella, did you think it will work again? (I mean having a group of paying people)

Totally agree. seems I got to fix my reported issues by myself other than waiting other developer to do it. even though get one PR merged is always hard.

1 Like

I agree to this. The current basic mode should be “if it’s already there, don’t remove it”.

And I think this is the way a monolith should be developed. Built big-comprehensive-all-batteries-included system. Then when a user doesn’t need a feature or a module the system should provide a way to disable or turn it off.
It’s like building a full-furnished house. Throw away what you don’t like.
i.e: ERPNext way.

As oppose, the platform way of development. The platform is minimal but having all the hooks and api for add-ons to be added.
Like an empty house. Buy and build your own needs.
i.e: Odoo way.

1 Like

this would be amazing. Maybe a defacto built-in dashboard like plotly as well

That’s exactly the reason I agree with you that a better organized community could be so important.

Browsing these forums, or even just this thread, we can see a wide range of opinions about “what should be next”. There is no coherent voice, and that makes the process of dialog difficult for everyone. I understand why people get frustrated when PRs take forever to get merged (or don’t get merged at all), but I’ve also been on the other side and know that understanding somebody else’s code can take as much time or more than writing it yourself. As a community driving contributions together, it would be much easier for everyone to maintain a productive dialog.

I know that this was tried before, but in my opinion it was just too much too fast. If I recall correctly, there were team leaders for each module and a number of ambitious initiatives for big new functions. That kind of delegation works for similar projects like Drupal or Moodle, but they have development communities ten or a hundred times larger than what we have here.

I’d encourage us to think about something much more modest: a dozen folks, working together, to think through community needs a bit more broadly than we currently can as individuals.


I think we have been here multiple times. Here is the simple answer:

Build trust. Contribute small fixes. Get involved in code reviews. Help write tests

Many times the maintainers have been burnt by contributors who have no long term commitment to the project and end up cleaning their mess over and over again.

All the development is public and we are even publishing roadmaps. Don’t complain. Be helpful.


@rmehta can you define your definition of “trust”?

I know it’s not much, but did it really works?


It’s not a complain, I fell that discuss is an open place for ideas, and that divergent ideas are welcomed.

I wrote, to explain my experience with a community member, in the last years.

In my background I have helped others, without ask anything in charge, like I said to you before, in one of our discussions, “Everything has a price, even an open-source has a price, and the price I can pay, is help others in good faith!”

And I’m not complaining by the work of ERPNext team, instead I’m telling, what I fell, us as a community, we need to work more, and together, to help others, to follow your words.

Because, to me, is uncertain and unclear the path that should be followed to achieve the goals defined in your sentence.

And more important, it doesnt answer my initial question

The limits of do-ocracy: FLOSS often follows the model of power for those who do. To earn power, one must contribute code. It works, but there’s a limit: how to represent the needs of users of the software who aren’t able to contribute code? #citationneeded

:mask: Luciano Ramalho :umbrella: :snake: :alembic: :arrow_forward: (@ramalhoorg) May 11, 2021

Also, with a clear path in how to build your meaning of trust, everyone else in this community, including who is unable to code, will be able to follow.

I’m open to write an guidance, and to help others understand what is expected from they in this jorney, but, first I need to understand what’s expected!


The way to contribute is that if you find an issue, you send a fix. < 10 contributions in the last 3 years is not good enough to bring any kind of equity on the table.

@revant_one and @snv have found their niches in contributing and they have been given write access to the core repos (check their contributions).

Frappe devs are already struggling with whatever expectations there are from users and community. At this point, there are many entry points for someone who wants to help. Sometimes you may have to ping people personally to get some attention, but by and large if your contributions are good and follow the guidelines, (tests, documentation, PR explanation etc) they should be accepted.

Edit: Overall if you don’t feel like empathising with the current maintainers, by all means please start your own community and start contributions.


So you got your answer @max_morais_dmm

As far as @rmehta is concerned the way to get the community built is to provide fixes:

As you can see there is NO representation for your concept of:

This developer team does not have any non-coders and does not know how to respond to them. So, the only contributions that are considered are those that provide the code to fix an issue and all of the supporting documentation and testing to validate. That is it. That is all.

This sentiment has been expressed many times in the forum.

I am sorry max, but unless the make-up of the core team were to change, (or their ideals were to change) I do not see a way to have the non-coder community represented. This pretty much makes the ERPNext community a community of ONLY developers. I just think that distorts the the business viewpoint the project is supposed to enhance and support.

This is how open source projects become abandonware. If the target user is not involved in the design or upgrade aspects of the project, it tends to wander off on tangents that does not ultimately help the user base, but merely caters to the developer whims. This is likely how we end up with tons of new features and really no in-depth work to fully develop any features beyond their initial introductions.

Once a developer has checked the new feature off their bucket list, they look for the next feature challenge to build out their portfolio of developer accomplishments. Nobody goes back to actually build any real-world use cases into the skeleton of a feature left behind after it is first introduced.

I contend this is the EXACT same thing that @rmehta describes here:

The difference is that it is the very developers that claim to be burned that are in fact burning their users in much the same way. They develop only the beginnings of a feature and get it into the core, then never revisit it. IT is left there to give false hope to a user community that it will ever become a full feature.

How is that any different form the complaint that developers are unable to support fixes that the PR submitter have no “log term commitment to” ??

In my estimation it is exactly the same thing. It just depends on which side of the ever widening abyss you happen to be standing on.

This is why @max_morais_dmm I question the viability of enhancing the user community. It will always be met with the retort of “Provide PR fixes that are ready to merge in order to contribute.”

That has always been the answer, and that has always set the parameters for the growing abyss.

Non-coders need not apply.


1 Like