4 ms·
There are times and places not to do this though. I see business encapsulation as a legitimate goal. the general public should not be exposed to the internals
by einhverfr 13y ago
There are times and places not to do this though.
I see business encapsulation as a legitimate goal. the general public should not be exposed to the internals of your business. They should know what you do and what you can do to help them but they don't need to know all the administrative details. Keep your interfaces with customers clean. That requires not revealing the internals of your business to everyone in the world.
At Efficito, virtually all of our work on LedgerSMB gets contributed back to the community. There is one exception which is not given back for this same reason: We modified LedgerSMB to work ok in a multi-tenent environment.
To do this we did two things. First we enhanced the authentication structure to make it work, and we contributed this work back. However, secondly, we wrote a custom authentication provider to handle the details.
Now, had we wanted to release the custom auth provider back, we would have made some changes in structure. As it is, however, the structure of the auth provider is closely bound to our approach to hosting. Publishing it would effectively ensure that everyone would see our internals, and the benefit to them would be only in cloning our services. The work wasn't significant (maybe 5 hours development time) but it also wasn't generally useful to everyone else.
So we kept it secret. There's nothing wrong with this any more than there is anything wrong with insisting that you don't break encapsulation when doing object-oriented programming.