In article <977 at biosys.apldbio.COM>, james at apldbio.com (James Candlin) writes (with stuff
deleted ...):
|> ... Applied Biosystems has several products which compete directly with
|> some of the commercial software products mentioned here. ... it's true that
|> we do want to recuperate some of the support costs of maintaining the file formats and
|> associated access software from other commercial suppliers. On the other hand,
|> we do support in-house, non-commercial developers free of charge, and we absorb the
|> consequent costs, because we do want to encourage innovative software development
|> that adds value to the instruments without cutting into our market for software
|> products.
The problem is that ABI software (like all software) is often deficient in several ways.
The initial version of the Inherit Assembly program, for example, was almost unusable.
Although the assembled sequences were very good (among the best of 10 different assembly
programs I've examined), the editor was hopelessly cumbersum -- it took almost 13 minutes
find and fix 8 errors in one assembly, as opposed to 45 seconds with Sequencher. Their
more recent version, AutoAssembler, has a vastly improved editor, which is similar in
design to that of Sequencher. Now, there is the *perception* that ABI is modifying, and
de facto encripting, its code so as to break other programs. This strikes people as
unfair and potentially detrimental to their science. Compression is obviously useful,
but ABI should certainly tell people which compression algorithm is being used.
...
|> >The problem here is that ABI don't give out details of their file formats;
...
|>|> We don't do this because we regard the file format as fluid. The purpose of the
|> libraries is to isolate application software from improvements elsewhere in the
|> system. This design is simply good software engineering practice. We use these
|> libraries internally in our own application software, and they are no different from
|> what anyone else gets. It'd be hard to support direct use of the file format within
|> our own development efforts, and it'd be a nightmare in the larger community.
|>|> This is an development perspective rather than a product marketing one, but I hope
|> it helps to provide some of the missing context in this discussion.
...
Certainly no one should question ABIs right to modify their file formats for the
purpose of adding value to their product. I have deep problems if the purpose is to
gain a monopolistic lock on the market. ABI can easily release the file formats with
a big disclaimer noting they can be changed at any time without notice. The
compression method should be disclosed or the ability to uncompress one's data should
be added to the software.
As a scientist, I demand to have access to my raw data. I would be very hesitant
to buy an insturment that outputs heavily processed data (as the ABI trace files are)
without being able to access my raw data (the chromatogram profiles are much different
from the final trace profiles).
The above views are strictly my own and do not necessarly reflect the policy of the
NIH or the Federal government. I have no association with either Applied Biosystems or
with Gene Codes Corp., except as an occasional beta tester of their products. All
miss-spellings in the above text are also strictly my own
--
______________
Mark J. Miller phone: (301) 496-9343 or 496-5688
Building 12A, Room 2033 fax: (301) 402-2867 or 496-0734
National Institutes of Health Internet: mark at helix.nih.gov
Bethesda, MD 20892
