Custom versions & sync
VibeExchange should feel like a software marketplace and collaboration space, not a Git tutorial. Under the hood, GitHub remains the durable source-control layer. In the product, the same ideas become simpler actions:
| GitHub concept | VibeExchange language |
|---|---|
| Repository | App workspace |
| Fork | Custom version |
| Pull from upstream | Keep up with the original |
| Pull request | Offer changes back |
| Merge | Accept the change |
| Branch | Draft change |
| Issue | Build request |
The goal is a GitHub facade for people who want to vibe-code and steer software without knowing what Git is.
Original app and custom versions
Every funded listing has an original app workspace. That workspace contains the canonical roadmap, treasury, build history, releases, and sponsor governance for the listing.
A sponsor, creator, customer, or team can create a custom version when they want something different:
- a feature that is too specific for the original;
- a branded or private deployment;
- a workflow tailored to one team;
- a risky experiment that should not affect everyone;
- a paid feature that might later become useful to the original app.
Behind the scenes, VibeExchange can back that custom version with a GitHub fork. The product does not need to expose the word “fork” to the user unless they open advanced details.
Three paths for a custom version
1. Stay synced
The custom version keeps receiving accepted improvements from the original app. In product language this is keep up with the original.
Use this when a team wants local customization but does not want to maintain an isolated product forever.
2. Evolve separately
The custom version becomes its own long-running app workspace with its own funding, roadmap, releases, contributors, and governance.
Use this when the custom direction is truly different from the original.
3. Offer improvements back
If a custom feature becomes generally useful, its owner can offer it back to the original app. Behind the scenes, this is a pull request from the fork into the original repo. In VibeExchange, it should feel like:
- Pick a shipped change from your custom version.
- Explain why it should become part of the original.
- Attach funding or a conditional pledge if needed.
- Let original sponsors review and vote.
- If accepted, the original app gets the improvement.
Funding model
Custom versions create a clean funding choice:
- Fund the original when you want the feature everyone should share.
- Fund your version when the feature is specific to you or your team.
- Fund an offer-back when you built it privately but want the original app to adopt it.
Each app workspace needs its own ledger and governance state. A custom version can inherit history from the original, but its money and votes should be auditable as its own workspace.
Product surfaces
The non-technical UI should expose these actions:
- Customize this app — create a custom version from the original.
- Keep up with original — show pending original improvements that can be pulled into the custom version.
- Offer back — propose a custom change to the original sponsors.
- Evolve separately — make the custom version independent.
- Compare versions — show what differs in features, releases, funding, and governance without showing raw diffs first.
Advanced users can still open the GitHub repo, branch, PR, and fork links. The default path should not require that vocabulary.
Governance
Original app sponsors decide what lands in the original. Custom-version sponsors decide what lands in their version.
An offer-back crosses those boundaries, so it should be reviewed by the original app’s governance rules. Conditional pledges can make that negotiation concrete: “release this pledge only if the custom feature is accepted into the original.”
Status
This is the product direction for the next repo layer. Today, VibeExchange already treats each funded app as a repo-backed workspace. The next step is to make fork/sync/offer-back flows legible as custom versions for non-technical users while preserving GitHub as the behind-the-scenes source of truth.
The detailed implementation plan lives in
CUSTOM_VERSIONS_AGENT_WORKSPACES_PLAN.md in this site package.