English version: Why FreeCAD still feels like beta after 10 years, and does it still have a right to exist? — a structural analysis.
FreeCAD is al meer dan tien jaar in ontwikkeling, en toch voelt het voor veel gebruikers nog steeds als een beta-programma. De gebruikelijke reactie is: “maar de geometrie-kernel (OCCT) is toch goed?” Of: “het is open source, wat verwacht je?” Beide antwoorden raken de kern niet. Het probleem zit niet alleen in de integratie, noch in de licentie — het zit in wat FreeCAD eigenlijk is, hoe het gefinancierd en bestuurd wordt, en in de fundamentale afhankelijkheid van een kernel die ze niet sturen.
Het is geen CAD-programma, het is een CAD-ontwikkelplatform
FreeCAD is niet opgezet als een product voor eindgebruikers. Het is een platform om CAD-workflows op te bouwen: werkbanken (workbenches), een Python-API, een plugin-systeem, een feature-tree met parametrische historie. Dat maakt het krachtig voor mensen die in CAD willen hacken, maar ruw voor wie gewoon een model wil tekenen zonder de software te bestrijden.
Een geproduktiseerde CAD-app (Fusion 360, SolidWorks, Onshape) kiest voor: afronding, UX, een smalle doelgroep, opinionated workflows. FreeCAD kiest voor: uitbreidbaarheid, compatibiliteit met oude bestanden en macro’s, ondersteuning voor zoveel mogelijk domeinen (mechanisch, architectuur, meshes, scripting). Die keuze is legitiem, maar het is geen productkeuze.
De kernel IS een probleem: een asymmetrische commerciële relatie
FreeCAD gebruikt Open Cascade Technology (OCCT), een volwassen, industriële CAD-kernel. Maar de relatie is fundamenteel ongelijk:
- FreeCAD rijdt gratis mee op OCCT — geen licentiekosten, geen kernel-team nodig.
- OCCT gebruikt FreeCAD als gratis test suite — duizenden gebruikers, talloze workflows, real-world edge cases die OCCT zelf nooit zou testen.
- OCCT is commercieel — ze verkopen support, custom development, en enterprise-diensten. Ze hebben geen reden om features te bouwen of bugs te fixen specifiek voor FreeCAD zonder er geld voor te krijgen.
Dit betekent: FreeCAD moet bedelen voor kernel-aanpassingen. Een feature die FreeCAD nodig heeft voor robuuste parametrische herberekening, toplogie-bewaking, of assembly-constraints? Die komt er alleen als OCCT er commercieel voordeel in ziet, of als FreeCAD het zelf bouwt — wat vereist: diepe C++-expertise, coordinatie met upstream, en een maintenance-last die een vrijwilligersproject niet aan kan, of geavanceerde AI-modellen.
In een commercieel CAD-pakket (Parasolid, ACIS, ShapeManager, C3D) is de kernel eigendom van hetzelfde bedrijf dat de app bouwt. Ze kunnen de kernel aanpassen aan de app, en de app aan de kernel. FreeCAD heeft die hefboom niet. OCCT zou specifiek voor FreeCAD ontwikkeld moeten worden — een fork met een eigen roadmap, afgestemd op de workflows die FreeCAD wil ondersteunen. Maar twee dingen blokkeren dat:
- Geld: de FPA besteedt geen budget aan kernel-werk (zie financiële misstand hieronder) — er is geen geld apart gezet voor “OCCT-fixes voor FreeCAD”.
- Principes: FreeCAD weigert AI te omarmen om zo een fork te realiseren, uit ethische overwegingen. De hulp die ze zo hard nodig hebben (AI-ondersteunde C++-kernel-ontwikkeling), slaan ze uit.
Resultaat: de harde CAD-problemen (booleaans die mislukken, constraints die inconsistente worden, feature-volgorde die modellen breekt, onvoorspelbare herberekening) liggen op de grens tussen kernel en app. OCCT zegt: “werk correct met onze API.” FreeCAD zegt: “jullie kernel geeft ons geen houvast.” En niemand lost het op.
Waarom het “beta” blijft voelen
CAD is één van de weinige domeinen waar “correct en herhaalbaar” belangrijker is dan “snel en makkelijk”. Een kleine bug in een booleaans of constraint kan een heel project ongeldig maken. Gebruikers voelen die scherpe randen direct, omdat het hun werk breekt.
Daarbij komt: FreeCAD wordt gedreven door een gemeenschap, niet door een productteam met een roadmap die UX prioriteert. Er is geen product owner die zegt: “deze workflow breekt voor 80% van de gebruikers, we fixen dit vóór we nieuwe features bouwen.” In plaats daarvan wint “we kunnen nog meer workflows ondersteunen” steeds van “het programma moet echt werken voor de gebruiker.”
De financiële misstand: geld gaat naar ontwikkelaars, niet naar bugs (en zeker niet naar de kernel)
De FreeCAD Project Association (FPA) beheert donaties en verdeelt ze via een grantsysteem. De jaarrekeningen zijn publiek (FPA repo). Wat eruit blijkt: geld stroomt naar “developer grants” — voorstellen voor refactoring, API-documentatie, CI, UX-onderzoek, Toponaming-mitigatie. Niet naar een wachtrij van gebruikersbugs, niet naar release-stabilisatie, niet naar “maak de pijnlijkste workflows werkend”, en zeker niet naar “betaal OCCT voor FreeCAD-specifieke kernel-verbeteringen”.
Dat creëert een mismatch: gebruikers die doneren doen dat omdat ze een klaar CAD-programma willen, maar de financiële structuur beloont technische diepgang en ontwikkelaarsarbeid. Een ontwikkelaar krijgt betaald voor “Sketcher refactoren”; de gebruiker die “simpele booleaans breken nog steeds” koopt geen fix. En de kernel-kwestie — de wortel van veel van die pijn — blijft onbetaald, onbehandeld, en onbespreekbaar.
Verontrustend genoeg: zelfs binnen de FPA is onduidelijk waarom mensen doneren. De top-tier donateurs op de FPA-website zijn erg uiteenlopend — van hobbyisten tot bedrijven, van idealisten tot gebruikers die simpelweg willen dat het project voortbestaat — en er is geen helder inzicht in wat hen drijft. Die opaciteit maakt het onmogelijk om de financiering op een productdoel in te richten: je kunt geen roadmap bouwen voor “klanten” als je niet weet wie je klanten zijn en wat ze verwachten.
Een verdeelde gebruikerbasis, geen productvisie
De FreeCAD-gebruikersbasis bestaat uit incompatibele groepen:
- Ingenieurs/professionals die stabiele CAD-bestanden verwachten, dezelfde kernfunctionaliteit als professionele software, en minder eisen stellen aan de UI — ze accepteren ruwe randen als de onderliggende modeller betrouwbaar is en bestanden correct rondkomen.
- Hobbyisten/makers die eenvoud willen — ze begrijpen de modelleerfilosofie niet en struikelen over elke onlogische interactie.
- IT-ontwikkelaars/script-enthousiastelingen die de uitbreidbaarheid, Python-API en platform-idee leuk vinden — zij zijn vaak degenen die code schrijven en regels bepalen.
Degenen die de code schrijven (groep 3) hebben de meest invloed. Hun incentieven liggen bij technisch interessante werkpakketten, niet bij eindgebruikerspijn. Niemand binnen het project durft te zeggen: “dit werkt niet als product, we moeten de identiteit en prioriteiten van het project fundamenteel veranderen.”
Wat de nieuwe golf wel goed doet
Programma’s als SolidCraft (open source, parametrisch, in Rust) beginnen bij wat gebruikers al kennen: een ribbon met tabbladen Solid, Surface, Mesh, Sheet Metal, Plastic, Utilities; links de modelboom; onderin de tijdlijn. Dat is de indeling van Fusion 360, tot de tabbladnamen toe. Waar FreeCAD begon bij wat technisch interessant was, beginnen deze nieuwe tools bij het programma dat mensen al gebruiken — maar dan gratis en open source.
Ze hebben een smaler bereik, minder legacy, minder compatibiliteitsballast, minder parametrische complexiteit. En cruciaal: sommige (zoals SolidCraft in Rust) bouwen hun eigen geometrie-kernel of koppelen zich vrijer aan een kernel die ze wel kunnen sturen. Ze zijn misschien geen “betere CAD” in de diepe engineering-zin, maar ze voelen wel als een betere product.
Conclusie: geen complot, wel een structurele blinde vlek — en een existentievraag
FreeCAD is niet slecht bedoeld. Het is een ambitieus technisch project dat per ongeluk in de vorm van een eindgebruikersapp is gegoten, gebonden aan een kernel die het niet kan sturen, zonder gedefinieerde doelgroep, met een financiering die ontwikkelaarsarbeid beloont in plaats van gebruikerspijn — en waar zelfs de donorstroom ondoorzichtig is voor degenen die het geld beheren.
De keuze is simpel: of FreeCAD kiest bewust voor “platform voor CAD ontwikkelaars” en communiceert dat helder, of het kiest voor “CAD-app voor ingenieurs en makers” en daagt de organisatie, financiering, roadmap en kernarchitectuur (kernel-controle) daadwerkelijk daarop in. Alles ertussenin blijft “beta na 10 jaar”.
Maar er komt een scherpere vraag: de vibecode-golf dwingt FreeCAD misschien wel om te kiezen voor “platform voor CAD ontwikkelaars” — de enige identiteit die nog een kans lijkt te bieden. Maar zelfs die ruimte krimpt: als iedereen met AI-hulp hun eigen CAD-programma kan bouwen in plaats van een FreeCAD-werkbank te schrijven, wat is dan nog de meerwaarde van het platform? De drempel om een volledige, smalle, opinionated CAD-app te bouwen is drastisch gedaald. Waar vroeger een workbench de logische stap was, is nu een nieuw programma de logische stap. Dat stelt de fundamentele vraag: wat is het bestaansrecht van FreeCAD in een vibecode-samenleving?
Als FreeCAD geen product is, geen kernel controleert, geen heldere doelgroep bedient, geen inzicht heeft in zijn donateurs, én het platform-model ondermijnd wordt door de makkelijkheid van het bouwen van eigen apps — dan is het niet meer een project in een identiteitscrisis, maar een project dat zijn reden van bestaan kwijtraakt. En als het platform-model zelf onder druk komt door de vibecode-revolutie, dan is de tijd van half-hartige keuzes voorbij.
Bronnen: 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 (auteursrecht op functionaliteit, zaak SAS Institute v. World Programming, Hof van Justitie 2012, richtlijn 2009/24/EG).