Skip to content

Public Release Boundary

OrganicOS is now being shaped into a public website and future GitHub release path. That makes the release boundary a first-class part of the project.

The rule is simple: publish the story, source, screenshots, docs, and builds only after private runtime state has been removed.

The following can usually be published after review:

  • project overview and architecture summaries;
  • screenshots, gallery images, and visual identity assets intended for public use;
  • source code from a selected canonical repository;
  • README files, docs, and contribution notes;
  • build instructions that do not include secrets or private endpoints;
  • release notes, checksums, and version information;
  • GitHub links and public repository metadata.

The following must not be published without a redaction pass:

  • tokens, API keys, passwords, cookies, or browser/session state;
  • private network addresses, private service URLs, and tailnet-only routes;
  • Home Assistant, media server, admin, or assistant runtime credentials;
  • WSL handoff artifacts or user-state bundles;
  • generated caches, logs, node modules, build output, and backup directories;
  • screenshots that expose private account data, hostnames, devices, or credentials;
  • unreviewed service maps, port maps, and local configuration dumps.

Before adding a download link or publishing a repository, verify:

  1. The source repository is intentionally selected.
  2. The license and upstream attribution are clear.
  3. The build command works.
  4. The artifact has a checksum.
  5. Private state has been removed.
  6. The README explains what is current, experimental, or future-facing.
  7. The Portal links point to the right public page.

The Portal is the first public organizing surface. Broader downloads and repository publishing should follow the GitHub Cleanup Plan and the Repository Map.