You're conflating encapsulation, OOP and open source. Encapsulation can be done (and is a good idea) in any programming paradigm, OOP or not. For instance, in

You're conflating encapsulation, OOP and open source. Encapsulation can be done (and is a good idea) in any programming paradigm, OOP or not. For instance, in C you can use the static modifier to not expose a function to the outside world, or use a typedef to expose an opaque handle rather than exposing the struct definition in a public header file. In Haskell you can limit which functions and types are exposed by a module as well. These are just two examples: languages that provide no means of encapsulation whatsoever are few and far in between. BASIC comes to mind. Likewise, a closed source component can expose internals in harmful ways and an open source component can over-encapsulate things to the point where it becomes useless for any use case except for a few select ones that the component author anticipated. Of course it's helpful to be able to inspect the source but that doesn't really have a lot to do with encapsulation. (Although it does have to do with the concept of "psychological encapsulation" established in the article.)