Contribute

The platform is MIT, and this page is not a general invitation. There are two places where an outsider’s work has more leverage than ours, and both of them are places where we are structurally the wrong people to do it.

Add a vendor to a class that already has a subsystem

This is the highest-leverage contribution the platform accepts, and it is deliberately the smallest.

The kernel splits a driver into three layers: the runtime gives mechanics, the subsystem gives meaning — what a chat turn is, what a function call is — and the provider gives translation, this vendor’s HTTP and streaming dialect mapped onto the subsystem’s types. The hard, expensive, opinionated part is the middle one, and for chat, stt and tts it is already written and shipped. What is left for a new vendor is the small layer, and that is the design working rather than an accident.

The proof that it is small is what already stands under those subsystems: openai-chat-driver and anthropic-chat-driver are two vendors under one chat, and openai-stt-driver and openai-live-stt-driver are two devices from the same vendor under one stt. Each of those is a repository you can read end to end.

Start at bentos-driver-sdk-dart (MIT), which those drivers were proven against, and read one of them beside it. A driver you add works with every program on the machine that ever opens that class of device, because the program names the device and never the vendor.

What this does not mean is adding a subsystem per vendor. One subsystem per class of device, never per vendor — a vendor that does not fit an existing class is a conversation about the class, and worth having.

Build an application on the primitives

The second ask is larger and less comfortable, and it is the one that moves the design.

Process — the fourth primitive, the doing one — has run out of road twice when designed from the top: it arrives true and too abstract to yield a schema. It will not be settled by more design. It will be settled by concrete applications built on entity, event and place, where questions like what is a run, who baptizes a state, and does every component carry a failure terminal are answered by something that had to work.

The same is true of the questions the platform already knows are open — when a place advances a pin, how deep a manifest declares, what a Process run even is. Status grades every one of them. None will be closed by argument; each is waiting for something that had to work.

So: build something small and real on top, and tell us where it hurt. A report of the shape this is what I tried to model, and here is where the primitive would not hold it is worth more to this floor than a patch.

Where the code is

github.com/cafe01/bentos-userland is the entry point and where releases are cut. Beneath it the platform is a repository per part, all MIT: the kernel and the ABI, the userland, the ports tree, the driver SDK, the inference subsystems — chat-inference-dart, stt-inference-dart, tts-inference-dart — and a driver per vendor under them.

Issues are open on those repositories, and there is no CONTRIBUTING file to read yet: the project is early enough that the useful first move is a report or a driver, not a process. If you are unsure whether something belongs, the honest answer is usually in status — a piece marked open is a piece where nobody will tell you that you are wrong, because nobody knows yet.