Open source vs closed models: what changes for a normal reader
A plain-language guide to what “open” usually means for AI models: weights, code, data, or API-only: vs closed products, with tradeoffs for privacy, audit, cost, and safety, and Bommasani et al. as the door into access and release.
Primary source: Bommasani et al., On the Opportunities and Risks of Foundation Models (CRFM 2021): access and release: https://doi.org/10.48550/arXiv.2108.07258
Headlines love a fight: open vs closed, as if one team were automatically freer, safer, or smarter.
For a normal reader, the useful question is quieter: what can you get, who sees your prompts, and who owns the mess when something fails?
Nothing here is about consciousness. Chatbots are one product shape, not all of AI. Door: What ChatGPT is (and isn’t).
The short version
- Closed often means an API or product you call: the vendor runs the model; you send inputs and get outputs.
- Open weights often means you can download a copy and run it yourself, with caveats: license, hardware, and usually not the full training data or recipe.
- In AI, “open source” is messy. Weights ≠ code ≠ data ≠ a reproducible training run.
- What changes for you: privacy of prompts, whether you can inspect or finetune, dependence on a vendor, and who owns misuse risk.
- Open is not automatically safer or better. Closed is not automatically worse. Measure the tradeoffs.
Closed: you call a product
With many chat and API products, the model stays on the company’s side. You send a prompt; their servers run it; you get text, a score, or an image back.
Gloss in one line: an API is “a door you knock on; the house stays theirs.”
Convenient: no GPU shopping, no self-managed updates. Filters and quality are partly the vendor’s design problem, not magically solved. The trade is dependence: price, rate limits, policy, and uptime are theirs. Your prompts usually leave your machine. Read the privacy terms; “chat” ≠ “private.”
Open weights: you can run a copy (with caveats)
Open weights means the learned numbers, the model file, are published so others can download, run, and often finetune them. Big difference from “API only.” Not the same as classic open-source software.
- Weights without the full training data is common.
- An inference recipe may omit the full pretraining playbook.
- The license can still limit commercial use or redistribution, downloadable ≠ do anything.
- Hardware still matters; “open” does not mean “free on a phone.”
Open weights widen what you can host and adapt. They do not hand you a full factory tour of how the model was born.
Why “open source” got messy in AI
In software, open source often means readable code plus rights to run, study, modify, and share. Foundation models add huge data, expensive training, and safety choices that do not fit a tidy git badge.
Primary source: Bommasani et al., On the Opportunities and Risks of Foundation Models (CRFM, 2021). Their report maps opportunities and risks; sections on access and release treat openness as a spectrum, who may use the model, with which artifacts (API, weights, code, data), and with what downstream effects, not one label that ends the argument.
Ask what was released, not only whether someone said “open.”
What actually changes for you
Who sees your prompts. Closed APIs usually send inputs to the vendor (often logged under their policies). A copy you run on machines you control can keep prompts closer to home, if you set it up that way. Hosted “open” demos can still phone home; check where the bytes go.
Inspect and finetune. Open weights make probing, evals, and specialization easier, see Pretrain then finetune. Closed APIs may offer fine-tune endpoints or none; you rarely get the full weight file.
Vendor dependence. Closed products centralize updates and uptime. Open weights let you pin a copy, and make you (or your host) own patches, serving, and monitoring.
Misuse and responsibility. Publishing weights widens helpful use and harmful reuse. An API can add rate limits and filters, and concentrate power in one org. Neither choice skips evaluation: Why evaluation matters.
Cost and quality. APIs bill per use; self-hosting trades that for hardware and ops time. Compare systems on the real job, not on marketing adjectives.
A measured scorecard (not a winner)
| Question | Closed API / product | Open weights (typical) |
|---|---|---|
| Where do prompts go? | Often vendor servers | Can stay local if you self-host |
| Can you download the model? | Usually no | Often yes (license permitting) |
| Full training data released? | Rarely | Still often no |
| Easy finetune on your stack? | Sometimes via vendor tools | Often yes if you have compute |
| Who ships safety filters? | Mostly vendor | Often you (or the packager) |
| Who gets paged at 3 a.m.? | Vendor’s ops | Yours (or your host’s) |
Your row depends on the job: homework, company docs, medical drafts, and public demos weight privacy, liability, and quality differently.
Easy → technical doors
| If you’re curious about… | Easy / History next step | Technical door |
|---|---|---|
| Chat as a product, not a mind | What ChatGPT is (and isn’t) | InstructGPT / related papers via that post |
| General model → specialist | Pretrain then finetune | BERT and pretrain/finetune trail via that post |
| Measuring behavior, not vibes | Why evaluation matters | CheckList and eval papers via that post |
| Access, release, and foundation-model risk | This piece’s primary source | Bommasani et al., CRFM 2021 |
The honest caveat
Open is not automatically safer or better. Closed is not automatically trustworthy. Downloadable weights help audit and adapt, and can reduce some privacy leaks; they also shift ops and misuse burden onto whoever runs the copy. APIs can add guardrails and convenience; they also concentrate control and usually see your prompts. Match the release shape to the job, read the license and privacy terms, and evaluate on the real task. On this site, Easy reading aims for clear claims, clear limits, and a path to the paper when you want to verify.