Surface
- Yogesh Jadhav
- Apr 1
- 2 min read
Have you ever encountered a project developed using numerous dependencies sourced from multiple locations? Developers include multiple #OpenSource libraries in dependencies without realizing
Who maintains the library?
Under which license, the code is being released?
What is the release frequency?
Are there any key-man risks associated with the project?
What are the motives behind publishing the source code?
What is the sustainability model for the project?
How frequently vulnerabilities are identified and fixed?
Which transitive dependencies that it rely on?
Are these dependencies riddled with incompatible Open Source licenses (e.g. MIT with GPL)? If compatible, start with question one for each library.

Do you find these questions are often responded with a long pause OR some brave souls may say - If it is open source it must be good OR look at the stars. This inexperienced behavior will result in nothing but putting the customer's business at utmost risk. Without realizing production grade systems require a perfect blend of many key aspects, can seriously expose applications to many vulnerabilities (well it's not just security but longevity).
Open source is not a problem here, but a decision not backed by rationales. Merely based on what I know, or what I am comfortable with leads to poorly implemented solutions. Solutions developed on such hypothesis often lead to inefficient runtime performance, applications runtimes laden with vulnerabilities, poor developer experience, lack of tooling support (debugging, performance tuning), conflicting dependencies, countless hours spent solving build issues, monkey patches, and list will go on.
Hackers love applications with dependencies sourced from multiple locations. Bigger the surface, higher the chances of finding vulnerabilities. Hence it is vital to adopt an ecosystem that is empowered to address concerns in a reliable manner. Open source organizations like Apache, SpringSource, Jboss, etc. have the foundations built on a solid understanding of business needs. It doesn't mean the source code released by these organizations is free of any issues listed above. However, the ecosystem built on years of trust, well-defined guidelines, and backed by the strong consortium, ensures timely response to mission-critical problems.
As an architect, what do you think about your software dependencies surface? Is it built on a solid ecosystem OR feel-good acronyms?
Comments