The Reddit blackout is a lesson in risk management

Joe Mainwaring - Jun 16 '23 - - Dev Community

This morning I ran headfirst into the picket line for the Reddit Blackout which hindered some research I was doing into a technical solution.

Image description

While I empathize with the impact to indie devs and SMBs dependent on the Reddit API, I can't support the protest. Reddit's API is not a public good; we are not entitled to freely access it. While I could cite capitalist talking points to support my position, I'd rather focus instead on a different narrative, one which I suspect is underestimated by many indie devs and SMBs - risk.

Risk Management

Risk Management was originally defined as part of the ISO 31000 Standard and can be summarized as:

the identification, evaluation, and prioritization of risks, followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events, or to maximize the realization of opportunities.

For mature technology companies like WorkTango, we are required to invest in Risk Management, and one way we meet this obligation is by maintaining an artifact known as a Risk Register. A Risk Register is a ledger which captures all of the criteria outlined in the definition of Risk Management. We add to this register as risks are identified, and engage in a quarterly exercises to brainstorm new risks. This provides the business as a whole with an understanding of potential risks for resource planning (feature development) and strategic decision making.

So why bring up risk management and the risk register in the context of the Reddit Blackout? If WorkTango was in the business of creating a client app for Reddit's platform, we would have identified Reddit's free API as a dependency risk.

Dependency Risk

Dependency Risk is a category of risk you take on whenever you have a dependency on something (or someone) else. When we build client apps wholly dependent on a third party platform, a dependency risk is created. That third party could cease operating, or as both Reddit and Twitter have demonstrated, stop giving away their resources for free.

Open APIs are free, as in beer

As a developer, it's best to think of Open APIs as free, as in beer:

  • The API resource (beer) cost you nothing
  • But APIs aren't free, somebody paid for the API (reddit)

The 2010s was a golden age in capital investment and the technology industry benefited significantly, enabling a lot of free resources as a draw to build audiences and engagement. However, the 2020s so far have proven to be more challenging. Money is no longer free and as a result, many companies are having to mature their business models to be more self-sustaining. This means reducing expenses and finding additional sources of revenue. Monetizing previously open APIs is an unfortunate intersection that addresses both needs. Expect less free beer on the internet as we progress through these tougher economic times.

Mitigating the Risk

The only way to mitigate a dependency risk is to add a layer of redundancy, but when you build apps on top of platforms like Reddit or Twitter; you can't fail over to a different platform to access the same content. So how would I mitigate this risk?

  1. Accept that if this risk is realized, it's game over for the app. Since I do not own the backend which my app depends on, losing access to it means my app can no longer function. Draw up a plan to wind down the product gracefully in the event this risk is ever realized.
  2. Diversify. If I can't prevent a game-over situation, the next best mitigation strategy is to diversify my revenue streams. That means building a second app on a different platform (ex: slack app), or building an app without the platform dependency risk. That way, if I lose one app, I take a financial hit, but hopefully the other app can support myself while a new app is conceived to replace the lost revenue.

Did you find this post insightful, or perhaps you disagree with my risk points in regards to Open APIs? Share your thoughts in the comments below.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .