I was hoping to have a new chapter finished for the Kestrel 3 User's Guide done by yesterday evening. Well, the text at least; I still need to work on screen shots. Unfortunately, I had completely forgotten I had a dinner appointment with some open-source community friends of mine, and that kind of derailed my plans a bit. Tonight's not going to work either, as tonight is a martial arts training night. So, it'll have to be either Thursday or Saturday at the earliest.

I think it's high time I start becoming more serious about tracking my time, defects injected and removed, and other relevant metrics in an attempt to get better at both completing my tasks at my day-job as well as maintaining predictability on delivering Kestrel-related progress. I've written a blog article about it on my personal blog.

While commuting back and forth to work, I tend to spend that time working on the Polaris CPU's formal requirements specification. I need this formal requirements definition so that I can justify what goes into hardware actually maps to a real requirement of the hardware, and to catch defects in the design as early as possible. It's OK if I forget something; if I discover I need some feature which I forgot to document, I can always revise the document. At least it'll be recorded somewhere and tracked. This is important, because:

• This documentation is the source of truth for programmers references.
• This documentation can be checked against other artifacts, from design documents to actual Verilog code, to see if everything agrees. If not, that's a defect by definition, and warrants immediate repair.
• This documentation will directly inform the Polaris data sheet documentation.
• This documentation can provide the historical context behind a variety of technical decisions. It's value becomes most apparent if I happen to be challenged legally for something (worst-case) or if I give a tech-talk and someone asks a question on an obscure topic which I've long since forgotten about (best-case).

Of course, I'm not talking about writing 600-page, DoD-standard requirements specifications documents here. But it does need to be formal enough to allow tracing any given line of Verilog code back to a requirement.

Finally, if at some point someone is interested in funding the project, having enough data to provide an earned-value diagram or two, a formal requirements definition, and prediction intervals for delivery dates will almost certainly become immensely valuable for facilitating negotiations.

Boy, wouldn't that be nice? If someone could drop $450,000 on my lap, I'd be able to focus on the Kestrel's development full-time for three years with my current standard of living. But, on the other hand, if someone did want to drop that kind of cash for the project, I have to wonder where the strings are attached, and who will control them. This latter issue is the number-one reason why I haven't sought funding for the project. I want to make sure the core Kestrel project concept is as financially and legally unencumbered as I know how to make it. Once a baseline project is available, then and only then will I consider commercially forking the project for personal gain. (Of course, I have no control over what other people do, only over what I can do with it. If some company wants to fork and commercialize Kestrel before I've attained a baseline architecture, that's their responsibility to bear.)