Case Studies

A case study on this page describes a real deployment of the Foundation's software: where it runs, what it does, and what changed because of it, measured in numbers the subject stands behind. None have been published yet. We would rather have an empty page than a page of vague success stories.

The subjects of our case studies are the people who run the software in production — device makers, engineering teams, research groups — telling their own story in their own words. The Foundation's role is to check the facts, not to write the praise.

To qualify, a case study must describe a deployment that is real and current, and it must include measurable results: cost saved, reliability improved, development time reduced, or whatever the relevant metric is for that deployment. Qualitative claims like “it works well for us” are welcome in a testimonial, but they are not enough for a case study.

The bar is high for a simple reason. A case study carries the Foundation's credibility, and credibility is the only thing a nonprofit has to spend. A single inflated claim would cost us more than a dozen honest pages would earn.

We ask three things of anyone featured. First, verifiable numbers: figures you can defend if asked, with the methodology behind them stated in the piece. Second, permission: written agreement to publish, from someone authorised to give it. Third, review: you read the final draft before publication and confirm it is accurate.

We will not pay for case studies, accept payment for them, or let a commercial relationship shape the findings. If the subject is also a donor or partner of the Foundation, the case study will say so.

Some deployments cannot be named: a product not yet announced, a system under a confidentiality agreement, a team whose employer restricts public statements. We can publish a case study with the subject anonymised, describing the deployment and the numbers without identifying the organisation.

Anonymised studies go through the same verification. The Foundation will still know who the subject is and will still check the figures; only the published page withholds the name. If we cannot verify a claim, we will not publish it anonymously either.

A product showcase is marketing: it selects the best angle and omits the rest. A case study, as we define it, includes the constraints — what the software did not do, what was hard, what the team would do differently. Readers evaluating our software for their own deployment need the full picture, and that includes the rough edges.

We will not publish case studies written by the Foundation about other people's deployments. If we did not run it, we do not narrate it.

If you run our software in production and have numbers to share, we would like to hear from you. Write to contact@embeddedos.org with a short description of the deployment, the metrics you can stand behind, and whether you can be named or need anonymisation.

We will reply honestly about whether the material fits and what would be needed to publish it. Not every proposal will become a case study, and we will say so early rather than drag the process out. There is no fee, no obligation, and no marketing review of your words beyond checking the facts.