It looks like in 2020 or 2021 I wanted to contribute to shared open source EEG infrastructure and was experiencing dissociative amnesia around the popular toolkit from out of France. Instead I found https://brainflow.org from Russia. I wanted to unify the USB-based drivers to work easily on mobile, and began patching libusb to no longer require root on android by spending the time to learn the android APIs. This was messy and hard for me, and I spent most of my EEG dev effort cleaning the mess up so as contribute my work to libusb, to collaborate. I tried hard to preserve my commits during my laborious transformation of crazy spaghetti to organized interface, but I may not have succeeded. I am not a fan of rebasing due to possible loss of history; I believe the issues rebasing addresses should be interface concerns. Github says an old tip before rebase may have been https://github.com/libusb/libusb/commit/928e2a7f24a161324a46e83b92680e4597ab... . However, this branch contains further work that never made it in and may show similar activity: https://github.com/xloem/libusb/tree/android-dev Anyway, over the course of maybe 2021 and 2022 different people engaged my PR at https://github.com/libusb/libusb/pull/874 dated Feb 12, 2021. Libusb's maintainers were mostly MIA but android projects began using the code. On Nov 1, Google actually finally added a feature to their JNI that I linked to needing in the PR, although making use of this feature hasn’t been implemented, because by that time I could barely psychologically comprehend and engage the work anymore at all, from repeatedly using my coping strategies with it. During discussion of merging with the one maintainer available to reply, one of the things is that a few quirks came up mostly around option handling in libusb. To work around the missing JNI surface that google implemented in November, I had added a new option to libusb to pass a handle in. There were also a small handful of bugs that would be introduced by parallel trunk commits that were in rare conflict. When I engaged these things, even though devs were present, people wouldn’t reply for sometimes months, and there would be demonstration of confusion. Generally work would eventually come from a visitor new to the codebase invested in using things, and still there would be huge communication gaps. One dev began revamping the option handling in trunk in parallel with my work and the work of visitors, as if they did not see it and did not see our comments. A breaking change was left, and a fix eventually merged with my casual involvement, although by then it was very very hard for me to engage. Since I had burnt out, a new PR was opened by somebody else, to rebase and merge my work, at https://github.com/libusb/libusb/pull/1164 dated Jul 11, 2022. Presently still open, looking promising for merging though. Meanwhile, a new release was made that included the option handling code implemented in parallel in trunk. This release unfortunately broke many downstream projects by simply outputting a deprecation warning, and they had -werror. Ongoing at https://github.com/libusb/libusb/issues/1236 . I think what is relevant is my latest comment at https://github.com/libusb/libusb/issues/1236#issuecomment-1406146882 :

With all this attention, it seems important to mention that libusb is badly in need of maintainers. There was almost nobody available to review the change that preceded this issue.

In this email. I possibly meant to include more information on the unique and weird path the watershed breaking change developed via, but I found this difficult and did not do so. In quick summary, it was basically the extent of all my interactions with the project during those two years, issue comments and pull request comments and tagging people, trying to facilitate development ease and engage capacity from those interested, in my strange way amid the strange situations.