In defense of thin wrapper startups

All platforms start as simple features.

The story of Linux – the most popular open-source operating system (OS) – is a telling example.

In 1991, Linus Torvalds, then a college student, described the initial version of Linux in a forum post:

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones … I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want.  Any suggestions are welcome, but I won't promise I'll implement them :-)"
- Linux’s History

The early version of Linux was dead simple: a combination of an existing command line tool (bash), an existing compiler (gcc), and a way to run multiple tasks on the same CPU. Some would have called Linux a thin wrapper around bash and gcc.

It's hard to foresee the future impact of simple tools — especially ones built on nascent technology. The history of software products is littered with many such examples. Here is a fun way to observe this phenomenon: pick your favorite software platform and use the Wayback Machine to view its landing page from when it started. Here is Twilio’s — famously a thin wrapper around Verizon and friendly web development syntax.

While all platforms start as features, not all features become platforms. How can we distinguish between an idea that could become a big platform and one that will forever remain a feature?

There are the usual platitudes: work on something people want, build in a big market, ride a new technology wave. 

I have come to appreciate a more subtle reason that has nothing to do with the specifics of an idea but everything to do with the people behind it. Intensely curious builders have much higher odds of building a platform. This is because platforms are discovered, not built — and discovery follows curiosity. The most promising sign of intense curiosity is an unreasonable amount of detail about a problem space. Back to Linux, Linus’ early interviews are filled with many tiny and detailed frustrations of an OS called Minix that inspired him to build Linux. I particularly like this nugget about how the keyboard bindings in Minix partly inspired the project that would later become Linux: 

“Getting Minix wasn't a pleasant experience: the keyboard bindings were wrong, and it didn't exactly act like the suns I was used to (I *hate* the bourne shell for interactive work). The keyboard was easy to correct (although I didn't like the Minix keyboard driver code) … So somewhere around March-91, I had a 386 [Intel processor] system running Minix-386, and I was able to install awb's gcc-1.37.1 port. After that, I was able to port bash to the resulting mess, and things looked a bit better.”
- Linux News Issue #3

There is always a gap between product insight and execution. Early Linux seemed primitive compared to what it would become. But, the core insights were there from the beginning. If you find yourself getting sucked down a rabbit hole of some problem space, lean into it even if the first attempts seem trivial. Every initial product is underwhelming compared to its future potential.

It seems obvious that curiosity is a prerequisite for further discovery, that early products are often underwhelming compared to their future potential, and that the best way to build a platform is to build small, useful features. Yet, every new wave of technology brings a fresh chorus of thin wrapper accusations — "GPT wrapper" is the latest cheap shot from pundits.

I would rephrase PG with less derision: The term "GPT wrapper" marks the speaker as having little curiosity.

Recently, one of the earliest Linux contributors, Lars Werzenius, reflected on the last two decades of Linux's story: 

"In 1991, Linus wrote that Linux "won't be big and professional like gnu". In 2023. Linux is running on every continent, on every ocean, on billions of devices, in orbit, and on Mars. Not bad for what started as two threads, writing streams of As and Bs on the screen."
- The Early Days of Linux

Not bad, indeed.