Open Clone Marketplace: an app store for software you actually own

Open Clone Marketplace: an app store for software you actually own

Table of Contents

Audio of the post:

Every useful app eventually asks you to pay a subscription, accept a new privacy policy, or trust a server you don’t control. What if you could take a great app, deploy your own copy of it in a few minutes, and own the data forever — even if you can’t code?

That’s the idea behind the Open Clone Marketplace: a catalog of open-source apps inspired by well-known products (expense splitting, kanban boards, habit trackers, shopping lists…) that anybody can deploy to their own cloud account with a single prompt.

The problem: great apps, zero ownership

Self-hosting has always been the answer to vendor lock-in, but it has a brutal onboarding cost. Even a “simple” Flutter + Firebase app expects you to install a toolchain, create a backend project, wire up authentication, apply security rules, build, and deploy. That’s a wall most people never climb.

So the marketplace splits the problem in two:

  1. A machine-readable manifest (clonefest.json) that fully describes how to deploy an app — tools, accounts, and every ordered step.
  2. An AI agent (a Claude skill) that reads that manifest and walks a non-technical user through the whole thing, running the commands it can and explaining the clicks it can’t.

The result: you press GET on a catalog card, Claude opens with the prompt ready, and ~30 minutes later you have your own instance live at https://your-project.web.app.

How it fits together

Three moving parts, each intentionally boring:

  • App repos — each one is a normal open-source GitHub repo with a clonefest.json at its root. That file is the single source of truth.
  • The catalog — a static GitHub Pages site that reads an index (apps.json), fetches each manifest, and renders an store–style front end. No backend, no build step, no cost.
  • Two Claude skills — clone-deployer (for people installing an app) and clonefest-generator (for authors publishing one).

Because the catalog reads manifests at runtime, adding an app is just a pull request. There’s nothing to redeploy.

Anatomy of a clonefest.json

The manifest is a small, validated JSON document. All user-facing text is bilingual (en required, es optional), and the deploy steps are typed as either shell (a command the agent can run) or manual (something the user does in a browser console). Here’s a trimmed example:

{
  "$schema": "https://clonemarket.org/spec/clonefest.schema.json",
  "clonefest": "1.0",
  "id": "plan",
  "name": "Plan",
  "clone_of": "Kanban boards",
  "category": "productivity",
  "tagline": {
    "en": "Kanban boards for your team. Your data, your Firebase.",
    "es": "Tableros kanban para tu equipo. Tus datos, tu Firebase."
  },
  "owner": { "name": "Your Name", "github": "your-user" },
  "repo": "https://github.com/your-user/plan",
  "license": "MIT",
  "platforms": ["web", "android", "ios"],
  "stack": {
    "frontend": { "framework": "flutter", "language": "dart" },
    "backend": { "provider": "firebase", "services": ["auth", "firestore", "hosting"] }
  },
  "deploy": {
    "target": "firebase-hosting",
    "estimated_minutes": 30,
    "steps": [
      { "id": "clone", "type": "shell",
        "run": "git clone https://github.com/your-user/plan.git && cd plan",
        "title": { "en": "Clone the repository", "es": "Clona el repositorio" } },
      { "id": "firebase-project", "type": "manual",
        "url": "https://console.firebase.google.com",
        "title": { "en": "Create a Firebase project and enable Auth + Firestore",
                   "es": "Crea un proyecto Firebase y activa Auth + Firestore" } },
      { "id": "deploy", "type": "shell", "run": "firebase deploy --only hosting",
        "title": { "en": "Deploy to Firebase Hosting", "es": "Despliega a Firebase Hosting" } }
    ],
    "verify": {
      "en": "Open your web.app URL, create a board and drag a card between columns.",
      "es": "Abre tu URL web.app, crea un tablero y arrastra una tarjeta entre columnas."
    }
  }
}

The key rule: never ship your own secrets. No API keys, no project IDs — every person who deploys the app brings their own backend. The flutterfire configure step regenerates the config to point at their Firebase project.

Publishing an app in three steps

1. Generate the manifest

You can write the JSON by hand from the template, but the fastest path is the clonefest-generator skill: it inspects your repo (stack, owner, git history, README steps) and produces a valid manifest.

You: generate the clonefest for my repo https://github.com/your-user/plan
Claude: [reads pubspec.yaml, firebase.json, README…] → writes clonefest.json

2. Validate it locally

The schema is published, so validation is a two-liner:

npm i -g ajv-cli ajv-formats
curl -fsSLO https://clonemarket.org/spec/clonefest.schema.json
ajv validate -s clonefest.schema.json -d clonefest.json --spec=draft2020 -c ajv-formats

Commit clonefest.json to the root of your repo.

3. Open a pull request to the catalog

Add one entry to apps.json, pinned to a commit SHA so the reviewed manifest can never change underneath you:

{
  "apps": [
    {
      "id": "plan",
      "manifest": "https://raw.githubusercontent.com/your-user/plan/<commit-sha>/clonefest.json"
    }
  ]
}

CI validates the manifest against the schema, checks that the id matches, and lints the deploy steps for dangerous commands (piped curl | sh, sudo, rm -rf, writes outside the repo). A maintainer then reviews the steps by hand before merge — because the clone-deployer skill executes them on real users' machines, that human review is non-negotiable.

Why the manifest matters more than the code

The interesting bet here isn’t any single app — it’s the format. A clonefest.json turns “deploy this repo” from tribal knowledge buried in a README into a contract a machine can execute and a human can audit. Once that contract exists, the same agent deploys any app in the catalog, and the catalog itself is just a list of URLs.

It also keeps everyone honest about ownership. Because the manifest forbids shipping secrets and the deploy always reconfigures against the user’s own backend, “self-hosted” isn’t a marketing word — it’s structurally true.

Try it

The catalog is live at clonemarket.org with a handful of apps to start: expense splitting, kanban, habits and shopping lists — all Flutter + Firebase, all MIT-licensed.

  • Deploy one: install the clone-deployer skill and press GET.
  • Publish yours: grab the clonefest-generator skill and open a PR.

The apps listed are independent open-source projects inspired by well-known apps. They are not affiliated with, endorsed by, or connected to the original products or their trademark owners.

Related Posts

Teaching an LLM to ride the bus (Coruña edition)

Teaching an LLM to ride the bus (Coruña edition)

I’ve been playing around with the Model Context Protocol (MCP) for a few weeks now. There’s already a lot of material out there, but I wanted to try it with a simple, real-world case: the buses in A Coruña.

Read More
Building an AI-Powered newspaper article approval system with Human-in-the-Loop

Building an AI-Powered newspaper article approval system with Human-in-the-Loop

Audio of the post:

In the fast-paced world of digital journalism, editors face the daunting task of reviewing hundreds of article submissions daily. While AI can draft articles quickly, human oversight remains crucial for maintaining editorial standards, ensuring factual accuracy, and preserving journalistic integrity. This is where Human-in-the-Loop (HITL) middleware becomes invaluable.

Read More
Transforming RAG systems with enhanced context (a langchain implementation)

Transforming RAG systems with enhanced context (a langchain implementation)

Audio of the post:

I recently stumbled upon Anthropic’s fascinating post about contextual retrieval and was immediately intrigued by the potential to revolutionize RAG systems! The concept was so compelling that I decided to put it to the test with a real-world experiment using 10 years of annual reports from CUAC FM. What started as curiosity turned into a comprehensive research project. I crafted 30 carefully designed questions paired with 30 human-reviewed reference answers to rigorously evaluate whether contextual retrieval truly delivers on its promises. The results? Absolutely game-changing!

Read More