Here's your "FEA is complex" response
There are two major things to think about when it comes to FEA: capability and user-workflow. I would argue that the capability is (largely) available in the open-source domain. It's the user-workflow that's hard. For instance, there are some groups who need to work on large complex midsurfaced assemblies that are integrated within a sophisticated PLM system that provides material models etc. There are others who work with voxelized MRI data, some who receive facetted models (e.g. STL from a surface scan). Some groups need to link multiple simulations together to model an entire part's manufacture from bar-stock through forging, cutting, welding, assembly, and use; and other groups that just need to compute a simple eigenvalue result. Some groups prefer to model changes in boundary conditions within separate "steps", while others prefer monolithic steps with wide variations in boundary conditions. Some groups want to run on a single computer, others need to run on a 100-node high-performance computer while others on a super-computer. Some groups have simulations so massive the only way to visualize full-body data is via
in situ visualization (see Catalyst), while others eschew visualization altogether in favor of "probe" data. Some groups prefer to use "general contact", while others require specific "surface-to-surface" pairs. Some groups want to model a weld via "element activation" whilst others use might use activation of tied-contact. Some customers are fine using quadratic tetrahedra, while others need to devote months to building a high-quality hex mesh. Some people want/need to write their own PDE to solve, while others just want to solve standard elastoplasticity. Some people think we should call them "displacement" or "temperature" boundary conditions, while others would call these "Dirichlet" boundary conditions. Some people want fracture solved via element deletion, others via J-integral crack opening, and others via phase-field fracture.
These things (and more) reflect different user wants and imply workflows and I think it's been hard for the open-source community to "decide" on a specific workflow and UX. Some of the best cases of good "full-package" FEA softwares include Calculix (replicate Abaqus workflow) and Salome Meca (meant for the open-source Code Aster code designed for nuclear reactor efforts in France). Notice that both of these are pretty focused in their scope / workflow.
But I do think the open-source community is
exceptionally rich & mature in FEA workflow building-blocks. Consider the following
partial lists:
FEM Preprocessing: CodeAster, CalculiX, ONELAB, Computational Model Builder, FreeCAD
FEM Meshing/Discretization: TetGen, Gmsh, fTetWild, Sigma|MeshKit, SAMRAI, libCEED
FEM Solvers/Frameworks: FEniCS, MOOSE, MFEM, ElmerFEM, Sparselizard, OOFEM, FEBio, deal.ii, FreeFEM, CalculiX, Goma, Nalu, GetFEM++, Hermes, NASTRAN, pyNASTRAN, Albany, JuliaFEM, Firedrake, libMesh, LANL FEHM, Truchas, Tusas, ExaConstit, libROM
FEM Equation Solvers: PETSc, Trilinos, XBraid, SUNDIALS, Hypre
FEM optimization: DAKOTA, OpenMDAO, hiop, Ceres Solver
FEM Post: ParaView/VTK, GLvis, VisIt
And even: "the open source computer aided engineering Linux distribution CAElinux."
And this list doesn't even include things like threeJS, OpenGL, etc.