White Papers

This page is where the Foundation will publish its white papers: long-form arguments about how embedded systems should be built, aimed at the people who make platform decisions — engineers choosing an operating system, technical leads setting architecture direction, anyone who has to live with the consequences of a foundational choice. A white paper here is an argument, developed at length, not a summary and not a brochure.

None have been published yet. White papers will appear as the architecture work reaches the point where the argument is worth making in full. Until there is an argument, there is no white paper — and saying that out loud is better than filling the page with placeholders.

A white paper in the Foundation's sense is a complete case: it states a position about embedded systems design, lays out the reasoning and the evidence, addresses the reasonable objections, and concludes with something the reader can act on. It is longer and more deliberate than a blog post, and it carries the Foundation's name, which means it carries the Foundation's reputation.

This is deliberately distinct from the other publication formats on the site. Technical Reports document how something was built. Publications are the peer-facing research output. Blog posts are informal and conversational. A white paper sits between the report and the publication: less formal than a peer-reviewed paper, more committed than a blog post, and written for a reader who is deciding what to build.

The bar is simple and high: the argument must exist first. A white paper is not a way to generate interest in work that has not been done; it is the full presentation of work and thinking that have already happened. There are no marketing white papers here — no documents whose purpose is to make the platform look good rather than to say something true.

This means white papers will be rare. That is intentional. A page with three white papers that each made a serious argument is worth more than a page with thirty that each said something vague. The Foundation would rather publish slowly and be worth reading than publish often and be skimmed.

Before publication, a white paper is reviewed by the project maintainers. The review is not a rubber stamp: it checks the argument for holes, the evidence for soundness, and the claims for overreach. A white paper that does not survive review does not get published, and one that needs to be wrong will be corrected openly rather than quietly replaced.

White papers are published under the Foundation's name and, like all Foundation software and research output, are free to read and share. The source reasoning behind them — the design documents, the measured data, the code — is public in the GitHub repositories, so readers are never asked to take the argument on trust.

If Publications are where the Foundation speaks to researchers, and the Blog is where it thinks out loud, white papers are where it makes its case to decision-makers. The three can and will reference each other: a white paper may build on published research and be discussed informally on the blog, and a blog post that grows into a serious argument may eventually become a white paper.

Readers looking for current published work should check the Publications page and the News page, which are where finished output and announcements appear.

White paper topics come from the Foundation's own research programme — they are the arguments the work itself has earned. But the maintainers are interested in the arguments the community needs made: positions on embedded systems design that you think should be argued seriously and in full, backed by evidence.

If you have a topic in mind, write to contact@embeddedos.org with the argument as you see it and the evidence you think supports it. A proposal does not commit anyone to anything, but the serious ones will be read carefully.