Every Door is definitely one of the easier ones and I like it but dang I wish the dev could get more funding to make it a nicer UX. Between the glitchy raster tiles and need to click load data all the time I feel it gets tiring fast.
I've considered building a separate app that's similar but oriented around the idea of using voice of pictures to update things (with AI extracting and formatting the data for you to review). But alas making yet another tool isnt ideal.
I had a brief chat with the dev at State of the Map (the OSM conference) a few weeks ago. I think he'd appreciate some help, maybe even a co-maintainer.
Isn’t that a door (haha) opened by our supreme new AI coding overlords: that now it’s possible to take the Every Door source code (it’s on Github), and throw it into a coding agent with the instruction to „improve <ux shortcoming of your choice> without breaking functionality“, and with some iterations and human validation that yes, the UX is now indeed better, play the changes back with a PR?
“Make it nicer” will lead to unpredictable and controversial changes, likely to clash with the project owner’s vision. The owner would be better off using the LLM as a collaborator, if anything, to decide where to take the design.
However, UX can also be improved by some simple heuristics that could be seen as mechanistic by the standards of modern LLMs.
Performance and responsiveness, for example, contribute to UX even when the UI remains fixed. I’d wager Fable-level LLMs could improve perf on most open-source GUIs by benchmarking typical use cases and progressively applying standard tricks like caching, buffering, batching network calls.
Claude Design can help. Fable is pretty good at UI when you narrow down to a specific page or—better—something like a modal, table, etc.
If someone is a user, they'll have specific complaints. Claude Design is more than capable, which can then be fed directly into Claude Code to implement, test, iterate, and ship.
I agree that it lags behind coding and imo the highest leverage area for Anthropic to invest in. Hopefully they do so; UI is consistently one of the main (severe) differentiators between OSS and paid options.
No but if you have specific asks like “make this resizable” “I should be able to drag and drop to combine” or “add a button on the top right to close” it’s quite good at directed changes
I can improve the UI to my taste but if the maintainer doesn't have time/money to maintain a big ol vibe coded PR for some very opinionated change isn't going to do much.
That would appear to leave me with the choice of just using it for myself (lame) or I then have a public fork to maintain :(
If there's basically no shot of it getting up streamed I think I'd rather make something from scratch to suit my needs without the extras.
Anyway, I hope the AI overlords help us fund more maintainers soon!
I keep my neovim config maintained by a LLM which is a fork of Kickstart.
My example might be an outlier on the easy side because they have a custom/plugins directory that will not have merge conflicts ever so I try to never modify the main init.lua and keep all of my changes separate in my own files. This prevents merge conflicts.
I can then ask my LLM to add a plugin or customize existing plugins by writing files in this separate directory to add/overwrite plugins and configurations. This works great for me.
If I were working in the main file creating merge conflicts, I could imagine it could get messy fast.
I have been volunteering with the Internet Archive via Open Library for about half a decade now. Sending money is awesome and they're also always looking for volunteers! There are so many projects going on for Open Library and staff has quite a few volunteers but right now especially I think it would be awesome to have a few more experienced folks joining to help (many volunteers are students).
Here's just a few things we could use more experienced folks to help on:
- Solr performance, it currently gets quite slow under load and there are two read replicas but we think there may be some ways to improve it besides adding more replicas. You can run a full production copy of solr based on the dumps... But the current workflow to do this is kinda broke so I had AI fix it up but we haven't been able to verify if it's a fully working/good solution.
- We're doing big redesigns of major parts of the frontend. If your down to help for that Lokesh had many tickets open and guidelines and welcomes PRs.
- I'm currently migrating us from web.py to fastapi and could certainly use more experienced help for trickier ones.
Anyway, if you're actually willing to help all you gotta do is join our community call tomorrow at 9am PST and share your interests. We'll you on to something you like quickly :)
Not another language because the performance issues are limited to the code being sync. Anyway, a gradual migration was a must as well.
This is the first I hear of Litestar and I think it does seem very values aligned. I fastapi was picked simply because it was already known by the team and had a very thriving ecosystem. That being said, the hard part is getting off the old sync web.py stuff. Once everything is in async land moving to another framework if needed is relatively trivial. Thanks for sharing that though I'll keep an eye on it!
I’ve been using litestar for loads of projects recently and have been loving it. The ability to have full request/response typing (and openapi spec autogeneration) with your favorite dataclass framework is quite nice (I use attrs). I didn’t want to be forced to use pydantic like some other frameworks do.
I was one of the initial developers of Open Library and wrote most of it's backend code. I doubt any of the performance issues could be because of code being sync. Open Library is IO bound and it is most likely spending time waiting for db to respond.
Was there any performance analysis done that indicated that the "code being sync" the main bottleneck?
The issue wasn't the latency of a single DB query (though many were improved/cached), but sync worker saturation:
When traffic spikes, slow network calls to archive.org (for availability) and Solr tie up all available sync workers. The queue backs up, and suddenly every page becomes slow because there are no free workers left to handle requests.
This was handled from both sides: handling high-concurrency waiting better, while simultaneously optimizing Solr and removing archive.org from the critical path where possible.
I see the problem. But I feel switching to async is too big a change and there could be simpler ways to address this.
1. Solr was used (I think still continue to be used) for many things it is not quite the right fit. It was done then because, it was simpler to do. For example, it is used to get list of editions when a work is loaded. Limit Solr only to search and figure out a better way to manage the other pieces, would be a good start. Search could be made a different service and the frontend could call it via API. Both of these together will remove Solr from the critical path.
2. The availability status of archive.org could come from a database and a backend task can continue to update it very frequently.
Wonderful to see @raybb and @anandology in this thread.
Lots of operational challenges come up when running a service for 14M patrons.
And Open Library in particular has a handful of challenges.
1. It's database has grown significantly (800+ GB) and Anand is right that IO (even on SSDs) is a challenge. The `thing` (infobase/infogami) triple-store design is well thought out and gets us a lot, and any system has to be tuned as it scales to hundreds of millions of rows. One strategy here is being smarter about cache and also shifting some of the load from psql to solr. Rishabh and others volunteers have been amazing assets as we've moved in this direction. Jim Champ on staff has been helping me tune psql, pgbouncer, and some of our high IO crons to improve raw db performance.
2. Limited hardware resources. We're trying to move some of our services within the Internet Archive's kubernetes cluster and we've done a great job migrating towards a world where everything is dockerized. It used to be a very painful process for our team of 3 to handle server ops, upgrades, and networking for nearly 15 manually orchestrated servers. One of the bare-metal racks running much of Open Library is significanly oversubscribed on vCPUs and so moving services off to free space and eliminate steal is critical for us right now. Our main web server (ol-www0) suffers from up to 20% steal and we're seeing a lot of congestion before requests even get to our web nodes (app servers). We have a plan and it takes time.
3. Open Library is still dependent on Archive.org for many lookups -- like book availability (which Ben Deitch has been helping me and Drini move into solr). When there are network issues and a network requests takes 5+ seconds, every web.py worker on that thread grinds to a halt and Ray's work moving us to FastAPI has made a significant impact
4. Solr. Drini has been heroic at restructuring our setup to use replicated solr in a way that has increased performance and relieved some of the pressure on our main cluster. This was a huge bottleneck for us this time last year and we've taken a lot of steps to ameliorate our situation. See: https://blog.openlibrary.org/2025/09/12/open-library-search-...
5. Raw spikes in traffic. We are seeing massive amounts of traffic that slams our book pages, increasing the pain of all the above. It saturates our limited resources, puts more strain on our database, ties us web workers... It makes modsecurity even more expensive. Part of the solutions is being more clever about provisioning, part of the solution is using fail2ban to prevent bad traffic from subtracting from the experience of the patrons who depend on us. Part of the solution is caching and optimizing our database to scale with load.
There isn't just one solution and the same 3 engineers on staff (and the support of a completely stellar community of dedicated volunteers fellows and leads) are doing our best to balance ops improvements with the necessary "product" and design improvements necessary that ensure we're useful to people to begin with.
I hope this gives the world a bit more of a glimpse how we operate and what some of our challenges are. We're an open source project and our goal is to share as many learnings as we can and to build something useful, sustainable, and beneficial for the community at large.
Thank you Ray, Anand, Drini, Jim, Lokesh, Lisa, Charles, and so many dozens more for your tremendous work (present and past) and thank you for being in our corner.
I'm still hoping one of these mega AI LLMs will figure out how to install Linux on the many old iPads that become nearly useless after Apple stops updating them and you can't install new apps.
Oh definitely, there's great value in it for those who already own Macbooks for one reason or another. I just personally have found myself shying away from buying a Macbook multiple times over the years because the Asahi Linux experience was really really rough at the time & probably still is for the generations I would be interested in buying.
Yea, this project doesn't just benefit someone who goes out and buys a new Apple laptop. It's going to be most beneficial years from now, after Apple deliberately obsoletes today's hardware, stops updating them with software, and tries to turn them into e-waste.
I never really got the hang of LaTeX but I've really enjoyed Typst the past few years and even made a few books with it. Have you ever tried that or have thought on it?
I posted this on another thread but can someone please run this on some old iPads so we can be able to fully install Linux on them. If AI is so good surely it can do that and save millions of devices from turning into ewaste.
If someone could do something similar but to install Linux on old iPads that would be amazing. Their specs are ok but when the app store stops providing versions of apps for your OS it really makes them nearly useless.
This is a lovely project. Were you inspired by any projects like this for other cities? I think I saw something once for NYC but it didn't have nearly as many images.
Also, I'll probably share this in the next issue of https://urbanismnow.substack.com since we try to share positive things happening in cities around the world!
Yes! There are many similar projects[0] that we drew inspiration from. I hope to set Yesterdays apart in terms of our crowdsourcing toolset, tight integration with OSM and Wikidata, and the relationships we are building with libraries and museums that hold these collections.
I'll have to check out your Substack, it sounds right up my alley!
I've considered building a separate app that's similar but oriented around the idea of using voice of pictures to update things (with AI extracting and formatting the data for you to review). But alas making yet another tool isnt ideal.
reply