My plan, and what's not in it

What I learned

• Write down what you won't build. Deciding features one at a time is how a small tool slowly becomes a big one. A written list kept the first version small, so I'm doing the same for the next year.
• Not every feature has to run everywhere. If every feature had to work on all four platforms, I'd ship less. I'd rather have a feature on the Mac than not have it at all.
• Count the cost of a platform's tools before relying on them. Apple's frameworks do a lot of work for you, but you can't take that work with you to other platforms. I learned that when I ported away from Image I/O.
• If I'm asking for trust, you should be able to check. I say your photos never leave your drive. Open sourcing the whole app means you don't have to take my word for it.

I've written a fair amount about how LightPhotos works, but not about where it's going. I've been deciding that one feature at a time, and that's how a small tool slowly turns into a big one.

So here's the plan, and the part I find most useful is what I'm leaving out. It's the same idea as the seven-item list in the first post, except this list covers the next year instead of the first afternoon.

Your photos stay yours

I'm not building a service to store your photos. There's no account to create, nothing to upload, and no library I keep for you. Your photos are files on your drive, and LightPhotos opens the folder they're already in.

I didn't start out with this as a principle. I got here the hard way, after losing years of photos to a library format only one app could read. I wrote about that in the first post, and it still shapes most of these decisions.

I do want to reach drives that aren't plugged into your computer, starting with Google Drive. What's holding that back is speed. A photo tool that stalls every time you press the arrow key to go to the next photo isn't worth shipping, so I'll only do this if the performance is good enough. I don't know yet whether it will be.

I'm not cloning Lightroom

Lightroom has a lot of really good features, and I'm not going to match them. The AI features are the strongest part, and nearly all of them work by sending your photo to someone else's servers. That's the one thing I've said I won't do.

What I want to look at instead is ComfyUI, a tool for running AI image models on your own computer. I haven't built any of this yet, so think of it as something I want to try, not a promise. What I like about it is that the model runs where your photos already are, and nothing leaves your drive.

Not every feature on every platform

If every feature had to work the same way on all four platforms, I'd ship less, and what I did ship would be the plainest version.

So I treat two groups of features differently. The basics everyone expects already run everywhere, in the browser and on Windows and Linux as well as the Mac. Browsing a folder, rating, filtering, the basic adjustments and export are all in that group, and anything similar I build next will join them.

Beyond those basics, I want to find out how much Apple's own frameworks (the building blocks Apple provides for Mac apps) can do for me. That means Core Image, Vision and VisionKit, Image I/O, AVFoundation, and Object Capture, which builds 3D models from photos. I already know from porting away from Image I/O how this goes. You get a lot of work done for free, and then you can't take any of it with you.

This time I'm going in expecting that. Anything built on those frameworks will probably be Mac-only, maybe for good, and I'd rather have a feature on one platform than not have it at all.

Getting your photos out

Since I don't want LightPhotos to be your photo library, it has to be easy to send your photos to something that is. So I plan to support Immich, a photo library you can host yourself, and exporting to cloud storage more generally.

What I care about is that export works the same way whether the server is on your home network or somewhere out on the internet. I don't want to end up with two separate features where one of them is half-finished.

Everything from the keyboard

I want every feature reachable from the keyboard, so you can use the whole app without touching the mouse. I mean all of them, not just the common ones.

Part of the reason is that keyboard shortcuts are what I wanted from a photo tool in the first place, and they're why Luminar didn't fit how I work. The other part is that when I chose to build everything in Rust, I gave up the kind of accessibility browsers give you for free, and I said so at the time. Keyboard support is the part of that gap I can close myself, so I'm treating it as a requirement.

Shortcuts you can change

The thing I've hated most about photo apps is that every one of them expects a different set of keys. Luminar AI, RawTherapee and Darktable each want you to learn their own keys, and that's a big part of why I don't want to use any of them.

If you've switched photo apps before, you probably know that feeling. You already know how you like to work, and the app is asking you to start over. I don't want LightPhotos to do that to anyone.

So I want every keyboard shortcut in LightPhotos to be customizable. If your hands already know a set of keys from another app, you should be able to use those keys here instead of learning mine.

Open source, all of it

I plan to open source the whole codebase. I don't mean a core library with the interesting parts held back, or an old version released later. I mean the whole app.

It's the same reason as the storage decision. I'm asking you to trust that your photos stay on your drive and nothing gets uploaded, and you should be able to check that yourself instead of taking my word for it.

The next app works the same way

This plan goes beyond one photo editor. I want to build other Rust apps the same way, and by now I'm following that pattern on purpose.

First I build a native Mac app, because a Mac is what I use and I'd rather aim the first version at a user I understand well. Then I take the basic features to the browser with WebAssembly, and from there to the other platforms people actually use.

LightPhotos is where I worked out that order. Sharing the basic features across every platform while letting the extras differ, keeping the core editing code in its own module away from the interface, and weighing the cost of a platform's frameworks before depending on them all came from this codebase. I expect to carry those over as they are.

The plan on one page

What the list is actually for

None of this has dates on it. I work on LightPhotos in bursts, and a roadmap with quarterly deadlines would just be made up.

What the list really does is give me something to say no against. The first version shipped because I wrote down seven things and left everything else out. This is the same idea with a bigger list.

I'd also like people to argue with it. If something here is wrong, or something obvious is missing, log it at the issue tracker and I'll read it.

The current builds are on the downloads page, and the browser version is at the web app if you want to try it without installing anything.