TLDR
Tools for software engineers aren’t restricted by licenses and are good, leading to an acceleration of their industries.
Mechanical Engineering software is good, but limited by restrictive licenses with only bad open source alternatives. This prevents Mehcanical Engineers from building great things outside of work (in Open Source land).
The Stone Ages
Where would the machine learning industry be today if Python was paywalled like Matlab?
Would we have self driving cars if the computer vision community’s tools prevented commercial use?
The Current State
I’m trying to build some Open Source Hardware projects.
It’s been very difficult: https://ondroid.ai/devops/mechanical/cadPackages/
It should be difficult for technical reasons, but it’s difficult for operational reasons.
It took months just to spin these projects up to a point where others may be able to contribute — the Mechanical Engineering DevOps side has been a disaster because of restrictive licensing and poor product development.
Example: How do I share a Stress Analysis?
Working with other engineers on analysis is a core part of engineering complex mechanical systems. It’s already difficult in offerings you’ll find in a typical engineering office because we can’t have engineers work concurrently (Except if you’re working in a quip or Google sheets document, but still, not ideal).
For developing an Open Source project, this limits us almost exclusively to open source alternatives such as LibreOffice. I think you can get away with Google Sheets, but versioning control on something like this seems night-marish.
The method I’ve developed for my Open Source Hardware projects follows something like:
- Install Python
- pip install jupyter mkdocs-materials mkdocs-jupyter
- Run analyses in Jupyter Notebooks
- Install and Configure MKDocs in GitHub repository
- Supplement analysis with Markdown in MKDocs that link to the Jupyter documents (analysis)
This is partly painful because it assumes the engineer knows how to use Git, Python and write code (most do not).
Licensing ~= Interoperability
The lack of interoperability between engineering software is not a bug, it’s a feature.
Dassault knows that ISO standards in the STEP file format do not transfer history based feature definition of CAD models.
Ansys knows they have no obligation to make your decades of analysis using their software transferrable to your next FEM software provider.
The lack of interoperability is used against us as a tool to keep us locked into the ever worsening pricing schemes. This is probably not a new concept to you, but what is a new concept to me is the idea that this has literally driven a worsening of the mechanical engineering discipline as a whole.
I can’t send you my hand calcs because you use Google Sheets and I use Quip.
I can’t send you my static structural single part FEA because I have Ansys and you use FreeCAD.
This leads to soloed engineers, a lack of openness and communication, and a world that can’t build on the shoulders of the previous giants.
Science and Engineering is only possible via those shoulders.
Hence my original questions at the beginning of this article — what would the ML industry look like if this were true for them?
What would it look like if every software engineer had to build TinyGrad from scratch before committing their first real line of code?
FreeCAD Software Does not fix the CAD Problem
FreeCAD is unusable for complex mechanical design and assembly because of its deviation away from Mechanical Engineering practice to focusing on Parametric modeling instead of robustness and usability.
There may be hope, but I’ve spoken to the creators of Ondsel (a potential savior of FreeCAD) and they do not have plans to implement these direct modeling tools.
Even in the best case that the Free software catches up, we’re still half a decade away before it’s implemented reliably. This issue isn’t limited to CAD either — FreeCAD FEA is pretty good for single parts, but it’s still at least a decade away from having the multi-body assembly simulation ability of tools like Abaqus ($10,000/year).
How to Fix it
- Enable enterprise registration on open source projects (not a big deal, I think most people would be happy to do that)
- Track usage (already happening by the cloud based providers) and correlate it to pushes to a repo. This can be easily automated
- If a certain percentage of the work being generated ends up on the repo, leave the project alone
- If not, kill the license
Why is This Hill to die on?
The things we Engineer today are more complex than they have ever been, and that trend will only continue upwards. Complex systems require complex and distributed teams of people.
Complex engineering is bottlenecked by a singular restriction: communication.
We can’t communicate if we all use different languages. (Solidworks, Ansys? Catia, Altair? NX, Cadence?)
This means we can’t engineer complex systems outside of work — and even then, it’s still painful at work because licensing incentives drive a lack of interoperability.
