Hi Frank, list,
I have circa 9 years experience with the libusb project (ie. the
project that created libusb-0.1, libusb-1.0 and
libusb.org) and
I was asked by two succeeding libusb maintainers to take over
after them.
The first time I declined, because I did not feel that I knew the
code well enough to take responsibility for it. The project went
a year or so without any maintainer, we worked on creating the
libusb-1.0 API during that time. The second time I was asked in
summer of 2010 I accepted, after having spent another few years
with the project.
Frank Buss wrote:
> All these programs, forks and version are a bit confusing. I hope
> the libusbx project will solve this.
libusbx and the people there are rather the problem, not the solution.
(libusb-win32 is also a problem. It always was.) The emperor has no
clothes.
It's well worth to remember, and I think quite telling, that libusbx
very clearly proclaimed themselves to be "a hostile fork" in their
announcement email thread.
Anyway, I wish that you would look more closely into the facts of the
libusb situation. The history is indeed complicated, but if you take
some time to look into it you will have the satisfaction of knowing
what really happened, as opposed to knowing only what others say.
I can tell you all that you would ever want to know and more, but I
think it's much better to read independently and form an own opinion.
The libusbx people are quite persistent with propaganda and self-
promotion, and my time is simply too limited to fight lies, name-calling
and ad hominems all over the internet, while at the same time working
with untainted downstreams (one libusbx maintainer is a Red Hat employee
and most distributions switched to libusbx when he switched the Fedora
package source) as well as doing qualified user support and training,
and sometimes even working on actual code. I spent well over 1000
hours on libusb-1.0.9 over the course of circa two years. All of my
libusb work is voluntary.
I have high standards. The vocal majority on the libusb mailing list
disagree with this and want a feelgood sense of progress, regardless
of quality. None of them produce significant amounts of commits. Few
of them produce any commits at all. I naïvely tried to reason about
this, but that of course only made things worse.
There are many reasons for my high standards; part of it is that I
am uninterested in dealing with many users experiencing some problem
if I could preempt that by being more careful during development and
review (one-to-many benefit), another part is that I feel that it is
our damn responsibility to produce the very best quality software
that we can possibly accomplish since we are in the privileged
position of being able to create software which the entire world
can reuse.
Especially with open source I do not accept that deadlines should be
a driving factor, because deadlines will always result in mediocre
quality. We can do better than mediocre as a community, but obviously
people will also have to wait longer to get something that they can
try out, if they will not get anything at all until something exists
which is good enough to actually perform reliably.
Experience shows that almost nobody shares my values, libusb only
drives every printer, scanner, digital camera and MTP or iPod MP3
player on every Linux system in the world, and none of those things
are very important. Some of the medical systems might be, though.
People get frustrated, scared, angry or annoyed when I tell them that
I think that they can do even better than their first try. That's sad,
but all I can really do is to continue working according to my own
standards and keep rejecting mediocrity. Maybe some day someone will
appreciate that.
Please excuse this digression, as you may understand this is a topic
that I care about, and I believe that I have unique experience from
being the maintainer of libusb for several years and having been with
the project for such a long time, but I also don't want to go too far
off topic on this list. If you or anyone else wants to discuss libusb
with me, please let's do so privately or maybe on IRC.
If you feel like debating with me, please first have a look at this:
http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of-debate-550x417.jpg
This list is about FPGALink, so let's get back on topic:
I'm a big fan of LPC1300, they're really cute controllers! I'm happy
to hear that you're working on adding support for them in FPGALink! :)
The LPC11U24 and other LPC11U controllers will probably work without
significant changes to the code. Awesome!
But is LPCOpen really the very choice? FPGALink is clearly a very
open source project. LPCOpen not so much. The LPCUSBlib license with
its restriction on use with NXP Microcontrollers is pretty daft, and
a polar opposite of an open source license. The only "open" about
LPCOpen is four letters in its name, I'm afraid - there aren't even
Makefiles for building with GCC.
I for one don't think this is such a good fit in a real open source
project such as FPGALink. I'd welcome suggestions for other sources
of a USB stack. I've taught several workshops with the LPC1343 using
modified code from 32bitmicro's old GNU toolchain port of NXP
examples, but that code isn't so much better from a licensing point
of view.
I would very much welcome ideas for how to easily improve this. Maybe
it would actually make sense to write a simple replacement for the
NXP code, it's actually not doing all that much..
Hoping for good ideas
//Peter