Yet another modeling kernel? Hell, no.

I recall several times when managers approached me with "intriguing" proposals. The first time was about taking on the role of a modeling leader. Another time was about taking on the role of OpenCascade development head. I declined both times. After a while, this same sort of proposal repeated outside the company, while the whole idea was kind of similar: to develop yet another modeling kernel from scratch. At OCC, such proposals had the flavor of walking over people's heads because all these positions were never actually vacant, and the whole situation just sucked from a human point of view. The external "offers" did not feel much better, as the whole idea was to develop something close-sourced for the benefit of unknown gentlemen. Also, starting a modeling kernel "from scratch" sounded a bit like a bad joke, as the times when such "innovations" were relevant are clearly gone.

Why am I writing this? Well, what I'm probably trying to say is that, from my personal perspective, it's way better to start with something existing. OpenCascade is probably not an ideal foundation, but there is one feature that outweighs all possible cons: it exists and it is accessible. What it means for me as a company founder is that I have full control over the backbone technology and can make it evolve one way or another without depending on big boys. That's the whole story behind open source: freedom. The ambitions to develop new modeling stuff can be realized by adding new features and fixing what's not working in the base kernel. You don't have to contribute anything back, and I'm clearly not going to, partially because of CLA but mostly because of what's written here. Because, from another perspective, open source is just a business model. I.e., this is how others make money on you. Look at OpenFOAM as an example. Smart people told me that to plug their solvers in, you'll have to spend so much energy that it becomes way more appealing to delegate the configuration process to those who know how to do it.

Another dilemma we had to solve was "to fork or not to fork." It's appealing to get rid of the OCC legacy in some ways, especially when it comes to constant compatibility issues. We even made a fork to release the ver.1.1 of Analysis Situs, but time has shown it was not an ultimate solution because:

• There are some useful improvements, especially in the data exchange module. For example, new versions of SolidWorks might happen to write STEP files in a little different way, and the newest releases of OpenCascade will come with patches for that matter.

• Our customers often already use one or another version of OpenCascade, and it's not an option to bring in a fork with our copy of "vanilla" OpenCascade.

• Having OpenCascade up-to-date is good for YT lessons, as people always want to learn the "cutting edge" technology.

The reasons mentioned above were not born out of our heads. It's rather practical knowledge accumulated over the years of engineering software development. And these reasons made us compose our SDK as a sort of "addendum" to OpenCascade. Here's the picture:

As you can see from the color codes, Mobius (our little in-house B-splines lib) remains independent of OpenCascade. This is done deliberately, and the idea from day one was to bring in custom B-spline-oriented algorithms aside from the clunky implementation provided in BSplCLib. In practice, to use Analysis Situs as an SDK in the OpenCascade-based application, it should be enough to add a couple of extra libraries to your development environment. This extended composition of libraries is something we would call a new "geometric kernel," where we have full control over the sources and have enough room to develop new algorithms.

Want to discuss this? Jump in to our forum.