[Openocd-development] ftd2xx -> libftdi

[Zach W. <zw...@su...>]

Hi all,

Having had time to reflect quietly about the FTD2XX situation, I have
started to grow concerned about the numerous options that have been
proposed to address the FTD2XX distribution issue.

All these efforts -- in N directions at once -- most trying to solve one
single problem, and this issue is not even central to our in-tree code.
Except for the socket driver, the rest all seem like workarounds for the
proper solution.  Only libusb+libftdi serves our long-term interests.

What other solution offers as much value -- in the _strategic_ sense of
that word?  All of the other ideas are short- or medium-term fixes,
designed to workaround the fact that the free software solution cannot
provide parity with the proprietary driver today.  

If that sums it up, we have the source code for libusb and libftdi along
with the impetus to top its performance.  The free libraries can
probably surpass the closed driver benchmarks over time, and it can be
distributed with OpenOCD when linked as a static binary.

Furthermore, we could be exploiting the "many eyeballs" phenomenon, when
we appear to be doing the exact opposite: N solutions, each preferred by
their own followers for individual reasons.  There is nothing "wrong"
with everyone doing their own thing, by the way.  This is simply my
observation of our situation, meshed with experience from the matrix of
open source and free software universes (i.e. the bazaar).

Let me go through the solutions again, this time classifying each
proposal as a workaround or long-term solutions, with pros and cons:

Short-term:
0) documentation: in-tree recipes for building on all platforms
   - Pros: no code!
   - Cons: ditto
1) build kit: automatic building tools
   - Pros: distribution-compliant, developer-friendly
   - Cons: needs full toolchain; not good for windows _users_
2) ... (still pending approval from the FSF) ... (compliant???)**
   - Pros: user-friendly, ....
   - Cons: slow, non-standard, yuck, yuck, yuck ;)
3) libftdi+ftd2xx+wrapper: ABI compatible with libftdi to wrap ftd2xx
   - Pros: a low-hanging fruit
   - Cons: still uses FTD2XX (not GPL), requires separate install,
           may be hard to emulate libftdi with proprietary library

Middle-term:
4) socket-based driver:
   - Pros: nice to have anyway... binary distributable!
   - Cons: performance hits?

Long-term:
5) libusb+libftdi: *** in theory, should be the best
   - Pros: can provide full performance, and best binary distribution
   - Cons: Windows-only problems?  no experts?  no specs?  it's hard?
6) FTDI releases FTD2XX under BSD/LGPL/GPL-compatible terms
   - Pros: easiest technical solution
   - Cons: hardest legal solution

If we are pursuing all of these at one time, our collective resources
are not being used efficiently.  It's nice to see all the activity, but
I think we could make more productive use of our collective time.  Now,
I am *not* asking anyone to change what they are doing, but "what if"
_everyone_ just buckles down and focuses on fixing libusb and libftdi? 

As I said at the start of all of this, this option seems like the best
use of the community's resources:

(a) It will be the best contribution to the free software community.
(b) We would start to leverage the "many eyeballs" phenomenon here.
(c) We should be able to make it outperform the closed implementation.
(d) It removes all doubts about binary distribution.
(e) All of the above -- these each bear reading again.

After the weekend, I will try to put a list of outstanding problems with
the free solutions in the TODO list, because this is where I want to
focus my own attention in these matters.  Others appear to be pursuing
the socket-driver approach, and there is little point in duplicating
that work.  I now want to show that the free solution will be superior.

Developers: are there others that want to follow this same path?

Users: I think _your_ best solution is a free one, for the reasons that
I have given but deserve to be restated here clearly:

1) FREE allows a _single_ binary installer to deliver *all* components, 
   without entering into any GPL-compliance gray areas.
2) FREE *may* be made to _outperform_ the closed solution, 
   but we *can* make it perform _equally_ well.
3) FREE *will* be supported _better_ by the community and contributors.

Distributors: do you want to deliver this solution to your users, if not
today then someday?  Will you contribute to making it happen?  I have
done USB, async I/O, and reverse engineering; I can fix the performance.
Windows fixes must be obtained elsewhere, as I don't use that; however,
any engineer with similar experience and confidence could do both tasks.

Cheers,

Zach Welch
Corvallis, OR

** If the FSF is responsive to other inquiries, but fails to respond to
my inquiry about a loophole, is that a tacit confirmation of it? :)