I have previously invited @bkm to share and contribute to documentation but makes no sense to keep repeating the stuff.
But hey, I have no entitlement on your labour and neither have you any entitlement on our labour. Instead of showing some gratitude, you choose to rant. Fine.
We reap what we sow. The records are out there for everyone to see. If ERPNext fails it’s on us.
Happy to work with contributors who are ready to contribute on our (current maintainers) terms.
@bkm I got the answer, and I fell there’s viability of enhancing the user community, I personally share many of your toughts on the last answer.
I need now, sit, revise all answers here, and the guidance that @rmehta have gave-me.
I probably I’ll need ping the developers that Rushabh pointed me, to talk with they, and understand how they are working into the “Contribution Guidelines”.
The community we already have, and I don’t want to break this community, and I personally don’t have problems with the current maintainers job, I understand they focus.
The subject here, is a point for the whole community, including me, that we need to work together, to address our needes, improving the community, and the product also.
I end up here, with my home lessons to do, and my sincerelly appologies, if in the middle of my knowlege discoveral, I have been rude, or I missed with respect with anyone in this community.
No, you are not at all being rude. You are only wishing the community to become the “ideal” community of both developers and users. Unfortunately, that is not how this community seems to be structured.
If anything, they are being rude to you.
As if to only further place an exclamation point on the points I made about the differences between users and developers, @rmehta has further driven the point home and likely served to further divide the community into the “haves” (developers) and the “have-nots” (business users) with this stinging remark:
So the average business looking to adopt ERPNext as a business management tool, must have on staff developers or be able to pay for developers to do their bidding.
I do not think the community is a bad one. It is just the community that has a focus on the development aspect of the project and not necessarily the usefulness aspect of it (unless you can contribute the code to enhance or fix it).
As you can see from the reply by the head of the developer team here, they are a bit sensitive to being called out for the truth of the matter. They think that community members like myself do not appreciate the work they have done in building the project. They get that part completely wrong because they are blinded by their own agendas and their desire to make their project bigger and better all the time. They miss the point of the project having to be actually useful in order to gain market traction.
So, I am not offended by their scorn. I will continue to build on the project and try to keep it viable in the eyes of users, at least as long as I can continue to pay for developers to continue to fix or fill in the gaps. But they do get a bit testy when you point out the disconnect between a developer portfolio and an actual business management package.
In for profit enterprises that build SaaS solutions, they have to focus on user acceptance and usability in order to continue to make money. In a open source project there is no such requirement and the project can then veer off into whatever makes the developers content without regard to how it is accepted by the users.
Just spend some time reading the forum here. You will find it obvious very few community members actually use the project in their businesses unless they are developers themselves or they can pay developers to fix the problems for them. The community is not structured toward the average user or non-coding implementer.
Complaining is pointless. The community is what it is. It is better to simply understand what it is and work within it if you can.
But to your last humbling reply… You are not the problem here. Your are not being rude. The community only seems rude to you because you didn’t understand it’s foundation and its driving force. Take heart. Your ideals are welcomed in the hearts of almost all users. They just may not be met with the open arms here that you would hope.
BKM
@max_morais_dmm and @bkm I do personally appreciate your contributions to this community, I learnt a lot from you by reading a lot of threads.
As non professional programmer and with SAP background, I contributed some PRs to both Frappe and ERPNext, some finally merged into core , but more other PRs had been rejected due to lack of documentation, test case or too complicated for the framework. I did not feel frustrated PR been rejected because I understand core team’s consideration and concern.
I will continue to contribute small PRs as needed and as I can. but I do support @bkm’s idea to involve non developer for PR process.
All of this is so sad! 
My take on this is that many of the respondents on this thread earnestly want to help. However they find it difficult to do so because they’re invariably wearing a business rather than an IT hat. Unfortunately their hat is deemed less important for the longevity of the project.
I also come from a business angle, although I can help myself ( and others : [Tutorial] Using cURL for REST and RPC API calls ) with some tech related stuff, I nevertheless find it very dis-enfranchising to read how our desire to assist is being trampled upon.
Just imagine the magnitude of the force behind ERPNext if we can somehow unite both user communities. Just image the dominance this product can have world-wide. Technically it is very well constructed, but business wise it now needs the input of business users to polish it to become that pervasive solution all of us are yearning for. The one and only obvious choice for an ERP system.
Just imagine a few years from now, when we read this post again, how we’ll silently smile, knowing we did manage to overcome this division and made ERPNext the de facto best ERP system in the world.
Just imagine how easy it actually is to unite us all.
Non technical users can help with:
Many people are already doing this. Not sure why this accusation of “disenfranchisement”. This thread was specifically about code contributions.
Can you point out one blocker to these contributions?
Edit: This the exact kind of posturing that drives me away from this forum. Maybe I should just keep away. 
I beg to differ. The title of this thread is “ERPNext14…What would you like to see?” The 2 overwhelming aspects discussed are Feature Fatigue and a desire for an End User Community. None of those are about code contributions. I think this cuts to the core of the matter, not all assistance is, or should be, code related. From an end user perspective, the assistance we’d like to bring to the table has nothing to do with code, or even any of the things in your list of 5. It has to do with end users and their business requirements. Things such as ease of installation, guaranteed upgrade path, feature continuity, etc. All you have to do is read this forum’s posts about the difficulty people have installing this software, not to mention the problems they face when they want to upgrade. These aspects are of paramount importance for a business, once the feature list has been ticked.
I accept that ERPNext has both a SaaS and Books offering, yet SMEs want to use ERPNext installed on their own hardware or VMs. The question you have to ask yourself is : Do I want these users to form part of my ecosystem or not?
What is crystal clear to me, from the very first post in this chain, is that end users are not interested in more features (code contributions) but would love to give you feedback as to what needs polishing, without necessarily giving you that feedback in the form of code, documentation, videos, etc. As it is, in order to compile documentation, it turns out you need to read the code to find out why something works the way it does. A classical chicken-or-egg scenario. I cannot help with documentation because I cannot read the code. Many of us do our utmost to assist on this forum, offering the experience we gained after many hours of trying things, which is not what a business user/owner want to hear, irrespective of your feature list.
What I’d like to bring to your attention is that there are many “softer” issues at play other than code. From this thread is should be clear that users are eager to contribute, just not as code, and the lack of a mechanism to do so. You could argue that I’m either missing the point of ERPNext being a FOSS project, or that a mechanism for non-code contributions does exist, etc, but I’m not the only one on this thread echoing the same sentiment. Which means that we’re all equally as wrong, or maybe we have a point…
Can you be very specific about the kinds of contributions you would like to make and the barriers you are facing in making them?
Disclaimer: I’m a developer. My post is off topic and nothing to do with what I wish to see in v14. I’m here trying to support Rushabh and all the community!
In any software I think developers are always powerful. FOSS prevents developers from abusing their power. Frappe/ERPNext is FOSS. Users should not feel abused in any way while using Frappe/ERPNext.
My take on code contribution:
What I feel about non-code contribution.
Writing non-code is not really my skill. I generally reply in short and don’t participate in very long posts where I may have to keep adding long non-code answers.
Yes, apart from alluding to some of them already:
How can we inform the core team that we as end-users are concerned about the intention to drop the Chat functionality in v13. As it turns out there are major releases just about every year. Should a business have chosen to use ERPNext v12 for it’s Chat feature, then the lifespan of that installation is 1 year, since no further updates to v12 is expected and v13 has removed the Chat functionality. This is not something a business user/owner want to hear.
How can we rate or prioritize enhancements other than discussing them here in this forum and hoping that a coder with the necessary acumen will pick up on it and lodge a feature request, or even better attempt the coding themselves. We as end users are at the coalface of what is needed, so all we ask for is a non-developer friendly mechanism for us to lodge such feedback, discuss the issue, rate / prioritize it, and eventually have the visibility to see what is happening to it. This forum is not particularly conducive to that. How can I as a business user see what is being planned and what is being earmarked for discontinuation. Business decisions are made to mitigate risk and remove uncertainty, and the decision to embrace ERPNext is no different.
How can we urge to core team to please pay attention to the installation / upgrade procedure other than opening new posts on this forum ad nauseam. How can we inform them of the damage it’s doing to prospective users when they read these posts. I personally experienced 2 potential customers turning away from ERPNext just in this month alone! Generally I cross my fingers hoping that they will not find the forum until the installation is complete. Irrespective of how extensive the feature list is, reading about these problems does not endear a business user.
How can we stop this frantic quest for more features and go back to what we already have but make sure it works well. There are many such requests on this forum, unfortunately this is where it stops. Years go by without any attention to these efficiency considerations, yet new features are added fast and furious. How can we as business users have some input into what is developed.
I am immensely grateful @rmehta and his team for giving us this wonderful piece of software. I’ve been an ambassador for it for over 4 years now, and as a non-technical person, I have, and will continue to make contributions to it. I just hope that my end user insights could be deemed as useful.
Wow, this thread sure is a handful.
Concerning that wish list: I’d love to see a properly implemented pro forma invoice, aka an invoice the customer gets in advance, but it doesn’t go into accounting until converted into a proper invoice. It’s mostly used for sales with prepayment.
That’s all I can think of right now, everything else that comes to my mind wouldn’t really belong into this thread, going by its title.
It is VERY simple…
Business Use Case Advice
Features are started with noble goals, but they are never brought to the full force of their perceived intent. Business users make up the apparent intended target user base, but unless they are also coders, they cannot begin to continue to expand a weak feature into a robust option.
Take for instance the Manufacturing module. For years it has been just a simple and scaled down implementation of what is really needed. There is no ability to manage lengthy work order and build processes, there is still no functional scarp management function that does not require an accountant level permission to get involved to right the books, there are other numerous missing pieces to this module that other less friendly (and open source) projects have been able to do better or at least more.
There are other modules that began as feature additions that never get finished. With only the skeletons of features ever existing, businesses get frustrated with the lack of power and useful functions.
It is those voices that need to be heard in order to have the developers take notice and finish what they started with some of these “features” that never really amount to anything useful in a business setting.
It is the culture of the project that is forcing the frustration of the business community and turning them toward other business management solutions.
ERPNext should and could be the proper business management solution if only it could finish some of the feature projects it started years ago. The need for scrap management in manufacturing has been on the github radar for over 3 years. it never got any attention, but tons of other new features get plenty of attention (even if they too are never finished).
This COULD be a revolutionary project if it changed it focus away from developer tinkering and into better solving business problems. Sadly the people that are best equipped to help the project in that direction (business users) are not coders, so nothing ever happens to improve the business use cases.
This is about as “specific” as anyone can get about the kinds of contributions you actually need to improve this project.
There are the barriers! You only need to start asking the same question that started this whole thread. “What would you like to see?”
NOT “What can users code to make it do what they want?”
The barrier is the coding and the importance the project managers put on that as being a valid voice in the improvement of the overall project.
If you only talk to coders, then you only get code challenges and code portfolios that get used to promote the coders themselves in other projects rather that actually help THIS project gain business use. How many developers have cycled through he ranks of the frappe/erpnext team, doe their pet project contribution, and moved on? It is the coder only culture of the project that creates this phenomenon. They do a skeleton of a feature, get it merged, then go away to take what they learned to some other project where they will turn the skills into something fuller and more useful.
If you start to actually have developers ask what the business community needs and them code to those needs, you will have a far better and more prestigious project. You will also finally get the attention of the greater business community to become users.
If you want to greatly expand the paying user base to your own hosted services, then you must attract them with something they want. They do not want boastful features that turn out to be very incomplete. You get there by focusing on the business owners needs and not your coding desires.
Just my opinion. Some say that opinions are like rear ends. Everybody has them and the all stink. But since you ask for specifics, I presented them here.
BKM
I’m reluctant to call the things you’ve listed here “contributions”. They’re opinions about what should happen next in the software. You have numerous spaces to express these opinions, including but not limited to these forums, GitHub, direct email, and the conference.
I don’t mean this to sound antagonistic, but it sounds like what you’re really asking for is a way to compel other people to act on your opinions. The maintainers are inundated with opinions, including not least of all those held by their own client end-users.
If you want to contribute something useful, it has to move beyond one individual’s opinion. Build a working group. Write a design spec. Gather end user experience data. Operate at some kind of scale that goes beyond just having an opinion. There are so many ways forward to support this product, and in that process your voice will be clearer, more coherent, and more effective.
Exactly!!
There have been coalitions of users in the past that did this and still little or nothing happened. There is no official channel for getting even a group of users collective wishes into the code base.
There has to be some officially sanctioned way for these groups to get their voices heard. At this point there is no such channel.
BKM
what stops a group of users of hiring developers to provide code contributions?
Nor should there be.
Turning wishes into code takes resources. In an ideal world, resources would be unlimited and all wishes would be fulfilled. In this world, those with the resources get to choose how and where those resources are deployed.
I’m sure the maintainers would love to have scrap management and ten thousand other things in the codebase tomorrow, but — rightly or wrongly — that’s not their priority. If you think it should be their priority, you can say so, and the more organized and collective your voice is the more effective it will be. But, at the end of the day, none of us has the right to tell anyone else how to spend their time.
That is very correct! I don’t know that there can ever be the desired channel to get voices (or wishes) heard because of the nature of the project itself.
But at the same time, one cannot expect their project to just jump to the head of the market simply because they created it, or expanded it, or anything else. If you want it to be accepted more then it has to be better targeted.
My whole point is that this project is not targeted toward business. It is targeted toward coders. As long as that is understood upfront then the expected results are exactly what we see now.
The fact the the opening question of this thread amplified the feature fatigue aspect of the project is merely the result of the current overall project culture.
BKM
This is an entirely false dichotomy.
Look at the list of maintainers. Literally every single one of them, including the growing number from outside FrappeTech, is in the business of making clients happy by understanding their use case needs. That’s what keeps their office lights on, not publicly shared code commits.
That’s the flip side of this question of “feature fatigue”. I don’t have any insider knowledge, but judging from release notes I’d suspect that a great deal of what’s being added at each release is being added at the request of corporate customers. That’s the economics of this project, and we benefit vastly from the fact that coders choose to share their work.
The current track record for getting PR contributions into the core is what stops us. The percentage is very small and the cost of the development is very high. The gamble is great and the potential return is small unless you can somehow appeal to the core team.
BKM