You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Computer is an incredibly useful project, and I would be happy to contribute to it. I recently reported a Gemini tool-calling bug in #224, including a reproduced failure, implementation guidance, and regression cases. While preparing that contribution, however, I could not determine the intended path for outside code contributions or how changes are reviewed.
That is especially important for this project because, by its own security model, an authenticated Computer user has access equivalent to SSH: full filesystem and shell access with no path sandboxing or per-user isolation.
To be explicit, this is not an accusation of misconduct, a claim that uncredited work is being used, or an assumption that private review does not happen. I am pursuing clarification because I would like to understand how to contribute responsibly and how to evaluate updates to software with this level of host access. The answers may be entirely straightforward; they simply do not appear to be documented publicly today.
Snapshot below is as of 2026-08-17, with main at 9c54711.
What I could verify publicly
One visible upstream author to date
GitHub's contributor endpoint reports one contributor with 647 commits:
$ gh api repos/open-webui/computer/contributors?per_page=100 \ --jq 'map({login, contributions})'[{"contributions":647,"login":"tjbck"}]
The local Git history resolves every commit to variants of the same name and email:
$ git log origin/main --format='%aN <%aE>'| sort | uniq -c 1 Tim Baek <tim@openwebui.com> 1 Tim J. Baek <tim@openwebui.com> 645 Timothy Jaeryang Baek <tim@openwebui.com>
Visible pull requests appear to be release promotions
There have been 82 pull requests. All 82 were authored by tjbck, with head main and base release:
$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \ --jq 'group_by(.user.login)|map({author:.[0].user.login,count:length})'[{"author":"tjbck","count":82}]
$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \ --jq 'group_by(.base.ref)|map({base:.[0].base.ref,count:length})'[{"base":"release","count":82}]
$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \ --jq 'group_by(.head.ref)|map({head:.[0].head.ref,count:length})'[{"head":"main","count":82}]
For example, #214 promotes main to release, has no description or review, and was merged about 16 seconds after creation: #214
This appears to mean that the repository's pull-request count and merge rate describe its release workflow rather than its outside-contribution or code-review process. If review occurs elsewhere, documenting that would resolve the ambiguity.
These examples show that issue-based contributions can influence the product, which is encouraging. They do not establish whether external PRs are accepted or explain why fork PR creation failed in those cases.
Questions not answered by the current documentation
At the referenced commit, the repository has:
no CONTRIBUTING.md describing the supported contribution path;
no CODEOWNERS or documented reviewer roster;
no Computer-specific SECURITY.md or documented inheritance of the parent project's policy;
no pull-request-triggered test or lint workflow—the existing workflows publish Docker/PyPI/releases on pushes to main or release;
a PR template requiring acceptance of a broad CLA, despite there being no visible external PR precedent.
Computer is distributed under the Open Use License and describes itself as “source available” with “all rights reserved,” rather than under an OSI-approved open-source license. Its CLA grants Open WebUI Inc. broad, perpetual rights to use, modify, sublicense, and commercialize contributions.
That arrangement is not inherently improper, and this issue is not challenging the project's choice of license. It does make a clearly documented contribution process particularly helpful: prospective contributors should be able to understand what rights they retain, how authorship is recorded, and how acceptance of the CLA works.
This is unclear when someone cannot open a PR and instead provides patches, code snippets, or links to branches in an issue. The CLA says it applies to contributions submitted “to this repository in any form,” while the PR template's checkbox appears to be the documented mechanism for confirming agreement. It is not clear whether issue comments or linked branches are treated as CLA-covered submissions, or how affirmative acceptance is recorded in that workflow.
Are changes on main reviewed by anyone other than their author before release? If review happens privately, can the review and release policy be documented?
Are outside patches rewritten or squash-applied under the maintainer's authorship? If so, how is contribution attribution preserved?
Does Computer inherit Open WebUI's security-reporting policy, and who can release a fix if the primary maintainer is unavailable?
Is this single-maintainer structure temporary while Computer is young, or is it the intended long-term governance model?
Does the CLA apply to code snippets, patches, or branches submitted through issues? If so, how is informed acceptance recorded when the contributor cannot use the PR checkbox?
Possible documentation and process improvements
Depending on the answers above, it may help to consider:
adding a CONTRIBUTING.md that states whether fork PRs are supported and how to submit one;
documenting the maintainers/reviewers, release process, and security-reporting route;
correcting any repository or organization setting that prevents legitimate fork PRs, if that is unintended;
adding pull-request CI for at least formatting, linting, and focused tests;
preserving external authorship through normal merges, co-author trailers, or an explicit attribution policy;
explaining that the existing main → release PRs are release promotions rather than independent code review;
documenting the license and attribution treatment of issue-submitted patches and linked branches, including when the CLA applies and how contributors affirm acceptance.
The project can reasonably choose a centralized, source-available model. The concern is not centralization by itself; it is that interested users and contributors currently have to infer the model from Git history, contribution attempts, and repository settings. A short, explicit document would materially improve confidence and make it easier for people who value Computer to contribute constructively.
Summary
Computer is an incredibly useful project, and I would be happy to contribute to it. I recently reported a Gemini tool-calling bug in #224, including a reproduced failure, implementation guidance, and regression cases. While preparing that contribution, however, I could not determine the intended path for outside code contributions or how changes are reviewed.
That is especially important for this project because, by its own security model, an authenticated Computer user has access equivalent to SSH: full filesystem and shell access with no path sandboxing or per-user isolation.
To be explicit, this is not an accusation of misconduct, a claim that uncredited work is being used, or an assumption that private review does not happen. I am pursuing clarification because I would like to understand how to contribute responsibly and how to evaluate updates to software with this level of host access. The answers may be entirely straightforward; they simply do not appear to be documented publicly today.
Snapshot below is as of 2026-08-17, with
mainat9c54711.What I could verify publicly
One visible upstream author to date
GitHub's contributor endpoint reports one contributor with 647 commits:
The local Git history resolves every commit to variants of the same name and email:
Contributor graph: https://github.com/open-webui/computer/graphs/contributors
Visible pull requests appear to be release promotions
There have been 82 pull requests. All 82 were authored by
tjbck, with headmainand baserelease:For example, #214 promotes
maintorelease, has no description or review, and was merged about 16 seconds after creation: #214This appears to mean that the repository's pull-request count and merge rate describe its release workflow rather than its outside-contribution or code-review process. If review occurs elsewhere, documenting that would resolve the ambiguity.
Contributors have reported difficulty opening PRs
CreatePullRequestpermission error. The issue was later fixed, but the PR failure was not explained: bug: OpenAI-compatible streaming usage can end responses early #96Addressed!, but again did not clarify the supported contribution path: feat: stdio MCP tool servers need an env variables field in the UI (branch with fix available) #201input_json_deltafragments are ignored #196, a third contributor supplied a detailed implementation and offered to open a PR; the issue was subsequently addressed without a public external PR: bug: tool-call arguments are never captured —input_json_deltafragments are ignored #196These examples show that issue-based contributions can influence the product, which is encouraging. They do not establish whether external PRs are accepted or explain why fork PR creation failed in those cases.
Questions not answered by the current documentation
At the referenced commit, the repository has:
CONTRIBUTING.mddescribing the supported contribution path;CODEOWNERSor documented reviewer roster;SECURITY.mdor documented inheritance of the parent project's policy;mainorrelease;Relevant files:
Contribution licensing is also unclear
Computer is distributed under the Open Use License and describes itself as “source available” with “all rights reserved,” rather than under an OSI-approved open-source license. Its CLA grants Open WebUI Inc. broad, perpetual rights to use, modify, sublicense, and commercialize contributions.
That arrangement is not inherently improper, and this issue is not challenging the project's choice of license. It does make a clearly documented contribution process particularly helpful: prospective contributors should be able to understand what rights they retain, how authorship is recorded, and how acceptance of the CLA works.
This is unclear when someone cannot open a PR and instead provides patches, code snippets, or links to branches in an issue. The CLA says it applies to contributions submitted “to this repository in any form,” while the PR template's checkbox appears to be the documented mechanism for confirming agreement. It is not clear whether issue comments or linked branches are treated as CLA-covered submissions, or how affirmative acceptance is recorded in that workflow.
References:
Questions for the maintainers
mainreviewed by anyone other than their author before release? If review happens privately, can the review and release policy be documented?Possible documentation and process improvements
Depending on the answers above, it may help to consider:
CONTRIBUTING.mdthat states whether fork PRs are supported and how to submit one;main→releasePRs are release promotions rather than independent code review;The project can reasonably choose a centralized, source-available model. The concern is not centralization by itself; it is that interested users and contributors currently have to infer the model from Git history, contribution attempts, and repository settings. A short, explicit document would materially improve confidence and make it easier for people who value Computer to contribute constructively.