Re:On Internal Engineering Practices at Amazon
by jacobparker on Wednesday March 27, 2019 @07:07PM
(#19507174)
There's some public documentation on the "one version" policy here: https://opensource.google.com/docs/thirdparty/oneversion/
Re:On Internal Engineering Practices at Amazon
by nerdponx on Wednesday March 27, 2019 @09:21AM
(#19500538)
This all sounds like justified inconvenience in the name of safety at scale. As long as you have a good relationship with the package approval guys this is a fine workflow in my experience.
Re:On Internal Engineering Practices at Amazon
by jrockway on Wednesday March 27, 2019 @10:10AM
(#19500913)
Yeah, I thought it was fine (I was both a reviewer and a user).
I mostly posted to provide some contrast to the folks that are saying things like "there are too many open-source libraries and they need to be approved to make sure there aren't any security problems", which is not what we did. We did not attempt to limit the use of libraries, nor did we vouch for the security-readiness of packages before they were allowed to be checked in to source control. If you think there are too many npm libraries and are looking for an example of a big tech company saying "no more!", this is not it. Use all the libraries!
We suggested that people get security reviews, but it was up to the user of the package to figure out whether or not that was necessary. Often security reviews would be blocking the project's launch and would be done at that time.
The final thing we enforced was a "one version" policy. If everyone was using foobar-1.0, and you wanted to use foobar-2.0, it was on you to update everyone to foobar-2.0. This was the policy that people hated the most, but basically mandatory at the time because none of the languages widely used at Google supported versioned symbols. Having library A depend on foobar-1.0 and library B depending on foobar-2.0 meant that application C could not depend transitively on library A and library B at the same time, which would cause many disasters.