What project risk for a tick-data project?

The previous post on this blog kdb+ versus MongoDB versus McObject versus OneTick versus... has spurred some interesting debate.

In one camp is the "established player" school of thought that is really a modern version of "No one got fired for buying IBM".  As such, the only choice for a tick data store is kdb+.

The other camp is to look at the performance per unit cost and see if the software offers value for money. Since Arctic is open source and on github it has a zero price tag attached.

Now, readers of this blog will know that TCO is more important that the vendor price tag, if a piece of open source software has a zero price tag but then requires you to spend a lot of money on hiring developers to look after it then it's not exactly cheap.  Another example - if the code itself if functionally complete but not optimised then it may require more hardware to run than if a commercial vendor had optimised the code.

 

To be clear - this blog is a fan of open source - MongoDB, NodeJS and R to name but a few are part of our daily toolkit. But the metric that people need to look at is TCO, not a vendor price tag.

 

This brings us to risk, the main point of this blog post.  Open source projects often fade away and are left with no current committers.  Of course, one can then "take-over" by forking and creating an in-house version.  But then we reach the problem of "buy versus build" which of course we have already covered here.

 

So rather than look at price tags, we need to look at the decision as a complex package of "real options" around FOSS/possible build versus buy.

 

We'll return to this theme over time...