SustainOSS Media as a Product

In invisible world of digital infrastructure, the survival of people and projects depends on the visibility of meta issues that happen with people and projects. Visibility allows these issues to be fixed. The journalist approach would be to write about it constantly, and the product approach would be setting relevant metrics and tracking them.

My personal story this month would be I personally have is the lack of reviews/merges for https://pypi.org for more than half of a year. The reason I guess because people are people, they want to be in control, they don鈥檛 like to be forced, and they can not and do not feel like solving conflicts. That鈥檚 why we have forks in Open Source. There is no single truth, single source, single repo. Forking is a way to solve conflicts.

Now we are talking about infrastructure. We have https://pypi.org and due to the reason how economics work, it is probably the only reason why Python Software Foundation is sponsored. Much like NPM and others. I can鈥檛 validate this assumption. I just guess. To validate I need to compare $300000 that were donated just for PyPI with total donations to PSF. Some donations are probably funds to develop specific features, some maybe only for maintenance, but who am I to taks to foundations? I can鈥檛 even find the right mood to mince my words to speak with people so that they won鈥檛 break. And that鈥檚 why I came here. To see if SustainOSS can help. And it could help if it could be an Open Source Media Product, that also resolves conflicts in addition to be publishing platform.

You know, in traditional media business you have these actors, TV personalities and the ability to choose channels if you don鈥檛 like it, but even if you put them in the open, ask questions about areas they have no experience with, they would probably also show their other human sides, which is - being opinionated, offensive in their views, awkwards, religions, whatever. You can exploit their human qualities to cancel them. But in our world we don鈥檛 have other people except those who are already open. Code of conducts, rules, bans, they all about desire to ignore this nature. But if there is a thing that can help bring up conflicts and solve them, then we could bring open source collaboration to a new level.

I鈥檓 not sure I understand your concern. Are you saying that you submitted patches to pypi and these are not being reviewed?

When I managed the OpenStack community, I dealt with multiple cases where the interests and priorities of maintainers and contributors clashed for disparate reasons. In my experience, there is no way to solve these issues without looking at the details.

Well, it all started with this PR - Extract and host wheel METADATA on upload by abitrolly 路 Pull Request #9972 路 pypa/warehouse 路 GitHub - which is the 3rd top voted feature among issues. I was trying to solve dependency resolution problem for Python and found that pip downloads huge archives from PyPI just to parse the metadata with dependencies and versions from there. If packages in metadata doesn鈥檛 meet currents constrains, pip downloads other versions until a match is found. In case of Tensorflow each version is 400Mb+ archive. Considering how many people are trying Python solely for learning AI, that鈥檚 a huge waste of traffic, so I expected $300k sponsors to the project and PyPI maintainers to be interested in solving this problem. But after some initial comments nothing is happening. In the end I got completely ignored even for PRs that Fix broken development setup by abitrolly 路 Pull Request #10469 路 pypa/warehouse 路 GitHub

I see鈥 Waiting over 4 months for a patch to merge is frustrating. I鈥檓 not very familiar with the way PyPi organizes its development. With OpenStack, each project held a weekly meeting online on IRC, at different timezones to accommodate participation from the east and west of the world. Also, much of the tech leaders hang out on IRC and can be asked to provide feedback on merge requests. During the IRC meetings it was possible also to ask for a slot to further discuss features. And ultimately, OpenStack held quarterly in-person meetings among developers. Additionally, a mailing list was available to further discuss a PR.

All these would have been great opportunities to iron out differences of opinion, gauge the importance of the patch proposed, rally support from other community members.

Usually, the problems I saw were caused by reviewers being busy with other priorities. It鈥檚 as simple as that: it鈥檚 not your patch the problem nor lack of money. The problem most likely is the fact that your patch is not included in a roadmap yet. This is not a problem that money can fix: my experience tells me it鈥檚 a maintainer bandwidth issue, a release management and project management issue.

When problems like this increased too much in OpenStack, we introduced processes to debate features before they came in as proposed patches. That way a release manager would know to allocate precious review time to the features that were planned for the release.

Is there a way for you to engage with other PyPi developers and users that is not on GitHub? IRC or voice chat? Can you think of the root cause that is preventing the tech leads of PyPi to take the time to fully review your patch?