Original Announcement
From: Tom Lane <tgl@netcom.com>
Newsgroups: misc.invest.technical
Subject: Request for Developers: Financial Data Server/Database
Date: 08 Mar 2000 16:12:45 -0500
Hi folks,
My company is considering releasing as open source some software we've
been developing and using in-house. What we've got is C/C++ code for
reading a real-time financial data feed (such as S&P Comstock, Reuters
Selectfeed, etc), parsing the feed to extract the interesting data,
making live data available to applications, and accumulating historical
data in a tick/intraday-bar/daily-bar database.
We've been using this stuff in a production setting for about five
years; it is robust, well wrung out, and *fast*. (We routinely collect
ticks for the entire NYSE and AMEX, plus a lot of domestic and overseas
futures markets. During trading hours, the data parser uses under 1% of
the CPU of a 75MHz HPPA RISC box. The available commercial equivalents
we've heard of would be choking on this load on such a slow machine,
even if they had it all to themselves...) We use the code ourselves on
HPUX and Linux; it should be possible to port to most flavors of Unix.
However, we are a small shop, and we've never had time to flesh out
the code to do more than the bare minimum that we needed in-house.
We are wondering if there is interest out there in extending the system
to handle additional data feeds, connecting it to industry-standard
application APIs like TIB, collecting fundamental data (earnings &etc)
as well as current prices, writing better documentation, building nicer
administration tools than we have, porting, etc etc.
Thinking in blue-sky terms, it might be possible to adapt the code to
collect non-financial time data series, such as manufacturing process
control data, realtime experimental results, or what have you.
I see from perusing SourceForge that there's already an open-source
project (Real Time Data Server, http://www.paritech.com.au/rtds/) with
goals similar to what this code does. But they appear to want to build
something from scratch, and in any case we have different ideas about
licensing --- I think a BSD-like license is preferable for this project,
since the code will need to work with proprietary applications. The RTDS
folk evidently want to use GPL and try to navigate around its "viral"
properties.
If you have the skills and interest to work on this, please contact me.
At this point we are just testing the waters to see if we could attract
enough help to justify giving up proprietary control of our code.
Regards,
Tom Lane
Director of R&D
Structured Software Systems / TREE Capital Management