Musings On Our Open Source Experience

Chris Lees 20th Apr 2018
4 min read

API Specifications FinSpec Best Practice

It’s been over two years now since we publicly launched our FinSpec schema for capturing electronic specifications in financial services, so I thought I would share some experiences on how it has gone, along with my perspective on the overall direction of electronic specs.

First the scorecard for the FinSpec schema — drum-roll, please!

10 watchers + 8 stars on Github, and no real-world implementations (besides our own). Awesome! I’ll be the first to admit that we are a long way from setting the world on fire with this one…

So does that mean we will chalk it up as a failure? Not at all. In fact, this is pretty much what I expected. To understand why we need to look at the two principal reasons anybody open sources anything - crowd participation and interoperability.

Crowd participation is the most frequently-cited benefit of Open Source; inviting others into your team to review, improve and extend your code. This is a benevolent act from the core maintainers, performed for the greater good. It creates code that is more robust and useful for a wider community and encourages re-use. This is a schema and not code of course, but it is reasonable to expect that active participation would include requesting extensions or active discussions about how to implement.

It isn’t a surprise to us that nobody is really looking to comment or request extensions to the FinSpec schema. Why? Because we understand that industry participation in efforts such as this is - and always has been - limited and principally driven by firm-centric (profit) priorities. It’s not limited to standard either. How many times have “customer advisory committees” fallen by the way-side after initial enthusiasm is quickly replaced by falling attendance and lack of preparation? You probably aren’t the first developer to make common tools such as QuickFIX run 10% faster, but think about how much time you could have saved if somebody just contributed that code back.

And while it is entirely depressing to see it, it is also no surprise that developers in banks or software vendors continue to dream up with their own internal, custom electronic spec formats. As you start to explore automating and migrating to more electronic specs, it always was going to be easier to roll-your-own format that you can amend over time, than think about adopting something industry standard.

With so much doom and gloom, why do I still have faith in our Open Source venture? Well, we needed this schema for our own tools anyway, and we thought it may help others if and when they think more about interoperability. While this is very much a waiting game, the fact that we are putting out a viable format at all may attract others to use it when (and if) they realize that their internal format isn’t inter-operable or hits a dead-end. We continue to pour all of our knowledge and experience of how best to represent specs into this schema, so why not benefit from that knowledge?

But can I let you into a little secret? The simple fact is that I don’t really care whether others use FinSpec or not, or any other format for that matter. Why? Because in the “real world” it doesn’t make a material difference to the problem we are trying to solve. I don’t know what the internal structure of a JPG or PNG files is, I just want to see the image. Just as I don’t care how tabular data is stored in XLSX or music is stored in MP3. These things are irrelevant to me as long as I have applications that let me open and use them.

And that is my key point here. The formats are actually completely irrelevant - it is the applications that read and write them that will ultimately matter. These applications will determine whether our industry adopts electronic specs and therefore benefits from improved efficiency and accuracy, or whether we remain bogged down by inefficient and expensive manual processes.

That’s why FixSpec has invested so heavily in making SpecServer the best specification editor we can, and then letting it import and export to multiple formats. That way we can more directly address the real pain-point in the market and help firms be more efficient while also giving them the flexibility and hooks back into their existing systems and processes.

So FinSpec is here to stay, but whether it is widely-adopted or not is a matter of time. Besides, it is essentially free for us to do it, so why switch it off?

PS. If you liked this article then please get in touch, or better still - throw us a star on Github!

Find This Useful?

To receive more tips for improving efficiency in YOUR connectivity process, sign up to our FREE monthly email newsletter.

Awesome - thanks for signing up. You can unsubscribe at any time by simply dropping us a line.