Skip to main content

Contributing

So you’ve found us — open-nexus-os.io.
That’s the front door, the story, the vision.

But before we talk about “contributing”, one important reality check:

Open Nexus is in active early development and currently maintained by one person.
That means the project moves fast internally, but bandwidth is limited externally.

So if you’re here to file bug reports or feature requests:
we can’t reliably triage or respond to those yet. Not because we don’t care—
but because we’d rather be honest than collect a backlog we can’t service.

We use GitHub to reach developers worldwide,
but most modules are being migrated to our own GitLab — gitlab.open-nexus-os.io/open-nexus-os.

That’s where day-to-day development takes place.

If you’re curious (best entry points)​

  • /community — Discord and community spaces (best for conversation)
  • /blog — latest updates
  • Discussions — longer-form threads
  • GitHub repo — public mirror and entry point
  • Wiki — background and guides

What “contributing” means right now​

Here’s the part that matters most: at this stage, the biggest help is signal.

Code isn’t the bottleneck yet — attention and honest pressure are. The most valuable thing you can do costs nothing:

  • Talk about it. Tell someone who’d find a from-scratch, RISC-V-only OS interesting. Share a blog post. A project like this grows by word of mouth long before it grows by pull requests.
  • Discuss it in the open. Reddit, Hacker News, forums, your group chat — wherever developers actually argue about systems. Public discussion is how an idea gets stress-tested, and we’re listening.
  • Ask the hard questions. About the architecture, the failure modes, the trade-offs, the claims in the papers. A sharp question is worth more than a vague “looks cool.”
  • Challenge the assumptions. If something looks wrong, say so — specific, bounded, testable. That’s the feedback that actually changes the system.

None of this is a consolation prize. Talking about the project, in public, with real scrutiny, is genuinely one of the most useful things you can do for it today.

And when we’re further along and ready for hands-on contributors, I’ll personally help you get set up — building, running, and finding a first piece to work on. That part is coming. For now, the door is open for conversation.

This chapter documents how we work when a change is actionable:

  • How to set up your dev environment
  • How we evaluate and accept changes (with limited maintainer bandwidth)
  • How the license works

For how the codebase is structured and tested, see the Architecture section. For companies, see For Industry.

If this project interests you, come talk to us.
No pressure. No promises. Just an honest conversation about where things are—and where they’re going.