[jonjacky]

This project reminds me of the approach at Xerox PARC in the 1970s. Alan Kay wrote [1]:

(At PARC we avoided) putting any externally controlled system, in- house or out, on one's critical path. ... Thus, virtually all the PARC hardware ... and software ... were completely built inhouse by these few dozen researchers.

This sounds disastrous, (because) in programming there is a widespread first order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true --- an incredible amount of time and energy has gone down these ratholes. On the second hand, if you can build your own tools, languages, and operating systems you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible.

1. http://www.vpri.org/pdf/m2004001_power.pdf

[user_7832]

When would you (or anyone else) say would it be the best to consider doing everything by yourself from scratch? For example, I want to build a little arm server. I'm realistically going to use linux server or similar as I don't want to make my own OS. But if I'm undertaking something on a microcontroller - there's definitely a point where bare metal starts winning. How do you find that?

[jonjacky]

I would say: when the existing offerings completely prevent you from doing what you want to do, or require ugly workarounds that are not consistent with your goals, or when future changes in those dependencies might compel you to do extra work just to keep your own system running.

One more reason to start from scratch: to get the functionality you want from an existing offering, you would also have to include a lot of other stuff you don't need, resulting in unnecessary complexity and resource consumption.