Fourth Grant Goals and Guidelines - oils-for-unix/oils GitHub Wiki

Thank you for participating in the 4th NLnet grant for Oils !

This page is a reminder of my ideas for

  1. Reaching our project goals
  2. Ensuring a good / rewarding experience for contributors
    • It shouldn't be a chore to stick around in the years to come!

My feeling is that people work on Oils for some combination of:

  1. Building a better shell in the future (OSH and YSH)
  2. The challenge
  3. Improving debugging, testing, and coding skills
  4. Improving writing skills
  5. Having a public record of concrete accomplishments

(and feel free to let me know if there is something else you're getting, or not getting, from this work)

I know it's a lot of difficult work, for not that much monetary reward!

I wrote this after writing October 2025 Posting

Two Main Project Goals

Prove That We Can Build Real Distros with OSH

That's the title of the Kanban board: https://github.com/orgs/oils-for-unix/projects/1/views/1

The general idea is to move bugs from left to right.

Any movement is a good thing -- we purposely set it up so you don't have to take on the whole problem! This project is necessarily collaborative

(For some color, Samuel's work on oily-pine inspired this work. He found many good bugs, that our other work wasn't finding. And I know nobody besides us will fix these bugs. We need funding and a concerted effort to fix these bugs.)

Social Goal / Help Others Help Us

But actually that goal might be secondary to the social goal.

Since we're on our 4th NLnet grant, and most of the project is "in shape", I really want others to be able to apply for NLnet grants in the future!

This work is pretty legible and objective, so I think it's a good candidate for funding.

In contrast, work on YSH is hard to explain, and hard to plan / estimate. Some of it is research.

You could call it illegible or less legible, from the POV of funders.

And that's OK, because I will continue to work on YSH anyway.

Tactics for Moving Forward

Any Movement on the Kanban Board is Progress

As mentioned, you don't have to take on the whole problem! Different people are good at different things

I Do Things Step-Wise

This is a corrolary of the above. You might want to take on "a whole problem", but it still helps to do things in steps.

That is, the kanban board refelcts how I actually do things:

  1. Reproducing a bug is the first step.
  2. Reducing a bug to a small test case is a separate step. You need a "blank mind".
  3. Fixing the bug -- any fix is progress, no matter how ugly it is.
    • I often lean on the CI -- if I change this, what breaks?
    • That's also the reason I will ask you to write comprehensive tests for new features -- so we can lean on the CI on the future.
  4. Refactoring afterward is important
    • To keep the codebase clean. It's over 9 years old now! And IMO still fun and productive to work with.
  5. Removing legacy OSH features from YSH is important
    • Examples: empty argv semantics, set - semantics, trap quirks, ...
  6. Writing is important
    • It can be a harsh test of your ideas, which is good!
    • Do you really understand a topic? Do new ideas stand up to scrutiny? Can you explain yourself well?

Writing is Encouraged (and it's hard)

It spreads knowledge, and you can even teach yourself about a problem by writing about it.

Writing about a bug often takes longer than fixing a bug -- that's normal. But actually I think a good goal is to be able to write more quickly. That should come with repetitions.

Taking a Break is Good

One of the good things about this project is that it's not a "real job"! Everyone is working on it part time (except me), so it should fit into your schedule.

(Probably the biggest risk is that if you don't read Zulip for awhile, the "story" can get lost ... i.e. are we going to achieve our goals?)

Caveat: Clang Didn't Replace GCC

  • OSH is probably better for new distros ... unless a large group of people does a large amount of work
  • my experience is that many distro maintainers don't know shell well
    • (although this can also be precisely because shell is so hard to learn)

Related