business plan

I showed my counselor the post on filing system protocols. He got sort of a panicked look. We were supposed to be talking about how to have "something to show" to potential investors, and he had no idea what I was writing about, or how it was supposed to be relevant.

I explained that creating operating system features is one of the lines of business I want to be in.

More generally, I think, one thing I want to do is publish software that readers assemble themselves. I'll explain ... and here reader really implies that this is a literary product. I want my customers to build their own operating systems by typing code in on the keyboard, and I want them to fully understand every line of code they type in.

This is not typically attempted because of the perception that software is far too complicated for the average user to understand. Is software inherently complicated? I'm not sure it actually is. I envision code that creates simple broad structures. Components are then added within that structure, in an unhurried way. Components are similarly structured, too, or can be, so that the component can be modified by adding elements within its structure. Yes, a certain amount of care is required to avoid conflicts and unexplainable events, but that's just life. (As long as the structure is rational, it's possible to minimize such things just by thinking about it.)

The idea that "software is a mistake" is tempting. In a way, I'm saying what people need is programming interfaces, which are vastly or infinitely more versatile than "applications." That's extreme, though. What if more conventional kinds of software were built and marketed with more respect for the architecture in which they will operate? But that's another topic.