Yeah. To quantify, OCCT is >1M lines of code, and SolveSpace's NURBS kernel is <10k. This general smallness is what subsequently made stuff like the browser target feasible, though it obviously comes with downsides too.
We'd welcome contributions, and it's much easier to contribute to the smaller codebase. I think there's potential for coding agents to accelerate this work since robust point-in-shell and shell-is-watertight tests are mostly sufficient to judge correctness, allowing the agent to iterate; loosely you could define your geometric operation as a function of whether a point should lie within the output region, then ask the agent to convert that to b-rep. I wouldn't currently expect useful progress without deep human effort and understanding though.
Well, he was nice enough to write the Linux port in the first place, and he personally develops under Linux, so...
To develop free, general-purpose, desktop, parametric 3d CAD software is fairly thankless work. It's a huge task, and relatively few developers have the necessary mathematical skill and ME domain knowledge. The commercial market is mature, limiting opportunities to monetize. I have great respect for the time and other resources that whitequark (and others) have chosen to expend here in spite of that.
> Interesting bit of trivia: SolveSpace comes from M-Labs
I developed SolveSpace, and whitequark (via M-Labs) is the current maintainer. He's responsible for all the non-Windows ports, plus the last few years of features and some significant refactoring. We hope the latter will make the codebase more accessible to other contributors.
SolveSpace's NURBS operations are worse than OpenCASCADE's, but they're literally orders of magnitude smaller. There's still no great free alternative to Parasolid, SOLIDS++, etc. SolveSpace's constraint solver is pretty good, and people seem to mostly like the UI.
"Constraint" means something different to Cassowary than it does to us here, and isn't obviously useful. An optimized matrix library (Eigen, BLAS, LAPACK, etc.) would provide a modest speedup without too much work.
So yeah, the constraints in SolveSpace are nonlinear. They're solved by a Newton-ish method, which for underconstrained sketches also minimizes at each step the sum of the squares of the distances that any un-dragged points move (plus some other stuff). The Jacobian matrix is computed by an internal symbolic algebra system, allowing considerable flexibility in the range of user-facing constraints without a combinatorial explosion of hand-coded special cases.
As whitequark notes, the final solution of the constraint equations is a relatively small part of the overall work. The difficulty is mostly in writing them, to handle many useful cases in relatively few lines of code, and to converge reasonably in the Newton's method.
For a dramatic speedup, we could partition the constraint equations into roughly-triangular form, and then solve sub-systems in dependency order. Practical sketches seem to have a lot of such structure, and a visualization of that graph would be an interesting expression of the design intent. (To be clear, this isn't a spreadsheet; you still have to numerically solve systems of multiple equations, just not all of your equations at once.) I wrote an earlier solver that did this in some cases, but SolveSpace doesn't at all.
We'd welcome contributions, and it's much easier to contribute to the smaller codebase. I think there's potential for coding agents to accelerate this work since robust point-in-shell and shell-is-watertight tests are mostly sufficient to judge correctness, allowing the agent to iterate; loosely you could define your geometric operation as a function of whether a point should lie within the output region, then ask the agent to convert that to b-rep. I wouldn't currently expect useful progress without deep human effort and understanding though.