Changing Tack
It’s been almost two years since I made Orca open source, so I thought it would be a good time to reflect on what we’ve done so far, and introduce some changes in the project’s direction. Here’s the outline:
Recap
In these past two years, we did a lot of groundworks, i.e. tooling and systems work laying foundations for future features and better developer experience. Here are a some notable examples:
- Ben Visness wrote a native tool to bundle Orca apps. This allowed us to get rid of our Python requirement for app developpers, as we discovered that Python installs can vary widely from user to user and it’s very hard to get a Python tool to work consistently for everyone.
- Maintaining parity accross several vector graphics backends was difficult, and we encountered a number of issues with the OpenGL backend on Windows, so I wrote a common vector graphics backend using WebGPU for both Windows and macOS, and improved our rendering pipeline along the way.
- Reuben Dunnington implemented the C standard library in terms of Orca APIs, to help integrate third party libraries and provide C developers with a familiar interface.
- I substantially rewrote the UI styling system following feedback from early testers. The new API simplifies styling rules and introduces style variables and themes.
- We designed a JSON description of Orca APIs to help documentation and language bindings efforts.
- I setup a documentation website including the (auto-generated) API reference.
- Michael Kutowski wrote an Odin bindings generator, and Laytan added an Orca target to the Odin compiler.
- Julian Del Signore and Reuben Dunnington wrote Zig bindings.
- Caveat: since Orca APIs are changing rapidly, and making idiomatic bindings always requires some manual authoring, bindings might still be frequently broken at this stage. Nevertheless, we now have a “source of truth” that makes tracking API changes way easier and less error-prone than before.
- Reuben Dunnington wrote a much improved build script using the Zig toolchain. It removes a dependency on Python (this time for contributors) and all the bad surprises it implies, and also comes with incremental builds, automatic fetching of external dependencies, cached Debug/Release modes, building and running tests and samples, etc.
- I wrote a custom WebAssembly interpreter (mostly complete, but not merged yet). Owning this piece of the engine will allow us to experiment with WebAssembly extensions such as virtual memory, dynamic linking and multithreading, as well as debugging and live feedback features.
- Speaking of which, our integrated WebAssembly debugger is also coming along, and can already do source-level and bytecode-level stepping and registers and variables inspection.
I’m pretty proud of the team for achieving this much, especially given our limited time (more on this later). This is the kind of work that is difficult to showcase, but is also extremely valuable, as we’re now in a better position to onboard contributors, help language bindings maintainers, debug our WebAssembly SDK, and experiment with our own execution environment.
On the other hand this means we still have a pretty limited API set. For example, we purposefully delayed working on new APIs like networking or audio, because we first needed to develop the tools to debug their wasm-side implementations, and because they depend on choices we’ll make about the execution model (like multi-threading). Ultimately this is a problem of priorities and scope, but long time contributor Reuben Dunnington has already started fleshing out the file system API, and there is more to come.
After this phase of getting the codebase off the ground and building the tools we need to iterate on it, I think it is time to shift gears, and I’ll explain how in the next section.
A New Heading
Since my first post here, my ideas about the goals and strategy of Orca have evolved a fair bit, so I want to give readers a clear idea of those changes.
The high level goal was and still is to make a better stack for building, distributing and running applications. Originally I thought about these three aspects as somewhat separable concerns, that could be tackled in sequence. I also put a stronger emphasis on the distribution and execution models (although I did hint at integrated tooling and composition features).
I’ve come to think a much more fruitful perspective is to consider development, distribution and execution as modalities of the same live environment. In this approach these three modalities support and flow from each other. The execution model supports both development features like hot-reloading and time-travel, and distribution features like portability and sandboxing. The distribution model can be used both for transparently fetching apps and for fetching plugins and packages for the development environment. And the development environment cooperates with the runtime to provide insight into, and control over, the execution of apps, in addition to helping package programs for distribution.
This rebalances the focus in favour of the development workflow in this environment, since the distribution and execution models can now support more interesting features by cooperating closely with the dev tooling. This also seems to me like the most interesting area for research and progress. In particular I’m interested in exploring the idea of a live, observable programming environment mixing code and visual components to interactively compose and debug applications. I engaged with the topic a couple times (see for example here and there) and I’m eager to wrestle with it again.
Along with this shift in focus, I’m also revising the strategy to get there. The original plan was to first build a minimal product (an Electron-like platform) providing practical value from the start, which hopefully would generate interest and translate to some users/contributors/sponsors, and then use that as a base for further explorations. This did seem reasonable, and I still think it would be for an organization with enough velocity. But for a part-time and (mostly) solo developer like me, it pushes “the interesting parts” way too far in the future. As such, it fails to account for maintaining a clear vision and sustaining my own long term enthusiasm, and, I fear, also the enthusiasm of other contributors and sponsors.
Leaning into the more innovative and exploratory aspects of the project, although less predictable, might actually be the more sustainable way. First, it feels more rewarding to me personally, so it is more likely to keep me working on it. And second, while the original plan was trying to foster adoption as in “users buying into the product”, I think this new focus can foster adoption as in “a community playing with and exploring the vision”, which actually makes more sense for a long-term project like Orca.
Ok, but what does all this mean in practice?
- The launcher, the runtime, and the development tooling will all be part of the same environment. Orca Apps will be more like SmallTalk images that you can inspect, tweak, and live program, rather than opaque WebAssembly blobs.
- You’ll still have the ability to “export” an app as a standalone though, because that’s sometimes useful and it doesn’t cost much more.
- We’ll research ways of weaving code and visual interfaces together to better support liveness and interactivity of the programming process.
- We still want to run modules compiled from traditional programming languages, but we might extend or diverge from the WebAssembly spec as needed by the environment. In practice languages like C, Zig, Odin or Rust that don’t need to rely on fancy new Wasm proposals should be fine.
- Language support like APIs bindings and debugger integration will be based on community effort.
- Work on new APIs like networking, audio, video, etc, might progress a bit slower, although community proposals and contributions are very welcome.
- I’m more interested than ever in a Linux port, but I don’t have the bandwidth to tackle it myself right now. If someone is up for it I’m happy to help.
Generally speaking, I will put a stronger emphasis on research and exploration, and start tackling the more “radical” aspect of the project sooner than planned. Obviously, in the longer term I want Orca to become a complete and polished product (not just a research project!), but I think the path to the best version of it goes through this research effort. In the meantime though, I do want our experiments to be actual features you can play and engage with, and I hope the community will take part in the exploration!
Communicating Progress
One of the main channels I’ve used to keep people posted on the project is this blog. The thing is, blog posts take a long time to write, and not all updates feel worthy of a full-blown post. I think we need more frequent, smaller-sized updates so that we don’t work “invisibly” for extended periods of time. This way people can see the project is well alive, gauge the direction it’s moving towards, and hopefully get interested in participating or supporting it.
To address this, I’ve added a Devlog page to the website. This is a curated feed of small progress updates and news that require way less work than a blog post or newsletter, so hopefully we can publish them more often. I also set up an RSS feed for it so you can get the latest updates directly in your favorite reader. By the way the blog also has its own feed here (it already existed, I just made it more explicit). I’ll also continue to publish blog posts at a slow pace, but reserve them for technical walkthroughs of specific systems of Orca, or “position” posts refining the vision of the project.
As a reminder, we also have a Discord server where we chat about Orca development. I added channels that pull in the RSS feeds from the website as well as the logs from the git repo, so if you want to see everything in one place that’s where you should go!
Funding
During the past two years I took a couple contract jobs, and I dipped into my savings to work on Orca the rest of the time. Balancing contracts (sometimes two at a time) with making progress on Orca was pretty hard. Obviously it meant less time and energy for the project, but it also involved a lot of context switching. In particular, research really needs a critical mass of focused time, so it’s the part that suffered most.
Over the year, monthly donations to Orca have amounted to around $400 on average, which I’m immensely grateful for, but of course it isn’t enough to keep the project going long term. With my savings dwindling, I clearly need to ramp up funding, otherwise I’ll likely have to take more contracts, or even a full time job sometimes in the coming year, which would considerably slow down the project.
I’ve been looking into R&D grants, and applied to some. We’ll see what this yields, but this is a slow and hit or miss process. The most truthful funding source remains donations, because they express the interest and commitment of supporters and users sharing the project’s vision. Speaking of which, I created a bunch of new sponsorship tiers. They each come with some perks, from getting your name credited as a sponsor, to priority support and consulting hours. I’m also thinking of making special content (i.e. advanced tutorials and technical walkthroughs) for sponsors, but this is a start.
I also set a first goal of $4000 per month, as this is the amount that would allow me to focus on Orca full time. I’m only 12% towards that goal, but that is a beginning, and you can help push that number up!
If you think the research and programming work I do on Orca is important, and you want to help me move the project forwards, please have a look at the Orca Github Sponsors page and pick a tier you’re comfortable with (or choose a custom amount) - any help is deeply appreciated!
Thanks for reading, and see you soon~
Thanks to Reuben Dunnington for his feedback on this post’s draft.