Open-sourcing three AI-infrastructure projects for a US startup

Results at a glance

• 3projects taken from private code to public repositories
• 79commits of mine preparing the repositories for release
• 2licence models matched to the business: Apache-2.0 and source-available
• 5five-star reviews from the same client over repeat orders

Who did what

The client's engineers wrote the product code and handed it over. I owned everything that turns code into a public open-source project: structure, naming, history, licensing, rules, security, automation, documentation and launch. The client and project names are left out on purpose.

The three projects

• An open specification for LLM deployments. A YAML standard backed by a JSON Schema that describes what a model needs in production: GPUs, batch limits, serving and scaling targets, and governance rules.
• A read-only GPU-waste scanner for Kubernetes. A Python CLI that finds idle GPUs, oversized GPU tiers and unscheduled GPU nodes in vLLM clusters.
• A production-readiness knowledge base. Vendor-neutral checklists and playbooks for running LLMs in production, from Day-0 to Day-2.

1. Make the history safe to publish

Going public publishes every commit ever made, not just the latest code. Before any repository went public I:

• scanned the full history for secrets, keys, tokens and internal hostnames;
• removed internal-only files, test outputs and anything that referenced private infrastructure;
• chose between rewriting history and starting the public repository from a clean initial commit, and made sure no private branches or tags were pushed by accident.

2. Repository structure and naming

A visitor decides in seconds whether a repository is serious. Each one got a predictable layout:

README.md  LICENSE  CONTRIBUTING.md  CODE_OF_CONDUCT.md
SECURITY.md  GOVERNANCE.md  CODEOWNERS
.github/ISSUE_TEMPLATE/   .github/PULL_REQUEST_TEMPLATE.md
.github/workflows/        docs/   examples/   schema/ (or src/, tests/)

Folders and files got clear, lowercase, hyphenated names that say what they contain, and documentation is versioned alongside the code (e.g. docs/v0.1/, schema/v0.1/) so links don't break when the spec moves on.

3. GitHub SEO: names, descriptions, topics

Open source only helps go-to-market if the right people find it. For every repository I wrote:

• The name. Short, lowercase, memorable and searchable.
• The description. One sentence with the main keywords first, which is what GitHub search and Google show.
• Topics. Up to 20 focused topics per repository (for example kubernetes, llm-inference, vllm, mlops, gpu, model-serving), so they appear on GitHub's topic pages.
• The README. A clear H1, a one-line value proposition, the problem it solves in plain words, badges, a quick start that works copy-paste, and keyword-rich section headings. Images have alt text.
• The rest. The homepage link, a social preview image for link sharing, and pinned repositories on the organisation profile.

4. Licensing

The specification and the scanner went out under Apache-2.0, because adoption is the goal and companies' legal teams accept it easily. It also includes a patent grant. The knowledge base went out under a source-available licence, free to read and use but protected from being repackaged by competitors. Each repository has the full licence text, and the licence is shown in the README badge and detected by GitHub.

5. Commit and merge conventions

• Conventional Commits (feat:, fix:, docs:, chore:, release:), so history reads like a changelog and release notes can be generated from it.
• A protected main branch. All changes go through feature branches and pull requests.
• Squash merging as the default, so every pull request lands as one clean, revertible commit with the PR title as its message. Merged branches are deleted automatically.
• Semantic versioning with git tags (v0.1.0), a CHANGELOG.md, and GitHub Releases with generated notes.

6. Rulesets on the default branch

• Require a pull request before merging, with at least one approval.
• Require review from CODEOWNERS for the files they own.
• Dismiss stale approvals when new commits are pushed.
• Require CI status checks to pass before merging.
• Block force pushes and branch deletion, and require a linear history.

7. Security and vulnerability handling

• SECURITY.md with supported versions and how to report a vulnerability privately, plus GitHub's private vulnerability reporting switched on, so reports never start as public issues.
• Dependabot alerts and security updates for dependencies and GitHub Actions.
• Secret scanning with push protection, so a leaked token is blocked before it lands in history.
• Least-privilege workflows, with read-only GITHUB_TOKEN permissions by default.
• The scanner's Kubernetes RBAC is documented as read-only, so users can audit exactly what it can touch.

8. Workflows (GitHub Actions)

• CI on every pull request.
• Schema validation. Every example specification is validated against the JSON Schema, so a broken example can never be merged.
• Release and package publishing. Tagged releases build and publish the package automatically.

9. Community files and contribution flow

• CONTRIBUTING (setup, branch naming, commit style, PR checklist), CODE_OF_CONDUCT and GOVERNANCE (who decides and how).
• Issue forms for bugs and feature requests, a pull-request template, and labels including good first issue and help wanted, which GitHub surfaces to new contributors.
• GitHub Discussions for questions, so the issue tracker stays for real work.
• Every item on GitHub's Community standards checklist complete.

In the client's words

Ameer's knowledge about the open source strategy including licensing, workflows, issues, discussions, etc. is very thorough and deep. He is also very meticulous and committed to the delivery timelines.

US client, Fiverr review, quoted verbatim. Four more five-star reviews came from the same client.

Outcome

All three projects are public, discoverable and still actively developed by the client, and they sit at the centre of the company's go-to-market. The client came back for repeat orders from 2 days to 4 weeks long and called the work instrumental to their launch.

The full checklist I follow is in my post How I take company code open source on GitHub. I used the same playbook for my own open-source SMS gateway exporter.