Long-term, Enterprise-focused Application Framework

[hsrai]

Over the years, many of us in this community have benefited from the ideas, speed, and openness that Frappe and ERPNext have brought to open-source business applications. They have enabled countless teams and individuals to build real systems quickly.

At the same time, some of us working in long-lived, enterprise environments have been reflecting on a complementary but slightly different set of priorities:

1. Extremely strong core invariants

2. Clear ownership of foundational domain concepts

3. Long support cycles and conservative change policies

4. Explicit governance and decision-making processes

5. Predictable upgrade paths over many years

These priorities are not about speed or feature velocity, but about trust, stability, and longevity; qualities that become increasingly important as systems grow older, larger, and more widely depended upon.

With this context, I started early exploration of a clean-slate, open, enterprise-grade application framework, inspired by lessons learned from Frappe, ERPNext, and other mature platforms, but intentionally designed from day one around:

1. A minimal and stable core

2. Strong separation between core domains and extensions

3. Governance-first development

4. Conservative evolution rather than rapid iteration

This effort is not a fork, and not positioned as a replacement for any existing project. Rather, it is an attempt to explore a parallel path that may better suit organisations where stability and policy matter more than rapid change.

I am still in the thinking and design phase and are primarily looking for:

1. People interested in long-term platform design

2. Experience from enterprise or public-sector deployments

3. Contributors who value documentation, review, and governance as much as code

If this perspective resonates with you, or if you would like to help shape such an initiative at an early stage, I would welcome your thoughts and participation.

The goal is to learn together; openly, respectfully, and with a long view in mind.

[Peer]

These clearly are important aspects for users who “bet” their shop or their lives on a software.

“Lives” may seem an exaggeration for some, but I don’t mean this word just in a “life or death” sense, but in a “the part of my life I need to spend in order to get a benefit from the software”, and how much life I need to invest for that benefit.

There are conflicts of interests between different groups, and if you are paid by some governance or university or institutional body, your set of problems to solve might be different from the set of problems a young first-time one-man-shop or some startup needs to solve (the people for whom ERPNext is made), and the creators also have legitimate needs.

Also, “rent-seeking” is not an illegitimate concern as such because everybody will get old and/or sick and some rent will be needed by most everyone on earth. This includes also “secondary” or “dependent” developers who bet their life on the software, and in fact, even more so than the Frappe people, because their influence on it is less direct, but they need to master the whole thing anyway to make it work for their use case.

So it’s really an ecosystem question not in the simplistic ad- or investor-seeking sense, but in the sense of taking into account the common AND conflicting needs of interconnected everybody.

What makes it somewhat different from the general open source ecosystem where these questions have been discussed already and a lot, is this:

• ERP software is DIRECTLY linked to the economy which is the life support system of everyone on this earth living more or less IN the interconnected economy
• and as such, it’s linked to power because it’s empowering people to do their thing independently from the big players who tend to become oligarchies. These might not be bad as such, because the quality of every social system depends on the qualities of the individuals they are composed of, but being disempowered historically is a path and a temptation to abuse of power.

So, this subject immediately touches pressing civilizational and spiritual (in the sense of life-foundational behavior tendencies) questions.

[asieftejani]

@hsrai I am interested in giving time as long as

This effort is not a fork

We need to be united even if we disagree with founders and whatever decisions they make we have to respect them as leaders - hopefully they will respect us back and listen to our greviences - thats what teamwork is all about

[hsrai]

Thank you for the thoughtful replies @Peer and @asieftejani I appreciate the time and perspective shared.

To clarify, this is not a fork and not a rejection of Frappe or ERPNext. These projects have empowered a large community and deserve respect.

The intent is to explore a complementary approach for environments that prioritise long-term stability, conservative change, and clear governance.

This is an early, exploratory phase focused on learning and dialogue, not division or replacement.

If around 5 people are interested and can contribute 5–6 hours/week, I’ll share an initial blueprint for discussion.

The effort would be slow, transparent, community-driven, and openly documented, no timelines or expectations of quick outcomes.

I welcome continued discussion and input.

[revant_one]

@hsrai

To clarify, this is not a fork and not a rejection of Frappe or ERPNext. These projects have empowered a large community and deserve respect.

If I’m starting today, I’d never fork and repeat the same decisions.

• No global state, I’d start with dependency injection, easy to test and override.
• use python entry points in combination with DI to override, customize anything from the framework or any apps. Entry Points - setuptools 80.9.0 documentation. NO monkeypatching or re-invented hooks.py
• I’d get rid of doctype jsons (15+ years ago there was no Pydantic) and dynamic doctype metadata in db is also not really preferred by me, I’ll not prefer any property change unless the tests pass. So if new field is required, I’ll prefer new release. Same with custom doctypes. I’ve made so many apps, I add doctypes and fields of my own. And for overrides, check point 2
• I’d not be re-inventing components if i find tools provided by larger community than ours. Use uv, cookiecutter, sqlalchemy, etc. don’t re-invent (most have great test coverage, assures stability)
• Async/Await all the way.
• Hexagonal Architecture, Ports are defined, Adapters are implemented, Adapters can be extended, replaced, overridden.
• Target good test coverage from the day 1. Begin with TDD/BDD.

@hsrai

If around 5 people are interested and can contribute 5–6 hours/week, I’ll share an initial blueprint for discussion.

I’d like to know the blueprint irrespective of we do it or not.

[asieftejani]

@revant_one these are excellent points - now thats called experience

so if I can ask the leadership or anyone else to help me understand: -
why are we trying to de-google (e.g. drive, slides, mail) when these tools are available free for us and battle tested
wouldnt it be better to stablize as @hsrai says , improvement documents/translations and try to implement some of the above points by @revant_one

then again maybe this is what the gold partners or enterprise customers want so in the end “Customer is King” then only can “Community gets FOSS”

[szufisher]

@revant_one

use python entry points in combination with DI to override, customize anything from the framework or any apps. Entry Points - setuptools 80.9.0 documentation. NO monkeypatching or re-invented hooks.py

any sample code can be referenced? currently I heavily used monkey patches to override standard functions, I would like to learn and use more elegant way to achieve the same.

[kolate_sambhaji]

@revant_one

If I’m starting today, I’d never fork and repeat the same decisions.

@revant_one You mentioned some excellent points!, I would like to add a few more patterns that other enterprise products or other companies using (just to help new developers )

Event Sourcing & CQRS: Store state changes as events rather than current state.
Products like Shopify use this for complete audit trails and time-travel debugging.

GraphQL APIs: Let clients request exactly what they need. GitHub, Shopify use
this to reduce over-fetching and API call overhead.

Message Queue Architecture: Decouple long-running tasks (RabbitMQ, Celery).
Odoo uses PostgreSQL NOTIFY, but dedicated message brokers scale better.

Feature Flags: Deploy code without enabling features. GitLab uses this for
gradual rollouts and A/B testing without redeployment.

OpenTelemetry: Distributed tracing across services. Essential once you move
beyond monoliths.

Contract Testing (Pact): Test service integrations without running all
services. Netflix uses this extensively.

Domain-Driven Design: Clear aggregate boundaries, enforce business rules at
the domain level. Critical for complex business logic.

API Versioning: Stripe’s approach of maintaining multiple API versions with
clear deprecation timelines is gold standard.

Idempotency Keys: Prevent duplicate transactions on retries. Every payment
gateway does this.

Currently in Frappe, we work around these with creative solutions, but native
framework support would be transformative for enterprise deployments, also it will help both developers and framework.

[asieftejani]

If you are adding GraphQL please also include SOAP XML (Quickbooks desktop USA market & Tally India)

[revant_one]

@szufisher

any sample code can be referenced? currently I heavily used monkey patches to override standard functions, I would like to learn and use more elegant way to achieve the same.

No frappe example yet. Non frappe example here: https://gitlab.com/castlecraft/citadel/-/blob/main/citadel/apps/book-keeper/examples/book_keeper_plugin/pyproject.toml?ref_type=heads

@kolate_sambhaji

Event Sourcing & CQRS: Store state changes as events rather than current state.
Products like Shopify use this for complete audit trails and time-travel debugging.

@kolate_sambhaji

Domain-Driven Design: Clear aggregate boundaries, enforce business rules at
the domain level. Critical for complex business logic.

That should be optional. Framework should allow to move progressively towards DDD/CQRS/ES. May not be required on the first day.

@kolate_sambhaji

Idempotency Keys: Prevent duplicate transactions on retries. Every payment
gateway does this.

I believe this check happens on modified field of doctype. There is no explicit “version”, does the job. We get the message to retry because doc was modified.

[hsrai]

@revant_one

If I’m starting today, I’d never fork and repeat the same decisions.

+1

This states everything. I thought many time to fork and improve it, but after thinking hard I concluded to start a green project, with no traces of any project will be good. Just take clues, good things and bad things from various project and decide on that for a new green project, with blank slate.

@revant_one

• No global state, I’d start with dependency injection, easy to test and override.
• use python entry points in combination with DI to override, customize anything from the framework or any apps. Entry Points - setuptools 82.0.0 documentation . NO monkeypatching or re-invented hooks.py
• I’d get rid of doctype jsons (15+ years ago there was no Pydantic) and dynamic doctype metadata in db is also not really preferred by me, I’ll not prefer any property change unless the tests pass. So if new field is required, I’ll prefer new release. Same with custom doctypes. I’ve made so many apps, I add doctypes and fields of my own. And for overrides, check point 2
• I’d not be re-inventing components if i find tools provided by larger community than ours. Use uv, cookiecutter, sqlalchemy, etc. don’t re-invent (most have great test coverage, assures stability)
• Async/Await all the way.
• Hexagonal Architecture, Ports are defined, Adapters are implemented, Adapters can be extended, replaced, overridden.
• Target good test coverage from the day 1. Begin with TDD/BDD.

Your apprach is matching with mine a lot. With feedback of all who are experiencing pain because of decisions taken decades back (which were right at that time) either as developer or user, as expectations have hightened because of many new technologies. tools, and approached emerged since then, will help to pick the best for the propesed project.

@revant_one

@hsrai

If around 5 people are interested and can contribute 5–6 hours/week, I’ll share an initial blueprint for discussion.

I’d like to know the blueprint irrespective of we do it or not.

To develop an enterprise-grade open platform for building long-lived business applications, inspired by lessons learned from existing ERP and web frameworks.

Vision is to provide:

1. A strong, coherent core framework that values correctness, clarity, and longevity

2. A modular ecosystem that avoids duplication while encouraging reuse

3. A system where architecture decisions are explicit, documented, and reviewable

4. A platform suitable for serious enterprise use, not only rapid prototyping

A software which prioritises:

1. Stability over novelty

2. Explicit design over convenience shortcuts

3. Governance over personalities

4. Predictability over surprise upgrades

It is less about coding but more about goverance and decisions taken.

Tech Stack

Proposed, may change after discussion and feedback. Anything not listed here is out of scope for now.

A. Core Principles

1. Enterprise-grade stability
2. Clean core, strict ownership
3. Governance-first
4. Cross-platform development
5. Linux-first production
6. No runtime magic
7. Composition over inheritance
8. Deterministic builds & upgrades

B. Backend

Area	Proposed
Language	Python 3.11+ Base 3.12, Supported 3.11 to 3.14
Framework	FastAPI (explicit, typed)
Starlette	ASGI framework
Uvicorn	Production-grade ASGI server
Data modeling	Pydantic [v2 Strong typing, validation, serialization / Config via env/files (12-factor friendly), typing-extensions: Forward compatibility ] + dataclasses
ORM / DB abstraction	SQLAlchemy 2.x (explicit usage only, typed, async support)
Migrations	Versioned, explicit (Alembic-style)
API style	REST first (GraphQL optional later)
Auth	Core-owned, pluggable providers
Backend style	ASGI

C. Database

Area	Proposed
Primary DB	PostgreSQL
Schema	Strict constraints
JSON usage	Allowed, but not core data
Multi-tenancy	Explicit, not implicit

D. Cache / Queue

Area	Proposed
Default	Valkey
Role	Cache, jobs, locks
Abstraction	Required (no Valkey-specific code)
Redis	Compatible, not primary

F. Frontend

Area	Proposed
Framework	Vue 3
Language	TypeScript
UI model	Component-based only
Styling	likeFrappe-UI (Tailwind based. but green project)
State	Explicit (Pinia)
Rendering	SPA (no server-side HTML)

G. Tooling

Area	Proposed
CLI	Single cross-platform CLI
Shell scripts	Forbidden
Node usage	Frontend build only
Python pkg mgmt	poetry
JS pkg mgmt	pnpm
Build model	Deterministic, reproducible

H. PDF / Reporting

Area	Proposed
wkhtmltopdf	Not used
PDF	Pluggable (WeasyPrint)
Reports	Metadata-driven, backend-owned

I. OS & Platform

Area	Proposed
Dev OS	Windows / Linux / macOS
Prod OS	Linux-first
Containers	Optional, not mandatory
systemd/k8s	Infra concern, not framework

J. Explicitly Excluded

1. jQuery
2. Bootstrap
3. Server-side HTML templates
4. Runtime schema mutation
5. App-level core entity redefinition
6. God tool like Bench

[Yamen_Zakhour]

Interesting.. I always find myself attempting similar projects but discontinue them halfway because I work solely and lose interest quickly.

One of those attempts was with the cloudflare stack which I find is really promising and powerful (apart from sqlite but it works for 95% of businesses).

The stack is something like this;

• Backend (ex; Hono) & Frontend(s) (ex; Payload) : Cloudflare Workers
• DB: Cloudflare D1 (+ Drizzle)
• Redis: Cloudflare KV & Queues
• Storage: Cloudflare R2
• Realtime: Cloudflare Durable Objects
• Scheduler: Cloudflare Triggers

It might be ambitious but the concept is to build an entirely serverless and extremely scalable framework that lives on edge. There are no devops involved, and provisioning is literally few clicks (which you can automate).

This stack also benefits from all Cloudflare services and tools like cdn, data localization and hints, cloudflare uptimes and speed (edge), Cloudflare for SaaS and more

The most interesting part is you can literally provision hundreds of instances (clients) while still remaining on their extremely generous $5 plan and the extremely cheap zero-egress storage.

Another solution which I have been recently utilizing for smaller clients is Directus with PostgreSQL which provides almost the same “batteries” as Frappe, much easier maintaining and provisioning, a more powerful permission system which makes it suitable for multitenancy, and most importantly, much more mature SDKs for frontend development with easier socket setup. You can consider this rather than rebuilding the dream framework from scratch.

Things that keep me in the Frappe ecosystem;

• Reports system
• Customization layers (Fields, Client and Sever Scripts)
• Print formats
• Clients with “enterprise” requirements specially accounting, inventory and manufacturing. ERPNext is extremely mature and battle-tested with years of R&D.
• Workflows

Things I hate about it;

• Provisioning & DevOps
• Anything related to custom frontend development and UIs (and socket)
• Sometimes the permission system specially for grouped resources (like teams, lead pools, etc..)

[asieftejani]

@hsrai so this means you want to start a fresh framework with your stated objectives
how will new_green_framework integrate/connect with erpnext?
maybe check out GitHub - tryton/tryton: Mirror of tryton which is the fork of odoo before going commercial - i believe it is community driven and focused on stability

[revant_one]

• There is always a clash between Indie vs Enterprise.
• The Indie needs quickstart, low-code, get to market fast without hasles. “batteries included”. The day 1 developer.
• The Enterprise want to then extend it beyond day 1 on day 100. “batteries replacable”.
• Generally I deal with enterprises who want the battries replaced. I’ve replaced them with our upgrade packs.
• This Indie vs Enterprise problem is with all low-code stuff out there. You get the 80% done (as loan/debt) and then choke on 20% (as heavy interest to clear the debt). I stopped looking at low code, because I’ll land with more or less frappe framework alternative where I will benchmark it for features with “frappe framework”.
• Indie is looking for one click install of ERPNext, DIY, cheap, low cost.
• Enterprise is looking for installs on complex environments that scales. Ready to pay, no-diy and consultants-based, They are not looking for one click install of SAP.

I had expressed this before, the framework should be progressive. In indie-mode, you should not depend on anything other than python runtime. Mac, Windows, Linux doesn’t matter. It should be monolith, users in db, everything in one db. reports, permissions, user attributes, etc are in same db. Potentially runs on standard SQL (sqlite), so developer doesn’t even need a running db service.

When enterprise want the same, they will do things that are seen as unnecessary by indie: CQRS, External authorization (OPA/SpiceDB/Cedar, etc), change the DB to postgres or something external. Add analytics (elasticsearch, clickhouse, etc) db for reporting. They will connect with their central identity provider / AD instead creating and syncing user in all apps.

If we see the target market (Indie) it is for the $5 cloud instances. So the focus is: One-click installs, One screen apps, Easy hacks to code. Enterprise are not even target because each enterprise will potentially express different things and hold you accountable compared to low skin-in-the-game investment of $5.

[0spinboson]

tbh as an relative newcomer with a fair bit of experience with volunteer work and some with developing for frappe (at least enough to run up against its shortcomings), I think this is an avenue worth exploring in depth, but I’m not sure I would start from zero once the exploration phase is done — I just don’t think there’s that much demand for a wholly new framework that people would have to learn and develop and migrate to on the one hand, and volunteers (or FOSS organizations who can spare a few dozen FTE for exploratory work) to develop such a framework.

I say this, mindful of the fact that both odoo and tryton exist and are being developed ‘by the community’ (sort of, in the first case, as they’re constantly being rug-pulled by odoo Inc.), and none of these initiatives are likely to really get somewhere if only because of the fragmentation. Adding yet another framework besides frappe to this.. no.

Also, looking at frappe framework itself, I think the issue is less one of bad choices being made per se, and more one of lacking core developers and volunteers contributing to that. Take for instance this bug report i submitted, which struck me as pretty fundamental. Yet we’re now months in, and nobody seems to have so much as looked at it; and while the RQ improvements in frappe v16 go some way to mitigating this, I don’t really see a reason why you wouldn’t want to have this as well. Yet – crickets. That to me smells like an understaffed team. Similarly, in developing my own app, I added a system for critical operation rules; middleware to check whether the users calling APIs actually have the right to call them, and a secure operations framework, with which I’ve tried to do something similar for regular method calls (adding roles and role profiles checks). That said, I’ve mostly come up with these on my own, and I don’t doubt that there are issues with my choice of solutions.

All of these strike me as shortcomings that a better system would deal with, but my sense so far is that it would be much better to try to improve the frappe core applications by pushing for better separations of concerns and the creation of best practices documentation, coupled with ways to make it easier to find, organize and catalog existing functionality than having them be spread across modules, patching code, and so on. And I also think that most of these are issues that frappe could and would adopt if there was a bigger pool of core devs that talked through issues more; and that the issue isn’t so much rapid development as it is lack of people leading to things slipping through that shouldn’t.

That said, the things that puzzle me most about frappe is the lack of core audit logs.

[gagan0123]

The tension between Indie and Enterprise is often framed as a zero-sum game, but I believe that’s a false bifurcation. Coming from a WordPress background, I’ve seen how a stable core can serve both a $5-a-month site and a global enterprise equally. While the architectures differ, the governance lessons are universal: you don’t need to choose between speed and stability if you prioritize modularity.

1. Performance as a Universal Value

Performance isn’t an “Enterprise” feature. A faster core benefits an indie on a tiny VPS just as much as a corporation with millions of rows. Optimizing query efficiency and the Python runtime is a tide that lifts all boats. If it makes the framework faster, it should be implemented for everyone.

2. Core vs. Extensibility

In WordPress, the “core” is sacred and stable, while the “expandability” allows enterprises to build custom, complex systems on top of it.

• For the Indie: They get a functional, “batteries-included” system out of the box that just works.

• For the Enterprise: They get a modular architecture where “batteries are replaceable.”

We should focus on making Frappe’s components less “soldered” to the core. This doesn’t hurt the Indie who uses the defaults; it just makes the framework more robust for those who need to swap them out.

3. Stability and Backward Compatibility

A critical reason for WordPress’s dominance is its legendary commitment to backward compatibility. Things stay compatible for a very long time before they are eventually deprecated and removed. This gives developers the confidence to build plugins and custom enterprise logic knowing that a minor core update won’t wreck their work.

Frappe needs to move away from the culture of “breaking things fast” and move toward a model where the core remains stable. When developers don’t have to spend half their time fixing things that broke due to a framework update, they can spend that time building features that benefit the whole ecosystem.

4. Reducing Technical Debt

The “low-code debt” mentioned in this thread is real. WordPress solved this by providing clear APIs and hooks. By refining Frappe to be less “magical” and more “explicit,” we reduce the interest on that debt. Clearer abstractions help the DIY indie debugger and the enterprise consultant equally.

5. Predictable Release Cycles

The biggest benefit to the project would be a predictable release and deprecation cycle. Enterprises need this for planning, and Indie users benefit from not having their setups broken by sudden architectural shifts.

Instead of choosing between Indie speed and Enterprise stability, we should focus on Performance, Modularity, and Stability. If we make the framework faster and its components more decoupled, the “target market” becomes irrelevant because the tool itself becomes fundamentally better for any use case.

[asieftejani]

@gagan0123 I was about to ask in this post: -
Is there some balanced middle ground sweet spot where we can satisfy both the Indie and the enterprise
I think you have pretty much answered that
Now lets hope the leaders read + agree or at least comments with the disgreement - @rmehta
Thanks

We should focus on making Frappe’s components less “soldered” to the core.

I dint understand this sentence - I thought the core (which is in this case the framework) should be stable and sacred. Do you mean erpnext should not be soldered to the framework so that people can customize it?
If not please can you provide an example for my better understanding

Edit: - They just bumped up the python and node versions - does that impact the core?
Also many apps in v16 dont work with v15 - that could be a classical example of backward compatability

[volkswagner]

@0spinboson

Yet – crickets. That to me smells like an understaffed team

I don’t think Frappe is understaffed; they are underfocused. They let team members run wild, creating new products before perfecting existing apps.

[peterg]

@volkswagner

I don’t think Frappe is understaffed; they are underfocused. They let team members run wild, creating new products before perfecting existing apps.

Your comment is entitled and unkind. It’s not a good look.

The Frappe leadership has talked extensively both here and on its blog about how it is structured and why. If that structure is not your preference, that’s fine, but there’s absolutely no need to be rude about it.

[volkswagner]

@peterg

Your entitlement is showing.

It’s pure frustration.

I’ve invested thousands of dollars in the Frappe partnership program (with a negative return).

I’ve tried to help the project in multiple avenues and I will still continue to help in the ways I know how and can afford.

I can only hope Frappe management listens to user complaints. Without customer feedback no product on the planet will evolve into a satisfactory experience for the consumer.