f8f9756687
Christian: 'Let's have every NextCloud thing come back as well-rated as it should be. It's deserving of the same level of scrutiny everybody else is.' Priority 20, above Slack and Kino, because this is the replacement we recommend to clients. If we will not grade our own recommendation, nothing else we publish is worth reading. 14 products: Server, Files, Talk, Mail, Calendar, Contacts, Photos, Notes, Deck, Office, Passwords, the spreed signaling stack, and both migration bridges (Dropbox, Google Drive). The migration apps matter most, because a migration tool that does not work makes the off-ramp a slogan. Nextcloud Server is the one to grade first. Every app score is conditioned on the platform underneath it, so grading the apps before the server would be measuring the second thing. None of these has a score yet, and none will get one until it has evidence. The recently-added attestation ladder and the reproducible-build cap both apply: Nextcloud is open source but has no reproducible build practice yet, so verifiability cannot exceed 3 on any of these today no matter how good the code is. |
||
|---|---|---|
| deploy | ||
| packages | ||
| .gitignore | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
bigtech.sucks — Draw the Line
V0.1 scaffold per master spec. A retro frontier game that scopes Big Tech exposure and sequences the off-ramp.
Structure
packages/
core/ Render-agnostic game logic, seed data, scoring
core/db/ The living database: schema, seeds, build + verify
web/ React + Vite SPA (V1 funnel)
server/ Minimal waitlist API (email + channel only)
The living database
The database is the source of truth. The site is a view over it. Nothing in the UI may
hardcode a number that lives in bigtech.db.
npm run db:build # rebuild the db, apply seeds, verify, regenerate the catalog
npm run db:verify # run the instrument's own checks against the existing db
packages/core/db/bigtech.db is built, not committed. What is committed is the part that
matters: db/schema.sql, db/seed/*.sql, and db/build.mjs.
The build refuses to pass if a score breaks the instrument's own rules:
- dimension weights must sum to 100
- every stored
weighted_totalmust recompute from its scores - every grade must match its band
- every score must carry a written rationale
- no tier-4 claim may attach to a scored dimension
- the reproducible-build caps are enforced, not documented: no reproducible build caps verifiability at 3, an experimental one at 6
A product with no assessment surfaces as unassessed. It is never given a guessed number.
That is why the 43 legacy roster entries sit in the database as placeholders and exactly one
product carries a real score.
Adding an assessment
- Write
packages/core/db/seed/000N-<slug>.sqlusing the shape in0001-signal.sql. - Every score needs a
rationaleand at least three tier-1 or tier-2evidencerows. npm run db:build. If it fails, the report is not ready to publish.
What the numbers mean
See the instrument spec. Scores are 0 to 100, and a weighted average is not the headline: the weakest dimension is, because a 90 with a 5 on local data exposure is a 90 that will leak.
Quick start
npm install
npm run build -w @bigtech-sucks/core
npm run dev # web on :5173
npm run dev:server # waitlist API on :3001
V1 flow
Welcome → Meet Red → Draw the Line → Overworld → Showdown → Homestead → Reveal (Binary Ranch) → Waitlist
Governance
- Creative assets are candidates — director approval required before ship
- Company name revealed only at homestead/reveal phase
- §13 open decisions are not silently resolved (see
packages/core/src/data/config.ts) - Client-side sovereignty report; server stores waitlist fields only
Roadmap
- V1.5: Terminal/SSH render (Go + Charm)
- V2: Concierge migration, journey chronicle, physical fulfillment (stubs in
v2-stubs.ts)