The skiftOS GitHub repository is a mirror of one on Codeberg

The GitHub repository is a mirror

The repository description ends with a word in parentheses, and it is the most important word in the file: mirror. The project's canonical home is on a different forge entirely, at an address under the same organisation name on that host, and this GitHub copy is downstream of it. Everything else follows from that. The website, the documentation site and the chat invite all point at the project's own infrastructure rather than at GitHub, and the build system is linked to yet another repository on that same other forge. So the star count, the fork count and the issue list you can see here are a read only view of work happening somewhere else. For a reader that is harmless and mildly confusing. For a contributor it matters: an issue or a pull request opened in this repository is not obviously where the maintainer works, and the file never says so in prose anywhere except that one parenthetical.

The build system is a third repository

Of the six components the project names, one is not in this repository at all. The build system and package manager is a separate project with its own repository, described as versatile and designed for cross compilation and complex project management. What this repository does contain is that tool's manifest and its lockfile at the root, plus a shell script, which is the entry point a person would actually run. So the dependency graph a reader can inspect here is the package set for one project, not for the operating system as a whole, because the pieces that compile it are described elsewhere. That is a normal arrangement for a system built from several repositories and it is also the reason the build section of the file is so short: with a manifest, a lockfile and a script, the build is a command you are expected to learn from the documentation site rather than from the readme.

The project ships its own browser engine

Read the component list and the scope is unusual for a hobby operating system. There is a core library of foundational building blocks. There is a reactive user interface framework. There is a desktop environment. There is a microkernel. There is the build system. And there is a browser engine, described as built for speed, accuracy and simplicity. Five pieces of a modern computing stack in one repository, none of which is a thin wrapper around an existing project, is the difference between this and a hobby kernel with a shell. It also sets the bar honestly: a browser engine is the hardest part of that list, and having one in tree means the system can be evaluated on something more interesting than booting. Each component is linked to its own directory in the tree, so a reader can go from the one paragraph summary to the code, which is the most navigable thing about this repository.

The kernel's own classification is hedged in the text

The kernel entry reads: a capability-based microkernel, with the word pragmatic in quotation marks. That is a small piece of punctuation doing a lot of work, because capability based and microkernel are both established terms with consequences, and the quoted word is not one of them. The author is telling you the design is small and practical rather than formally minimal, without committing to a classification the reader might then hold the project to. It is the most careful sentence in the file and it is easy to skim. The three stated principles read the same way. Modularity means components are as self-contained as possible to encourage customization. Simplicity means clear solutions preferred over complexity. Modernity means current C++ practice for safety, readability and efficiency. None of the three is a specification, and a project of this kind is going to be judged on the code rather than on the list.

The build section says it is easy and links out

The building section is two lines long. The first sentence says building from source is easy. The second links to a documentation page. There is no command, no prerequisite list, no toolchain version and no mention of what the build produces, in a repository whose root contains a manifest, a lockfile and a shell script that presumably does it. The same pattern runs through contributing, which is a single sentence welcoming contributions followed by a link, and through documentation, which is a separate site. That is a defensible choice for a project whose real audience is people who will read the code first, and it is a poor choice for anyone who arrives with a ticket to file. It also means the file cannot answer the question a new contributor asks first, which is what has to be installed before anything builds, because nothing in the visible documentation states it.

One named author, three handles, and GitHub Sponsors

The acknowledgements section is written in the first person by a single person, thanking three individuals by their handles for friendship, support and motivation, one of them additionally for contributions to this project and to another one, and then thanking everyone who contributed and supported the author through GitHub Sponsors. So the funding route is the sponsorship platform, the social route is one chat server, and there is no corporate sponsor named anywhere in the file. That is consistent with the project describing itself as a labour of love and an artistic pursuit rather than a commercial product, and it has a practical consequence: the bus factor is one, and the mirror relationship means even the issue queue is elsewhere. The licence line is the other durable thing in the file. The system and its core components are under the GNU Lesser General Public License at version three or later, with the full text both linked and included in a licence file in the package.

The production warning is the first thing in the file

Above the introduction there is a bold warning, and it says three things in one paragraph. The system is in the early stages of development. It is not ready for daily use. Please do not use it in production environments. Then the traditional phrase about dragons, which is the one piece of folklore in the file and does not need repeating. What is notable is the placement and the tone: this is not a line at the bottom under a licence, it is the first content in the document, it is bold, and it names the specific misuse to avoid rather than saying the software may be unstable. The repository has no releases at all, and the default branch received a push on 8 July 2026, so there is also no tag to try and no version to pin. A reader who takes the warning at face value has the right mental model: this is a place to look at how someone builds an operating system, not a place to deploy one.

Editorial conclusion

Treat this as a research and reading project rather than something to deploy, which is what the project itself says in its first paragraph. It names developers and people interested in niche open source operating systems as the audience, and puts a bold warning above that saying it is not ready for daily use and should not go into production. If you want to understand the design, this is an unusually legible codebase for an operating system: the components are separately named, separately licensed under the same permissive copyleft terms, and the kernel's own classification is hedged in the source text. Two things to settle before you clone anything. File your work on the forge the project actually uses, because the GitHub copy is a mirror and issues opened here may never be read. And find the build system, which is a separate project with its own repository, because the manifest and lockfile at this root only describe what that tool does. The licence is the LGPL at version three or later, which lets you link and modify freely and obliges you to publish changes to the covered components.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. Project website
4. README
5. skift-org/skift on GitHub