[abharya]

This is still an early project to start somewhere.

We are working on this problem as well. Trying to identify dependency trees and which smaller projects are the most widely used (indirect deps) and will impact the most on the critical projects in the list.

[vlovich123]

Don’t get me wrong. I appreciate this work and it’s super important if you get it right. I’m worried the first step is drastically in the wrong philosophical direction as far as the metric itself goes.

If you’re just proving out the tech then do that but the current publishing of the most “critical” projects is laughably wrong (as I’m sure you’ve heard from the comments on the page). The project isn’t a dead end but any attempt to use the data right now to drive decisions is a lost cause. Maybe you have some secret sauce that makes it work better for internal Google projects but if that’s the case that methodology should be published as well so that people can get an understanding of how Google uses this more effectively.

I’m just contrasting this to a paper Google published recently about how to measure uptime more effectively in cloud. Every step of that paper was eminently approachable and didn’t have any obvious philosophical flaws that stood out to me (we can argue about them but any potential arguments were called out).

Again, I applaud the attempt. This is a super important problem and trying to tackle it is laudable. Getting the right metrics is crucial and this is being released far too early with a presentation that makes it seem far more complete than it is.