The Economics of Open Source Payments
Me-as-a-Service is a superior business model to domain-specific software
You wouldn’t eat at a restaurant too embarrassed to let you see the kitchen.
High quality food is made with high quality ingredients. A restaurant would only lock you out if its owners had something despicable to hide.
Software follows the same dynamics. Citibank wouldn’t have accidentally wired $900 million if they had engineered proper automated controls and simple to use technology.
It wasn’t a fat finger. It was software built in a hideous kitchen.
Many companies do not know how to build software that is high quality. But they’d rather have it built by a team of engineers pressed for resources, than using open source software.
Even when there is high quality open source software out there, the fact that it is open is a no-no for them.
They’d rather ship crappy software as long as no one outside can see it.
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Today’s post is the second installment on a series I’ve called A Sketch of a Payment Systems Protocol. You can read the first installment here for free.
Want to be notified when there’s a new post? Hit that subscribe button below.
You know what they say: you can’t have your cake and eat it too.
What it means is that it’s impossible to have two things that are mutually exclusive. It’s a warning against naivete and wishful thinking.
However, it doesn’t always apply. For example, many people believe you can’t have high quality software and not pay for it. 90 percent of software is crap anyways, so it’s reasonable to think that in order to get something in the top 10, you’ll probably have to pay for it, either by licensing or by building it yourself.
Open source companies have proven this belief wrong.
Like in the music industry, it is possible for a tech company to give away some of what its customers are seeking, and make a profit. Software that’s high quality, and free, can be built sustainably.
My policy on cake is, I’m pro having it and pro eating it.
Wordsmithing is not a business
The world is drowning in undifferentiated payment orchestration technology.
These companies have independently built software that does pretty much the same thing. They run into similar problems, are incentivized to fix similar bugs and let similar problems go unsolved.
It has pervasive effects. By design, most orchestration platforms runs into a systemic bug because they support an information flow that’s very fragile:
Most providers, when a merchant sends a payment request, are designed to send the outcome of that request and the acknowledgement at the same time.
It’s obvious to see why: people want to know if the payment went through immediately, and asynchronous processes can be complex to manage.
See where I am going with this? Bundling the acknowledgement and the outcome of the payment hides a fatal flaw: if processing the payment takes too long, the server will time out, and the merchant will never get any acknowledgement of its request.
Importantly, this doesn’t mean that the payment never happened. It means that the merchant never learns about it. The shift of liability gets broken when a timeout happens, and bundling everything on the same response increases the chance that it will happen.
Timeouts make reconciliation impossible.
— Bad API design costs a lot of money. In payments, it's clear why
Why does this happen? I think it’s because these companies see their codebase as the core of their business model, and refuse to let others see it.
But what if it wasn’t? What if payment orchestration platforms were open source companies?
Their users would certainly benefit. So often, bugs or misunderstandings have to be solved by asking around, sending emails, and having patience. Lots of patience. If orchestration platforms let you see their codebases, engineers would be able to look around and find the information they needed on their own.
But orchestration platforms would benefit too! How much engineering time gets wasted giving that kind of support? The optimal amount of email back-and-forth is zero: that’s why most orchestrators have documentation that is clearly written haphazardly, and in a rush.
But most importantly, engineers on both sides would be able to talk code, and subtle bugs would be easier to solve as a result.
The platforms’ belief that codebases are valuable is precisely what prevents them from being more successful.
Zebras and Quality
There are at least two resources that are spent in software. One is time, the other is money.
Money is used to buy the hardware, and pay the electricity to run it. But to build software, you can only use time: that of the engineers. Software is built with time, and is run with money.
Doctors have a saying: when you hear hoofbeats, think of horses, not zebras. It means that rare illnesses are rare. Most likely, symptoms are caused by something boring, not something rare.
In software, the dynamics are reversed. Once a bug is fixed, it’s not going to appear again on its own. Boring bugs tend to decrease over time.
Which means that, in time, the only bugs that remain in software are zebras: exotic, hard to reproduce, difficult to find.
As a result, there is only one way to build high quality software. You ship as soon as you can, and then you find and crush all the bugs in the system one by one.
Software is built with time, and it is run with money. Money pays for running the software and lets you find the bugs.
Time spent in the codebase is the path to high quality software.
Me-as-a-Service
How does all of this get funded?
Another way of asking the same question is: who should spend time in the codebase improving its quality while others benefit for free?
The short answer is: whoever gets paid to do so.
Unlike closed source, an open source payment orchestration library like acquiring is used, is looked at, and is being improved by many companies, rather than one. The increased frequency of improvements will render its closed source alternatives obsolete.
Closed source software doesn’t get improved unless it makes economic sense to the company that built it. But there’s a company somewhere willing to fund a particular use case, regardless of its usefulness to others.
As a result, if open source is useful to you, not “as is”, but adding a particular behavior you need but don’t have the time to implement yourself, you’ll pay money to get it done.
Open source payments can be funded with a Me-as-a-Service business model. You pay for it as long as “as is” is not enough.
Otherwise, permission is hereby granted free of charge.