Managing Software Dependencies

Software introduces similar long-term challenges, that are often overlooked at the start of a project. Choosing actively maintained software components is often more important than whether they are open source or commercial. Both can provide excellent long-term value when backed by sustainable organisations and clear maintenance strategies. When evaluating software, engineers should consider several factors:

  • Is the project actively maintained, and by whom?
  • Does the licensing model remain suitable for the intended product lifecycle?
  • How quickly are security issues addressed?
  • How many additional dependencies are introduced?

The last question is frequently underestimated. Modern software frameworks can introduce hundreds of transitive dependencies. Including an entire framework solely to support a single file format or utility function may unnecessarily increase maintenance effort, software size, and long-term risk. By contrast, a careful modular design based on minimal packages pays off quickly.

„Own your interfaces by separation of concerns.“

Hardware abstraction deserves the same attention in software architecture. While proprietary programming frameworks such as CUDA can provide excellent performance on supported hardware, they also create dependencies on a single hardware ecosystem. Open standards such as OpenCL or SYCL may offer greater flexibility when long-term portability is a primary design objective, even if they require additional engineering effort or involve performance trade-offs.

Growing Importance of Software Transparency

The upcoming Cyber Resilience Act (CRA) further increases the importance of understanding software dependencies. Software Bills of Materials (SBOMs) are becoming an essential tool for documenting the components contained within a product.

Seiten: 1 2 3