5 ms·

Open Source Insights

55 points by hasheddan 5y ago

weaksauce 5y ago
looks like a lot of useful information however it's unfortunate they didn't add rubygems analytics and project dependencies as a whole report or api support.
erk__ 5y ago
Pretty nice site the only issue I have is that the Crates.io part does not differentiate between development dependencies and normal dependencies.
swyx 5y ago
TIL you can just look up the personal emails of the entire React core team just by visiting this page now https://deps.dev/npm/react https://deps.dev/npm/react one of the many poor decisions of npm: being completely blase about privacy.
- vntok 5y ago
  Others would call that being transparent and reachable.
  - nighthawk454 5y ago
    I mean, depends on who puts it there? If the contributors list their emails knowingly for that purpose, that's one thing. If a tool leaks your NPM account email, which you have no control over, that's not exactly transparency. You can see the Collaborator's NPM profile, where _they_ can set handles to contact them at. You can also get to their GitHub profile where they also can set handles to contact them at. If the tool made it easier to see those, then great. These emails don't appear to be directly listed on NPM's website. Or correlated with Github/NPM profile. My guess is they're surfacing the email associated with that user's NPM account? Which is not otherwise obviously listed. And the only way you could control it is by also affecting who is an owner of the NPM project itself. If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge, and without any particular way of managing it. Meanwhile they've already listed perfectly good ways of being 'reachable'.
    - NoNameProvided 5y ago
      > If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge When you login into the NPM CLI it printed in all caps that the given email address will be public. I don't like this either about NPM, but it's not like they are leaking in, they are upfront about it and warn you that the registered email address will be accessible to anyone in the package metadata.
      - nighthawk454 5y ago
        Yes, that is totally true. That's kinda what I was going for putting 'leaked' in quotes. It's not really leaked because the data is technically public. You can of course scrape it from say: https://registry.npmjs.org/react https://registry.npmjs.org/react However, it's been made significantly more accessible in a tool like this. NPM doesn't list it prominently in their UI anywhere (I believe). So the 'leak' is up-publicizing data outside of the control of the owner, and when other, intentional (and likely better) alternatives exist.
- mook 5y ago
  That seems to be straight from the NPM feed: https://registry.npmjs.org/react/17.0.2 https://registry.npmjs.org/react/17.0.2 So at least it's on NPM and not this new thing.
ChrisArchitect 5y ago
Title could be better. add "Dependency Graphs". "Dependency Graphs for Open Source packages" or something
belter 5y ago
To the Googler who created this I say congrats on the promotion. To the rest of the HN crowd, I would like to propose a game. You suggest how many months it will take until this will end up here: https://gcemetery.co/ https://gcemetery.co/ The one closest wins. Here goes my bet : 24 months See you all in 2 years or sooner...
- Torwald 5y ago
  22 months
dblock 5y ago
Cool. Ironically, not open-source. +1 on wanting Ruby.
myroon5 5y ago
Similar: https://libraries.io/ https://libraries.io/
- alexellisuk 5y ago
  Funnily enough for openfaas/faas - only the Google product showed dependencies. Both different tools also showed different "dependents" If the exercise is to capture / mediate GPL2/3 dependencies, then having results missing kind of defeats the purpose.

55 points by hasheddan 5y ago

looks like a lot of useful information however it's unfortunate they didn't add rubygems analytics and project dependencies as a whole report or api support.

erk__ 5y ago

Pretty nice site the only issue I have is that the Crates.io part does not differentiate between development dependencies and normal dependencies.

swyx 5y ago

TIL you can just look up the personal emails of the entire React core team just by visiting this page now https://deps.dev/npm/react https://deps.dev/npm/react one of the many poor decisions of npm: being completely blase about privacy.

vntok 5y ago
Others would call that being transparent and reachable.
- nighthawk454 5y ago
  I mean, depends on who puts it there? If the contributors list their emails knowingly for that purpose, that's one thing. If a tool leaks your NPM account email, which you have no control over, that's not exactly transparency. You can see the Collaborator's NPM profile, where _they_ can set handles to contact them at. You can also get to their GitHub profile where they also can set handles to contact them at. If the tool made it easier to see those, then great. These emails don't appear to be directly listed on NPM's website. Or correlated with Github/NPM profile. My guess is they're surfacing the email associated with that user's NPM account? Which is not otherwise obviously listed. And the only way you could control it is by also affecting who is an owner of the NPM project itself. If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge, and without any particular way of managing it. Meanwhile they've already listed perfectly good ways of being 'reachable'.
  - NoNameProvided 5y ago
    > If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge When you login into the NPM CLI it printed in all caps that the given email address will be public. I don't like this either about NPM, but it's not like they are leaking in, they are upfront about it and warn you that the registered email address will be accessible to anyone in the package metadata.
    - nighthawk454 5y ago
      Yes, that is totally true. That's kinda what I was going for putting 'leaked' in quotes. It's not really leaked because the data is technically public. You can of course scrape it from say: https://registry.npmjs.org/react https://registry.npmjs.org/react However, it's been made significantly more accessible in a tool like this. NPM doesn't list it prominently in their UI anywhere (I believe). So the 'leak' is up-publicizing data outside of the control of the owner, and when other, intentional (and likely better) alternatives exist.
mook 5y ago
That seems to be straight from the NPM feed: https://registry.npmjs.org/react/17.0.2 https://registry.npmjs.org/react/17.0.2 So at least it's on NPM and not this new thing.

ChrisArchitect 5y ago

Title could be better. add "Dependency Graphs". "Dependency Graphs for Open Source packages" or something

belter 5y ago

To the Googler who created this I say congrats on the promotion. To the rest of the HN crowd, I would like to propose a game. You suggest how many months it will take until this will end up here: https://gcemetery.co/ https://gcemetery.co/ The one closest wins. Here goes my bet : 24 months See you all in 2 years or sooner...

Torwald 5y ago
22 months

dblock 5y ago

Cool. Ironically, not open-source. +1 on wanting Ruby.

myroon5 5y ago

Similar: https://libraries.io/ https://libraries.io/

alexellisuk 5y ago
Funnily enough for openfaas/faas - only the Google product showed dependencies. Both different tools also showed different "dependents" If the exercise is to capture / mediate GPL2/3 dependencies, then having results missing kind of defeats the purpose.