Software Demand Signals — June 21, 2026

An affordable, open, self-hostable shared-3D-printer job queue for makerspaces/universities/libraries with SSO and per-user-private jobs - the FOSS tools are single-brand and the printer-agnostic option is enterprise-sales-gated

saas real project •• multiple requests

Institutions running shared 3D-printer fleets (universities, makerspaces, libraries) want a submit, admin-review, print, and per-user status workflow where students cannot see each other's files, with SSO against existing campus accounts and self-hosting for cost and privacy. They are stuck on email-based workflows because the capable FOSS tools are single-printer or single-brand and the mature printer-agnostic platform (3DPrinterOS) keeps the institutional features they need (SSO, on-prem, per-user-private fleet queues) behind quote-only Education/Enterprise tiers, with only a single-user public plan beneath them. The value is an affordable, brand-agnostic, self-hosted queue that these budget-holding institutions can actually deploy.

builder note

Don't try to out-feature 3DPrinterOS - it already has on-prem and SSO; win on being open, cheap, and genuinely printer-agnostic (OctoPrint/Klipper + Bambu + Prusa) with dead-simple SSO, because the buyers are cash-strapped labs and libraries currently choosing email over a quote-only enterprise tool.

landscape (4 existing solutions)

For institutions the realistic choice is a capable but enterprise-sales-gated SaaS (3DPrinterOS) or DIY/abandoned/single-brand FOSS, so there is no affordable, open, printer-agnostic, self-hosted queue with SSO and per-user privacy - which is why universities keep building bespoke submission portals or running everything over email.

3DPrinterOS Verified on their site: the dominant printer-agnostic education/library platform DOES offer private-cloud (on-prem) deployment, SSO, print queues, and per-team access controls - but those institutional capabilities live only in its quote-only Education and Enterprise tiers (custom pricing, demo-gated). The one public self-serve plan, Premium at $19/month for 2 printers and a single user (14-day free trial), is single-user remote management and cannot run a shared, per-user-private institutional fleet - leaving the needed setup out of reach for small makerspaces, libraries, and cost/privacy-driven self-hosters.

bambuddy Capable self-hosted FOSS fleet manager, but Bambu-Lab-only, and per-user-private queues plus SSO are still in 'Supporter voting', not yet built.

OctoPrint / Obico One-printer-per-instance and single-user oriented; no native multi-user submit/review queue with per-user privacy across a fleet of printers.

BotQueue A FOSS multi-printer queue in concept, but RepRap-era and effectively unmaintained.

sources (1)

other https://github.com/maziggy/bambuddy/issues/1620 "I would really prefer to work through SSO rather than manually creating" 2026-06-03

3d-printingmakerspaceself-hostedssoeducation

A brand-agnostic local-control plus open mapping/scheduling layer for retail robot mowers (Husqvarna, Worx, Eufy, Mammotion, Ecovacs, Sunseeker), so your zones and schedules aren't trapped in each vendor's cloud app

other real project •• multiple requests

Owners of Wi-Fi/Bluetooth robot mowers want local, manufacturer-independent control plus portable mapping, zones, and scheduling, because every brand ships its own cloud app and locks the data inside it. Right now this is served only by a swarm of separate per-brand reverse-engineering projects (one repo per manufacturer), so no unified, local, cross-brand control and mapping layer exists. The value is for homeowners and home-automation users who want their mower in Home Assistant and want maps that survive a vendor shutting down its cloud.

builder note

Don't try to boil the ocean across 20 brands at once; pick the 3-4 fastest-growing cloud-locked brands (Mammotion, Eufy, Sunseeker) and nail portable maps plus local scheduling, because the real moat - and the reason per-brand hacks keep dying - is sustained reverse-engineering as vendors rotate cloud auth.

landscape (4 existing solutions)

Robot mowers are as fragmented as early smart plugs: every brand has its own cloud app and no neutral layer offers cross-brand local control or portable mapping/scheduling over mowers you already own, which is why a Home Assistant forum thread tracking 18-20 brands and a swarm of single-brand repos keep re-solving the same problem separately.

Home Assistant lawn_mower entity platform Provides a unified entity type but every brand still needs a bespoke integration, mapping and zones are not standardized, some mowers are mis-exposed (Ecovacs GOAT shows up as a vacuum), and it requires running Home Assistant.

OpenMower Excellent open RTK-GPS control, but only for hardware you physically convert yourself, not the retail cloud-connected mowers people already own.

Per-brand community integrations (Mammotion-HA, Sunseeker, eufy-robomow-ha) Each one reverse-engineers exactly one brand and re-breaks when that vendor rotates cloud auth or firmware; the constant per-brand duplication is itself the evidence of the missing cross-brand layer.

Vendor cloud apps (Automower Connect, Worx Landroid, Mammotion) Walled gardens whose mapping and zones are non-portable and stop working if the manufacturer discontinues the cloud service.

sources (3)

other https://github.com/Sdahl1234/Sunseeker-lawn-mower/issues/67 "is it possible to use your integration with local MQTT?" 2026-06-15

other https://github.com/jnicolaes/eufy-robomow-ha/issues/5 "Can confirm, the setup works with a C15" 2026-05-18

other https://github.com/home-assistant/core/issues/169723 "Ecovacs GOAT A3000 LiDAR robotic lawn mower exposed as robot vacuum cleaner?" 2026-05-04

smart-homerobot-mowerhome-assistantinteroperabilityiot

A reliable, multi-brand hearing-aid/cochlear-implant audio-streaming and pairing tool for Linux PCs, Steam Decks, and standalone adapters (ASHA) instead of being phone-locked or buying vendor accessories

other real project •• multiple requests

Hearing-aid and cochlear-implant users want to stream audio straight from Linux PCs, Steam Decks, and DIY Bluetooth adapters over the ASHA protocol rather than being tied to a phone or forced to buy the manufacturer's proprietary streaming accessory. Today this works only through fragmented, per-brand, GUI-less developer projects that re-break on every device firmware or OS update, so getting sound requires deep Bluetooth debugging. The opportunity is a reliable, multi-brand, GUI-driven ASHA streaming and pairing layer for an audience whose hearing device is their only audio path and who will pay to never lose it.

builder note

The trap is shipping another single-brand hack that dies on the next firmware or BlueZ update; the defensible product is a maintained multi-brand compatibility layer with a real pairing GUI (ideally paired with a certified hardware adapter), because for this audience audio literally stops working without it.

landscape (4 existing solutions)

Streaming ASHA audio from anything other than a phone is served only by fragmented, single-maintainer, GUI-less projects plus an experimental mono-only native stack, so each hearing-aid brand and each OS update silently re-breaks audio for users who have no alternative audio path.

Native BlueZ + PipeWire ASHA support Verified against the developers' own writeup: experimental, mono-only with stereo still 'pending', no pairing/tuning GUI, tested on a single device, and not yet in stable distributions.

Pico-ASHA (Raspberry Pi Pico W ASHA bridge) DIY firmware bridge maintained essentially by one developer; per-brand breakage (Starkey never establishes L2CAP, Med-El/Rondo regressed between releases) and a pairing UI still being hacked together.

asha_pipewire_sink (Linux PipeWire ASHA sink) Streams to Linux but connections flap and abort on handhelds like the Steam Deck, behavior varies by hearing-aid brand, and there is no GUI for setup.

Manufacturer phone apps + proprietary streaming accessories Lock direct streaming to the vendor's phone app or a paid hardware accessory; there is no supported Linux, desktop, or game-handheld path.

sources (3)

other https://github.com/shermp/Pico-ASHA/issues/56 "Having a better GUI to test and pair with will make testing easier" 2026-05-08

other https://github.com/thewierdnut/asha_pipewire_sink/issues/44 "Does this change anything for ASHA hearing aids in general?" 2026-06-05

other https://github.com/shermp/Pico-ASHA/issues/25 "I'll return the Pico and just have to buy their official accessories" 2025-04-10

accessibilityhearing-aidscochlear-implantlinuxbluetooth