Help build darwinOS

darwinOS is a volunteer project. Every feature, driver, and doc page is written by someone who wanted it to exist. Here's how to pick a lane.

You write C — work on the kernel and drivers

The kernel (XNU), the dynamic linker (dyld), the service manager (launchd), and most of libSystem are written in C and C++. If that's your language, this is where most of the early work lives.

Good places to start

  • Bring-up bugs in the XNU port — anything tagged `good-first-issue` in the `xnu` repo is scoped to a morning or two.
  • IOKit drivers for common hardware: network, block, HID, USB. Pick a device you own; we'll help match it to an IOKit family.
  • launchd jobs — porting or writing plist-driven services that userland needs at boot.

You write Swift or Objective-C — work on userland

Darwin's userland — the frameworks and daemons above libSystem — is a mix of Objective-C, Swift, and C. If you've shipped Mac or iOS apps, almost everything here will feel familiar.

Good places to start

  • Foundation-level gaps. We carry a trimmed Foundation; filling in missing classes and rdars is an easy first contribution.
  • CLI tooling. Command-line utilities — the modern equivalents of coreutils — are a great way to get commits in without needing a running VM.
  • Developer tooling. lldb integration, DTrace front-ends, crash reporter. Help the tools that help everyone.

You have hardware to port

darwinOS only matters if it runs on real machines. If you have a board — a single-board computer, an older Mac, a server, anything — we want to support it. Hardware contributors tend to touch the kernel, IOKit, and the boot chain together.

Before you start, check the Status page to see whether your target already has a partial port. If it does, pick up where the previous contributor left off. If it doesn't, open a tracking issue and post in the hardware channel so others can help.

You don't code — help anyway

Operating systems are built by more than programmers. The work below is real and load-bearing — and most of it is harder to fill than the coding work.

Documentation

Most of this site is stubs. Good technical writers are the difference between a project people *want* to contribute to and one they bounce off. Pick any under-documented subsystem and help.

Testing and triage

Reproduce bug reports. Write test cases. Keep the issue tracker honest. A triager who closes duplicates and files useful new issues is worth several engineers.

Design and identity

The site, the logo, the wallpaper, the installer UX, the release announcements — all of it needs people who think visually. Open a discussion if you want to help here.

How we work

darwinOS is governed by the people who show up. There is no BDFL and no sponsoring company. Small changes land via pull request with a single reviewer from the affected subsystem. Larger changes go through a lightweight RFC process — a markdown document in `docs/rfcs/` that names a problem, proposes a solution, and invites pushback before any code lands.

The Code of Conduct applies everywhere: repos, chat, issue tracker, community events. Disagreement is fine; being a jerk is not. Maintainers enforce it with the minimum intervention needed.

Keep exploring