It's a good question, one that we are discussing a bunch.

We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client codebase. The server portion of Warp will remain closed-source for now.

You can see how we’re thinking about open source here: https://github.com/warpdotdev/Warp/discussions/400 TLDR;

As a side note, we are open sourcing our extension points as we go. The community has already been contributing new themes [https://github.com/warpdotdev/themes]. And we’ve just opened a repository for the community to contribute common useful commands. [https://github.com/warpdotdev/workflows]

I wish you the best, this does look really cool. The collaboration aspects especially are pretty great; with remote work becoming the norm, terminal sharing without having to go through grainy zoom video shares is going to be amazing. And the workflows look super useful as well.

Just my thoughts on this: I wouldn't consider using it personally, but would advocate for using it in companies where e.g. there are engineers that work closely with support, teaching them how to debug etc. If it was OSS, I do think it would increase adoption by a lot.

Is your framework well-integrated with accessibility tools on Mac OS? If so, will you continue to integrate with those tools on other platforms?

We are actively working on a11y! It's still a work-in-progress, but the goal is to a) make Warp the most accessible terminal there is and b) make a11y be an integrated part of the UI framework, so creating accessible apps in rust would be a no-brainer for future users of our framework.

And yes - once we go cross-platform, we will work on the a11y support there too.

> We are actively working on a11y!

Glad to hear it! I'm working on a Rust GUI accessibility library that might interest you:

https://github.com/AccessKit/accesskit

If you'd like to email me so we can compare implementation approaches and perhaps avoid duplicated effort, my email address is in my HN profile.

thanks - will follow up once the dust settles!

That's really lovely to hear, and to be honest, makes me more hopeful about the direction of the project in general.

cieplik did a great job implementing support for VoiceOver and having a few blind engineers beta test the app

Can you tell us more about your GUI framework? E.g. what sort of paradigm are you using?

The UI controls is something I like to see. And possible support for mobile?

Why does it need a server? Is that normal for a terminal?

This is for cloud-enabled features not presently in other terminals.

Right now, we have two relevant features: 1. The ability to share a "block" of input/output to a permalink that anyone can view. 2. A.I. command search.

Later on, for an individual, it may mean being able to sync settings across devices, fast setup of your terminal on new computers, and being able to access the command line on any device via the web.

For teams, it means we can build collaborative features. This does not mean just Google Docs-style real-time collaboration, but asynchronous collaboration through sharing commands, settings, and history. It means increased knowledge-sharing through wikis and READMEs that run directly in the terminal. It means making the terminal safer and more secure via integrated password-management and audit logging. It means making the terminal a more extensible and customizable platform, with a nice modern ecosystem.

The app works offline, just the two features I mentioned won't work.