Sharing FIX Resources in GitHub

The Village Green

Three years ago, the Global Technical Committee decided to open up FIX technical efforts to a wider audience. We wanted to expand awareness of FIX protocols among software developers in the financial industry, and also to solicit their input and contributions.

GitHub is the village green for software developers throughout the world, especially for open-source projects. (Its value was recently affirmed as an acquisition by Microsoft.) GitHub started as nice user interface for the Git source control package, but it has been steadily enhanced with wikis, project management, and other tools. The business model is free use to public projects while private projects pay reasonable fees. Hence, the popularity.

All of our projects in GitHub are under the organization name FIXTradingCommunity — you can see a list of projects on our main page (currently 23 repositories). All of our projects are public, meaning that anyone in the world can view contents; they don’t need to be a member of FIX Trading Community, only have a GitHub user ID.  Anyone can enter issues for bug fixes or enhancement requests, and they can propose changes through what’s called a pull request. Acceptance of changes is controlled by a project maintainer appointed by our working groups.

Tech Specs

The GTC and its working groups have used GitHub projects in a few ways. First, we have composed and edited technical specifications. This is a bit unusual. GitHub is mostly used for computer code. It shows the versatility of the tools, but the main point is social interaction. Specs are now viewed as a collective effort as opposed to a lone person writing a Word document. Some of the technical specs now maintained in GitHub:

  • Simple Binary Encoding (SBE)–very low latency message encoding
  • FIXP performance session layer
  • FIX Orchestra–machine readable rules of engagement
  • JSON Encoding–a FIX message encoding conducive to browsers

GitHub provides  tools to view usage. We can see that the SBE project in particular is catching on.

  • 66 users marked it as a favorite project
  • Over 100 users viewed it in the past two weeks
  • Lots of questions entered recently through the issue tracker.

That’s pretty popular for a spec.

Working Code

We strive to keep FIX Protocol relevant in the face of rapidly changing software world by making our specifications easily available.  Application designers have many choices of technologies, standard or non-standard. One of the best ways to influence the choice is provide a sample application for a developer to adapt and build upon. Therefore, the GTC has sponsored demonstration projects for some of our technical standards.

For Orchestra alone, these demos are provided:

  • A generator for QuickFIX data dictionaries and session configurations from Orchestra files
  • A working domain specific language (DSL) to express when a conditionally required field is actually required or when a certain response is triggered by a FIX message.
  • Validation of a message and population of parts of a message, e.g. an ExecutionReport echoes some of the fields of an incoming order such as ClOrdId and OrdType

Other proofs of concept:

  • Project Timpani: From a browser–without installing any other software–a user issues a SecurityDefintionRequest to a server, which returns any number SecurityDefinition messages for display. Demonstrates JSON Encoding, WebSocket transport.
  • Project Conga (now in progress): high performance trading application (NewOrderSingle, OrderCancelRequest, ExecutionReport). Demonstrates SBE over WebSocket without a traditional FIX engine.
  • Project Silverflash, a reference implementation of FIXP performance session layer

Given the success of FIX standards like SBE, you can expect more to come.