I wanted to ask the group if there would be interest in a new working group around open source project dependency mapping. There is a lot of the great work going on with this topic with lots of different goals, approaches, and lessons learned. I think there is an opportunity to consolidate the conversation and work together.
I would love to facilitate this, would anyone be interested in joining?
Happy to join these conversations, thanks for facilitating
There is a lot of conversation on the topic of dependencies in the CHAOSS Risk Working Group. Feel free to check out the meeting minutes and join upcoming meetings.
The Risk working group meets every other Monday at 9:00am CT (usually 16:00 CET, check your local time) via Zoom – Agenda and Meeting Minutes
Info about working group: https://github.com/chaoss/wg-risk
Great! @GeorgLink that’s good news and I might join one of those coming up since risk is definitely a key theme.
I do think a separate group focused on the mapping would be fruitful for a lot of people. There are several companies / tools trying to work in this space (Backyourstack, Flossbank, FOSSA CLI, synopsis, Scarf, etc…), it would be nice to see if there is room to make this a collaborative project.
At FairOSS, we can get a certain distance with identifying top level dependencies through Q&A with the company but down the tree is another story.
@RichardLitt I know this post is new, so I’ll let it marinade for a little. Let me know when you think there is enough to get going. Thanks all!
Tidelift is using dependency analyzer as well. Not open source as far as I remember. A lot of work for open source dependency tracking is made by maintainers of various Linux distributives. https://repology.org/ in particular does a good job of tracking various packages, like adding a missing package index for PyPI.
Or do you want to map dependencies to particular people and their well-being?
The solution of Tidelift is actually FLOSS:
I used the search engine for https://opensustain.tech/ and https://github.com/protontypes/LibreSelery quite a lot.
https://libraries.io/ shows info about software included in different repositories, but doesn’t provide a dependency analyzer to check your own project.
In the LibreSelery project we combined the following projects to get a very powerful OSS dependency scanner that is platform-independent:
It works perfectly across all package systems supported by the Libraries.io API.
Being transparent, some of FairOSS’ interests in dependency scanning are:
To be able to identify top level open source dependencies within the walls of a company so we can allocate equity to them in our ledgers. Not all of the open source tools that companies use are available in public repos. This may be a standalone tool.
To be able to map dependency relationships to a scope that makes sense (i.e. where do we stop, at the OS, hardware, etc…). Along with our equity allocations, this would help us begin to expose a fair market value for a given project.
I would think the first meeting or so would be to set the ground rules and objectives for the working group. I’d be curious to know what others’ goals would be.
Those sound like the perfect items for a first meeting, to me. 
I believe in the long term this goes contrary to the transparency goal you’ve mentioned. When companies silo developers from participating in open source financially, it erases the connections within the community, and creates a market for various open core initiatives, which are still vendor locked to single entity controlling source code and the communication behind it.
An alternative to that, is to let developers identify the dependencies and help them grow to be responsible.
This is not entirely true: GitHub - librariesio/bibliothecary: đź“” Libraries.io Package Manager Manifest Parsers
@abitrolly The lines between communities and companies are symbolic and I think there is a lot of overlap. FairOSS would love to influence more community-driven open source and expand the opportunities for people to make a living in it. We are still figuring this out though because you also have companies that ARE essentially open-source projects.
So there is definitely a company dependency scanning angle and I think what you’re hitting on is what project governance’s interest in this would be. For us, we think that projects should manage their contributions like a company manages the equity they grant their employees (e.g. called cap table), and that maintainers would do this for their contributors and their upstream dependencies. We have some basic thoughts about this at the moment for projects but think that dependency scanning could help here too. All the more to define a focus for the working group
Maybe you’re right. When I took a look at the list of Tidelift supported packages, I saw it is much bigger than in Bibliothecary README. I didn’t realize that the entries are specific packages and not just package managers.
Tidelift is said to use core chunks for parsing from bibliothecary, but if I understand AGPL right, the Tidelift service that uses chunks of AGPL code should also be open source, and there are not forks of Bibliothecary at Tidelift · GitHub
I disagree with that. Community is just a bunch of people, who don’t easily change their preferences because of market or change in management. Symbolic lines may happen for small family business, but on a scale corporations are not humane. I speak from my experience dealing with Epam and Wargaming.net - despite of brilliant people working there, there is little really that they could do to foster community like culture there. Lack of understanding and resource allocation inside gave birth to service companies that do “community building” events that have that same bitter taste as a political astroturfing.
Thanks for your perspective, and one that I would like more insight into particularly if you have a background in Economics. Would be open to a chat if you had some time, DM me if you’re interested.
probably worth someone looking into that… 
Hey fam,
This is my first post on sustain oss and I’m on mobile since I just received elbow surgery so bear with me if I make an user error.
(Thank you Benjam for the loop in)
I’d love to join a working group from Flossbanks perspective. We are almost exclusively working on dep graph mapping to ensure we distribute donations appropriately down the entire tree. Our open source repository is Here. We have JS support as it’s easiest (npm), we’re working on python (pypi) and ruby right now. The idea is that anyone can use this resolver to resolve a map of the entire dep tree as well as the “weight” of each package. I can go into further detail on how this works if anyone would like.
Thanks for setting this up Russell!