📁 The file dilemma

There is this movement against files in most disciplines. Files are hard to manage, track, version, and secure (unless you use Git). Thus, a lot of tools have moved to SaaS (software-as-a-service) applications in the cloud. Jon Hirschtick articulates this point of view very well. Cloud and APIs are the new "file."

I'd like to present a few counterpoints.

• Integration: One of the ways we add value fast is integrating systems. This is due to the network effect, where Metcalfe defines the value as the square of the number of nodes (or in our case integrated systems or types of data). When we can integrate multiple types of data (say hardware, software, and mechanical), the value increase is much greater than just linear.
• AI: AI needs context to be effective. The easiest way to provide context is to run a local agent that has access to files that are in an open format. MCP (Model Context Protocol) may be another way.
• Accessibility: One of the problems with SaaS and APIs is you don't really own the data. Ten years down the road, are you still going to have access to it? Are you still going to have the tools needed to use the data?

Files are flexible and scale. The success of Linux evidences this (which adopts the Unix philosophy that everything is a file), the web (it still uses a bunch of plain-text files for every site), and software development (anyone ever heard of source code?). Software is by far the largest and most complex systems humans have created, and it is still 99% based on the lowly text file. Since its inception in 1991, the Linux kernel has had more than 20,000 contributors. Onshape is impressive, but it is a long way from scaling to projects of this size and longevity.

The reality is that a mix of files and APIs is no doubt required. However, if you want scalability and flexibility, I'm not sure you want to throw out files. GUI technologies have been trying to do this for decades, but HTML and friends are still king (anyone remember Flash?).