Dependency Mapping Working Group

:+1:

@abitrolly thanks for the notes. For me I think the conversation went something along the lines of

resolving dependency trees is something we all need to do and a job we can all share

from there we discussed the merits of what we could do with that dependency map, which we decided to ignore as thatā€™s where we all diverged, but we share this core.

Libraries.io was built intentionally to be a central resource that others could build from and extend

was my pitch to the group. Librareis.io is currently under the stewardship of Tidelift who took it on when Andrew and myself joined, but they have done little with it. Some are limited by the rates onthe API, some wondered whether we should fork the project. This is an undertaking and one that has costs associated with it (databases are large and growing) so it is only worth considering this at the point we would see considerable uplift in value. Some did not thing that crossover was yet upon us.

Letā€™s continue to work on our propositions and come together when we feel this pain more accutely.

Was the conclusion that I took from this. @joelwass is happy to continue resolving dependency trees on the fly and taking the hit to do so if needed. FairOSS didnā€™t appear to be far enough along yet for this to be hurting them either. Iā€™m not sure about LibreCelery as Tobias wasnā€™t able to make it, but I beleive the LibreCelery is on pause for the moment.

If anyone took a different reading from the above please do share it. Everyone brings their own interpretation and no one is right or wrong.

Thanks

2 Likes

Iā€™m going to revive this conversation because I few things happened last week:

I noted a request from a colleague re. some dependency mapping projects, and I recalled a bunch of analysis we did at Libraries.ioā€¦ but the pages we made feat

  • ā€˜digital infrastructureā€™ projects with >100k dependent repos
  • ā€˜unseenā€™ infrastructures with 100k+ dependencies and <100 stars
  • bus factor dependencies with >100k dependents and 1 maintianers

I quickly checked and, last month, Tidelift started methodically removing these routes,:

then, later that week I got a note from a Universirty in Berlin who are looking at Libraries.io to help with some of their studentsā€™ research, so I tried to point them at the data downloads that we documented at libraries.io/data

again gone.

Then I read the report from Plaintext group: Securing Open Source Software at the Source

Recommendation 1: Identify and catalog critical software in need of support

and I canā€™t help but think thatā€™s what we built Libraries.io for, and Tidelift are paring it down to be there own little personal library. And I think nope.

So, my question is. Does anyone in this group actually need a resource like this? Because I am pretty sure I can find the :dollar: and the :innocent: to support itā€¦

Iā€™m not sure if Flossbank has a direct need for this (maybe we will in the future) but we build things that the community needs - not just us - so I think weā€™re very interested in reviving libraries.io if the money to support the infrastructure isnā€™t too costly (or can be covered)

We could definitely take care of the engineering aspect. Happy to chat more

For advocacy I am interested to have a single link to such dashboards, and I am interested in mapping all OSS, not just libraries.

Right now Iā€™ve got only GitHub - epam/OSCI: Open Source Contributor Index - which is a dashboard for corporations to brag about how much they commit to open source projects. Which can also be the stats how much open source projects do they own,