Neighborhood Commons · Developers

Build on the Neighborhood Commons.

Tell us about your app. We'll send a verification code, issue your service key, and route a one-time operator review. Reads work immediately; writes activate when we approve — usually within a day.

The deal, in one breath. Reads are free. Writes are licensed CC BY 4.0 — other apps in the ecosystem can mix and remix anything you contribute, with attribution back to you. Public information is welcome. Copyrighted material you don't have rights to is not.

What kinds of contributions fit — and what doesn't

Three shapes of contribution, all welcome:

First-party publishing. You're building an app that lets people post things they run. "I'm building a tool where yoga teachers across Philly post their class schedules." The yoga teacher asserts their own offering via you.
Proxying public information. You're collecting public facts that already exist on the open web. "I'm pulling event listings from venue websites across South Philly into a single feed." Public info is public; bringing it into the Commons makes it discoverable to every other app.
Witnessing with evidence. You're capturing things observed in the world. "Users of my app photograph flyers they see on telephone poles, and I OCR them into structured events." The flyer is public; the evidence is the photo.

What's not permitted:

Copyrighted text, photos, video, or audio you don't have rights to redistribute under CC BY 4.0. (You can link to it from a description, but the description itself must be yours or rights-cleared.)
Personal information about individuals. The Commons holds zero PII by design. The entities you publish are organizations, venues, performers, classes — not individual private people.
Content you haven't verified is real. Confidence isn't required; care is.

There's a market here, and quality matters. Consumer apps that read from the Commons filter what they surface. App A might only show events from first-party verified organizations. App B might show everything but visually mark unverified entries. App C might block-list contributors whose data is consistently wrong. If the information you contribute is sloppy or suspect, downstream apps will rightly filter it out — and you'll have done a disservice both to your own work and to the people you were trying to support. Conversely, accurate well-attributed contributions get picked up everywhere and compound your reach.

The two questions below are how we get a feel for the shape of what you're doing. Be plain and specific — there's no special phrasing we're listening for.

Email * We'll send your verification code here.

App name * How readers will see you. "Via Merrie." "Via Holler." Keep it short.

Tagline * One-liner. Up to ~80 chars renders well in splash cards.

Description * ~2000 chars. Plain text for now.

App URL * Where users go to use your app.

Who it's for (optional)

Category (optional) Free-form, e.g. "publishing", "discovery", "civic".

What you're building * A paragraph is plenty. Name the data shape (events, hours, schedules, broadcasts) and the entities involved. Concrete is best — "I'm collecting public yoga-class schedules across Philly," or "I'm building a tool where chess clubs post their meetups," or "I'm OCR-ing flyers my users photograph." Any of those reads cleanly.

Verification process * How do you confirm the publisher of your content has authority over what they're publishing? Whatever fits: "I scrape venue calendar pages and de-dupe — the venues already post these publicly." Or: "Teachers create an account in my app and add their own classes." Or: "Users upload a photo of the flyer with each submission." Any of those reads cleanly.