Best Open-Source Startup Event Tools & Agents (Updated Weekly)

Four findings, and two of them correct things we told you last week.

1. We were wrong about `luma.com/waterloo`. It is a real city page. Last week we said it "resolves to an unrelated event page from a past cohort" and used it as the headline example of Luma's patchy city coverage. That was wrong. It resolves to a genuine Waterloo discovery place and returned a full event list this week — eleven startup and AI events after filtering, including most of Waterloo Tech Week. We're flagging it here because it was load-bearing: it was the evidence for "city-page coverage silently fails for mid-size cities," and that argument is now weaker than we made it sound.

2. `luma.com/ottawa` genuinely is a dead end, and now we know what it is. It's a community calendar — "Ottawa AI and Tech Community" — not a city discovery page, and it has zero upcoming events. Its ICS feed is live and returns an empty calendar. So the "mid-size cities fail" point survives, but on a sample of one rather than two.

3. There is a real unauthenticated Luma discovery endpoint, and we used it. Here's the honest tension. `api.lu.ma/discover/get-paginated-events` returns clean JSON — name, start time, URL, host, venue — with no key and no account, and it paginates properly where the rendered page lazy-loads. It is also exactly the kind of undocumented endpoint this page has twice told you not to point anything at. We used it this week because it was the difference between a complete sweep and a partial one, and we're not going to recommend a practice publicly while quietly doing the opposite. Our position: it works, it's undocumented, it can change or close without notice, and it carries a terms-of-service question we can't resolve for you. Prefer ICS. Read rendered pages where ICS doesn't exist. If you use the discover endpoint anyway, know you're building on something with no stability promise — and keep it away from anything you sell.

4. The ICS feeds are the real find, and they're the part that keeps working. Every Luma calendar exposes `https://api.lu.ma/ics/get?entity=calendar&id=` and returns a standard VCALENDAR with no key and no browser. We verified four this week: Waterloo Tech Week (124 events), MaRS Discovery District (18), Communitech (16) and the dormant Ottawa one (0). This is a published, standard interface — it survives your browser automation breaking, it survives your scraper breaking, and a normal calendar app can subscribe to it. If you build one thing from this page, build the ICS subscriber.

One limit worth documenting: Luma's authenticated endpoints don't accept a browser session — `get-subscribed-calendars` returns 401 even from a signed-in tab. The calendars you personally follow are not reachable programmatically. Only calendars you can name are.

And a note on last week's outage: our browser automation failed on every page last week, including `example.com`. It worked normally this week from the same codebase against the same sites — consistent with a transient fault. The advice stands regardless: have two ways in, and make the failure loud.

One tool. frm (15 stars, MIT) builds pre-meeting briefs from your CardDAV contacts and recent email, and ships a SKILL.md so an agent can drive it. Honest limitation: it only knows what you already know. It does no external research on speakers or attendees, which is the half that actually takes time.

We filled that gap by hand again this week, and it got faster. Organizer speaker pages are usually plain HTML lists — one festival's directory gave us 230+ named speakers with titles and companies in a single page read, a SaaS conference gave 80 more, total time under ten minutes. What it did not give us was verified LinkedIn URLs. Those still have to be confirmed one at a time, and speaker-page links are frequently auto-generated LinkedIn search URLs rather than real profiles. That's a trap worth knowing about.

Monica is built for friends and family, not deal flow, and its last stable release is v4.1.2 from May 2024. PingCRM is the most interesting for post-event work — it merges Gmail and Telegram into one timeline and drafts follow-ups it never auto-sends, which is the correct default after you've met forty people and can't remember which conversation was which. Run it with the LinkedIn extension switched off; that extension is the part most likely to break or get an account flagged.

Eleven jobs have no good open-source tool: no aggregator for startup or VC events; no legitimate Luma search API (an undocumented discovery endpoint works and ICS feeds are properly supported, but there's no documented queryable interface); no Eventbrite discovery API; no maintained Meetup client; nothing that de-duplicates one event across platforms; no attendee or speaker research tool; no agenda triage; no working badge or business-card capture; no free post-event enrichment; no event-aware CRM; and no event category in the MCP registries.

One trap: the GitHub topics are false friends. `event-aggregation` is dominated by the .NET design pattern, `luma` by Luma AI video and the Magento Luma theme. There's no topic where this category actually lives.

Eight steps. Step 3 has been rewritten again this week, and it now leads with ICS.

1. Seed from the two open datasets — `developers.events/all-events.json`, `all-cfps.json`, and Confs.tech's per-year files. Free, no code.

2. Accept that this misses every startup event, and fill the gap by hand. Keep a curated seed list of accelerator, VC and ecosystem calendars for your region. No tool exists; pretending otherwise is the main failure mode.

3. Subscribe to ICS feeds first; read pages second. Every Luma calendar publishes one at `api.lu.ma/ics/get?entity=calendar&id=` — a standard VCALENDAR, no key, no browser, no undocumented endpoint. Build your seed list of calendar ids once and this step needs no automation ever again. Where no feed exists, Luma city pages and Eventbrite browse pages render fully in an ordinary browser.

4. Normalise and de-duplicate. Fuzzy-match on name plus start date plus city. Roughly a hundred lines you write — our own sweep produced five duplicate pairs this week.

5. Score events against your thesis with an LLM step. Where an agent earns its place, and where no skill exists to copy.

6. Store survivors in Twenty or EspoCRM as a custom object. You define the event object yourself.

7. Prep with `frm` plus a manual pass over the speaker list. Treat any LinkedIn URL on a speaker page as unverified until you've opened it.

8. Close the loop with PingCRM. LinkedIn extension off.

Steps 1, 7 and 8 are genuinely served by open source. Steps 2, 4 and 5 are code you write. That ratio is the honest state of this category, and it's why most founders end up with a spreadsheet instead.

Three verification rules to steal. The most common failure in event data is the wrong year — if the year isn't explicit on the organizer's own page, discard the record rather than inferring it. Never let a discovery step fail silently; an empty list looks identical to a quiet week. And, new this week: check whether a source is dead before concluding a city is. We wrote off `luma.com/waterloo` last week on one bad read. One retry would have caught it.