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.
I’d be curious to know about what breaking changes you’ve encountered. I’ve had relatively little difficulty across versions with my org’s own customizations, which are relatively broad. Of course, everyone’s experience on this will be different.
That said, I’d love to see Frappe continue to mature in this regard as a platform, particularly on the question of how to produce more stable abstractions and interfaces. This would be a great topic for a community user group to start thinking through.
Development is always going to be expensive. There’s just no way around that. People who can’t afford those costs – whether in time or money – are always going to have less control than those who can. I don’t think that will ever go away, but Frappe has done more to minimize those costs than any other framework I’ve worked with. That’s what excites me about this platform and its democratizing power.
As raised in many issues partially dating back several years, a proper implementation of process manufacturing would be amazing! This issue has been raised repeatedly over many years and is needed by several users
e.g.
According to wikipedia, process manufacturing is used in many different sectors including food, beverage, chemical, pharmaceutical, nutraceutical, cosmeceutical, textiles, consumer packaged goods, cannabis biotechnology industries, semiconductor fabrication, steel & aluminum, aircraft & spacecraft (and I believe this list isn’t exhaustive). To me it seems to be a fairly basic feature (in terms of what an ERP system should be able to handle) that should have been included in ERPnext already a few years ago.
If you search by “Breaking Change” in this forum, you will find many!
On the past I developed the Title Links resolution for an important problem in ERPNext and frappe
After a period making it mature, one commit on the UI of the framework, completely and silently deprecated the JQuery widget that was being used to address the problem, using Awesomplete instead, what turned almost impossible at least to me maintain the app.
There’s other cases also, but or they are smaller or they dont resolve important features!
I feel that one area that ERPNext has to look into is an Engineering module A lot of companies do design and development of products. It requires a lot of feedback from various business activities and a lot of businesses need to track the development cycle of the product. Incorporating it in ERPNext will make the product cycle complete and also make it easier for companies to track the revision of the products.
Warehouse bin system is another feature which I would definitely like to have
QR code for the fields in printing and scanning them creating new documents or opening existing documents from QR code will also be nice