[crazy] I was involved in a core libusb change that broke many projects.

[Undescribed Horrific Abuse, One Victim & Survivor of Many]

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/928e2a7f24a161324a46e83b92680e4597ab717a
. 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.