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

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

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.)

But Also Provide a Stable OSH Language Definition

We don't necessarily have to fix every bug -- our goal is to either fix each issue explain / provide a patch for it.

This is why documentation and writing are important. A language has to be explained to its users!

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.
  4. Refactoring afterward is important
  5. Removing legacy OSH features from YSH is important
  6. Writing is important

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

Related