There's no money in CAD by itself, meaning just the drawing part. Drafting is a low-value activity often performed by low-value workers who don't write software. Even if they wanted to, they couldn't make software tools for themselves. It's not like when web developers make web development tools, or when machinists make machinist tools.
CAD is sort of a piazza where the value a company gets from it comes from everything that's attached to it - reporting, CAE, CAM, etc. And they do invest in those things, often quite heavily.
It's big business to create these tools. The investment and expertise that go into them is enormous. That's why many of them cost as much as hiring another employee. They do at least as much work as one. They keep up with all the latest and greatest regulations, technologies, manufacturing processes, etc. And they give you access to a lot of valuable proprietary information.
Even if a company threw twice as much money at open source CAD, they'd still get basically none of that. They would just have an expensive drawing tool. It would be basically worthless and worth almost nobody's time.
For customers with low requirements, the less expensive tools do the job at just the right price point where it doesn't make sense to invest in advancing something like freecad.
Also, many companies in many countries are pretty much "allowed" to pirate the really expensive software. Once they get big enough, the software company will ask them to start paying some reduced amount. So there's an unofficial free tier that's way better than any open source toy.
Case in point, BRL-CAD has had more than 450 years of full-time effort invested, tens of millions with development spanning over four decades. However, that investment is heavily centered around features, integrations, and capabilities that are not as typically useful to the general public.
Usability's slowly expanded, but primary paid focus is military vulnerability and lethality analyses where BRL-CAD is absolutely unparalleled. Even against the likes of CATIA, Creo, NX, Solidworks, etc., development is heavily and strategically optimized and invested for solid geometric analysis, validity, verification, and performance. BRL-CAD so overwhelmingly outperforms the commercial tools in the analysis space and is so well-integrated that it would likely cost tens of millions to stop using it.
Still, general usability is not funded and is left to the auspices of the open source community. That's a long road. Adding usability and developing infrastructure for a system that complex takes time and a level of expertise that isn't common. Until it gets minimum viable general usability, it's hard to scratch one's own itch without personal investment or extrinsic incentives.
To me it sounds like professional CAD is really hard and nobody can "just make it" in a few years of work. That's the reason why open source CAD doesn't really exist today in the professional space. But once it exists, it will eat the world. The transition phase will still take dozens of years because of all the work invested in existing platforms. We will probably see something similar to the adoption of Linux in the commercial space where it simply makes sense to use Linux instead of developing your own OS or licensing some other OS.
You mean a bit like an operating system without a kernel...?
https://wiki.freecadweb.org/Path_Workbench
My thesis is that the bigger challenge is "economic", not technical.
The value as linkdink said above is the add-ons, integrations, extensions, and the like.
It's a bit like Unreal Engine 5 having integrated the Quixel model library. You don't just get some C++ code, you also get ready-made art assets. And then you get compatibility with four game console platforms, mobile platforms, etc...
...
...
??
Cad software often includes simulation stuff which requires an engineers mind.
Current Solvespace maintainer here. IMHO there is a lot that can readily be added to solvespace. Then there could be a big effort to do hierarchical sketches. And it is reasonably possible to rewrite some of the geometry internals if needed. All of these things are a LOT of work. The problem is the number of people with the background, software skills, and interest in contributing is very very small.
Having said that, we will just keep chugging along. I've been very busy with personal stuff this year, but soon should have free time to address my backlog of stuff I personally want to do.
Open Source has the advantage of time as long as people stay at it ;-) OTOH Blender and FreeCAD have used the constraint solver. If they borrow some of UI ideas then we all win too!
Spot on the nose about number of people and their endurance tilting at the hard problems. BRL-CAD's been going at it longer than anyone, and the backlog only increases. I do believe open source CAD can get there, but it'll require more coordination.
Thanks!
>> Spot on the nose about number of people and their endurance tilting at the hard problems.
It worries me at times. The creator has moved on but can still be consulted on stuff. The 2nd lead maintainer burned out and nominated me. I see my position as somewhat temporary, but I'm willing to hold it until 1) I get the improvements done that I want to and 2) the right successor comes along - which I worry may never happen ;-)
>> I do believe open source CAD can get there, but it'll require more coordination.
Completely agree. Not sure how to focus all the different efforts though. Talking about it is certainly a start.
Currently researching geometric modelling kernels but collaboration in the community and bringing focus would solve this... even if it's better awareness and marketing so that solvespace folk and brlcad folk (and more!) aren't doubling up.
If there is interest in creating a new geometry kernel I'd be happy to discuss how ours works, what the main challenges are, and what limitations the approach has.
Another topic is licenses. I see FreeCAD uses LibreDWG now but has to jump through some hoops because its GPLv3 (not LGPL) and they are GPL2.x.
For the prior, OpenCAx Association was created specifically to encourage and even sponsor OSS coordination. It's still in formation, but it's purpose has been to help underpin Google Summer of Code collaboration for BRL-CAD, FreeCAD, OpenSCAD, LibreCAD, STEPcode, IfcOpenShell, and most recently KiCAD.
For the latter, creating a shared product or even sharing small subsets of logic is a challenge. BRL-CAD fully invested in and helped establish STEPcode for STEP support, for example, and now it's its own project. Spent more than a million USD developing our STEP support.
BRL-CAD is arguably closest to developing something akin to ACIS or Parasolid as its libraries and converters collectively cover the most features, but not without limitations (e.g., lacking API design, dozen libraries). There's been some talk of integrating OCCT where they have features BRL-CAD lacks, but that's a lot like Creo bundling Parasolid and ACIS with Granite (i.e., lots of representation, conversion, and API considerations). We do have a long-term roadmap but it's all dependent upon what people volunteer and are interested in working on, what we're paid to work on, and what's the best path forward strategically (and from a maintenance perspective).
Right now, we're heavily focused on usability and creating reusable geometry conversion infrastructure (which includes AP242 and a couple dozen other formats) and are making progress getting funding as a multiyear development initiative. Long-term, we're working on the clean API problem developing what we calling the Modular Object-Oriented Solidity Engine (MOOSE).
MOOSE meet Tovero the horse.
I guess everybody's gone from this post, but for posterity, it might be worth looking more closely at the source for Tovero, since we had to work around the lack of a formal C API when wrapping BRL-CAD with C++. In retrospect, I probably wouldn't even have chosen C++, but just done a C API which would be easier to use with the FFI of many languages like Python, Julia, or Common Lisp--and eliminated the need for SWIG. At least think about putting a C API on top of the OO of MOOSE, if you intend it to be accessed by other languages.
For an intelligent way of putting a C API over a C++ OO design see:
This project also demonstrates F-rep, a technique for modeling geometry with implicit functions and SDF, and Tovero 2.0 used it as an external dependency for its geometry kernel.
Does any system aspire to be a Prolog for 3D? You sketch a variety of views and a system solves, if possible, for a solid geometry representation?
From https://solvespace.com/tech.pl
> The core of any parametric CAD program is its geometric constraint solver.
and
> In SolveSpace, constraints are represented as equations in a symbolic algebra system. In general, these equations are solved numerically, by a modified Newton's method.
and from https://en.wikipedia.org/wiki/Geometric_constraint_solving#M...
> symbolic methods have been applied to this type of constraint solving (see Reference 20 on the Wikipedia link).
And your Zen "beginner mind" question got me to thinking, maybe I could use Prolog itself in my CAD system to directly make 3D shapes, since Prolog has been written in Lisp. Although Prolog does have a number of limitations:
I'm not aware of any. Maybe slightly related, my plan for a "hole tool" in Solvespace is to add a hole entity to 2D drawings that will automatically create a featured hole when the sketch is extruded. But that's not actually solving anything in a math sense.
See: https://wiki.freecadweb.org/OpenCASCADE https://en.wikipedia.org/wiki/Open_Cascade_Technology
There is currently no incentive model that I know of that can make this work at a university, or even national lab. In these contexts currently it's really hard to get funding for a single "real" programmer for a year, let along a proper effort for something like this. If it became a critical infrastructure project for a federal level agency, sure - but why would they support doing it in public?
The problem is that writing one takes a big effort - like Linux kernel sized, and needs people with niche technical knowledge. It's much, much easier to find someone who can write a java app for a web page than it is to find someone who can write CSG code for a CAD system.
It may eventually happen, but it's not inevitable.
For what it's worth, BRL-CAD has over 450 full-time staff years of effort invested with ongoing dev funded by the U.S. Gov't. It was made open source specifically so that investment could be shared with the world, to help commoditize CAD like has been done for browsers and compilers. It's a long road to get there no matter what.
A pattern I've often seen is a tortise vs the hare sort of thing between FLOSS and $$$ software. The free stuff improves slowly but steadily. The $$$ stuff changes quickly but those changes are often driven by perverse incentives (people looking for promotions, shareholder value, etc.), and development tends to go off the rails and piss off users.
eventually i had to get a "real job", a job where i can't really be doing domain specific open source stuff without a potential conflict of interest.
on the plus side, i just bought a couch without having to worry about whether i can eat dinner.
Does anyone have any experience in the software side of the industry to help explain why nothing open source is able to step up in a meaningful way?