Blog by Sumana Harihareswara, Changeset founder
Libraries.io and the Infrastructure of Hospitality
Hi, reader. I wrote this in 2018 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.
So many times in my life in open source tools and platforms, I've run into the following problem:
We want to make a breaking change/prioritize work/get feedback.
Let's check with our downstreams.
How do we find and communicate with them?
Uhhhh.
We have stopgaps inside the application (like in-app and in-API messaging, Wikipedia banners) and outside (like creating users and announce mailing lists, publicizing social media broadcast venues, searching the web/GitHub for projects and people that mention/import our tool and pinging them personally).
Now, Libraries.io makes it way easier to be hospitable to my downstreams.
I co-maintain Twine, a utility that many developers use to upload packages to PyPI. We released 1.11.0 in March. The Libraries.io page about Twine shows me who's using it (see the screenshot on the left), and I can dive deeper to check who's pinned to an old version so I can ping them to check what's up. (Sometimes that conversation tells me about a problem in our upstream dependencies that I didn't know about.) If I want to survey some users to find out whether a particular breaking change would hurt them, this makes it way easier to find some representative users to ask, not just the power users and enthusiasts who take the initiative to reach out to me.
Libraries.io has an API so I could even automate some of this. And libraries.io covers npm, CRAN, PyPI, RubyGems, Maven, and a bunch more package managers across different languages and frameworks, so I'll see downstreams that aren't just in Python.
And the code is open source in case I want to understand how they rank projects in search results or add tox.ini support in their dependency checker.
I started drafting this post in March, and in the interim, I did a little paid work for Tidelift, the company that stewards libraries.io. So, disclaimer, I'm a bit biased now. But I thought libraries.io was supercool before Tidelift and I ever thought of working together. I'm glad the Ford and Sloan Foundations funded the initial version of this tool and I'm glad Tidelift is funding and using it now; it's already very useful, and I see it as part of the infrastructure that lets maintainers and users understand each other's needs.
