Open Source Launch

This page describes the production-ready open-source surface for gig.

The goal is not to add more features for launch. The goal is to make the existing vertical slice easy to understand, try, trust, and contribute to.

Positioning

gig answers one release-day question:

Did every change for this ticket actually make it into the release?

The strongest public demo path is:

gig trace ABC-123 --target prod
gig verify ABC-123 --target prod
gig guard ABC-123 --target prod
gig packet ABC-123 --target prod

That story is concrete, terminal-native, and useful to release managers, QA, platform teams, and engineers who maintain multi-repository delivery flows.

Launch-Ready Surface

  • README explains the product in one screen and shows a terminal demo.
  • Quick start gives a short path for first-time users.
  • CLI spec documents stable commands and JSON-friendly automation.
  • Demo and portfolio docs explain the work in a way employers can evaluate.
  • Contributing guide explains architecture, tests, and PR expectations.
  • Security policy explains responsible reporting and sensitive areas.
  • Issue forms route bugs, feature requests, and release-audit gaps separately.

Star-Worthy Slice

The public slice should stay narrow and strong:

  • remote-first ticket audit
  • target intent with --target prod
  • release truth graph with evidence gaps
  • CI gate through gig guard
  • release packet through gig packet
  • deterministic tests and docs build

Avoid marketing claims that are not backed by command output. Prefer commands, screenshots, JSON examples, and reproducible fixtures.

Contribution Funnel

Good outside contributions should map to one of these lanes:

  • provider evidence improvement
  • topology inference improvement
  • clearer release truth findings
  • export or JSON contract improvement
  • docs that match implemented CLI behavior

Issues should include the real release question, the provider involved, current manual workaround, and what evidence is missing.

Launch Blockers

Before calling the repository open source, the owner should:

  • Add an explicit license file.
  • Enable GitHub private vulnerability reporting if available.
  • Confirm public docs URLs and install scripts point at the intended owner/org.
  • Cut a tagged release and verify installer, npm package, and docs site.
  • Decide whether sample screenshots or demo data need further redaction.

Without an explicit license, the repository can be public but is not a complete open-source launch.