If you want your OSS to be Exceptional, it must be the Exception (chasm series, part 8)

Standing out in a highly saturated and fragmented OSS market can be really difficult. We’re regularly involved in bake-offs where we see dozens of OSS compared against each other.

We’ve recently been involved in one with 10 making the short-list for further analysis. All 10 are the best in class (for this client’s unique needs anyway) but are all variations on a common theme:- similar functionalities, comparable pricing and similar estimated delivery timelines. More or less the same. More or less the same capabilities. More or less the same price. More or less the same level of benefits. More or less the same decision barriers and implementation risk.

They all fit within the familiar parameters that have come to define this segment of the industry. But what if we dared to diverge from this path? What if we created an OSS that doesn’t merely replicate existing frameworks but instead aims to be exceptional? What if we completely reframed what is important for this type of OSS (eg. what would have to happen for you to deliver in 2 months instead of 9 months? Would that give you a competitive advantage?)?

You’re right. That decision would be hugely risky for the product builders.

Seth Godin eloquently articulates this disruptive notion in his recent blog post, entitled, It just barely works.”

The first Wright Bros. plane just barely flew.

The first version of VisiCalc was just barely useful.

The earliest bridges were shaky, unreliable and made of vines.

The secret of successful product development isn’t an innovation that bursts forth as a polished and finished product. Instead, it’s sticking with something that is almost useless, nurturing and sharing and improving until we can’t imagine living without it.

Imagine an OSS that embraces this radical re-framing. Initially, it may appear less complete than its counterparts.

When clients expect perfection, as they often do in the telco / OSS industry, it’s a huge risk deciding to deliver something that’s unpolished / unfinished. It essentially discards the existing asset (the current code-base) that the OSS vendor has invested so much in developing. It’s like knocking down an old house to build a brand new, but initially incomplete, barely livable one.

However, could you also ponder – what’s the bigger risk – to build something that is the exception but has the possibility of it not being adopted by the market; or to be custodian of an incrementally evolving OSS that is barely distinguishable from 9 others (and by the law of averages only wins 1 customer contract out of every 10 bids)?

This is where the chasm between buyer and seller comes into play again. The current bridges that are designed to cross the chasm between buyer and seller are engineering marvels – elaborate, sophisticated, expensive, time-consuming systems designed to span the trust, risk, skills and other gaps. With suitable reframing, can we reduce the size of the chasm and therefore simplify the mechanisms required to bridge it? What if we design solutions that don’t span the chasm in better ways, but bring the sides of the chasm (the buyer and seller) closer together?

This new solution doesn’t work like the others, it doesn’t look like the others, It’s not as complete as the others. It’s building the new green arrow that solves the age-old problems in entirely new ways, by re-inventing the 80% of functionality that most moves the needle for the client. It’s the exception.

We are at a fascinating inflection point, probably the most important in my career to date, where the age of artificial intelligence (AI) is firmly upon us. The lead being shown by the LLMs empowers us to rethink our OSS from the ground up, moving away from the outdated models that have governed our industry. Models where we’ve needed to design heavy business logic layers and the cumbersome UIs that have been necessary to drive the logic.

Generative AI solutions have shown that the need to create OSS tools with all logic “baked in” can potentially be replaced by simpler, more conversational reasoning UIs and business logic layers. It allows us to design systems that are not just functional but are totally reframed to be an exception from all others… until the others also follow your lead to remain competitive.

However, there is a window of opportunity / arbitrage for you to be exceptional. How long that window remains open depends on the other vendors’ tolerance of risk. As we said above, choosing the exceptional pathway would be hugely risky for the product builders. That can work against you (when being the first to take the leap of faith) but also work for you (when the other 9 vendors are potentially paralysed by the fear of taking the same leap of faith to re-invent their existing, undifferentiated product).

Just one last thought to leave you with before throwing it over to you for comments:

You do get to choose whether you’ll be the exception (ie do things differently to the others), but only the market will decide whether you’re exceptional (ie stand apart from all others).

Okay. Over to you? What are your thoughts?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

A million words about OSS

Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words.  And that’s

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.