What is an OSStracod?

Back on my first OSS project – all the way back, deep into the annals of time – the year 2000 to be exact, I was lucky enough to work with a really tight delivery team. We all lived in the same hotel in Taiwan and took taxis to work together. Each morning I’d read Dilbert in the newspaper. It seemed like every single day’s cartoon was written based off our team’s recent experiences on that project. Almost every episode was shared with my taxi-mates. I’m sure there were many confused taxi drivers in Taipei who were left wondering why a bunch of crazy Aussies had burst into tears of laughter reading the cartoon section of the paper.

The point is, Dilbert was never about OSS, yet always seemed relevant. The same goes for Seth Godin. As a renowned marketer, he probably has no awareness of OSS, yet his articles are often so prescient for our industry. I often borrow his quotes or article snippets. Today I’m going to borrow an entire article below (you can find it here):

The ostracod is extinct. Over millions of years, with good reasons at every step, it evolved to become the creature it was.

And when we add up all of those little steps, we end up with a creature that was no longer fit for its environment.

Organizations develop like this. So do work practices, cultural systems and “the way we do things around here.”

I’m sure there was a really good reason twenty years ago for all the steps that are now involved in the thing you do right now, but your competitor, the one who is starting from scratch, is skipping most of them.

Every day we get a new chance to begin again. And if you don’t, someone else will.

I’m currently working on two projects relating to inventories of the future and another report that’s due imminently about exciting innovations in the OSS / BSS space.

Inventory is our OSStracod. They’ve evolved over the last million years (or so it seems), with billions of developer hours invested as little steps. The little decisions made twenty years ago are baked into the solutions we work with today. Our OSStracod has two familial branches – the vendor inventory solutions and the service provider inventory stacks. 

Both branches have long and distinguished evolutionary histories. The accumulation of many little steps. However, in many cases, they are creatures that are struggling to fit into a changing environment. In addition, as we know, inventory transformations can be incredibly challenging, to the point that they’re scary to even contemplate.

Some people have even told me that inventory solutions are no longer relevant, that virtual infrastructure managers have abstracted away the need for these hard-to-perfect beasts. I’ve countered that they do remain very relevant.

Yet we stand at a real inflection point. Inventories of the past were built upon relational databases to manage networks that were largely “nailed up.” Inventories of the future will build upon the strengths of newer database models like graph and time-series, whilst also managing highly dynamic networks of greater size and scale.

And these are only the tip of the iceberg of architectural advantages awaiting a competitor starting from scratch today. Is today the day you decide to begin again, or do you continue to make incremental evolutions to your OSStracod and build on its proud ancestry?

I don’t envy anyone having to make that decision, so let’s close with a relevant Dilbert cartoon:

2 thoughts on “What is an OSStracod?

  1. Lol, “all the way back, deep into the annals of time” I really enjoyed reading this post and to humorously echo the context of the OSStripod I shall now term the practice of documenting an OSStripod as a OSSoscopy.

  2. hehe! Glad you saw the humour in this post Denny. I had a smile on my face when writing it. Many fun (and funny) times on OSS projects. With 20+ years in the game, I’m sure you’ve collected a lot of funny stories along the way too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.