2026–2029 operating plan — 1,000 Stars and durable ownership
Status: active from 2026-08-11
Planning horizon: 2026-08-11 through 2029-12-31
Audited public baseline: 837 Stars, 29 open issues, 0 open pull requests
Base milestone: 1,000 Stars by 2027-06-30
Completion rule: the Star milestone and every quality condition in the 1,000-Star roadmap must pass.
This document extends the milestone roadmap into a three-year operating system. It answers four questions that a launch plan alone cannot answer:
- what must become true before 1,000 Stars;
- what the project does if growth is early, late, or flat;
- how releases, support, and evidence continue after the milestone;
- how ownership moves beyond one maintainer without weakening review.
The dated baseline was rechecked through read-only GitHub API calls on 2026-08-11. Counts are observations, not a permanent truth. Weekly snapshots, not edits to this paragraph, are the source for future trend decisions.
1. Strategic mandate
The product promise remains:
The shortest trustworthy path from a rosbag2 recording to a verified Autoware-compatible map bundle.
The project does not need to out-feature every LiDAR SLAM framework. It must make this narrower job easier to discover, safer to run, easier to diagnose, and easier to reproduce than the alternatives. The durable adoption loop is:
supported input
-> diagnosable first run
-> verified map bundle
-> reproducible public proof
-> useful report or bounded contribution
-> recommendation and Stars
-> shared maintenance ownership
Stars are the discovery checkpoint at the middle of that loop. They never authorize a release, a compatibility claim, or a research claim.
Non-goals
- no paid, exchanged, automated, or mass-solicited Stars;
- no universal sensor or algorithm promise;
- no release whose success depends on a private bag, local-only revision, unpublished image, or undocumented maintainer action;
- no promotion campaign while first-map, support, or review capacity is failing;
- no SOTA-v6 result on the product critical path. The current research route remains bounded by its own exposure, promotion, and resource gates.
2. End states by horizon
The plan has three distinct horizons. Each later horizon preserves the earlier one rather than replacing it with a larger feature list.
| Horizon | Product and trust | Adoption and community | Operating result |
|---|---|---|---|
| 2027-06 — earn 1,000 | v1 readiness 10 / 10; current stable release; no known supported P0; verified guided map path |
ten cumulative independent first maps; five recent external contributors; 1,000 Stars in two weekly snapshots | the project has earned discoverability through a useful, reproducible product |
| 2028-12 — make it routine | documented compatibility policy; repeatable install/upgrade and rollback evidence; claims remain revision-bound | a maintained recipe set; one non-maintainer owns a bounded review area; contribution queue stays runnable | releases and support no longer depend on a launch campaign or private state |
| 2029-12 — make it resilient | support and release scope fit measured capacity; public artifacts can rebuild current evidence | at least two people can execute the release/triage procedures; succession or archive path is current | the project can continue, deliberately narrow, or archive without abandoning users |
The 2028 and 2029 outcomes intentionally avoid a larger Star quota. After 1,000, retention, release freshness, successful maps, and distributed ownership are more informative than maximizing a popularity counter.
3. Critical path and parallel work
The critical path is evidence-gated:
P1 crash safety and current support triage
-> publicly reviewable source + immutable onboarding fixture
-> clean Humble/Jazzy Docker/source matrix
-> packaged guided workflow + three independent first maps
-> v1 readiness 10 / 10
-> proof-led launch and maintained contributor queue
-> ten first maps + five recent external contributors
-> 1,000 Stars + 90-day sustain audit
-> two public-input release cycles + transferred review ownership
-> compatibility and succession practice through 2029
Three activities run beside this chain:
- weekly aggregate measurement and issue intake;
- one bounded community/contributor slice;
- at most one preregistered research diagnostic.
Research can improve future capability, but a failed or unfinished research candidate cannot delay a product reliability fix, release gate, supported-user response, or contributor review.
4. Phase register
Star counts are forecast checkpoints through G3. Only evidence exits a phase.
| Phase | Window | Primary outcome | Required exit evidence | Star interpretation |
|---|---|---|---|---|
| G0 — release hygiene | 2026-08 to 2026-09 | reviewable, crash-safe candidate and honest support surface | P1 #69 safe-rejection regression passes; issue triage is applied and current; source and fixture have public identities; four-row matrix meets its transition gate | forecast 860 |
| G1 — v1 activation | 2026-10 to 2026-11 | a newcomer can install, diagnose, and finish the supported path | v1 audit 10 / 10; three accepted independent first maps; packaged --guided path |
forecast 900 |
| G2 — proof launch | 2026-12 to 2027-02 | public proof converts qualified discovery into trials | stable v1; exact UX/benchmark scorecard; short demo; two recent external contributors | forecast 950 |
| G3 — ecosystem | 2027-03 to 2027-06 | adoption and contribution repeat without private guidance | ten cumulative first maps; five recent external contributors; maintained high-demand recipes | 1,000 in two weekly snapshots |
| G4 — sustain | 2027-07 to 2027-09 | milestone traffic does not degrade product health | 90 days of current release, activation, response, and review health with no material regression | maintain at least 1,000 |
| G5 — institutionalize | 2027-10 to 2027-12 | written contracts replace maintainer memory | two release cycles rehearsed from public inputs; one bounded non-maintainer review owner | maintain at least 1,000 |
| G6 — compatibility | 2028-01 to 2028-06 | support promises have a costed lifecycle | versioned ROS/sensor support policy; clean install, upgrade, rollback, and deprecation evidence | no acquisition quota |
| G7 — ecosystem depth | 2028-07 to 2028-12 | repeated user demand, not novelty, drives extensions | maintained integration recipes and consented case evidence; stale surface retired | no acquisition quota |
| G8 — maintainer resilience | 2029-01 to 2029-06 | release and incident work survives one-person absence | release and P0/P1 tabletop exercises; two people can run core checklists | no acquisition quota |
| G9 — strategic renewal | 2029-07 to 2029-12 | scope matches demonstrated use and capacity | evidence-backed continue, narrow, transfer, or archive decision for 2030 | report current count only |
An early Star crossing does not skip a phase. A late crossing does not justify weakening a quality gate. It changes the forecast and the current constraint.
5. Quarterly outcome plan
Each quarter has one product outcome, one community outcome, and one operating decision. Work that does not advance one of them enters the backlog rather than the active WIP set.
| Quarter | Product outcome | Community/distribution outcome | End-of-quarter decision |
|---|---|---|---|
| 2026 Q3 | prevent classic scanmatcher VoxelGrid overflow from terminating the process; finish candidate/publication preflight | complete the 29-issue disposition decision and keep five runnable starter drafts | can the clean G0 candidate enter public review and the four-row matrix? |
| 2026 Q4 | close distribution and first-map v1 gates without manual assembly | accept three independent first maps and establish a bounded support cadence | is v1 releasable and supportable, not merely taggable? |
| 2027 Q1 | publish stable v1 and reproducible UX/benchmark proof | ship one canonical English demo, Japanese companion, and two contributor outcomes | did qualified traffic, receipts, and useful reports rise together? |
| 2027 Q2 | keep v1 current and maintain requested sensor recipes | reach ten first maps and five recent external contributors | are all completion conditions true with 1,000 Stars? |
| 2027 Q3 | prevent activation, upgrade, and reliability regression | absorb milestone support within declared response and review capacity | did the 90-day sustain audit pass? |
| 2027 Q4 | reproduce two releases from written public contracts | transfer one bounded review domain and retain a healthy starter queue | can G5 close without one maintainer's private state? |
| 2028 Q1 | define supported versions, deprecation windows, and evidence refresh triggers | convert repeated supported questions into recipes; retire obsolete answers | what support surface fits available capacity? |
| 2028 Q2 | rehearse clean install, upgrade, rollback, and artifact recovery | publish a six-month project health review and contributor credit | is the compatibility policy proven by execution? |
| 2028 Q3 | improve only integrations backed by repeated user evidence | produce consented, privacy-bounded case evidence | which integration deserves maintained status? |
| 2028 Q4 | remove or quarantine stale experimental/runtime surface | audit contribution setup, review latency, and ownership gaps | does ecosystem depth reduce or increase maintainer burden? |
| 2029 Q1 | run release and supported-P1 tabletop exercises | train a second operator on triage and release evidence | which procedure still has a single-person dependency? |
| 2029 Q2 | close the highest single-owner reliability or release gap | validate succession contacts and moderation boundaries | can one maintainer be absent for a release cycle? |
| 2029 Q3 | audit product fit, dependency health, and public artifact rebuildability | interview only consenting active users/contributors through public, bounded prompts | should 2030 emphasize maintenance, transfer, or new product investment? |
| 2029 Q4 | publish the selected support and release policy for 2030 | preserve contributor credit and migration/archive guidance | continue, deliberately narrow, transfer, or archive |
The 2026 Q4 distribution route begins with the canonical NDT strict
preflight. Only a 30/30 READY_FOR_DRAFT_PR result may emit its schema-bound
create-only handoff; that handoff fixes exact identities and copy but keeps
push, PR creation, force-push, mark-ready, and merge authority false. This
separates a reproducible next external transition from permission to perform
it, preventing distribution urgency from weakening the v1 gate.
6. Metrics and target ladder
The north-star operational metric remains independent verified first maps per month. It is measured through voluntary, privacy-bounded receipts; no product telemetry is introduced.
| Dimension | 2026-08 baseline | 2027-06 target | 2028-12 health target | 2029-12 resilience target |
|---|---|---|---|---|
| GitHub Stars | 837 | 1,000 in two weekly snapshots | maintain milestone; report, do not optimize | report, do not optimize |
| Accepted independent first maps | 0 | 10 cumulative | at least 24 cumulative | at least 36 cumulative |
| First-run completion | not measured | at least 80% by attempt 10 | no material regression on current workflow | current workflow remains independently executable |
| Median active operator time, fixed demo | not measured | under 10 minutes | no material regression | current contract retained or replacement migration documented |
| v1/product readiness | 8 / 10 | 10 / 10 | current supported release passes its successor gate | current supported release passes its successor gate |
| Stable release age | 11 days at plan audit | under 90 days | under 120 days or an explicit maintenance exception | declared cadence met or project state changed publicly |
| External merged contributors, trailing 180 days | 0 | at least 5 | at least 4 without a campaign spike | contribution remains possible; ownership is the stronger gate |
| Bounded review owners outside the original maintainer | 0 | candidate identified, no quota-based promotion | at least 1 | at least 1 release operator and 1 triage/review operator; one person may cover both only with a named backup |
| Untriaged open issues | 16 | 0 | 0 at monthly review | 0 at monthly review |
| Supported P0/P1 public disposition | not tracked | P0 within 7 days; P1 within 14 days | capacity-adjusted target published and met | target met or support scope reduced |
The 2028/2029 first-map values are planning floors, not usage claims. If the receipt process creates support burden or selection bias, revise the metric in a quarterly review and preserve the reason. Never infer users from clone totals.
Metric tree
| Stage | Leading signal | Lagging signal | Correct response when weak |
|---|---|---|---|
| Discovery | qualified Autoware/ROS referrals; canonical-page visits | release-bundle downloads and Stars | clarify positioning and one canonical route |
| Activation | preflight completion; attempted first maps | accepted verified maps and completion rate | stop promotion; repair setup, diagnosis, or fixture cost |
| Trust | reproducible evidence rows; actionable reason codes | repeated runs, useful reports, citations | narrow claims and close evidence gaps |
| Contribution | runnable starter queue; focused-check duration | external PRs and merged contributors | reduce setup/review cost before opening more tasks |
| Sustainability | release age; issue response; review queue; owner coverage | retained users/contributors and successful release cycles | reduce scope before adding channels or features |
7. Forecast branches
Review the forecast monthly from four-week aggregates.
Stretch: 1,000 by 2027-03-31
Continue G3 quality work and begin the 90-day sustain audit. Do not replace the remaining first-map, contributor, release, or claim gates with the Star count.
Base: 1,000 by 2027-06-30
Run G0–G3 in order. This requires approximately 15.2 net Stars per month from the 837 baseline, about 1.3 times the preceding 90-day pace.
Organic/late: crossing in 2027 Q4
Keep quality exits unchanged. If first maps and contributions improve, revise the date and continue. If they do not, use the constraint rules below before doing more promotion.
Missed milestone at 2027-12-31
Do not carry an unchanged campaign into 2028. Run a strategic reset:
- fewer than three independent first maps: the product/activation contract is the constraint; pause acquisition work;
- first maps healthy but qualified discovery flat: positioning and durable distribution are the constraint;
- discovery and maps healthy but contribution absent: setup, review latency, or task design is the constraint;
- all leading signals healthy: retain the product plan and reforecast the Star date without manufacturing demand.
G6 compatibility work still starts where needed to protect existing users. Milestone acquisition work continues only when it does not displace support, release, or ownership health.
8. Portfolio, capacity, and ownership
Until G3 closes, plan normal maintainer capacity as:
- 60% product reliability, activation, and release evidence;
- 20% distribution, issue triage, and contributor review;
- 20% bounded research.
After G3, review the split quarterly. A default 50/30/20 split favors release maintenance and ownership transfer, but measured support demand may move capacity from research. Capacity never weakens a gate; it reduces scope.
WIP limits
- one product/release slice;
- one community or contributor slice;
- one bounded research slice;
- no more than two external contributions waiting for substantive maintainer review;
- no new promotion while a supported P0, failed release gate, or growing review queue is unresolved.
Ownership ladder
Ownership is earned through repeated, reviewed work—not issue count or Star growth.
| Level | Demonstrated capability | Allowed responsibility |
|---|---|---|
| Contributor | reproduces a bounded issue and passes focused checks | authors changes and reviews documentation evidence |
| Domain reviewer | repeatedly reviews one named area and identifies unsafe changes | advisory/required review for that bounded area |
| Release operator | executes the written rehearsal from public inputs with a maintainer | prepares evidence and rollback decision; cannot self-approve own release change |
| Maintainer | sustains review judgment, support boundaries, and governance expectations | merge/release authority under GOVERNANCE.md |
By G5, one non-maintainer should own a bounded review domain. By G8, at least two people must be able to execute the core release and issue-triage procedures, with separation of author and final approver where practical.
9. Explicit external-action gates
Local implementation and public mutation are different decisions.
| Gate | Examples | Required decision |
|---|---|---|
| L0 — local preparation | code, tests, docs, offline audits, read-only GitHub inspection | covered by the active development goal |
| E1 — source publication | push branch, create/update pull request | explicit branch/push/PR authorization and exact revision review |
| E2 — artifact publication | upload fixture, create immutable GitHub/Zenodo record, publish container | explicit host, license/provenance, checksum, retention, and upload authorization |
| E3 — community mutation | label/close/comment on issues, create starter issues, enable Discussions | explicit scope and wording authorization after a live duplicate/drift check |
| E4 — stable release | create tag/release, publish packages/images, announce release | completed release audit plus explicit release authorization |
An authorization for one row does not authorize another. Waiting on E1–E4 does not block safe L0 reliability, test, documentation, or audit work.
10. Next six weeks: 2026-08-11 to 2026-09-21
This queue is the first executable slice of the three-year plan.
| Order | Bounded outcome | Evidence and stop condition | External dependency |
|---|---|---|---|
| 1 | fix P1 issue #69 so unsafe VoxelGrid integer layouts are rejected without terminating classic scanmatcher | pure boundary tests; all affected call sites fail safely; focused and full package tests; no output change for valid clouds | none |
| 2 | refresh the clean G0 candidate audit from exact origin/develop and current HEAD |
clean diff inventory, release checks, docs, and provenance; stop on unrelated research/generated input | E1 only to publish |
| 3 | present one source/fixture/community decision packet | exact revision, host options, checksums, license/provenance, proposed remote changes, rollback | E1, E2, and E3 remain separate approvals |
| 4 | run the clean Humble/Jazzy Docker/source matrix when its public identity prerequisites exist | four outcomes; all four comparable is target; at least one comparable Docker and source row is minimum transition | public source revision and published immutable fixture where used |
| 5 | apply the 29-issue disposition and publish five starter tasks only if authorized and drift-free | checker passes immediately before mutation; every change logged; no silent label removal | E3 |
| 6 | prepare the first independent validator cohort from the canonical public route | no private setup help; accepted/rejected receipts follow the existing contract | public candidate and fixture/package path |
If publication authorization is still absent at order 3, continue with local reliability and release-readiness work. Do not fabricate comparable public matrix rows or mutate GitHub to keep the calendar green.
Order 6 now has a local validator cohort launch packet. It fixes the first-batch and review WIP limits, independence/privacy boundary, support service levels, repeated-blocker stop rule, and the attempt-10 completion/time decision. Its renderer intentionally refuses to produce recruitment text until the public candidate, comparable Docker/source rows, canonical path, and copy-ready handoff all pass. It authorizes no outreach or GitHub mutation.
The packet now has a companion anonymous operating state. Its evaluator binds
accepted attempts back to the authoritative adoption ledger, limits active and
unreviewed WIP, stops on repeated blockers, enforces the attempt-10 thresholds,
and expires operational-safety observations after 48 hours. No participant
handle is copied into that state, and READY_FOR_NEXT_ATTEMPT remains distinct
from external posting authority.
The live contributor next-action card also binds the existing #422 tracking
issue to that derived state. While the cohort is waiting, paused, full, or
under review, the issue remains visible for audit but is not offered as a
starter task. This prevents a good first issue label from sending a new user
through public documentation that has not passed byte-level deployment
provenance and comparable-route gates.
New weekly growth snapshots consume only its aggregate counts, rates, state, and fixed stop reasons, so a rising Star count cannot hide a stalled or paused first-map cohort. Historical snapshots remain immutable.
Order 1 reached LOCAL_COMPONENT_RECOVERY_PASS_PUBLICATION_PENDING through
bce5a9d. The
evidence record
passes the bounded fixture, valid-output parity, real-component
unsafe-then-safe sequence, ten-run stability check, and complete 10-suite
scanmatcher CTest on Humble/PCL 1.12 and Jazzy/PCL 1.14. G0 remains open: the
revision is local-only, supported public CI has not run it, and no carrying
release exists.
The parallel contributor slice reached
LOCAL_DUAL_DISTRO_PASS_PUBLICATION_PENDING at e2a4dfc. Its
evidence record
replaces ambiguous repository-root pytest discovery with one documented,
dependency-aware command and passes both complete maintained Python suites on
Humble and Jazzy. This makes the prepared-environment focused-check route
runnable, but no external completion or duration is counted until a public
revision and separately authorized starter task are used by an independent
contributor.
11. Quarterly review contract
Use the quarterly health-review template at the end of every quarter and at each phase transition. A review must name:
- the exact source revision and evidence window;
- the current phase and every incomplete exit;
- one largest funnel constraint;
- one product slice, one community slice, and at most one research slice;
- stop/continue decisions for the preceding experiments;
- owner, review date, capacity state, and external authorization state.
A quarter with no metric improvement can still be successful if it closes a reliability or ownership risk. A quarter with more Stars is not successful if activation, support, evidence, or release health regresses.
12. 2029 completion decision
At the end of G9, choose exactly one public operating state for 2030:
- continue — demand, release health, and owner capacity justify the current supported surface;
- narrow — preserve the verified core while deprecating integrations that cannot be maintained;
- transfer — move stewardship through documented governance, artifact, credential, and release procedures;
- archive — publish a final support state, migration options, reproducible artifacts, known risks, and the last verified release.
The project is durable when any of these decisions can be made honestly and without losing the evidence users need—not only when development continues forever.