If you build a system that needs geometry, most likely you will need to design a low-level geometry kernel that includes basic fundamental primitives and operations on these primitives. A quick win would be to install an open source library that already has these features. However, that can lead your business to many complexities in the future.

 

First, each time the library is updated, you may have severe consequences on your code. You will need to update it accordingly and you will need to follow the library closely to make sure your updates are correct. The more libraries you have, the more complex it becomes.

 

Second, with time, it will be hard to remove a library from your dependency list. This rather dramatic change may lead to many broken cases and un-predictable behaviour that you did not anticipate. So, you are stuck with it.

​

Another problem is security. External libraries may be vulnerable to hacker attacks and have serious security issues that can lead to potential company risks. Fixing such things when you do not always have direct access to that code may take time.

​

Finally, your code is not flexible enough. While your business is growing, you will most-likely need more features and specific cases handled by your geometry kernel that is not easy to add on top of the library code that did not have such a specific scenario in mind. And this is true even for highly generalized libraries that add freedom by sacrificing the code simplicity!

​

Note that it does not mean that using libraries is bad. Not at all! But they must be used wisely and preferably for high-complexity algorithms, which are rather static in time, well-tested, and rarely updated.

​

So, the best solution is to design and have your own geometry kernel highly specialized and tuned for your particular business needs! The drawback to build such a kernel is time, but I know how to make it fast and robust to move forward quickly.