Why I'm Choosing to Bootstrap my Intel Competitor
Some readers may have noticed the πΈππ ππͺππ link thatβs been on the main page for my substack for the past few months. Back in May, my friend Alex and I went on a month-long roadtrip around the country to raise money for our startup.
The πΈππ ππͺππ page is the pitch we were using, granted one that needs quite a few updates by now.
We happened to leave just as the markets crashed, and some of the people we met and conversations we had left Alex rather jaded, so weβre back to the plan I originally had, which was to bootstrap the whole thing.
This might maybe sound reasonable until I mention weβre trying to build an ambitious hardware startup. And that Iβm currently couchsurfing in Austin with substack as my only real income at the moment.
Our basic thesis is that a combination of Mooreβs Law and limitations in compiler technology have resulted in incentives within the hardware industry that favor compatibility over efficiency in ways that have compounded to a massive degree over the past 50 years. Most of the 10,000x difference between CPUs and ASICs is unnecessary and general-purpose CPUs that are 2-3 orders of magnitude more efficient should be perfectly feasible.
This is nothing new, as many companies have successfully done this before. Building record-breaking chips with a single engineer on a tight budget has been done before. Thatβs the easy part, actually.
The hard part is tooling. Especially with some of the recent examples, many ambitious chip startups have put nearly all their effort into hardware and very little into tooling. Abandoning backwards compatibility and building the relatively weird hardware necessary for these huge efficiency gains necessitates that programming without significant help from tooling will be difficult for mere mortals.
Adapteva shipped their chips with a GCC backend and a few parallel programming libraries. For an architecture thatβs as weird and different as the Epiphany, how is anyone supposed to program such a thing? Hardware without software is just an expensive paperweight.
That said, itβs possible for a single engineer to build an entire operating system and software suite by themselves, not even factoring in all the open source code that can be ported and the fact that much of the existing complexity is purely a product of bad decisions made by short-sighted hardware engineers. If a single engineer can design a record-breaking chip, and a single engineer can build all that software, think about what two engineers can do, especially if they work together to make sure each otherβs job is as easy as possible.
The current bootstrapping plan is focused on tooling. Getting a round of chips produced at a top fab like TSMC costs a couple million dollars. Not cheap, but bootstrappable. Weβre going to need very good tooling as it is, and some subset of that tooling is probably going to be useful for existing languages and hardware (after all, how hard is it to compete if much of your competition dates from the 70s and 80s?). A combination of dogfooding and consulting with startups should give us something actually valuable.
Good dev tools can bring in a lot of money if you can convince people to buy them (Iβve been warned this isnβt easy, but frankly Iβm up for the challenge). Enterprise tooling can easily bring in >$1000/engineer/year. It doesnβt take a lot to raise a few million dollars that way.
If youβre someone writing code who wants to talk about what kinds of powerful tooling we could build for you, DM me on twitter. I donβt care about your tech stack - if itβs code I have ideas on how I can help. I just need to refine ideas with some feedback and build.
I like some of Chris Grangerβs ideas, and clearly a lot of other people do too, though I have a lot of ideas beyond just copying LightTable.
But why not just take some VC funding?
Keep reading with a 7-day free trial
Subscribe to Bzogramming to keep reading this post and get 7 days of free access to the full post archives.