GitHub Community
Feature Request: Sealed Paid Pull Requests with Copilot Negotiation and Repository Repair Budgets #212237
Feature Request: Sealed Paid Pull Requests with Copilot Negotiation and Repository Repair Budgets
#212237
Replies: 1 comment
|
Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided. This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Feature Request: Sealed Paid Pull Requests with Copilot Negotiation and Repository Repair Budgets
The idea
Please consider an opt-in GitHub workflow that allows developers to offer completed repairs at prices they set, without revealing the implementation before an agreed purchase and disclosure.
Copilot could help prospective buyers evaluate the available evidence, ask questions, and negotiate conditions while respecting the confidentiality of the repair.
Organizations that benefit from open-source software could contribute to repository repair budgets, with authorized maintainers deciding which repairs to purchase within delegated spending limits.
Developers can price their completed work. Maintainers can buy back their time. Organizations can help fund the maintenance they depend on.
Ordinary unpaid contributions would remain available.
The problem
An independent developer who completes a useful fix may have to disclose the implementation before compensation is agreed, or arrange verification, negotiation, and payment through separate channels.
An upstream project can accept a repair without establishing any payment obligation.
At the same time, a maintainer may have a bug to fix tomorrow but limited time to investigate and implement a solution.
For example, purchasing a suitable repair for $100 might be preferable to spending several hours fixing the issue independently. Alternatively, the maintainer may decide to implement it themselves.
This is an illustrative choice, not evidence of actual demand or time savings.
There is also a funding mismatch: organizations may derive substantial business value from open-source software while maintenance decisions and workloads remain with individual maintainers.
The people financing maintenance, deciding what to merge, and delivering repairs do not need to be the same people.
A GitHub workflow could connect these roles without transferring technical control to sponsors or requiring maintainers to spend their own money.
Proposed workflow
1. Offer a sealed repair
A developer offers a completed repair to a participating repository, linked to an issue and a specific base revision.
The developer sets an asking price and provides a safe description of the intended outcome.
The implementation remains confidential to prospective buyers and the public before agreed disclosure. An authorized verification service could inspect it under appropriate access restrictions.
An unsolicited offer creates no obligation to purchase.
2. Evaluate the repair with Copilot
Copilot could assess the submitted repair against the reported problem using authorized static analysis, tests, or other available evidence.
The resulting report should distinguish:
Current Copilot capabilities do not establish reliable verification or confidentiality for this proposed workflow.
Reports should state what was checked, under which conditions, and what remains uncertain. A passing test must not be presented as proof of complete correctness.
Human review remains necessary.
3. Ask questions without revealing the implementation
Prospective buyers could ask questions such as:
Where appropriately authorized, Copilot could compare the sealed repair with buyer-provided requirements without disclosing either party's confidential material to the other.
Copilot would need to limit, generalize, or refuse questions that could reveal the protected implementation, including through accumulated clues, and seek clarification or authorization from the relevant party.
Neither party should obtain access to the other's protected code or negotiation information merely by asking questions.
4. Negotiate price and conditions
The buyer could accept the asking price, make a conditional offer, defer, or decline.
For example:
"We would purchase this for $200 if support for interface C and its regression test were included."
The developer could accept, counteroffer, or decline.
Copilot would facilitate the exchange but could not invent verification results, authorize disclosure, or commit either party to new terms.
The final scope, price, and conditions require explicit agreement between the parties.
5. Use repository repair budgets
Organizations, sponsors, and other beneficiaries could allocate funds to participating repositories.
Authorized maintainers could purchase appropriate sealed repairs using available funds within valid spending delegations and agreed limits.
For example, purely illustratively:
The maintainer would not need to personally fund the repair or obtain a new sponsor approval for every purchase already covered by delegated authority.
Funding would not grant the sponsor merge authority. The sponsor would not be entitled to dictate which patches maintainers accept.
Financial accounting should provide appropriate oversight without disclosing sealed implementation details, confidential negotiation terms, or protected personal information.
6. Agree, pay, disclose, and review
Before payment and disclosure, the parties would confirm:
Payment and disclosure would follow the agreed process.
The authorized recipient could inspect the delivered repair and compare it against the agreement.
Normal repository review would continue.
Purchasing a repair is not a commitment to merge it. Funding a repository is not a transfer of merge authority.
A decision not to merge does not, by itself, establish that delivery failed.
7. Preserve evidence and useful market history
The workflow could retain the agreed claims, relevant verification evidence, authorized answers, amendments, and delivery outcome.
Privacy-preserving summaries of purchase and non-purchase outcomes could inform future pricing and demand decisions.
Reasons for non-purchase should be optional. Silence should not be treated as rejection.
Declining to purchase should not create a reputational penalty. A non-purchase decision is not evidence that a developer's work lacks quality or that a maintainer is acting unfairly.
The system could help establish delivery credibility by comparing what was promised with what was actually delivered, while distinguishing misrepresentation from environmental differences, changed requirements, and ordinary defects.
Protected code, personal data, confidential business requirements, and private negotiation limits must remain protected.
Why this could benefit GitHub
For developers: An opportunity to offer completed work at a developer-set price without first disclosing the full implementation for free.
For maintainers: The freedom to compare their own time and workload with the cost of acquiring an existing repair, without taking personal financial responsibility for every purchase.
For organizations: A concrete means of funding repairs to open-source infrastructure they depend on, while delegating technical purchasing decisions to maintainers.
For GitHub: A way to connect issue discovery, completed fixes, verification, negotiation, funded purchasing, and ordinary code review in a coherent workflow around Issues, Pull Requests, and Copilot.
The proposal aims to reduce coordination friction, not to make paid contributions mandatory.
Relationship to existing solutions
Several parts of this proposal already exist in other forms.
Accordingly, this request does not claim that paid contributions, developer-initiated payment requests, repository funding, or delegated spending are new ideas.
The proposed distinction is their integration with a completed, developer-priced sealed repair, confidential verification, Copilot-mediated questions and negotiation, delegated purchasing, and payment-linked disclosure directly in the GitHub contribution workflow.
Equivalent proposals or implementations may already exist; no priority claim is made.
Risks and a limited pilot
Important product risks include confidential-code leakage, reconstruction through repeated questions, prompt injection, inaccurate verification, abusive submissions, unclear contribution rights, payment disputes, and unexpected maintainer workload.
These would require product and security safeguards determined by GitHub.
Current Copilot code review can miss issues or produce incorrect findings. Its existing capabilities should not be treated as proof that secure, confidential verification for this proposed workflow is already available.
Reference: GitHub's responsible-use guidance for Copilot code review.
A limited pilot could include:
Security vulnerabilities should remain subject to appropriate responsible-disclosure procedures. Disclosure of a security issue should not be conditioned on payment.
GitHub could assess actual purchases, developer outcomes, maintainer time and effort, negotiation burden, verification cost, confidentiality failures, delivery mismatches, and unwanted submission volume.
The payment architecture, verification design, meaning of sealed access, spending controls, and dispute procedures would be GitHub product decisions.
Closing
This is not a request to replace open-source collaboration with paid contributions.
It is a request to add a voluntary option for a situation that existing workflows do not fully connect:
A developer has already completed a repair. A maintainer may benefit from purchasing it. An organization may be willing to fund that purchase. GitHub could help them reach an informed agreement without requiring the developer to reveal the work before the commercial decision.
The developer retains pricing autonomy, the maintainer retains technical authority, and the funding organization can contribute without having to manage individual code reviews.
All reactions