OpenForge

Project Overview

OpenForge is a reusable Blueprint + Engineering Standards + Reusable Templates foundation for creating, evolving, deploying, operating, and maintaining high-quality open-source software.

Instead of reinventing repository structures, documentation conventions, CI/CD pipelines, supply chain security, and release governance for every new repository, OpenForge provides a battle-tested baseline derived from active production OSS projects.

Without imposing a specific programming language, runtime, or application framework, OpenForge establishes a practical engineering baseline that preserves project autonomy while maintaining platform-wide quality invariants.

Three-Tier Model

OpenForge separates Policy, Implementation, and Evidence into three distinct layers:

Core Principles

All OpenForge standards and templates adhere to these foundational principles:

• Dual-Language Documentation Policy: English is the canonical project language; Korean is a first-class translation. User-facing Markdown follows the <name>.md and <name>-ko.md pairing rule.
• Secure & Reproducible by Default: Projects must be reproducible, documented, testable, observable, accessible, and secure by default.
• Transparent Change Management & ADRs: GitHub Issues and Pull Requests serve as the primary change-management mechanism. Critical architectural decisions are recorded as ADRs (Architecture Decision Records).
• CI Quality Gating: All changes must pass build, test, lint, and security checks in CI before merging.
• Supply Chain Governance & Impact Analysis: Dependency compatibility alone does not justify immediate adoption of new releases. Runtime, toolchain, and dependency changes require workflow-wide impact analysis per Change Management.
• Trust Boundaries for AI Agents & Local Instructions: AI agents and repository-local instructions (AGENTS.md, CLAUDE.md) are treated as potentially untrusted execution inputs with explicit permission and sandbox boundaries per AI Engineering Security.
• Risk-Based Governance & CI Resilience: Even single-maintainer projects maintain automated governance controls without excessive manual overhead. CI outages must never force maintainers to bypass security gates blindly.
• Time-Bounded Security Exceptions: Intentional deviations from the baseline must be documented with rationale, scope, and expiration dates.

Project Lifecycle Model

OpenForge follows a closed-loop lifecycle from inception to operations, incident learning, and continuous standards improvement:

Idea
  ↓
Project Definition (Purpose, scope, license definition)
  ↓
Repository Bootstrap (Directory layout, GitHub templates)
  ↓
Documentation + Architecture (README pairs, ADR structure, inventory)
  ↓
Standards + Template Adoption (CI/CD, Docker, K8s, security baseline)
  ↓
Implementation (Language tooling, code intelligence, Makefile)
  ↓
Change Impact / Supply Chain Review (Dependency validation, version pinning)
  ↓
CI / Security / Testing (Static analysis, unit/E2E tests, container scans)
  ↓
Release / Publish Verification (SemVer, Changelog, SBOM, signature validation)
  ↓
Operations / Observability (Health checks, metrics, logs, backup runbooks)
  ↓
Maintenance / Incident Learning (Lessons log, regression testing)
  ↓
Lessons / Metrics (Maturity scorecard evaluation)
  ↓
OpenForge Improvement (Feedback into shared standards and templates)

Continuous Improvement Loop: Standard → Apply → Measure → Learn → Improve → Standardize

Engineering Standards Portfolio

OpenForge defines 29 granular engineering standards covering the full spectrum of open-source software engineering:

1. Core & Repository Management

• Repository Standard: Standard directory layout, root-level invariants (LICENSE, SECURITY.md, CONTRIBUTING.md).
• Documentation Standard: Dual-language pairing, documentation models, glossary, and architecture diagram conventions.
• GitHub Standard: Issue Templates (Bug, Feature, Architecture), PR Templates, CODEOWNERS, labeling, and branch protection rules.
• Development Standard: Language-specific tooling baselines (Go: gofumpt/staticcheck, Node/TS: ESLint/Prettier, Python: Ruff), unified Makefile task automation.
• Engineering Tooling Standard / Tooling Matrix: Toolchain selection, configuration management, and language tool matrix.
• CI/CD Standard: Continuous integration and deployment pipelines and pre-merge validation quality gates.
• Internationalization Standard: UI multilingual resource structure and translation key management standard.

2. Security & Supply Chain Governance

• Security Standard: Multi-stage builds, non-root users, read-only root filesystems, NetworkPolicies, PDBs, and Seccomp profiles.
• Supply Chain Security: Immutable package identity verification, signature and checksum validation, untrusted registry isolation.
• Package & Artifact Identity: Immutable package provenance, checksum, signature, and metadata verification.
• Plugin Supply-Chain Intake: Integrity verification, runtime capability constraints, and plugin intake pipelines.
• CI/CD Security: Principle of least privilege for CI tokens, immutable GitHub Actions SHA pinning, release isolation.
• CI/CD Resilience: Safe fallback strategies and risk mitigation during CI platform outages.
• Developer Environment Security: Local workstation boundaries, credential isolation, and secure tool execution.
• AI-Assisted Engineering Security: Local execution permission boundaries, prompt injection defense, and sandboxed AI agent execution.
• Container, Kubernetes & IaC Security: Container image hardening, non-root execution, NetworkPolicy, and IaC security.
• Secrets & Machine Identity: OIDC-based cloud federation, short-lived tokens, secret scanning, and zero hardcoded credentials.
• Vulnerability Management: Vulnerability triage procedures, security patch workflows, and prevention via lessons-log.md.
• Security & Incident Response: Incident triage, mitigation procedures, and lessons-learned test codification.
• Security Exceptions & Waivers: Time-bounded exception handling, risk ownership, and expiration auditing.

3. Change Management, Release & Compliance

• Change Management & Impact Analysis: Full workflow impact analysis before updating runtimes, dependencies, or build tools.
• Upgrade & Compatibility Engineering: Backward-compatibility testing, version support windows, and drift prevention.
• Reproducible Build: Environment and timestamp pinning for deterministic build artifacts.
• Release Standard / Release Security: SemVer, Keep a Changelog format, SBOM generation, and cryptographic artifact signing.
• Maintainer Governance: Risk-based automated governance and approval workflows for single-maintainer and multi-maintainer repositories.
• OSS Compliance: Apache 2.0 licensing, standardized SPDX headers, and dependency license compatibility audits.
• Reference Practices Audit: Extracting, codifying, and validating repeatable patterns from real OSS projects.

Reusable Templates Catalog

The templates/ directory in the OpenForge repository provides ready-to-use implementation templates:

templates/
├── github/          # Issue / PR templates, CODEOWNERS patterns
├── workflows/       # CI, release, SBOM, supply chain validation workflows
├── scripts/         # Toolchain verification, lockfile sanity checks, helper scripts
├── policy/          # Dependency review policies, plugin intake rules, waiver formats
├── container/       # Minimal multi-stage Dockerfile baselines
├── kubernetes/      # Deployment, Service, Ingress, NetworkPolicy, PDB, Kustomize
├── gitops/          # Argo CD App-of-Apps and GitOps deployment blueprints
├── identity/        # OIDC / Keycloak / OAuth2 integration contracts
├── observability/   # /healthz, /readyz, Prometheus metrics, OpenTelemetry contracts
├── backup/          # Backup and disaster recovery verification runbooks
├── offline/         # Air-gap bundle manifests and trusted plugin catalogs
└── design/          # README designs, architecture diagrams, status badges

Template Usage Principle: Templates are conservative starting points, not universal drop-in configurations. Always customize paths, permissions, domain names, image registries, and versions according to the target repository's threat model.

Reference Implementation Metrics

OpenForge provides a practical Maturity Scorecard to evaluate repository engineering quality and standards compliance:

Scoring System

• 2: Fully implemented and automated via CI/CD where applicable
• 1: Partially implemented or manually maintained
• 0: Missing or non-compliant
• N/A: Not applicable to the specific project type (e.g., UI i18n for CLI tools)

Key Evaluation Areas

Reference Implementations

OpenForge standards and templates are extracted from and validated against active production open-source projects:

Getting Started

A step-by-step roadmap for adopting OpenForge in new or existing projects:

# 1. Clone OpenForge and inspect templates
git clone https://github.com/dasomel/openforge.git
 
# 2. Copy base repository layout and GitHub templates
cp -r openforge/templates/github/ .github/
cp openforge/templates/design/README-template.md README.md
cp openforge/templates/design/README-template-ko.md README-ko.md
 
# 3. Add language toolchain and CI workflows
cp openforge/templates/workflows/ci.yml .github/workflows/ci.yml
 
# 4. Customize permissions, paths, and versions for your environment

For detailed guidance, see the Getting Started Guide.

Documentation Index

Explore detailed technical documentation on the OpenForge portal:

Links

• GitHub Repository: dasomel/openforge
• Engineering Standards: OpenForge Docs on GitHub
• Reusable Templates: OpenForge Templates on GitHub
• Korean Documentation: OpenForge Korean Portal