Join AI Codecon: Will Open Source Win AI?  🔗 **Source:** [Join AI Codecon: Will Open Source Win AI?](https://www.youtube.com/watch?v=y67CJPlth0A) > [!note]+ Document Notes > tags: [open-source-ai, architecture-of-participation, platform-vs-appliance, open-protocols, ai-governance, developer-autonomy] > author: Tim O'Reilly (inferred — see Attribution note) > source: https://www.youtube.com/watch?v=y67CJPlth0A > reference: O'Reilly AI Codecon promotional address, "Will Open Source Win AI?" > date created: 2026-08-25 06:14 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Join AI Codecon: Will Open Source Win AI? > > **Attribution note (reviewer inference).** Reader's `author` field records only `YouTube`. The speaker never states their name on camera. The identification as **Tim O'Reilly** is a reviewer inference resting on four independent markers in the transcript: he coined and uses "the architecture of participation" as his own established term; he says "an experience I had 30 years ago… the war for the web" in the first person about the Microsoft/Netscape/Apache period; he speaks as the convenor of the event ("we're devoting the next edition of the O'Reilly AI Codecon"); and the Apache-versus-proprietary-web-server narrative is a long-standing O'Reilly argument. Treated as high-confidence but **not verified against the channel page.** > <!-- deep-read:sections start --> ## 🧭 Table of Contents 1. Summary 2. Main Content and Notes 3. References 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## 🔗 References (in-page) - Source video: https://www.youtube.com/watch?v=y67CJPlth0A - O'Reilly AI Codecon (event being promoted) - DSPy — framework referenced via the named maintainer - Apache HTTP Server — the historical case the argument rests on ## 📝 Summary **What happened.** A 3.5-minute promotional address for the next edition of O'Reilly's AI Codecon, themed on open source AI. The speaker frames a single argument: proprietary frontier models are shifting from *platform* to *appliance*, and that shift creates the same opening open source exploited to win the web thirty years ago. **The mechanism claimed.** Functionality that once lived in relatively open, user-reachable surfaces — the system prompt is the example given — is being moved into model weights, where it is closed, unchanging, and controlled solely by the provider. The speaker credits this platform-to-appliance framing to a developer he names in conversation, alongside the idea of "prompt debt." **The historical analogy.** During the mid-1990s browser and server wars, Microsoft and Netscape competed by loading ever more features into their web servers while pundits said Apache could not keep up. Apache's counter-position was to stay a web server with a clean extension layer, letting anyone scratch their own itch on top. Apache became dominant; IIS and the Netscape server became footnotes. **Why it matters.** The speaker's claim is that the decisive variable was never feature count but what he calls *the architecture of participation* — whether a system lets people innovate without permission. He argues the open source AI movement is therefore much larger than open-weight models, explicitly naming **open memory** and **open protocols** as equally central. **Stakeholders.** Model providers; developers building on frontier APIs; open-weight model projects; protocol bodies (MCP and successors); conference attendees as the immediate audience. **Risks.** This is promotional content with a commercial interest in the answer being "yes, and you should come discuss it at our conference." The historical analogy is asserted, not tested, and the disanalogies between web servers and frontier models are not addressed. **Bottom line.** A well-formed strategic thesis delivered as a conference pitch. The durable idea is the reframing of "open source AI" away from weights and toward participation surfaces — memory, protocols, extension points. ## 📖 Main Content ### 🗒️ Notes - **[00:00–00:25] The river frame.** Opens with Heraclitus — you cannot step into the same river twice — then immediately qualifies it: rivers have repeating patterns, the rapids sit in the same place, the river rises and falls with the seasons. Applied to technology: the patterns repeat. - **[00:25–01:07] Platform to appliance.** Credits a conversation with a named developer — rendered by the auto-captions as "Drew Birding," a maintainer of "DSpi" (almost certainly **DSPy**; the personal name is a transcription artifact and is *not* reliably recoverable from audio-derived captions). The idea attributed to him: large proprietary models are moving from being a platform to being an appliance, with functionality that used to sit in relatively open features like the system prompt increasingly pushed into the weights — "closed away, unchanging, and under the control of only the model provider." - **[01:07–02:23] The war for the web.** Thirty years ago, Microsoft and Netscape fought over control of the web, with Apache as the open source contender. Both proprietary vendors loaded more and more features into their web servers. Industry pundits said Apache wasn't keeping up. Apache's position: we are a web server with a clean extension layer, and anybody who wants to scratch their own itch can build on top of us. - **[02:04–02:23] Outcome.** Apache became the dominant web server; an explosion of innovation happened on top of the open web; the Netscape and Microsoft servers became footnotes. - **[02:23–02:45] The pivot question.** Given proprietary models closing off access and serving their own interests instead of developers', is this the pivotal point where AI gets won by open source the way the web was? - **[02:45–03:21] The real thesis.** It is not just about open-weight models. It is about the architecture of participation — whether the system is designed so people can innovate without permission, go in different directions, figure out new things. The open source movement in AI is named as bigger than open weights: **open memory, open protocols**, and enabling every developer to control their own future. - **[03:21–03:31] The ask.** That is why the next O'Reilly AI Codecon is devoted to open source AI. ## 📚 References Primary sources preferred: - **Apache HTTP Server project history** — the empirical basis for the central analogy; Netcraft's long-running web server survey is the standard primary record of the market-share claim. - **DSPy** (`dspy.ai`, Stanford NLP) — the framework whose maintainer is credited with the platform-to-appliance framing. - **O'Reilly AI Codecon** — the event being promoted; the programme is the primary source for what "devoted to open source AI" means in practice. - **Model Context Protocol specification and roadmap** — the concrete instance of the "open protocols" leg of the argument, not cited by the speaker but directly relevant. ## 🗣️ Paraphrase *Paragraph by paragraph, in the reviewer's words.* **Opening.** Heraclitus is invoked and then partly overturned. Yes, everything changes — but rivers repeat. Rapids recur in the same places; seasonal rise and fall is predictable. Long exposure to technology teaches the same lesson: the surface churns, the structure repeats. **The diagnosis.** Something specific is changing about frontier models. Capability that used to be exposed where developers could reach it — the system prompt is the worked example — is migrating into the weights. Once inside the weights it is closed, static, and governed by one party. The vocabulary for this is a shift from platform (something you build on) to appliance (something you operate). **The precedent.** The web went through this. Two well-capitalized proprietary vendors competed by accumulating features in their servers. Commentators read Apache's smaller feature list as falling behind. Apache read its own position differently: be a good web server, expose a clean extension layer, and let the ecosystem build the future on top. **The result.** The ecosystem did, and the proprietary servers lost. Not because they were worse products at any given moment, but because innovation happened faster outside them than inside them. **The extrapolation.** If proprietary models are closing off access in service of their own interests, the same dynamic may be setting up. The question is posed rather than answered. **The redefinition.** The important move: "open source AI" should not be read as "open weights." The operative property is whether people can innovate without asking. That makes open memory and open protocols first-class parts of the open AI movement, not adjacent concerns. **The pitch.** The conference exists to work on this. ## 📰 Newsletter **WordPress angle — witty, and closer to home than it looks.** If "architecture of participation" sounds familiar to WordPress people, it should: it is arguably the most successful living instance of the idea. WordPress didn't win by shipping the most features in core. It won by shipping hooks — an extension layer so promiscuous that 60,000-odd plugins grew on top of it, most written by people who never asked anyone's permission. Core stayed a web publishing platform. Everyone else scratched their own itch. So when this argument gets made about AI, the WordPress ecosystem has unusually good intuitions about what to watch for. The tell isn't how many features a model ships. It's whether the extension surface is stable, documented, and reachable without a business development conversation. The uncomfortable follow-up: the same dynamic is playing out *inside* the WordPress AI story right now. Every time site-building capability moves from an open, inspectable layer (a hook, a REST route, a block registration, a theme.json token) into a hosted service you can only call, that's the platform-to-appliance shift arriving locally. The Abilities API and MCP-style surfaces are the current test case — they're either the clean extension layer, or they're the thing that gets absorbed. Worth reading alongside: [the MCP roadmap's progressive-discovery work](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/), which is the open-protocols leg of exactly this argument. ## ✅ Action Items **DevRel** - `#action/h2` Track the platform-to-appliance framing as a talk-and-writing frame; it travels well to WordPress audiences without needing AI expertise from the listener. - `#action/h3` Watch for the O'Reilly AI Codecon programme; the session list is a cheap map of who is working on open memory and open protocols. **OSPO** - `#action/h2` Adopt "can people innovate without permission?" as an evaluation question for any AI dependency the org takes on. It is more actionable than "is it open source?" - `#action/h3` Inventory which currently-open extension surfaces in the org's stack are candidates for absorption into a vendor appliance. **Community** - `#action/h3` The Apache story is a good on-ramp for community members who feel AI strategy is above their pay grade. It reframes an abstract governance question as a familiar extensibility question. **WordPress subteams** - **Core** — `#action/h2` The extension-layer argument bears directly on how AI-facing capability is exposed. Prefer registrable, inspectable surfaces over hosted calls where the choice exists. - **Core AI** — `#action/h1` This is the team where "architecture of participation" is a design constraint rather than a slogan. Abilities API design decisions are the concrete instance. - **Core Performance** — Not applicable to this source; no performance claims made. - **Core Program Team** — `#action/h3` Useful framing for roadmap communication about why extensibility is a strategic and not merely technical property. - **Mobile** — Not applicable to this source. - **Playground** — `#action/h3` Playground is itself an "innovate without permission" surface; the framing supports the case for it. - **Community** — `#action/h3` See above; good meetup talk material. - **Training** — `#action/h2` "Open weights is not the same as open AI" is a teachable distinction that Learn WordPress material on AI should carry. - **Marketing** — `#action/h3` The Apache analogy is reusable in positioning work about WordPress's own openness. - **Support** — Not applicable to this source. - **Design** — Not applicable to this source. - **Documentation** — `#action/h3` Extension surfaces only function as participation architecture if they are documented; this is the documentation team's stake in the argument. - **Photos** — Not applicable to this source. - **TV** — `#action/h3` Candidate topic for a WordPress.tv session on AI and openness. - **Polyglots** — Not applicable to this source. - **Accessibility** — Not applicable to this source; no accessibility claims made. - **Meta** — `#action/h3` Meta owns several of the extension surfaces the argument implicates (APIs, directories). - **CLI** — `#action/h3` WP-CLI is a participation surface in exactly the sense described. - **Hosting** — `#action/h2` Hosts are the layer most able to turn an open surface into an appliance; worth naming. - **Tide** — Not applicable to this source. - **Openverse** — `#action/h3` Open media as a participation surface is adjacent to the "open memory" idea. - **Themes** — Not applicable to this source. - **Plugins** — `#action/h2` The plugin directory *is* the architecture of participation made institutional; the analogy should be used deliberately. **The WPOCC** - `#action/h2` The "innovate without permission" test is a useful lens for The WP Open Community Collective's work on ecosystem governance and independence. **FAIR** - `#action/h1` FAIR's federated model is a direct instance of open protocols as the unit of openness rather than open source licensing alone. This talk supplies outside vocabulary for that argument. ## 🧪 Hypotheses 1. **The absorption hypothesis.** If capability continues migrating from system prompts into weights, then the measurable signal will be a declining ratio of behavior controllable via documented API parameters to behavior controllable only by model choice. *Testable by tracking published API surface area across model releases.* 2. **The extension-layer hypothesis.** If the Apache analogy holds, then AI systems exposing a stable, documented extension layer will accumulate third-party functionality faster than feature-rich closed systems, measured in independent integrations per quarter. 3. **The open-memory hypothesis.** If memory is genuinely a participation surface, then portability of memory between agents will become a competitive demand within 24 months, evidenced by an interchange format proposal. 4. **The disanalogy hypothesis (null).** Web servers had near-zero marginal cost and commodity hardware requirements; frontier models have extreme capital requirements. If capital intensity is decisive, open source AI plateaus at the capability frontier regardless of participation architecture. *This is the strongest competing explanation and the talk does not address it.* 5. **The protocol-consolidation hypothesis.** If open protocols are the real battleground, then protocol governance disputes — not model licensing disputes — will become the dominant open-source-AI conflict. ## 📊 Methodology **Study design: none.** This is a promotional keynote address, not research. Its evidentiary basis is a single historical case (Apache versus proprietary web servers), recounted from personal memory, plus one attributed conversation. **Data sources.** Personal recollection; one named conversation with a framework maintainer. No quantitative data, no citations, no comparison set. **Appropriate weight.** The argument should be evaluated as a *hypothesis-generating* frame, not as evidence. The historical case is real and well documented independently, but a single successful analogy is not a predictive model — the base rate of "open source wins this one too" predictions that failed is not discussed. ## ❓ Questions 1. What is the actual disanalogy budget? Web servers were cheap to build and run; frontier training runs are not. Which properties of the Apache case survive that difference? 2. If the system prompt is the canonical example of capability moving into weights, what is the second example? One instance is thin support for a trend claim. 3. What would "open memory" mean concretely — a portable format, a local store, a queryable log? The term is asserted without definition. 4. Who governs open protocols, and does protocol capture look different from platform capture in practice? 5. Apache won a market where the incumbent products were mediocre. What happens when the closed option is meaningfully better on capability? 6. Is "innovate without permission" the right test when the permission being withheld is compute access rather than API access? ## 🔮 Future Research - **Comparative extension-surface measurement.** Build a longitudinal index of documented, developer-reachable control surfaces per model provider. This would convert the platform-to-appliance claim from assertion to measurement. - **Base-rate work on the open-source-wins prediction.** Catalogue historical cases where the analogy was made (web servers, mobile OS, cloud infrastructure, browsers) and score outcomes. Mobile is the obvious counter-case. - **Open memory as a research object.** Nobody has specified what portable agent memory would contain, and the adjacent literature on whether persistent memory helps at all is unsettled — see the measured 3:1 write-to-read finding in the companion analysis of *Turn off Claude Code's Memory* processed the same day. - **Capital intensity versus participation architecture.** Model whether extension-layer advantages can overcome order-of-magnitude capital differences. ## 💡 Implications **Practice.** Teams choosing AI dependencies get a sharper question than "is it open?" — namely, "what can I change without asking?" That is checkable against documentation today. **Policy.** If participation architecture rather than licensing is the operative property, then policy instruments aimed at licensing (open-weight mandates, model release requirements) may target the wrong layer. Interoperability and protocol mandates would follow more directly from this argument. **Security.** Not addressed by the source. Reviewer note: extension layers are also attack surfaces, and "innovate without permission" and "execute without review" are uncomfortably close neighbours — the supply-chain analysis in the companion OCN broadcast processed the same day is the direct counterweight. **Education.** The distinction between open weights and open participation is a genuinely useful teaching frame and is currently rare in introductory AI material. **Funding.** Directs attention and money toward protocol and memory work rather than exclusively toward open-weight model training, which is where most open-source-AI philanthropy currently sits. ## 🧠 Learning Styles Assessment - **Visual** — Weak. No slides, diagrams, or on-screen artifacts; a single talking head. The river and the web-server-war both invite diagrams that are never drawn. - **Aural** — Strong. Well-paced spoken argument with clear rhetorical structure; works fully as audio. - **Verbal** — Strong. The argument is carried entirely by language, and the key term ("architecture of participation") is a memorable verbal handle. - **Kinesthetic** — Absent. Nothing to do, build, or try. - **Logical** — Moderate. The structure is clean (analogy → mechanism → extrapolation → redefinition) but the inferential step from Apache to AI is asserted rather than argued. - **Social** — Moderate by design; the entire piece is an invitation to a conference, i.e. to a social learning setting. - **Solitary** — Strong. Short, self-contained, requires no companion material. - **Naturalistic** — Unusually strong for a technology talk. The river/rapids/seasons framing is a genuine natural-systems analogy carried through the opening, not decoration. **Reading level estimate.** Roughly grade 10–11 (Flesch-Kincaid equivalent). Sentences are moderately long and clause-rich, but the vocabulary is plain; the only specialist terms are "system prompt," "weights," and two product names. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA: 1. **Perceivable — captions (1.2.2).** Auto-generated captions only. Demonstrably lossy: it renders a personal name unrecoverably and turns "DSPy" into "DSpi." **Fails** the spirit of 1.2.2, which requires accurate captions, not merely present ones. 2. **Perceivable — audio description (1.2.3/1.2.5).** No meaningful visual-only content, so audio description is not required. **Passes by absence of need.** 3. **Perceivable — contrast and visual presentation (1.4.3, 1.4.11).** Cannot be assessed from transcript alone. **Not assessed.** 4. **Operable — keyboard and controls (2.1.1).** Delivered via the YouTube player, which meets baseline keyboard operability. **Passes at the platform level.** 5. **Operable — timing and seizure safety (2.2, 2.3.1).** No flashing content reported; runtime is short and user-controlled. **Passes.** 6. **Understandable — reading level and language (3.1).** Plain vocabulary, clear structure, no jargon density problem. **Strong pass.** 7. **Robust — parsing and assistive-technology compatibility (4.1).** Platform-dependent; the transcript is machine-readable and available. **Passes.** **Highest-value remediation:** a human-corrected transcript. The caption errors here destroy attribution of an idea to the person credited with it, which is an accuracy failure with ethical weight, not just a usability one. ## 🌍 DEIB Assessment - **Cultural breadth.** Narrow. The entire historical frame is 1990s US commercial computing (Microsoft, Netscape, Apache), and the philosophical opener is canonical Western antiquity. No non-Western technology histories are referenced, though several are directly relevant to questions of technological autonomy. - **Inclusive language.** No exclusionary language observed. Uses "developers" and "people" as the general subject; avoids gendered defaults. - **Neurodiversity support.** Good. Short runtime, single clear thesis, concrete anchoring analogy, no rapid topic-switching. The repetition of the core claim in two forms aids retention. - **Representation.** Single speaker, one named third party. No diversity of voice within the piece; this is structural to the format rather than a choice within it. - **Psychological safety.** High. The framing is invitational and non-adversarial; the proprietary vendors are described as acting in their interests rather than as villains. Poses the central question rather than asserting the answer, which leaves room for disagreement. ## ✅ Logical Validity **Strong reasoning.** - The Heraclitus opener is genuinely well-used: it sets up and then immediately complicates a cliché, which earns the "patterns repeat" claim rather than assuming it. - The redefinition of open source AI away from weights toward participation surfaces is the strongest move. It is a substantive, falsifiable reframing, not a slogan. - The speaker poses the pivotal-point claim as a **question** ("is this a pivotal point?") rather than a prediction. That is appropriate epistemic hedging for the evidence available. **Fallacies.** 1. **Faulty analogy** — `#fallacy/faulty-analogy`. [02:23–02:45] The inference from Apache's victory to AI's likely trajectory treats two markets as structurally equivalent. Web servers had near-zero marginal cost, commodity hardware requirements, and a low capability ceiling; frontier models have extreme capital intensity and a rapidly moving capability frontier. **Located:** the transition from the Apache history to "is this the point where… AI is going to be won by open source." **Fix:** state the load-bearing similarity explicitly (extension surfaces attract third-party innovation) and concede the disanalogy (capital intensity), then argue why the similarity dominates. 2. **Survivorship bias** — `#fallacy/survivorship-bias`. [01:07–02:23] Apache is selected as the historical case precisely because it won. Cases where an open contender with a clean extension layer lost anyway — most obviously mobile operating systems — are not considered. **Fix:** name at least one counter-case and explain the difference. 3. **Appeal to authority via anecdote** — `#fallacy/appeal-to-authority`. [00:25–01:07] The platform-to-appliance claim rests entirely on one named developer's framing from a private conversation, with no supporting evidence offered. The framing may well be correct; it is unsupported as presented. **Fix:** supply a second instance beyond the system prompt. 4. **Suppressed evidence (commercial interest)** — `#fallacy/suppressed-evidence`. Throughout. The piece's conclusion — that open source AI is the important frontier — is also the premise of a conference the speaker is selling tickets to. This is disclosed implicitly by the ending but never acknowledged as a reason for scrutiny. **Fix:** none needed for honesty (the promotional nature is obvious), but consumers should weight accordingly. **Tone of voice.** Reflective, senior, invitational. Speaks from long personal vantage without condescension. Notably restrained: describes proprietary vendors as "serving their own interests" rather than in moral terms, and frames the thesis as a question. The register is that of an elder practitioner offering a frame, not an advocate demanding agreement. ## 🛡️ DARVO Analysis **Deny** — Not present. No accusation is being deflected; nothing is denied. **Attack** — Not present. Proprietary model providers are characterized as pursuing their own interests, which is descriptive rather than accusatory. Industry pundits are said to have been wrong, but in a historical account and without hostility. **Reverse victim and offender** — Not present. No party is positioned as a wronged victim. Developers are described as having interests that are not being served, which is a claim about incentives rather than a victimhood frame. **Assessment: no DARVO pattern.** This source is a straightforward advocacy argument with disclosed commercial interest and no defensive rhetorical structure. ## 🎯 Conclusion **Bottom line.** The durable contribution is a redefinition, not a prediction: *open source AI is not primarily about open weights; it is about whether a system permits innovation without permission.* That reframing survives independently of whether the Apache analogy holds, and it makes open memory and open protocols first-class rather than peripheral. The predictive claim built on top of it — that AI will be won by open source as the web was — is posed as a question and should be held as one, because the strongest counter-argument (capital intensity) is never engaged. **Next steps.** 1. Treat "what can I change without asking?" as a live evaluation question for AI dependencies. 2. Watch the O'Reilly AI Codecon programme for concrete work on open memory and open protocols. 3. Pair this against the MCP roadmap, which is the open-protocols argument with actual engineering behind it. ## 🧱 Refactor Appendix ### Literature Split Pad (H3) > [!quote] `#atom/literature/h1` > "It's not really just about open weight models. It's about what I call the architecture of participation. Is this a system designed where people can innovate without permission?" The central and most reusable claim. Converts an ideological question into a design test. > [!quote] `#atom/literature/h1` > "much of the functionality that used to be in sort of relatively open features, like you know, the system prompt, have been increasingly put into the weights of the model, closed away, unchanging, and under the control of only the model provider." The mechanism claim. Note it rests on a single example. > [!quote] `#atom/literature/h2` > "Look, we're a web server. We have a clean extension layer, and anybody who wants to scratch their own itch can build on top of us, and they will actually invent the future using our open platform." The Apache position, recounted. This is the historical anchor for the whole argument. > [!quote] `#atom/literature/h3` > "the open source movement in AI is way bigger than open weight models. It's in areas like open memory, in open protocols." Names the two surfaces the speaker considers underweighted. > [!quote] `#atom/literature/h3` > "anyone who's been around rivers knows that they have repeating patterns. You know, the rapids are in the same place." The framing device; useful rhetorically, no evidentiary weight. ### Atomic Split Pad (H4) - `#atom/zettel/z1` **Architecture of participation** — The decisive property of a technology platform is not its feature count but whether third parties can extend it without permission. Feature accumulation by incumbents is compatible with strategic defeat. - `#atom/zettel/z1` **Platform-to-appliance drift** — As a product matures commercially, control surfaces migrate from user-reachable configuration into opaque internals. The migration is usually framed as simplification and is rarely reversed. - `#atom/zettel/z1` **Openness is a surface property, not a licence property** — A system can be open-licensed and unextendable, or closed-licensed and highly extendable. The licence answers a legal question; the extension surface answers the strategic one. - `#atom/zettel/z1` **Analogy is hypothesis generation, not evidence** — A single well-fitting historical precedent generates a hypothesis. It cannot establish a base rate, because the precedent was selected after the outcome was known. ### Fleeting Queue - `#atom/fleeting/f1` The WordPress plugin directory is the architecture of participation made institutional — worth developing as its own note. - `#atom/fleeting/f1` "Open memory" is asserted here as a frontier, and independently measured as near-worthless in the Theo/Pi analysis processed the same day. Those two are not necessarily in conflict — *portable* memory and *automatic* memory are different objects — but the tension is worth writing up. - `#atom/fleeting/f1` Mobile OS is the obvious counter-case to the Apache story. Android is open-licensed and extension-rich, yet the participation architecture did not prevent platform capture. Why? - `#atom/fleeting/f1` Does FAIR's federation model qualify as an architecture of participation under this definition, or only as an open licence? <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Join AI Codecon Will Open Source Win AI.md|Join AI Codecon: Will Open Source Win AI? by YouTube]] ## Highlights - But what happened was really interesting. Microsoft and Netscape began to load more and more features into their web server. And the industry pundits were all saying Apache isn't keeping up. But I thought they were wrong, and the Apache folks thought they were wrong. What they said was, "Look, we're a web server. We have a clean extension layer, and anybody who wants to scratch their own itch can build on top of us, and they will actually invent the future ([View Highlight](https://read.readwise.io/read/01m0wacm5erqrk6naf1jzzm4qm)) - Note: The historical anchor for the whole argument — Apache's counter-position against feature accumulation. Bias check: Apache is selected precisely because it won; counter-cases where an open contender with a clean extension layer still lost (mobile OS being the obvious one) are not considered. - Tags: atom/literature/h2, fallacy/survivorship-bias - instead of the interests of the developers, you have to actually wonder, is this a pivotal point? Is this the point where just like the web was won by open source, AI is going to be won by open source. Because it's not really just about open weight models. It's about what I call the architecture of participation. Is this a system designed where people can innovate without permission? They can go off in different directions. They can ([View Highlight](https://read.readwise.io/read/01m0wace9ty2t25yfjz6q78gr2)) - Note: The central thesis and the most reusable idea in the talk: open source AI is not primarily about open weights, it is about whether the system permits innovation without permission. Converts an ideological question into a checkable design test. Note the claim is posed as a question, which is appropriate hedging for the evidence offered. - Tags: atom/literature/h1, atom/zettel/z1