Arch Linux

So the libusb release made on 2012-04-20 was magically two years ago?

Which "fixes" require you to use libusbx?

Don't be fooled by the recently done libusb-1.0.9 release, that was done by the libusb-1.0 maintainer *after* the libusbx fork was announced and had already done 2 releases.

What is an actual issue solved by libusbx that is present in libusb?

Hi, I'm the libusb maintainer. libusb has no actual issue which libusbx solves.

On 2012-04-19 around 4 am local time I had included all patches I could find into libusb, and went to rest, hoping for some feedback during the day.

Six hours later libusbx was announced with 1.0.10 being the current version. libusbx version 1.0.9 had been made internally as a "feelgood release" for the project participants.

When I saw the fork announcement I went to compare libusb code with libusbx code and found that libusbx had some 20 useful commits besides what was already in libusb.git, and I of course reworked and picked those into libusb.git right away. I then made the libusb-1.0.9 release, in the morning of 2012-04-20.

Indeed libusb-1.0.9 was released some hours after libusbx was announced. If I had done a release instead of pausing for some feedback then it would have been the other way around.

The libusbx maintainer Pete Batard (who is also the author of the libusb-1.0 Windows backend) wrote in http://marc.info/?m=133522749907137 "the prime reason we forked is because, under Peter's sole guidance, we very much think libusb is not going anywhere" which is pretty clear I guess.

I'm just happy that there is finally a git branch somewhere that is close in file contents and commits to libusb.git master. For a long time that was unfortunately not the case, which of course meant that being the maintainer required a lot more effort than one would wish for.

I'm happy to spam various links to discussion about the fork from back when it happened, but I'll try to write some kind of post about it instead, and just add a single link to that.

In any case I am continuing work on libusb, and as I wrote in an email right after the fork was announced I expect that both libusb and libusbx will pick commits from each other. The code is nearly identical so there is actually little if any technical reason to choose either one over the other.

(libusbx-1.0.11 does fix a bug on Windows which is present in libusb-1.0.9. The fix will of course be included in libusb too, but isn't relevant for Linux.)

Hi,

As one of the maintainers of libusbx, I guess I'll bring in some additional points, the first one of which being that a vast majority of existing libusb contributors have been involved with the fork in one way or another, which should be a strong sign that, despite the statement above, libusb does have very serious issues that cannot be resolved.

Some of the most damaging of these, to highlight a few, include leaving libusb users stranded without a release for 2 years, which we feel is both unacceptable and unjustifiable, months passing by before contributions were being looked into ...if at all, detrimental wrong calls, arbitrary decisions (such as patches being single handedly pushed without any form of review) or focus on elements that did not serve users by the maintainer(s), as well as complete refusal by Peter, who has been the sole project maintainer for the past year and a half, to share power, despite multiple qualified candidates willing to help.

As such, despite a lot of effort by many to try to bring the project back on track, and because we were met with what can only be described as a strong desire to maintain absolute authority on the project, we have had no choice but to create a fork. We also believe that anybody who spends more than a few minutes looking at the history of libusb or its release cycle is likely come to the conclusion that it is indeed not a healthy project and should better be avoided when a better solution exists. For instance, with libusbx, we very much intend to provide a project that is more in line with the core values that libusb has strayed away from, and that have made the success of FLOSS, such as Release Early Release Often, flexibility, and a strong willingness to place users' requirement/requests above the predetermined vision of any individual.

As to the diverging of libusb and libusbx, as one may expect, the differences between 2 branches of a fork right after it occurred are always minimal. However, the situation is already changing rapidly, with libusbx and libusb expected to become incompatible in terms of features, patches or anything that isn't related to the preservation of the existing 1.0 API, as the latter is about the only part we plan to keep untouched. For instance, we have already started introducing major incompatibilities in the Windows backend, with HID support (a feature that Peter strongly opposes), and we also recently introduced new topology calls to our API, that libusb may or may not carry. We also tend to be more proactive with regards to the inclusion of fixes, as well as produce out of band releases when critical ones occur.

As time goes by, this makes it a lot more likely that patches from one of libusb or libusbx will not automatically find their way into the other, with the result being that the choice to go with libusb or libusbx will carry stronger consequences for users.

Finally, as we are trying to be more open than libusb, I should probably point out that we have an explicit roadmap (https://sourceforge.net/apps/trac/libusbx/roadmap) which anyone can consult and provide suggestion for, as well as invite people to also check out the project repositories, as it should already demonstrate that libusbx tends to be a lot more proactive than libusb.