OpenSyntaxHQ is an engineer-first open-source organization focused on building practical, well-documented tools and reference implementations that make software systems easier to design, ship, and maintain. We value clarity, composability, and pragmatic engineering — not hype. Contributors are welcome from everywhere; we build together, review together, and keep the project usable for real teams.
- Libraries and tooling for developer workflows (CLI, SDKs, linters)
- Small, focused infrastructure and ops utilities (deploy helpers, monitoring helpers)
- Reference architectures and patterns (examples, templates, starter repos)
- Experiment repositories for new ideas that can graduate to maintained projects
- Read
CONTRIBUTING.mdandCODE_OF_CONDUCT.mdin this organization. They explain workflow, expectations, and how we treat each other. - Look through Issues and Discussions to find tasks or proposals. Issues = bugs/feature requests; Discussions = design and community conversations.
- Pick an issue or propose a small scoped one. If it’s a proposal, start a discussion first to get buy-in.
- Fork or branch in the relevant repo, implement changes with tests and documentation, open a pull request, and request review.
- Open an issue or join the discussion before doing major work.
- Work on a feature in a dedicated branch:
username/short-description. - Keep PRs focused and small. Include tests and short docs for user-facing changes.
- Use clear commit messages (imperative, short). Example style:
feat: add X,fix: correct Y. - PRs require passing CI and at least one approving review from a maintainer or reviewer before merge.
- Maintainers may request changes — iterate on feedback until the PR is ready.
- Code should be readable and documented: prefer clarity over cleverness.
- Include tests for behavior changes. New code without tests may be rejected.
- Public APIs should be stable or explicitly marked experimental.
- Follow license and contribution rules stated in individual repos.
- Pragmatic: Prefer solutions that solve real problems.
- Composable: Small, well-scoped modules that work together.
- Documented: Every project ships a short README and usage examples.
- Respectful: Critique code, not people. Follow the Code of Conduct.
- Sustainable: Avoid long-lived one-off designs; prefer maintainability.
- Use Issues for concrete tasks and bugs; Discussions for proposals and community coordination.
- Team membership and maintainers are visible under the People tab. Maintainers have merge rights for their repos.
- If unsure where to start, open a discussion and label it
help wantedorproposal.
- Repositories will specify a license in their root. We recommend permissive licenses (MIT, Apache-2.0) for most projects, but each repo may choose the most appropriate license for the code it contains.
OpenSyntaxHQ is about building useful, dependable developer tooling and examples. If you can explain a problem in a sentence and deliver a small, tested fix or example, you’re already contributing in the right spirit.