I love this idea, assuming it’s a new and independent project.
I didn’t interpret Volk’s reply as entitled. Disappointed, frustrated, confused, and a bit angry? Sure. But not entitled.
3 Likes
I am sympathetic to frustration. That doesn’t entitle any of us to be nasty. Please speak respectfully in these forums.
1 Like
This is a mammoth task on its own. Every developer dealing with legacy systems wants to start from a fresh slate, but that approach has its own traps. Legacy code is often ‘ugly’ precisely because it handles ugly edge cases. Do not tear down the old, ‘ugly’ wall until you fully understand why it was built that way. While Frappe may be aging, many of its solutions simply work in the context of enterprise grade software, to which many other low-code / no-code frameworks can’t even compare. Frappe is not just a framework, it’s a platform that evolved alongside ERPNext. It gave birth to Frappe Cloud (Press) and carries the deep context of the ERP landscape, its requirements and its pitfalls. To implement an RBAC system comparable to Frappe’s, you would need significant time just to design the mechanism. The same applies to offering customizations, such as Frappe’s Custom Field system.
Customization is the bread and butter of ERP, so don’t sleep on it early on. Every single tenant has unique specifications and needs, you cannot simply code a custom app and redeploy it for each tenant. That is a sourcecode nightmare that systems like Frappe solve through their built-in customization engines. I don’t know if there’s any term for it, but every enterprise software suffers from this phenomenon. The management layer wants to abstract everything out of the developer layer, and wants to design such a system that ‘non-technical’ employees can ‘design’ and configure themselves (SQL was once touted for business folks to ask questions from database in natural language), removing the need for developers altogether. That’s the crux of low-code, no-code promise. But such a system is a pipe dream especially in enterprise software. Now you can’t completely refute their reasoning, you can keep everything inside code for an erp project, but not for an erp product that you’re shipping to dozens or hundreds of customers, there has to be a delicate balance of compromises. The likes of Business Rule Engine, etc have to exist on that scale.
I used to work with a legacy codebase of an enterprise application. The system was designed in C#/.Net by engineers who previously worked in Delphi and Visual Basic. To be frank, it was almost a big ball of mud. Circular dependencies that were a nightmare to untangle, and there were so many of them throughout every layer that everyone gave up. There were no tests anywhere at all. I begged senior devs and my managers, to start something fresh, but they always shut me down. At that time I hated it, but now I understand why, at the end of the day the system with all its pitfalls and shortcomings provided value to our clients, it reasoned its existence by simply working. You never know how long will it take for you to finally ship the new architecture. If you have enough cash flow and human capital, you can assign a new R&D team for it but still you can’t give them a deadline. In the world of enterprise software, if you don’t ship fast enough, your ship will sink.
I wish you all the best in your endeavors. Before you start, you should read Mythical Man Month (specifically the part of second system effect) and also such related works by the likes of Grady Booch, Joel Spolsky, Steve McConnell, etc if that interests you. One thing you should do is connect with Rushabh and the foundational developers of Frappe and ERPNext. Ask them, if given the opportunity today, how would they design a new system from scratch?
4 Likes
FWIW, I have made at least 4 separate attempts to rewrite the framework but always abandoned it and transplanted the core ideas back to the existing one.
On general comments about governance, I have said before (on behalf of Frappe) that we want to onboard the best contributors and maintainers and support them however we can. But for that you have to show some skin in the game by traiging issues, fixing small bugs, connecting with core devs and then we are happy to offer merge rights based on your contributions.
13 Likes
@hsrai said:
A minimal and stable core
@0spinboson said:
it would be much better to try to improve the frappe core applications
@gagan0123 said:
Frappe needs to move away from the culture of “breaking things fast” and move toward a model where the core remains stable
If this whole conversation is to lead to any kind of action can we at least agree on a small team help the leadership keep the core stable and sacred?
1 Like
maybe. would depend on the analysis of the major pain points and to what extent they’re addressable while staying within the frappe framework before people can commit to that, plus whether people are comfortable with the governance model, i’d say? I mean I can deal with frappe’s warts so far, and vastly prefer it over odoo community edition or tryton or whatever, so i’m committed, but I cannot speak for others, leaving aside what my commitment is worth 
1 Like
First, I would like to sincerely thank everyone who took the time and effort to respond. The thoughtfulness and depth of the replies are genuinely appreciated. The perspectives shared - including the experiences mentioned by @rmehta about multiple attempts at rewriting; reinforce my belief that this area is worth careful exploration, while also underlining the size and complexity of the problem. All cautions and advice shared here are being taken very seriously.
In my view, most of us here share a deep appreciation for the Frappe / ERPNext ecosystem. Many of us were drawn to it early because of its clarity, speed, and openness, and it has enabled a large number of real-world systems.
Over time, as systems grow and are used in more demanding, long-lived environments, it is natural to observe certain limitations or trade-offs; often the result of decisions that were absolutely right at the time they were made.
Exploring whether it is possible to design a system without some of those limitations, using today’s technologies and with the benefit of hindsight, should not be seen as any form of disrespect to Frappe or ERPNext. On the contrary, such exploration is only possible because of the experience and lessons gained from these projects.
I would appreciate support for this kind of “scratch your own itch” exploration. I am confident it can benefit greatly from the insights and experience of this community, and that some of the learnings may, in turn, be useful to contributors and to the broader Frappe / ERPNext ecosystem as well.
3 Likes
What resonates most is the clear distinction being made between productivity-first frameworks and infrastructure-grade platforms. Both are necessary, but they serve fundamentally different risk profiles.
From long-lived enterprise and public-sector deployments, the hardest problems are rarely about features—they are about invariants, upgrade safety, governance, documentation, and institutional continuity when people and vendors change. In that context, prioritising explicit design, conservative evolution, and reviewable decisions makes a lot of sense.
At the same time, it’s important that such an effort remains complementary, learning from ecosystems like Frappe rather than fragmenting them. Even if this exploration only results in clearer architectural principles or governance models, it would still be a meaningful contribution for the wider community.
I’m interested in following and contributing to the design and governance discussion.
1 Like
We need to solve the “Bus Factor” (What if BDFL gets hit by a bus?) and “Asset Ownership” problems simultaneously. Here is a imaginary proposal for how we can structure the community and technical management:
1. Community Governance: The Hybrid Foundation Model
While a BDFL (Benevolent Dictator for Life) works for rapid prototyping, an enterprise framework requires a Multi-Vendor Foundation (similar to the MariaDB or CNCF models).
- Asset Ownership: A non-profit entity (or a fiscal sponsor like Open Collective) should own the trademarks, domain names, and infrastructure (forum, CI/CD, website, issue tracker). This ensures the project remains “sovereign” and cannot be unilaterally shut down by one company.
- Funding: Use a tiered membership model where anchor companies provide the baseline funding for full-time maintainers and infrastructure, while a Co-op/Individual tier ensures every member has a voice in general assembly votes.
- Roadmap & Leadership: A Technical Steering Committee (TSC) should be established. Membership is earned through merit (consistent high-quality contributions) rather than just financial sponsorship.
2. Code Governance: The “Living Record” Approach
I am a strong advocate for a monorepo for everything (Frontend, Backend, Docs, OpenAPI, Scripts, Helm charts, Docker, etc.) to ensure atomic commits and synchronized releases. Beyond the repo structure, we can adopt these standards:
- RFC (Request for Comments) Process: Before major features are built, a formal proposal is submitted to a
/rfcsfolder in the repo. This forces a discussion on breaking changes and API design before a single line of code is written. - ADRs (Architecture Decision Records): We should maintain an ADR directory to track the “why” behind major architectural shifts. This provides a permanent, searchable history of the framework’s evolution, vital for onboarding new maintainers.
- Structured Feature Lifecycle: Use a public roadmap to track the status of Feature Requests: Proposed → RFC Stage → Accepted → In-Progress → Completed.
- Strict PR Gates: All PRs must include updated documentation and pass a full “Green” suite (Lint, Unit, Integration, and Migration/Upgrade tests).
- Automated Release Management: Use Conventional Commits to automate the generation of changelogs and publishing to PyPI.
Why this matters:
Someone needs to handle the “boring stuff”: spam cleanup, security audits and hosting costs. By separating financial ownership (The Foundation) from technical direction (The TSC/RFC process), we create a stable environment where enterprises can confidently build their core business logic, knowing the project’s continuity isn’t tied to any single company or individual.
10 Likes
Thank you @revant_one very much for sharing such a thoughtful perspective. It’s clear a lot of experience and reflection has gone into this, and I genuinely appreciate you taking the time to write it.
At this stage, the goal is simply to listen, learn, and gather insights from across the community. Diverse views like yours help shape better questions, even before we attempt answers.
I hope others will also feel encouraged to share their experiences and thoughts. This kind of open exchange is exactly what makes communities like this valuable
All are requested to give their preferences about this project about various aspects by filling a very simple survey (if not done already; will take less than 3 minutes) at:
1 Like
We’ve been hacking around with the concepts I mentioned. Checkout Framework M.
14 Likes
Reason why I’m using Frappe is because ERPnext exists and a lot of open source tools.
I don’t know the background of most people, but have you tried to discuss some arguments, example: how can we integrate pydantic and what is the benefit?
Frappe has pydantic as dependency already:
Why it is not used as doctype? Because it will be overhead to write code that will understand Pydantic and also support legacy json doctypes. Why refactor then?
My reply was for “What if I start today”.
1 Like
Very nice project. I assume it is being built with an AI Agent (which should be probably the norm in 2026).
Would you be open to share your agent configuration, e.g. are you using Claude Code or OpenCode, which models … etc?
Everything is part of monorepo! check the checklists also on website for better readability, they are from monorepo itself.
we are auto generating documentation for humans and machines https://www.frameworkm.dev/checklists/phase-12-llm-documentation
we are generating this https://www.frameworkm.dev/machine/corpus.jsonl
if you open the repo in ai aided ide it should understand what is happening from adr, rfc, checklists, guidelines etc.
Some parts of checklist are incomplete you can pick them up and try out. Tests will fairly validate things.
4 Likes
Apologies - but I am confused (not a coder by training). This framework is to be in addition to Frappe or Replace Frappe? Bench commands? ErpNext etc… apps need to be rewritten?
Not related to bench, Frappe or ERPNext. It is inspired by them.
This is:
- AI assisted effort
- new Framework
- new cli
- new package (s) on pypi
- not related to bench
- not a fork
- not a contribution (may be proposal if taken it that way)
- not frappe, ERPNext or frappe apps
I guess the topic is very confusing. My assumption for this topic was “what if we start today”, I tried starting today with AI assist. You can think of it as Human and LLM learnings from other open source frameworks. If you go through docs LLM also noted anti patterns to tackle based on issues from odoo and frappe!
3 Likes
@revant_one I have checked your Framework M… seems like you are onto something there. It does look like an optimized stack and I do like the focus on trying to be services agnostic (like for database, redis, etc.)
As a non tech guy, I am mostly interested in server cost and efficiency (speed to generate a report). How does Framework M address that?
Thanks, looks very interesting to me even if I still have to struggle with the mental model a bit more.