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.
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.
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.
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.
I’m going to use an analogy, to explain my perspective of the ERPNext community.
Imagine that ERPNext is a sailing ship.
It’s a really nice ship. It’s beautiful and fun. It can be configured to do many things!
Also, anyone on Earth is welcome to climb aboard (as a passenger) for free!
Okay, what about the crew of the ERPNext ship?
ERPNext has a small crew of trusted individuals (Frappe, maintainers, a few others)
They sail in the direction they (and their paying customers/investors) want to sail.
They outfit and upgrade the ship, in whatever way they see fit.
What can passengers do?
If we want to join the ride and sail with them?
You are very welcome to do that.
If you want to assist the crew?
They appreciate your Code, Documentation, Blogging, Marketing, and Donations.
This concludes our relationship with the good ship ERPNext.
But wait…what if I want to change the direction (road map) of the product?
Find another ship
What if I want a “voice” and “say” in what happens to ERPNext? Such as Feature Creep, Dropping Features, Micro vs. Mono, or Changing How Things Work?
Find another ship
Sometimes the truth hurts.
The code is Open Source.
The project and its maintainers are not.
I really love ERPNext. And I really appreciate what the contributors have created.
But I’m not part of the crew. I’m a passenger. If I want to join the crew, I have to ---->
@brian_pond but even in a sailing ship, is got to have a bell that can tell that the ship is reducing speed for you jump from one ship to another, in the other way, on your analogy, if it doesn’t happens, the chance for you fall and drown is big!
This is exceptionally well said, and the only thing I’d add is that there’s also a middle way: community apps.
The maintainers are always going to be cautious (appropriately) about merging big new features from community pull requests. Community apps, on the other hand, allow the best of both worlds: rapid user-driven development and a stable core.
I think there was some hesitation in the past about apps as a potential source of fragmentation, but it doesn’t have to be that way. Drupal, for example, has always used plugins as a staging ground for incorporation into core.
Just to be clear, I’m not talking about large-scale apps meant to duplicate ERPNext. I mean something much simpler. If you, me, and a few other people feel that the Education domain needs refactoring, for example, public apps are a way for us to put our collective ideas into practice. That could be as little as a few tweaks or as much as a complete rewrite. In either case, that code becomes a doorway for broad community feedback and use-case testing. From there, incorporation into core (if appropriate) is a much simpler process.
The core (is not mature, to prevent break changes, there’s at least 10 break changes on every big release).
The UI (is not mature, to prevent break changes), (since 2009 I saw 4 UI’s in ERPNext, at-least a dozen of widget libraries, but v13 promises be the most stable, but only time will say)
There’s way to watch third-party apps, and make they evolve, get better and mature, what means, if you start an internal development, there’s a change that when you end that development, or the core will have changed, or ERPNext, or there will be a new feature that turns your development a waste of time).
Why:
Contribute to ERPNext take time, and during that time, we need to make money
(also convince customers to pay during months of development for get something pushed to ERPNext, is almost impossible, that’s why contributions happens by heart, and not by financing!)
(the same dichotomy here explain why so many contributions get stale and dont get merged)
Funny you mention this. I have to hack something together for this in the next couple of weeks (simple initial version). Maybe we can chat privately and share some ideas. I don’t know enough yet about how to package a module that we can share with ERPNext users, but I would be happy to learn and do it.
This is a good idea in general, but regular business stakeholder “users” will likely be taken advantage of. There will be a big difference in final pricing if I were to put a (fixed price) project on Upwork Vs. if the companies owner were to do the same. I guess if pricing isn’t a concern though (i.e. you need your custom feature/function bad enough) then it wouldn’t matter.
Still, if I were to pay for some custom module work for our instance of ERPNext, I’d definitely try to make it generic enough to share with the project team, or at very least share on github.
There is no way to determine the whimsical choices of the developer team that reviews the PRs. So even if it is well documented, tested, and presented in the format they prefer, there is no promise it can get into the system.
If this were a system structured around an unchanging framework, then one could create apps to fill in the gaps. However, core modules do not always lend themselves well to interacting with other apps in the framework. And even then, there is the possibility the framework or the core module changes to negate your effort.