IS NOW THE TIME FOR

OPEN SOURCE IN CTRM?

WHITE PAPER
Commodity Technology Advisory LLC, 2014
Introduction
IN THIS COMTECH ADVISORY WHITE PAPER, WE
TAKE A LOOK AT THE CONCEPT OF OPEN SOURCE
SOFTWARE IN COMMODITY TRADING. IN DOING SO,
WE ARE ASKING THE QUESTION, WHY HAS THIS
APPROACH NOT YET BEEN TRIED? AND IF IT WERE
TO BE TRIED, WOULD IT HELP? THE WHITE PAPER
IS REALLY DESIGNED TO FOSTER DEBATE AROUND
THE TOPIC AS OPPOSED TO TAKE A STANCE ON
THE ISSUE ONE WAY OR THE OTHER. ACUTELY
AWARE OF THE MANY CHALLENGES FACING BOTH
USERS AND VENDORS IN THIS FAST MOVING AND
COMPLEX BUSINESS, COMTECH ADVISORY IS
ALWAYS INTERESTED IN PURSUING RESEARCH
INTO HOW TECHNOLOGY ADOPTION MIGHT BE
IMPROVED. THE QUESTION POSED BY THIS
WHITE PAPER IS SIMPLY THIS IS NOW THE
TIME FOR OPEN SOURCE CTRM?
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
IS NOW THE TIME FOR OPEN
SOURCE CTRM?
Its also true that as the sof tware category has
grown and we estimate its a $1.6bn industry
this year some vendors have thrived and now
have triple or double digit million dollar revenues.
Vendors such as OLF, Triple Point (acquired it-
self by ION last year), Allegro, SunGard Energy,
Brady and EKA are all reasonably sizable com-
panies but there remains a whole raf t of smaller
niche vendors happily serving specific needs, ge-
ographies, or commodities, both small and large,
across the breadth of the market.
New or old, every one of these vendors initially set
out to do something unique. Each markets them-
selves as being somehow different and better than
those that have gone before cheaper, faster, more
sophisticated, more reliable, faster to implement
and the list goes on. In fact, by building on the latest
available technologies, they may indeed be an ad-
vancement of the state of the art in CTRM technolo-
gy. However, at their core, each and every new prod-
uct that comes to the market starts by dening and
modeling the same basic components of commodity
trading. For example, to simply capture a deal in a CTRM system, the
following information (and more) must be dened in the code and input
by the user:
Here we are in 2014, almost 20-years after the ETRM and later, the CTRM, software categories were invented and
in some ways, very little has actually changed. Yes, there has been some vendor consolidation, but for every vendor
and solution that has been acquired or gone out of business, at least one new supplier has consequently emerged.
We seem to have been writing that there are over 70 vendors of E/CTRM software for the last 10-years at least
and its true there really are that many in the CTRMCenter software directory. In fact, we have found and added
3-4 new ones this year alone!
/ commodity
/ counterparty
/ contract
/ deal
/ term
/ deal type
/ price
/ volume
/ location
/ facility, such as a pipe, wire, truck, train, vessel; each with a number
of other attributes that have to be defined and coded
Every new system that is brought to market starts out with a database
that is that actually the vendors interpretation of very common attri-
butes and sub-attributes such as names, phones numbers, email ad-
dresses, physical addresses, currencies, and the list go on. So why are
vendors constantly recreating the wheel of commodity trading every
time a new product is launched?
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
NO COMMON LEXICON
Anyone that has tried to integrate two different sys-
tems from different vendors, or has tried to move
data from a system from Vendor A that is being
replaced to a new system from Vendor B will have
encountered the impact of these different views; and
if a system was actually found to move transaction-
al data across, it will almost certainly have required
hundreds or thousands of hours of human interven-
tion to reconcile the differences between the two
systems. This is why it is exceedingly rare for any
software customer to move historical transactions
from one vendors system into another.
Given this lack of a common lexicon for
commodity trading systems, every system in use to-
day reects the denitions that their developers un-
derstood based upon their specic experiences; or
that they otherwise believe will be either easiest to
code or will best reect what their prospective cus-
tomers may want to see. This means that is unlikely
that any two systems will reect a singular common
understanding of the market. The result is that every
system, though they may use similar languages and
terms, reects a unique way of capturing very basic
and fundamental information that is otherwise com-
mon to the industry.
Part of the reason is that while you can nd dictionary denitions for each of these attributes, there is no common
lexicon across the commodity trading industries. For example, a deal can mean buying or selling, to a counterparty,
a specic volume of a specic commodity on a specic day, and at a specic point; or it could mean a buying or sell-
ing to a counterparty, a specic commodity at multiple locations, each with a different price across multiple days,
weeks or years. This difference, while not appearing on the surface to be consequential, actually has fundamental
implications on the way the deal is priced, tracked, valued and settled within a software system.
This lack of a common lexicon reected in the underlying
data structures leads to wasted time and resources by both the soft-
ware vendors and the users of these systems. The vendors recreate
what has been previously built by their competitors as they build-out
this code, and the customers are forced to learn the unique methods
and data structures used by the vendor in order to build and maintain
complex integration infrastructures to move data in and out of the sys-
tem, or to even develop reports that detail the deals and transactions in
the system.
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
SO, IS THERE A BETTER WAY?
WHAT WOULD OPEN SOURCE IN
CTRM LOOK LIKE?
Each company would contribute their interfaces
and other improvements into the product (inci-
dentally, you can still nd the code for EnyWare
here: www.sourceforge.net/projects/enyware).
TradeWell would make money by selling support,
much like Redhat maintains a supported version of
Linux. While the company ultimately wasnt success-
ful due to limited funding, the vision of open source
in ETRM/CTRM is probably even more intriguing
today.
Just what would happen if one of the new
or existing ETRM/CTRM vendors decided to throw
their product, in a stripped-down or basic version,
out into the market for free as open source code?
Certainly, most trading companies, regardless of
whether or not they are currently using some other
vendors product, would want to see what its about
At most, we would expect any CTRM packaged
solution to be only a 70% to 80% t to any individ-
ual companys requirements. This means that every
installation has, by necessity, a high proportion of
and would probably bring it into their shop to take a look at it. If the open
sourced product was able to address the fundamental needs (like con-
tract and deal capture) of enough market participants, and had a clear
and easily extendable architecture, then it is certainly conceivable that
more than one would think about what they could do with iteven per-
haps up to replacing their expensive vendor supplied systems. Others,
including those that didnt have a system or were looking to replace
their existing system, would be remiss if they didnt at least take a look
at how they could use it, and in the process, save a signicant amount of
money on the front-end by avoiding the license fees that normally come
with such systems.
Should such a scenario play out, it would certainly disrupt the
CTRM software industry. Instead of building new products from the
ground up, software vendors would need to concentrate on developing
the tools and capabilities that ultimately distinguish one vendor from
another things like sophisticated analytics, regulatory reporting and
complex multimodal logistics models.
custom add-ons, components and other functionality. Vendors have to
target a large enough portion of the available market to sustain them-
selves by building in signicant congurability and personalization in or-
der to avoid a good deal of specic client customization but, at the end
Several years ago, a company called TradeWell Systems sought to launch an open source version of their ETRM
integration product, called Enyware. The vision of the companys president, Andrew Bruce, was to provide an open
source product that, once interfaces were developed to the various ETRM/CTRM products commercially available
at the time, the market would quickly adopt as a standard integration hub for the industry.
The idea that each market participants needs and therefore their installation, is essentially different and hence, this
cant be seen as a true package market, is an idea we have expressed on many occasions over the years.
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
of the day, it still is less than a 100% t to require-
ments. In following this approach, vendors struggle
to build out, on top of their own version of their indus-
try model, a complete multi-commodity, multi-geog-
raphy E/CTRM solution; and as they build out this
blob of functionality on that unique interpretation of
the industry, it becomes harder and harder to main-
tain and support. We have seen this so many times
in the past that it is old news. Eventually, legacy
vendors and products lose their agility to react and
adapt to market changes or developments, and in so
doing, an opportunity emerges for ve guys in a ga-
rage to build a new solution on the latest technical
platform and off we go again.
So to revisit and rephrase the question posed earlier, What
would happen if someone started giving away their source code in the
same way that operating systems like Linux, DBMS technologies like
MongoDB and even predictive analytical tools like R, are given away?
Theres no question that a disruption in the ETRM/CTRM software
market would occur and that some vendors might not be able to react
quickly enough or appropriately. However, as proven by RedHat and
others, there are other ways to make money with open source software.
Late last year, for example, MongoDB Inc. raised $231 million, and be-
came the rst billion-dollar open source startup. For the existing CTRM
vendors caught up in a wave of open source adoption, quickly accepting
and becoming expert in the new standard would be key. This would
allow them to rapidly produce and implement new components that
would reach and capture a very large and emerging market.
NEW SOFTWARE APPROACHES
IN CTRM
Weve previously noted that true SaaS CTRM is
actually a very rare thing; even for those customers
with only the most basic functional needs, as very
few companies are comfortable having their data in-
termingled in the same instance as one of their com-
petitors no matter how secure the environment is,
or how many checks and balances have been built
in. Rather, we see CTRM adopted as hosted in the
cloud (meaning that rather than all clients use the
same software, each client is using a different instance) and almost cer-
tainly utilizing some degree of customized functionality.
After all is said and done, this type of deployment hasnt really
changed the dynamic of the industry, as much as it has changed the
way that companies pay for their software and receive support. Thats
not say that the model isnt working, it certainly is and for a variety of
other reasons, cloud-delivered software will grow. Its just that it doesnt
actually solve the myriad of fundamental issues around E/CTRM soft-
ware that weve discussed above.
The CTRM space is already seeing the advent of fresh ways of delivering software to this marketin particular, via
the cloud. However, we are not totally convinced the cloud will do much to fundamentally change the nature of this
market when it comes to addressing the shortfall in capabilities experienced by software users.
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
HOMEGROWN SOFTWARE
MAKING A COME BACK?
BUT OPEN SOURCE?
The trend has been conrmed by head hunters who
tell us there is a great job market developing among
the companies that have turned to in-house develop-
ment to meet their specic needs. While these com-
panies can nd specic point solutions to address
individual commodities or classes of commodities,
they have little condence that a vendor supplied
solutions will meet their requirements.
To some extent, this trend can be seen as a
step backwards, swapping lower cost and increased
In effect, the industry has at times, perhaps unwit-
tingly, irted with this model via industry consortia
such as EFETnet in Europe and GISB in the USA.
However, none of these efforts actually resulted in
open source applications being developed.
While an open source CTRM may seem un-
likely at least in the near-term, we suspect that such
a model could result in a number of positive devel-
opments for users, including faster development of
convenience for a better t to requirements. Certainly, it is not an option
open to the vast majority of companies that in one way or another trade
commodities and require a solution. Arguably, the market is growing
as regulations in particular net increasingly smaller commodity traders
who in the past may have been more than happy to rely on spread-
sheets or some other cost effective, but difcult to audit, approach. In
this regard, cloud-based and other non-traditional deployment options
are likely to be very attractive.
new and richer functionality, the ability to better interface and integrate
with other applications and potentially the development of new, indus-
try-wide capabilities such as standardized and efcient networks for
deal exchange, conrmations, scheduling and settlements. The most
agile and forward thinking vendors would continue to thrive by assem-
bling branded applications that build upon the open source core capa-
bilities, and could better differentiate themselves from their competition
by focusing on delivery of sophisticated tools and analytics.
As buyers realize that perhaps there simply isnt a packaged solution that will t the majority of their complex
requirements, homegrown development is once more gaining in popularity; especially among larger companies in
areas like agriculture and softs where there are a plethora of niche solutions but few that can meet the specic
requirements of a shop that trades a broad range of commodities.
So what would happen if we all simply recognized that every customer is different? What if the industry, both
users and developers, launched an open source library that everyone contributed to? Would this work? Would it
spell the death knell of the vendors in the space?
Commodity Technology Advisory LLC, 2014
A ComTech Advisory Whitepaper Is Now the Time for Open Source in CTRM?
OF COURSE, IT MIGHT NOT WORK
As weve noted many times before, there is no one
size ts all solution in the CTRM markets. If large
number of companies, spanning different markets
and commodities, starting pushing additional func-
tionality back into an open source product to meet
their specic needs, the product may become too
bloated and complex for those companies seeking a
cheap and easy solution to address their limited re-
quirements. As these smaller or even mid-sized com-
panies turn away from adopting open source CTRM,
the product could lose support; Without constant
improvement and continuing adoption, open source
products can simply fade away, abandoned in repos-
itories such as SourceForge and forgotten by almost everyone except
those that were the early adopters. And for those early adopters, should
that happen, the once promising vision of a shared solution would be-
come the reality of just another custom developed software program.
Open source software is also not without its own set of admin-
istrative and support issues, including availability of quality technical
support, code quality, documentation and licensing terms. All of these
potential issues would need to be addressed very visibly and with a
guarantee of some sort of governance by the open source community
in order for the industry to even look at such an initiative. Plainly, open
source may not be a panacea of good things for the industry but the
question remains is now the time to give it a try?
It could also be argued that an open source strategy in this market is destined to fail, either by not achieving enough
adoption (companies with regulatory or shareholder exposure are historically suspicious of freeware, particularly
for critical systems), or perhaps even falling victim to its own success if there were widespread adoption of the
opensource product.
ABOUT
Commodity
Technology
Advisory
LLC
Commodity Technology Advisory is the leading analyst organization covering the
ETRM and CTRM markets. We provide the invaluable insights into the issues and
trends affecting the users and providers of the technologies that are crucial for
success in the constantly evolving global commodities markets.
Patrick Reames and Gary Vasey head our team, whos combined 60-plus years in the
energy and commodities markets, provides depth of understanding of the market and
its issues that is unmatched and unrivaled by any analyst group.
For more information, please visit:
ComTech Advisory also hosts the CTRMCenter, your online portal with news and
views about commodity markets and technology as well as a comprehensive online
directory of software and services providers.
Please visit the CTRMCente at:
19901 Southwest Freeway
Sugar Land TX 77479
+1 281 207 5412
Prague, Czech Republ i c
+420 775 718 112
ComTechAdvi sor y. com
Emai l : i nfo@comtechadvi sor y. com
www.comtechadvisory.com
www.ctrmcenter.com