Ah, the classic Frappe Forum refrain: the software is deliberately broken or left undocumented so developers and consultants can milk users for lucrative support contracts. The claim itself is profoundly cynical, masking a messy reality under the guise of an organized corporate conspiracy. It assumes a level of coordinated, mustache-twirling malice among developers and partners to intentionally sabotage a global ecosystem just to squeeze out a few extra consulting dollars. It’s a comforting fiction because a deliberate villain is much easier to rage against than the boring, chaotic reality of open-source development. But if this were an actual financial strategy, it would be the most spectacularly incompetent business plan ever conceived.
Look at the economic engine of Frappe itself, which runs almost entirely on hosting revenue through Frappe Cloud. If the product is fundamentally broken, users don’t stay and pay for support; they simply churn and leave for a competitor. Churn kills SaaS businesses. Meanwhile, support is a massive cost center rather than a profit generator; every hour a core engineer spends hand-holding a frustrated user through a convoluted UI is an hour stolen from building revenue-generating infrastructure. Even the notoriously finicky easy-install script for self-hosters isn’t a trap to force you onto their paid hosting. It is simply the natural byproduct of a total lack of commercial incentives. It is maintained by the community on a strictly best-effort basis because, frankly, nobody is getting paid to make self-hosting foolproof for people who don’t want to pay anyway.
The idea that partners are gaming the global codebase for local profit is equally absurd. ERPNext is a massive, worldwide product, while most partners are small, localized operations. A boutique consultancy in Germany isn’t successfully sabotaging a core accounting feature just to milk a few hundred euros out of a local client. Doing so would destroy their own margins, forcing them to maintain messy, unsustainable workarounds across every single future upgrade. As for individual contributors, the conspiracy theory collapses entirely. Users never look at the Git blame log to see who authored a broken feature. Writing terrible code doesn’t win you high-paying consulting gigs; it just makes you look incompetent, and nobody hires the chef who poisoned the soup to cater their next event.
The real reasons things break or lack documentation are rooted in plain human flaws and structural friction. Take the developer who just spent fourteen hours straight coding a complex feature. They possess a perfect, crystalline understanding of how it works. Because it is painfully obvious to them, they genuinely do not comprehend what a layman will find confusing. Rushing to meet a deadline or finally log off for the weekend, they skip the documentation entirely. It isn’t a plot to keep you in the dark; it’s just a tired human being experiencing the curse of knowledge. Over time, this morphs into gradual complexity. A feature starts out elegant and simple, but over years, dozens of developers add tiny modifications for specific edge cases. No single addition is massive enough to warrant rewriting the manual, but collectively, they turn a streamlined feature into an undocumented labyrinth.
Furthermore, developers suffer from a perpetual context vacuum. While engineers obviously get better and wiser over the course of their careers, absolutely nobody has all the context all the time. A developer building a fix might tailor it perfectly for a five-person services business, completely unaware that their change will inadvertently wreck the multi-currency workflows of a massive global trading enterprise. Similarly, someone embedded in the specific regulatory realities of India will code brilliantly for what they know, entirely blind to how that exact same logic breaks accounting compliance for a user in Germany.
Then there is the structural tragedy of the documentation itself, where gatekeeping and architectural divides are very real, ongoing problems. The documentation lives in a separate wiki ghetto, completely detached from the codebase. If a user actually wants to fix a typo or update a guide, they cannot just submit a quick edit; they have to hunt down and reach out to some ambiguous gatekeeper—someone nobody actually knows—just to request write access. This creates a severe disadvantage in the current era of artificial intelligence. While LLMs can easily parse and edit code, they cannot seamlessly navigate and update a detached, permission-locked wiki. This makes it relatively harder to keep documentation up-to-date, widening the gap between what the software does and what the manual says.
The ultimate irony drops when frustrated forum users smugly tell critics to stop complaining and just go open a Pull Request to fix it. Right now, you literally can’t. The repository is choked because PRs are currently blocked due to a relentless, overwhelming flood of low-quality, LLM-generated spam. The system is clogged not by a cabal of greedy consultants plotting your financial ruin, but by automated noise and the sheer weight of its own global scale. Things are broken because building a one-size-fits-all global ERP is an agonizingly difficult problem handled by exhausted humans, not because someone is playing 4D chess with your wallet.
