Fork status, attribution, and technical notes

[Guria]

Nehir is a GPL fork based on Oliver’s work on OmniWM/Hiro. I want to keep that origin clear: the project exists because OmniWM was shared as open source, and upstream attribution will stay.

I was an active OmniWM user before starting this fork. I sponsored the project, tested builds, shared feedback, and reported issues because I genuinely wanted it to succeed.

Nehir appeared after it became difficult for me to keep contributing or tracking issues in the original project. OmniWM had several fast direction changes, regressions, closed issues, and then Hiro was announced as a rewrite. At that point I wanted to keep a version I could personally use, maintain, and share with people looking for the same Niri-style workflow on macOS.

The fork is intentionally narrower than OmniWM/Hiro. It focuses on Niri-style scrolling columns and removes things I do not want to maintain here, such as Dwindle support, quick terminal, clipboard history, and some other features. This is not a statement that those features are bad. It is simply a different scope.

Some Nehir choices are opinionated and affect configuration, defaults, hotkeys, runtime behavior, and debugging. These are exactly the kind of changes I would not insist on in someone else’s project.

Nehir is not technically a GitHub fork and uses a fresh/squashed history in the main repo. This is documented in NOTICE.md, and attribution is kept in the README

The pre-squash work is still available at separate repo.

If something from Nehir is useful for OmniWM/Hiro, I am happy for it to be reused or backported under the GPL/open-source model. Better behavior for users is a good outcome.

At the moment I do not have a way to continue related discussions in the Hiro repository, so I am documenting the fork state here. If Oliver wants to clarify anything, discuss attribution, or talk about possible backports, he is welcome to do so here or contact me directly.

I understand that maintaining a project like OmniWM almost alone can be exhausting, especially after it received a lot of attention quickly. If any of my actions came across differently than intended, I am open to clarifying that directly.

For now, Nehir continues as a focused GPL fork for people who want a smaller, Niri-style macOS window manager with a maintenance direction I can personally sustain.

[Guria]

Update on Nehir's direction

The original Hiro announcement referenced in the previous post (BarutSRB/Hiro#399) is no longer publicly available upstream, along with the rest of the Hiro discussions and branding. An archived copy is available here: https://web.archive.org/web/20260610213855/https://github.com/BarutSRB/Hiro/discussions/399

What changed upstream

Since the previous post, the upstream project changed course again. The Hiro information and discussions are no longer publicly available in the same form, the repository is back under the OmniWM name, and releases continue there.

This does not change the state of Nehir. Development continues independently of whatever happens upstream.

Why Nehir still exists

• It has already diverged. Layout behavior, settings, defaults, and maintenance choices have moved in their own direction.
• Some fixes and behavior changes are still different here. Nehir contains fixes and decisions that are missing, handled differently, or still being explored upstream.
• Some reports need independent validation. If a bug was closed elsewhere but still reproduces for Nehir users, it can be tracked and fixed here.
• It is intentionally opinionated around the Niri-style workflow, with a deliberately smaller scope.
• It is a smaller, more predictable place to test this direction.
• For me, reporting upstream is no longer an option. Nehir is the place where I can continue tracking the issues I can reproduce and maintain.
• The door stays open the other way. OmniWM is welcome to pick up fixes that land in Nehir; that is a win for everyone using macOS tiling.

Open source is not ownership

Ideas and fixes are not personal property. If something introduced here later shows up in OmniWM, Hiro, or anywhere else, that is a good outcome. Better software for users is a win.

The same works the other way. I also reserve the right to look at ideas that land upstream or elsewhere and decide whether they make sense for Nehir. The fork is independent, but not isolated.

What to expect from Nehir

• Every issue and PR reviewed and answered. No promise that every feature request is accepted or every PR merged, but decisions should be explicit, not left hanging.
• Attribution stays. Nehir will always credit the prior art and its author. The fork exists because that work was shared as open source, and that origin is not going to be erased here.
• Opinionated, but open to influence. Contributors can affect the direction, but the final call stays with the maintainer and should be said clearly.
• Clear release channels. Stable, RC, and experimental work should not be mixed without warning.
• Configuration changes documented before release where possible.
• Issues are not closed just because internals changed. User-facing behavior should be checked against a current build where feasible before deciding a report is no longer relevant.
• Low-effort or obviously AI-generated contributions may be reviewed with automation or closed quickly. Using LLMs is fine; submitting unreviewed slop is not.

What not to expect from Nehir

• No sudden core rewrites in patch releases.
• No surprise project renaming, ownership transfers, or ground-up rewrites in another language.
• No mass issue cleanup without validating whether the reported behavior still reproduces on the latest release.
• No guarantee that every requested feature is accepted. A smaller scope is part of the design.

Plans can change, but if they do, they should be said clearly and early.

For contributors

A well-described issue or plan is often more valuable than a direct code change.

Share your pain — workflow, reproduction steps, setup, expected behavior — before jumping to an assumed solution. Testing, traces, and clear reports matter as much as code.

[Guria]

I’m locking this discussion to keep it focused as a history/state-tracking note and avoid mixing it with general support or debate.

If you want to respond, ask questions, report issues, or discuss Nehir’s direction, please create a separate discussion or issue as appropriate. I’ll be happy to continue the conversation there.