illumos-gate: source access and build boundary for the illumos operating system

The core source tree, not the official development endpoint

illumos-gate addresses the need to inspect and work with the core illumos source tree. The README identifies the repository as the core source tree, while the repository description identifies this GitHub copy as a read-only mirror of the official repository at code.illumos.org. That distinction matters for developers deciding where to contribute changes. The README says that code changes must be reviewed and tested, and it directs contributors to the illumos contribution guide. It does not describe this GitHub mirror as the place to submit patches or maintain development work. The repository's default branch is master, and its top-level entries include `.gitignore`, `.hgtags`, `CODE_OF_CONDUCT.md`, `README.md`, `exception_lists/`, and `usr/`. Based on that layout, the tree is organized as a substantial operating-system source repository rather than a small library or standalone application. The README does not document the internal modules represented by the `usr/` directory, so the precise component boundaries cannot be confirmed here.

Building requires an illumos-based operating system

The one explicit build requirement is fundamental: the illumos build must run on an illumos-based operating system. This makes illumos-gate unsuitable for a first build on a machine that only provides a different Unix-like operating system or no operating-system build environment at all. The README does not provide a package installation command, a dependency list, compiler configuration, target image command, or build invocation. It instead links to the `Building illumos` documentation at illumos.org for detailed instructions. Because the repository is a read-only mirror, cloning it is not presented as a complete supported workflow for creating a new build. The `README.md` also does not claim that a successful build can be reproduced with a single documented command in this repository. This is a meaningful limitation for evaluation: an engineer can assess the source mirror's purpose immediately, but must consult the external build documentation to determine host requirements, prerequisites, and the resulting artifacts.

A first source-tree inspection has no repository-local tutorial

The repository does not document a local first-use command, test command, or runnable example. Its build section gives a platform prerequisite and links to the official build instructions, so the honest first-use tutorial is limited to what can be stated without inventing steps. Before attempting a build, the developer must use an illumos-based operating system and follow the linked `Building illumos` guide. The README does not document how to fetch the official repository, select a build command, configure a target, or install the resulting image. It also does not document a smoke test for the tree. This means that reviewing the source is straightforward from the repository contents, while building and validating an operating-system image depends on documentation that is not included in this repository. For teams evaluating illumos-gate, the first verification should therefore be host availability, not a locally reproduced build command.

Contribution rules make review and testing mandatory

The contribution boundary is clearer than the build boundary. The README states that code changes must be reviewed and tested. It directs people who want to submit a change to the `Contributing to illumos` guide, which indicates that contribution is a guided process rather than an unrestricted write workflow through the mirror. The repository also contains `CODE_OF_CONDUCT.md`, and the README says that participation in community spaces and the project is covered by the code of conduct. For an engineer, these details establish a basic adoption condition: changes cannot be evaluated as an informal local patch and then merged without review and testing. The README does not specify review timing, test environments, required sign-off, commit format, or a command that validates a proposed change. It also does not describe automated continuous integration in this repository. Those details must not be inferred from the presence of source files or the default branch. The safe interpretation is narrower: illumos-gate contains contribution instructions at the policy level, but the detailed engineering workflow belongs to the linked illumos documentation and community process.

Licensing is mostly CDDL, with exceptions requiring attention

The README states that most existing code is licensed under the CDDL and that new code will generally be expected to use that license. It also says that modifications of existing code may not alter the original license terms. This creates an important distinction for integrators and downstream distributors. The repository is not described as uniformly licensed by one simple rule for every file. Integrations from upstream sources that use another open source license are permissible subject to approval of the advocates. The top-level `exception_lists/` directory is visible, but the README does not explain the contents or legal effect of those files. The repository metadata reports the license as unknown, so that metadata should not override the more specific README statement about the predominant license. Readers who need to determine whether a specific component can be used under particular terms must inspect the relevant licensing information and follow the project's stated approval process. This article does not provide legal advice or infer which files carry exceptions.

Maintenance and release boundaries for the mirror

The repository is not archived, and its last push was on 2026-10-16. The repository information does not show GitHub releases, so there is no release entry here to use as a release-management signal. The repository description identifies this copy as read-only and points to the official repository at code.illumos.org for project activity. That makes the mirror's maintenance interpretation different from that of an independently maintained fork: recent source presence does not establish that contributors should open pull requests here. Upgrade planning should account for the distinction between reading this mirror and following the official repository's contribution process. The README does not document a mirror synchronization interval, a stable-release branch policy, a versioning scheme, or a rollback procedure. Those omissions matter for engineers who want reproducible builds or a controlled downstream fork. Based on the documented evidence, the concrete status is a non-archived read-only source mirror with a last push on 2026-10-16 and no GitHub releases listed.

Editorial conclusion

Adopt illumos-gate as the source reference if you need the illumos core tree and can work on an illumos-based system. Do not treat this GitHub repository as the active contribution endpoint or assume that cloning it is sufficient to produce an operating-system build. Verify the build environment and contribution destination in the linked illumos documentation first, because those requirements are outside this mirror.

Frequently asked questions

Official sources

1. illumos/illumos-gate on GitHub
2. Issues
3. Project website
4. README