Partners / Contributions
Contributions / Open Source
Contribute to inAi Open Source
Focused contributions to public tools, experiments, utilities, and reference projects.
inAi releases selected AI-native software in the open so builders can use it, inspect it, learn from it, and improve it. Focused contributions are welcome when they fit the purpose and current stage of the project. Each repository is different, so the best contribution path begins with the project itself.
Read the current guidance, search existing issues, and open an issue before investing in a substantial feature or architectural change. A small, well-explained improvement is usually more useful than a broad proposal.
Start with the project
inAi's Open Source portfolio includes active tools, experimental prototypes, reference utilities, and legacy projects. Those labels matter. They describe how a repository should be read and what kind of contribution is likely to fit.
Project needs change over time. The repository, its current issues, and its contribution guidance are the source of truth for technical setup, review expectations, licenses, and what is useful now.
Contribution is not only code
Different projects need different kinds of work. Depending on the repository and its current stage, a useful contribution may take one of the following forms.
Code and focused fixes
Correct a reproducible defect, improve reliability, or make a small implementation change that fits the project's current purpose.
Tests and issue reports
Add useful coverage or report a problem with the environment, reproduction steps, expected result, actual result, and any evidence needed to understand it.
Documentation and examples
Clarify installation, explain behaviour, add a minimal example, improve troubleshooting, or correct instructions that are incomplete or out of date.
Compatibility and developer experience
Improve packaging, installation, error messages, platform or provider compatibility, or the local development workflow.
Interface and accessibility
Where a project includes a user interface, improve clarity, navigation, keyboard use, accessibility, or the flow of a real task.
Security reports
Report suspected vulnerabilities privately. Security findings do not belong in ordinary public issues or pull requests.
Before you begin
A few minutes of alignment can prevent days of work on a change that does not fit the project.
Read the repository
Start with the README, current status, contribution guidance, security policy, license, setup instructions, and test documentation where they are available.
Search existing work
Check open and closed issues and pull requests before creating a duplicate report or implementation.
Decide whether to open an issue first
Small, self-contained corrections may go directly to a pull request when repository guidance permits. Open an issue first for new features, architectural changes, new providers or major dependencies, changes to public interfaces, security defaults, or broad rewrites.
Keep the scope focused
Solve one clear problem. Avoid mixing unrelated cleanup, redesign, dependency changes, and new features into the same contribution.
Test and document the result
Use the level of verification appropriate to the project. Explain what you tested, what you could not test, and whether the change affects behaviour, setup, interfaces, or documentation.
Submit a clear issue or pull request
Explain the problem, the proposed change, the scope deliberately left out, the verification performed, and any known limitation. Link the relevant issue when one exists.
Useful beats broad
A useful contribution identifies a real object: a repository, file, command, setup step, behaviour, test, example, or interface. It explains what happened, what was expected, and why the difference matters. It then proposes a change small enough to understand and review.
A strong issue or pull request normally includes:
The project and part of the project involved.
The problem or opportunity being addressed.
Reproduction steps or relevant context.
Expected behaviour and actual behaviour.
The proposed change and its intended scope.
How the change was tested or checked.
Known limitations or untested cases.
Documentation changes where behaviour or setup has changed.
Any issue, discussion, or earlier work that provides context.
Clear evidence and a focused change are more useful than a large declaration that a project should be different.
What to expect after submission
Contributions are considered in relation to the project's purpose, current stage, technical quality, clarity, maintainability, and current priorities. Review timing varies by project, scope, and available capacity.
A proposal may be accepted, revised, deferred, partially adopted, or declined. A useful idea does not always fit the project at that moment, and submission does not guarantee review, merge, release, or an ongoing maintainer role. Opening an issue before substantial work is the best way to reduce unnecessary effort.
Public repository history is the normal record of authorship. Additional acknowledgement may be used where appropriate.
Do not assume that an issue, pull request, or contribution request is paid work. Sponsored, commissioned, or ongoing work must be agreed separately in writing before it begins. Submitting or accepting a contribution does not by itself create employment, a contract, an internship, a partnership, or authority to represent inAi.
Keep public contributions safe to review
GitHub issues and pull requests are public. Do not include credentials, tokens, personal information, confidential material, private datasets, customer or employer data, proprietary code, or local files that should not be public. Use synthetic or sanitised examples where evidence is needed.
Only submit material you have the right to share. Each repository's license and contribution instructions are authoritative.
Regardless of which tools were used to create it, the person submitting a contribution remains responsible for understanding the change, testing it, checking that it can be shared, and correcting it when needed.
Found a potential vulnerability?
Do not open a public issue. Use the repository's security policy or private reporting route. When no project-specific route is available, contact inAi to establish a private channel. Do not include exploit details or sensitive evidence in the first message.
When GitHub is not enough
GitHub is the right route for focused improvements to an existing public repository. Contact inAi before implementation begins when a proposal involves sustained work, several repositories, sponsored or commissioned development, formal research, a commercial integration, or access beyond the public project.
Product testing without a repository change belongs under Testers. Research collaboration belongs under Academia / Research. Employment, contract, or ongoing development interest belongs under Work with us.
Start with one useful change
Choose the project, identify a real problem, and make the first contribution small enough to understand and review. The repository will tell you what the project is; a clear issue or pull request should show how you can make it better.