This is the English reading version of the Dutch article Waarom FreeCAD na 10 jaar nog steeds beta voelt en heeft het nog wel bestaansrecht?.
FreeCAD has been in development for more than ten years, and yet it still feels like a beta program to many users. The usual response is: “but the geometry kernel (OCCT) is good, isn’t it?” Or: “it is open source, what do you expect?” Neither answer gets to the core. The problem is not only in the integration, nor in the licence — it is in what FreeCAD actually is, how it is funded and governed, and in its fundamental dependence on a kernel it does not control.
It is not a CAD program, it is a CAD development platform
FreeCAD was not set up as a product for end users. It is a platform for building CAD workflows: workbenches, a Python API, a plugin system, a feature tree with parametric history. That makes it powerful for people who want to hack in CAD, but rough for anyone who just wants to draw a model without fighting the software.
A productised CAD app (Fusion 360, SolidWorks, Onshape) chooses: finish, UX, a narrow target group, opinionated workflows. FreeCAD chooses: extensibility, compatibility with old files and macros, support for as many domains as possible (mechanical, architecture, meshes, scripting). That choice is legitimate, but it is not a product choice.
The kernel IS a problem: an asymmetric commercial relationship
FreeCAD uses Open Cascade Technology (OCCT), a mature, industrial CAD kernel. But the relationship is fundamentally unequal:
- FreeCAD rides along on OCCT for free — no licence costs, no kernel team needed.
- OCCT uses FreeCAD as a free test suite — thousands of users, countless workflows, real-world edge cases that OCCT itself would never test.
- OCCT is commercial — it sells support, custom development and enterprise services. It has no reason to build features or fix bugs specifically for FreeCAD without being paid for it.
This means FreeCAD has to beg for kernel changes. A feature FreeCAD needs for robust parametric recomputation, topology tracking or assembly constraints? It only arrives if OCCT sees a commercial advantage in it, or if FreeCAD builds it itself — which requires deep C++ expertise, coordination with upstream, and a maintenance burden a volunteer project cannot carry, or advanced AI models.
In a commercial CAD package (Parasolid, ACIS, ShapeManager, C3D) the kernel is owned by the same company that builds the app. They can adapt the kernel to the app, and the app to the kernel. FreeCAD has no such leverage. OCCT would have to be developed specifically for FreeCAD — a fork with its own roadmap, tuned to the workflows FreeCAD wants to support. But two things block that:
- Money: the FPA spends no budget on kernel work (see the financial mismatch below) — nothing has been set aside for “OCCT fixes for FreeCAD”.
- Principles: FreeCAD refuses to embrace AI to realise such a fork, on ethical grounds. The help it so badly needs (AI-assisted C++ kernel development) is turned down.
The result: the hard CAD problems (booleans that fail, constraints that become inconsistent, feature order that breaks models, unpredictable recomputation) sit on the boundary between kernel and app. OCCT says: “work correctly with our API.” FreeCAD says: “your kernel gives us no grip on our workflow.” And nobody fixes it.
Why it keeps feeling “beta”
CAD is one of the few domains where “correct and repeatable” matters more than “fast and easy”. A small bug in a boolean or a constraint can invalidate an entire project. Users feel those sharp edges immediately, because they break their work.
On top of that: FreeCAD is driven by a community, not by a product team with a roadmap that prioritises UX. There is no product owner saying: “this workflow breaks for 80% of users, we fix this before we build new features.” Instead, “we can support even more workflows” keeps winning over “the program actually has to work for the user”.
The financial mismatch: money goes to developers, not to bugs (and certainly not to the kernel)
The FreeCAD Project Association (FPA) manages donations and distributes them through a grant system. The annual accounts are public (FPA repo). What they show: money flows to “developer grants” — proposals for refactoring, API documentation, CI, UX research, Toponaming mitigation. Not to a queue of user bugs, not to release stabilisation, not to “make the most painful workflows work”, and certainly not to “pay OCCT for FreeCAD-specific kernel improvements”.
That creates a mismatch: users who donate do so because they want a finished CAD program, but the financial structure rewards technical depth and developer labour. A developer gets paid to “refactor Sketcher”; the user for whom “simple booleans still break” buys no fix. And the kernel question — the root of much of that pain — remains unfunded, unaddressed and undiscussed.
Troublingly, even within the FPA it is unclear why people donate. The top-tier donors on the FPA website are very diverse — from hobbyists to companies, from idealists to users who simply want the project to keep existing — and there is no clear insight into what drives them. That opacity makes it impossible to aim the funding at a product goal: you cannot build a roadmap for “customers” if you do not know who your customers are and what they expect.
A divided user base, no product vision
The FreeCAD user base consists of incompatible groups:
- Engineers/professionals who expect stable CAD files, the same core functionality as professional software, and who make fewer demands on the UI — they accept rough edges if the underlying modeller is reliable and files come through correctly.
- Hobbyists/makers who want simplicity — they do not understand the modelling philosophy and stumble over every illogical interaction.
- IT developers/script enthusiasts who like the extensibility, the Python API and the platform idea — they are often the ones who write code and set the rules.
Those who write the code (group 3) have the most influence. Their incentives lie with technically interesting work packages, not with end-user pain. Nobody within the project dares to say: “this is not working as a product, we need to fundamentally change the project’s identity and priorities.”
What the new wave does get right
Programs like SolidCraft (open source, parametric, in Rust) start from what users already know: a ribbon with the tabs Solid, Surface, Mesh, Sheet Metal, Plastic, Utilities; the model tree on the left; the timeline at the bottom. That is the layout of Fusion 360, down to the tab names. Where FreeCAD started with what was technically interesting, these new tools start with the program people already use — but then free and open source.
They have a narrower scope, less legacy, less compatibility baggage, less parametric complexity. And crucially: some (like SolidCraft in Rust) build their own geometry kernel or couple more freely to a kernel they can steer. They may not be “better CAD” in the deep engineering sense, but they do feel like a better product.
Conclusion: not a conspiracy, but a structural blind spot — and an existential question
FreeCAD is not ill-intentioned. It is an ambitious technical project that accidentally took the shape of an end-user app, tied to a kernel it cannot steer, without a defined target group, with funding that rewards developer labour instead of user pain — and where even the donor stream is opaque to those who manage the money.
The choice is simple: either FreeCAD deliberately chooses “platform for CAD developers” and communicates that clearly, or it chooses “CAD app for engineers and makers” and genuinely commits the organisation, funding, roadmap and core architecture (kernel control) to that. Anything in between stays “beta after 10 years”.
But a sharper question is coming: the vibecode wave may well force FreeCAD to choose “platform for CAD developers” — the only identity that still seems to have a chance. Yet even that space is shrinking: if anyone can build their own CAD program with AI help instead of writing a FreeCAD workbench, what is the platform still worth? The threshold for building a complete, narrow, opinionated CAD app has dropped drastically. Where a workbench used to be the logical step, a new program is now the logical step. That raises the fundamental question: what is FreeCAD’s right to exist in a vibecode society?
If FreeCAD is not a product, does not control a kernel, serves no clear target group, has no insight into its donors, and the platform model is undermined by how easy it is to build your own apps — then it is no longer a project in an identity crisis, but a project losing its reason to exist. And if the platform model itself comes under pressure from the vibecode revolution, the time for half-hearted choices is over.
Sources: FreeCAD Project Association (FPA) repo — finances.md, annualreports/2025.md; FreeCAD developers forum: ribbon/Modern UI draft; GitHub discussion #13775; Ondsel: Breaking the open-source UX curse; SolidCraft; Licenseware: AI rebuilt Adobe/Microsoft apps as open source (copyright on functionality, case SAS Institute v. World Programming, Court of Justice 2012, directive 2009/24/EC).