Excalidraw users have spent years asking for a real table element instead of hand-aligning rectangles and lines, and it is the tool's single most-reacted request, still collecting plus-ones this month. Teams that want tables on an infinite canvas are stuck choosing between proprietary SaaS like Miro and FigJam or hacking it together in the open tools. The opportunity is a true table shape or plugin for the open whiteboard ecosystem, or a diagram tool that ships tables natively.
builder note Excalidraw has no real custom-element plugin API, so the pragmatic first win is a 'generate a table' helper that emits native Excalidraw rectangle and text groups bound together, rather than waiting for upstream to add a first-class table type.
landscape (3 existing solutions)
Tables are table-stakes in the paid whiteboards but absent from the open, embeddable ones, despite being the loudest Excalidraw request for years. The capability exists, just not where you can self-host or embed it.
Excalidraw No native table element. Users manually align rectangles and lines that drift and break on edit, which is what drove this to the top of the request list for four years. tldraw The other major open and embeddable canvas SDK also ships no native table shape, only basic shapes, arrows, sticky notes, and a custom-shape extension API that each integrator would have to build tables on themselves. Miro / FigJam Have polished native tables, but they are proprietary SaaS you cannot self-host or freely embed, and they carry per-seat pricing, so the capability is locked behind the closed tools. sources (1)
whiteboardexcalidrawdiagrammingtablesopen-source
Privacy-minded and offline-first travelers want real public-transport journey planning (bus, train, metro routing with schedules) without handing their movements to Google or Apple Maps. The most-reacted Organic Maps issue is a multi-year plea for transit routing that is still active this week, and OsmAnd's offline transit is schedule-blind and often fails. The opportunity is GTFS-backed, on-device transit routing for the de-Googled and offline crowd, possibly delivered as the data pipeline both apps lack.
builder note Because an active PR already targets Organic Maps, pure 'add it to one app' is half-claimed. The open lane is packaging GTFS feeds into offline-routable bundles, the data pipeline neither app has solved, which a separate product could license to both.
landscape (3 existing solutions)
Good transit routing today means real-time online services that track you. The privacy and offline maps this crowd actually uses either lack transit routing entirely or do it without schedules, leaving accurate offline journey planning unsolved.
Organic Maps Privacy-first offline maps with zero public-transport routing today. A community PR (#12890) is in progress as of 2026-06-08 but unshipped, so the feature is wanted but not yet available. OsmAnd Offers offline transit routing from OpenStreetMap data, but it uses default per-vehicle speeds from a routing config rather than real timetables, so journeys are schedule-blind and routes frequently fail to generate. Citymapper / Transit / Google Maps Accurate timetable-based journey planning, but online-only and tied to account and location tracking, which is exactly what this audience is trying to avoid. sources (1)
mapstransitofflineprivacygtfs
Audiobookshelf users who keep audiobooks and ebooks in one library want their ebooks to sync wirelessly to Kobo e-readers the way Calibre-Web already does, without cables or running a second server. The top Audiobookshelf request, labeled by maintainers as a possible plugin, asks for exactly this. The opportunity is a Kobo-sync bridge for Audiobookshelf, or a unified server that finally covers audiobooks plus ebooks plus native e-reader sync in one place.
builder note Do not fork Audiobookshelf. The cleanest build is a sidecar that speaks Kobo's sync API and reads an existing Audiobookshelf library, since the issue is literally tagged 'possible plugin' and Calibre-Web already proved the sync protocol is reverse-engineerable.
landscape (4 existing solutions)
BookLore 2.0 now covers both audiobooks and Kobo sync, partially closing this gap. The persisting opportunity is in the Audiobookshelf ecosystem specifically: its mobile apps (Prologue, ShelfPlayer) and plugin community are more mature than BookLore's, so users already invested in that stack still have no native Kobo sync path. The opportunity may be an Audiobookshelf-specific bridge rather than a new unified server from scratch.
BookLore BookLore 2.0 added full audiobook support and bidirectional Kobo e-reader sync, covering the unified-server + Kobo-sync combination this signal describes. The gap versus this signal is primarily ecosystem maturity (Audiobookshelf has a larger plugin/app ecosystem, including Prologue and ShelfPlayer), and BookLore's Kobo sync implementation differs from Calibre-Web's battle-tested OPDS-based approach — builders should assess whether BookLore's sync is feature-complete before treating this as a fully open space. Audiobookshelf The best self-hosted home for both audiobooks and ebooks, but it has no Kobo sync, so ebooks must move over a cable or through OPDS and email workarounds rather than syncing automatically. Calibre-Web Has real built-in Kobo sync (chosen shelves become Kobo collections, with automatic kepub conversion), but it only handles ebooks, not audiobooks, so users who want both end up running two separate servers. Kobo native sync Wireless sync works only from the Kobo store, Dropbox, or an OverDrive library, never from your own self-hosted collection, which is the whole reason people self-host their books. sources (1)
self-hostedebookskoboaudiobookshelfsync
People who moved family photos off Google Photos onto self-hosted Immich keep hitting the same wall, that sharing is clunky compared to what they left. The single most-reacted Immich request is a meta-issue begging for better albums, partner sharing, shared links, and library sharing, and the maintainers openly froze sharing work pending a redesign. The opportunity is a frictionless sharing and collaboration layer for self-hosted photos, or a competitor that nails sharing first.
builder note The trap is recommending features Immich already ships — it has partner sharing and shared links today, just poorly executed. The wedge is the UX redesign and reliability it publicly froze: seamless cross-device album collaboration, non-technical family member onboarding, and a sharing interface that doesn't require understanding Immich's internal library model. Build that layer on top of the existing Immich API rather than a new server.
landscape (2 existing solutions)
Self-hosted photo apps have nailed ingest, machine learning, and browsing, but sharing is the weakest surface across the board. The leading app publicly froze the feature, which turns a hunch into a validated, well-scoped gap.
Immich Has basic albums, partner sharing, and shared links, but the project froze sharing improvements pending a full redesign, and the 1000-plus reactions show current sharing is the most-felt weak spot. Google Photos The sharing experience everyone is benchmarking against (one-tap partner sharing, collaborative albums, instant links), but it is cloud-only and tied to the privacy and cost concerns that pushed these users to self-host in the first place. sources (1)
self-hostedphotosimmichsharingfamily
Data engineers want to diff big tabular files (CSV, Parquet) the way git diffs code, seeing exactly which rows, columns, and values changed between two versions, with hooks into DVC. The leading open-source option, Datafold's data-diff, was archived in 2024, and the survivors either choke on Parquet or load everything into pandas. The core value is a fast, file-first, schema-drift-tolerant diff that slots into a version-controlled data workflow.
builder note DuckDB already does the heavy lifting of reading the files, so the unsolved part is the presentation and the workflow fit (a column-aware, schema-drift-tolerant diff that drops into a DVC or git pre-commit hook), not the comparison math itself.
landscape (3 existing solutions)
Tabular diffing splintered into abandoned (data-diff), small-file CLI tools (daff), and hand-rolled SQL or pandas. Nothing today combines large-Parquet scale, a readable row, column, and value diff, and awareness of a data-version-control flow.
Datafold data-diff Archived and read-only as of 2024-05-17 with a last release in February 2024. It was also database-to-database oriented rather than file-first, so it never cleanly handled a loose pile of Parquet on disk. daff Supports only CSV, TSV, SQLite, and ndjson (no Parquet), is tuned for small-to-medium tables that share a common origin, and integrates with git as a diff handler but not with DVC. DuckDB (as a DIY workaround) Can read Parquet at scale and express a comparison in SQL, but it is a general engine with no purpose-built diff output, no schema-drift handling, and no version-control awareness, so every team rebuilds the same ad hoc query. sources (1)
data-engineeringparquetdvcdiffingcli