Summary
Urbit, like all operating systems, is primarily a tool for developers to build applications. For Urbit to win, the experience of developing applications needs to be top-notch. A few things need to work well for this to be the case. It should both be quick and easy to write and distribute a small application and know that it works properly. Sophisticated applications with large teams of developers and complex internal processes also need to be low-cost to maintain. Finally, the developer experience of Urbit OS itself (kernel and runtime) needs to be good, to maximize productivity when working on the core system.
A lot of different considerations factor into developer experience: source code management, dependency management, build times, general reliability, software distribution features, internal and external build system features, support for continuous integration and deployment, test harnesses, debuggers, telemetry (e.g. logs and metrics), and diagnostic tools all play a role.
Not to be discounted is the effect of the quality of an API on developer experience. A clean API that exposes solid, composable abstractions and has an ergonomic interface facilitates productivity much more than an API with leaky abstractions and a finicky or fiddly interface. The Urbit operating system exposes several such interfaces, and they should all be high-quality.
Projects
Completed
Desk Publisher Switching
Allows app publishers to more easily migrate distribution ships.
Completed
Gall Agent Backups
Exposes agent state in a %gall scry endpoint enabling agent backup and restoration.
Completed
OTA Approval
Allow users to selectively enable/disable OTA's on a desk-by-desk basis.
Completed
Terminal Improvements
~palfun-foslup wrote a whole suite of improvements to the terminal. This opened up a lot of opportunities for better developer experience and terminal-based user experience.
Completed
Native UI Research: Alpha
One of the main barriers to writing an Urbit app is that the standard way to present a user interface is by writing it in JavaScript that runs in a web browser. This has advantages, but it requires writing code in two languages, and it means you can't stay in Urbit entirely when writing an app.
Current
Arvo Ticks
Introduce the concept of an Arvo "tick" -- a number that Arvo tracks that increments every time Arvo runs a vane. This tick can be used in scry paths to request data at the latest available tick.
Current
Essential Desks
Introduces a distinction between essential desks and non-essential desks, where only essential desks will block upgrades. Newly installed desks will default to non-essential.
Future
libames
`libames` would aid in integrating Urbit with other systems, writing iOS clients, and allowing Urbit to be used in internet-of-things applications.
Use Nouns over HTTP
Eyre, Urbit's HTTP server, only supports communicating using JSON at the moment. Using "jammed" (serialized) nouns over HTTP would move JSON conversion logic from the server to the client, allowing a fully featured Gall agent to be written, including communication with a web client, without needing to write JSON conversions in Hoon.
Future
Native UI Research: Test-type
One of the main barriers to writing an Urbit app is that the standard way to present a user interface is by writing it in JavaScript that runs in a web browser. This has advantages, but it requires writing code in two languages, and it means you can't stay in Urbit entirely when writing an app. This phase of the work involves allowing hoon UI specifications to be rendered to a browser