I agree.

A large library represents a large attack surface and likely on features that are not even required.

Case in point; I developed an API for my company's products for logging. Some of the newer employees couldn't fathom that I would write anything to do with logging. After all, there's many different libraries out there already. This is true, of course, but my API acted as a façade for the functionality that we actually needed. Thus, we could have unit tests that proved the functionality that we actually needed, worked the way we expected. Any library could be used to implement the different behaviors.

The benefits; we were not tied to a specific library or implementation. In some cases we would implement our own functionality. We were always covered for regressions. We didn't have to worry about some open source guy making a change that violated our functional requirements, or introducing a new bug. Our client code didn't have to give a shit about different implementations, due to the abstraction.

The downside of this approach was that if a library implemented a great new feature that we decided we wanted, we would have to extend our façade, but actually that's not such a big deal. It's consistent with our philosophy of not coding for the future (that future may never come).

Another down side is that even though we essentially abstracted away the possible use of features that we didn't need, if a security issue was identified in a library component, our new age build processes would require upgrading, even if the feature with the security issue was not being used. To that end, the isolation we achieved through the abstraction was still subject to involuntary changes of underlying components imposed by carte blanche security policy. But at least we still had automated tests to ensure that our own feature requirements were met.

Having that ability to sleep at night is key for me. Having to worry that some open source library is going to fuck something up, or make a design decision that fucks up our products, is not my idea of fun. But apparently many think it's the only way. I think maybe I have been in the game too long!

I agree.

A large library represents a large attack surface and likely on features that are not even required.

Case in point; I developed an API for my company's products for logging. Some of the newer employees couldn't fathom that I would write anything to do with logging. After all, there's many different libraries out there already. This is true, of course, but my API acted as a façade for the functionality that we actually needed. Thus, we could have unit tests that proved the functionality that we actually needed, worked the way we expected. Any library could be used to implement the different behaviors.

The benefits; we were not tied to a specific library or implementation. In some cases we would implement our own functionality. We were always covered for regressions. We don't have to worry about some open source guy making a change that violates our functional requirements. Our client code didn't have to give a shit about different implementations.

The downside is that if a library implemented a great new feature that we wanted, we would have to extend our façade, but actually that's not such a big deal.

Another down side is that even though we essentially abstracted away the possible use of features that we didn't need, if a security issue was identified in a library component, our build processes would require the upgrade, even if the feature itself was not being used. To that end, the isolation we achieved through the abstraction was still subject to involuntary changes of underlying components imposed by security policy. But at least we still had automated tests to ensure that our own feature requirements were met.

Having that ability to sleep at night is key for me. Having to worry that some open source library is going to fuck something up, or make a design decision that fucks up our products, is not my idea of fun. But apparently many think it's the only way.