3 ms·

> Not your secret sauce Open source your damn secret sauce so other people can improve and benefit from it rather than hoarding it as your precious in a lockbo

by zanny 13y ago

> Not your secret sauce Open source your damn secret sauce so other people can improve and benefit from it rather than hoarding it as your precious in a lockbox like Gollum.

IgorPartola 13y ago
If you can do so without damage. I suspect that if Google opened up their exact page ranking algorithm, the quality of the web overall would drop dramatically for everyone. But for example, if they opened up their home page, or Google Docs people could actually improve upon them with no downside to Google.
- zanny 13y ago
  This assumes, though, that for every exploitable loophole in their page ranking there wouldn't be someone contributing efforts to fix it. I must concede that some of their cleverness is probably exploitable. It is hard to have really accurate searches without some hacks.
- chriswarbo 13y ago
  > I suspect that if Google opened up their exact page ranking algorithm, the quality of the web overall would drop dramatically for everyone. That's only because Google is a single point of failure. They have excellent engineers making their systems resilient, but relying too heavily on a centralised system inevitably amplifies those bugs which do slip through. If Google's code were Free Software, there would be many much smaller, much less stable instances out there. There would be far more outages, but each one would be very minor. Of course, a decentralised Google would be excellent. There are projects out there which try to do this.
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.

by zanny 13y ago

> Not your secret sauce Open source your damn secret sauce so other people can improve and benefit from it rather than hoarding it as your precious in a lockbox like Gollum.

IgorPartola 13y ago

If you can do so without damage. I suspect that if Google opened up their exact page ranking algorithm, the quality of the web overall would drop dramatically for everyone. But for example, if they opened up their home page, or Google Docs people could actually improve upon them with no downside to Google.

zanny 13y ago
This assumes, though, that for every exploitable loophole in their page ranking there wouldn't be someone contributing efforts to fix it. I must concede that some of their cleverness is probably exploitable. It is hard to have really accurate searches without some hacks.
chriswarbo 13y ago
> I suspect that if Google opened up their exact page ranking algorithm, the quality of the web overall would drop dramatically for everyone. That's only because Google is a single point of failure. They have excellent engineers making their systems resilient, but relying too heavily on a centralised system inevitably amplifies those bugs which do slip through. If Google's code were Free Software, there would be many much smaller, much less stable instances out there. There would be far more outages, but each one would be very minor. Of course, a decentralised Google would be excellent. There are projects out there which try to do this.

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.