mynewt-core is an Apache operating system for connected devices

A README that leads with CI rather than features

The Apache Mynewt core repository describes itself as an OS to build, deploy and securely manage billions of devices, and the README opens with the Apache licence header:

# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at

Then the logo, and then nothing but status. There are two CI badges for GitHub Actions, one for the build workflow and one for a build bootloader main workflow, and after that a hardware CI section.

That choice is telling. An operating system repository that leads with the licence, the CI state and the hardware test matrix is telling you that the thing to evaluate is whether the software actually runs on real devices, not what the marketing says. For a firmware project, that is the correct priority, because a feature list is meaningless if the timer does not fire on your board.

The primary language is C, the licence is Apache-2.0 with a NOTICE file at the root, the homepage is mynewt.apache.org, the default branch is master, and the last push was on 2026-10-19. The repository publishes no GitHub releases, which is normal for an ASF project where releases are cut by the project and recorded in release notes rather than as repository tags.

The hardware CI runs twelve sample applications across a board matrix

The hardware CI block is the most informative part of the README, and it is worth reading as a specification of what the project guarantees.

Twelve applications are run, and the list names them: blinky, clockdrift, coremark, cputimer, datetime, image, nvreg, pwm, trng, usb_cdc, usb_msc and watchdog. Each one is a small, sharp test of a subsystem, and each is run on a matrix of boards.

The board list gives you the real hardware coverage. It includes the Apollo3 EVB, the Arduino Zero, several Nordic PCA boards, the 10040, 10056, 10090, 10095 and 10121, a set of Nucleo boards from ST covering the F411, F767, G491, H723, H753 and U575, and a reel board. For each application, the CI publishes a status badge per board, which means a failure on one board is visible rather than hidden behind an aggregate pass.

The applications themselves tell you what the operating system is expected to do. blinky is the hello world of firmware. clockdrift measures time against a reference, which is the classic embedded correctness problem. coremark is a CPU benchmark, so there is a performance figure per board. cputimer and datetime cover the timer and real time clock interfaces. image covers image handling. nvreg is non-volatile register storage. pwm is pulse width modulation. trng is a true random number generator, which is a security subsystem. usb_cdc and usb_msc are the two USB device classes, communications and mass storage. watchdog is the hardware watchdog.

Between them they cover the parts of a device that break quietly. A build that passes on your desktop and fails the clock drift test on one board is exactly the failure this matrix exists to catch.

The source tree is the operating system, layer by layer

The repository listing is the architecture, and it is a rare example of a firmware repository whose directory names read like a system design document.

There is kernel/ for the kernel, libc/ for the C library, sys/ for the system layer, boot/ for the bootloader, and targets/ for the board and product definitions. There is also hw/ for the hardware abstraction layer. Then the subsystems: net/ for networking, crypto/ for cryptography, encoding/ for encodings, fs/ for the filesystem, time/ for timekeeping, and util/ for utility code.

Two directories are about the product rather than the operating system. apps/ holds the sample applications, which are the same ones the hardware CI runs, and mgmt/ holds the management side, which is how you talk to deployed devices. Two more sit alongside: compiler/ for the toolchain related parts, and test/ for the test suites.

Two configuration files describe the product itself. repository.yml is the manifest of what goes into a build, and version.yml carries the version. There is also a docs/ directory, a man-pages.conf for the manual pages, and a Doxyfile, which means the documentation is generated with Doxygen from the source rather than written separately.

For a team reading the code, the practical value of this layout is that the layering is the Apache way of doing things. The kernel, the C library, the system layer and the subsystems are separate packages with clear boundaries, and the board definition lives in targets/ rather than being spread through the source. That is the structure you want if you are going to maintain this for years and bring in new contributors.

Security is a documented model, not just a crypto directory

Two files at the repository root tell you how seriously the project takes security, and they are unusual enough to be worth reading before anything else.

THREAT_MODEL.md is a threat model, published as a file in the repository. SECURITY.md is the security policy, which in an ASF project is the process document that says how to report a vulnerability and to whom. The project also has an entire crypto/ subsystem directory, and the hardware CI runs a trng test, which means the random number generator is verified on real boards rather than only in the host test suite.

That combination matters for an operating system whose stated purpose includes securely managing a large fleet of devices. A cryptography directory on its own is not a security story. A cryptography directory, a hardware true random generator test in CI, a written threat model and a published reporting process is closer to one, and each of those four things is checkable by a reader without running anything.

There is also a .rat-excludes file at the root, which is the Apache Release Audit Tool exclusion list. The tool checks that every file in a release carries a proper licence header, and the exclusion file lists the paths where it does not apply, such as vendored third party code. The presence of that file in the root is a small but reliable signal about how the release process is run.

And the licence header at the top of the README, quoted earlier, is not decoration. In an ASF repository every source file carries that header, and the RAT check is what enforces it.

Apache project hygiene, and the coding standards the tree expects

The remaining root files describe how the project is run, and they are the same set you would find in any well maintained ASF repository.

.asf.yaml is the configuration the Software Foundation uses for the project, and .mailmap records the author identities for the commit history.

The ones specific to this project are more interesting. CODING_STANDARDS.md is a written coding standard for the C code, and AGENTS.md is present, which in current practice means the repository documents how to work on it with a coding agent. .clang-format and .clang-format-ignore mean the formatting is enforced by a tool with an explicit exclusion list rather than by hand, and RELEASE_NOTES.md is where a user looks to find out what changed between versions, which matters given that the repository itself publishes no GitHub releases.

Put together, the root listing reads as a project that takes the boring parts seriously. Licence headers are checked by a tool, formatting is enforced by clang-format, coding standards are written down, the version lives in version.yml, the build contents live in repository.yml, and the manual pages and API documentation are generated. For an embedded operating system that other teams will fork and extend, that is exactly the infrastructure that decides whether a fork stays maintainable.

Where this is the wrong choice, and what to verify first

It is worth being direct about the case against, because the platform is large and the README does not pretend otherwise.

Mynewt is a full operating system with a kernel, a C library, a bootloader, a management layer and a device update story. If your device needs a timer and a UART, that is a large amount of system to adopt, with a large amount of surface to own. A vendor SDK, or a bare metal library, is a smaller commitment for a smaller job.

Second, the hardware support implied by the CI matrix is a list of boards the project tests. It is not a list of every MCU with a Mynewt port, and the repository listing shows a targets/ directory rather than a catalogue in the README, so the honest first step is to look for your device there rather than assuming it is supported.

Third, and most important, the security claims are only meaningful next to their assumptions. A threat model states what the system is designed to withstand and, by omission, what it is not. Without reading THREAT_MODEL.md you cannot tell whether the design covers your device's actual exposure, and the presence of a crypto/ directory does not answer that question.

So the verification order matters. Read THREAT_MODEL.md and SECURITY.md first, then check targets/ for your board, then read CODING_STANDARDS.md and AGENTS.md to understand the contribution conventions, then look at RELEASE_NOTES.md and version.yml to know which version you would actually be building. Only after those four checks is it worth reading the source.

Editorial conclusion

Adopt mynewt-core if you are building a connected device and want a real time operating system with a documented threat model, a security policy, a management layer and hardware in the loop testing rather than a vendor SDK you have to trust. Do not adopt it if you need a bare metal library for one microcontroller with a simple job, since the size of the platform is not free, and do not adopt it without reading THREAT_MODEL.md and SECURITY.md, because the security claims are only meaningful next to the assumptions they are made under. Before you start, check that your board or MCU is in the hardware CI matrix, read CODING_STANDARDS.md and AGENTS.md for the contribution conventions, and confirm that the release notes and version.yml tell you which version you are actually building.

Frequently asked questions

Official sources

1. apache/mynewt-core on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README