Skip to content Skip to footer

Vibe Coding and Open Source: How the Movement Changed GitHub [Unbiased Research, 2026]

Vibe Coding and Open Source: How the Movement Changed GitHub [Unbiased Research, 2026]

Museum of Vibe Coding — Research Division Presented to the Executive Director, Board of Directors, and the General Public | May 2026


“Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns.” — Koren, Békés, Hinz, Lohmann. “Vibe Coding Kills Open Source.” arXiv:2601.15494, January 2026

“Tailwind is more popular than ever. Traffic to our docs is down about 40% from early 2023. Revenue is down close to 80%.” — Adam Wathan, Tailwind CSS creator, January 2026

“Remove the incentive for people to submit crap and non-well-researched reports to us. AI generated or not.” — Daniel Stenberg, cURL creator, on shutting down cURL’s bug bounty program, January 31, 2026


⚡ The Open Source Transformation at a Glance

MetricDirectionFigureSource
AI-generated code on public GitHub46% of all new codeGitHub / Vercel 2026
Claude Code’s share of public GitHub commits4%Boris Cherny, Anthropic, Feb 2026
Stack Overflow activity post-ChatGPT-25% within 6 monthsKoren et al. 2026
Tailwind CSS documentation traffic-40% from 2023 peakAdam Wathan, Jan 2026
Tailwind CSS revenue-80% from 2023 peakAdam Wathan, Jan 2026
cURL bug bounty confirmation rateFrom >15% to <5%Daniel Stenberg, Jan 2026
AI-hallucinated package names (USENIX 2025)~20% of AI-generated samplesUSENIX Security 2025
CVEs attributed to AI coding tools (Mar 2026)35 in March aloneGeorgia Tech Vibe Security Radar

Table of Contents

  1. Introduction: The Paradox of Growing Usage and Declining Sustainability
  2. The Academic Case: Vibe Coding Kills Open Source
  3. The Evidence: Four Documented Cases
  4. The Maintainer Response: Defensive Actions in January-February 2026
  5. Slopsquatting: The Supply Chain Attack Vibe Coding Created
  6. What Vibe Coding Did for Open Source: The Positive Dimension
  7. The CVE Surge: AI-Generated Code and the Vulnerability Trajectory
  8. The Sustainability Question: What Needs to Change
  9. The Museums Assessment: A Balanced View
  10. Frequently Asked Questions
  11. References

Introduction: The Paradox of Growing Usage and Declining Sustainability

The Number That Explains Everything

GitHub reports that 46% of all new code being committed to public repositories is AI-generated. Claude Code alone accounts for 4% of all public GitHub commits. Vibe coding tools are generating more code, committed to more repositories, used in more projects, than at any prior point in computing history.

And the open source projects that this code is built on are experiencing declining engagement, declining sustainability, and in some cases — active defensive measures against the tools generating all that code.

This is the open source paradox of the vibe coding era: more code being generated using open source components, and fewer people engaging with the communities that create and maintain those components. The usage has decoupled from the engagement. The harvest is increasing while the investment in the farm is declining.

This paper is the Museum of Vibe Coding’s complete analysis of this paradox — its academic foundation, its documented cases, its security consequences, and its resolution. It is the final paper in the Museum’s 20-paper research cluster and the one that examines vibe coding from the perspective of the infrastructure it builds on.


The Academic Case: Vibe Coding Kills Open Source

The Paper and Its Argument

On January 21, 2026, economists Miklós Koren (Central European University), Gábor Békés (Central European University), Julian Hinz (Bielefeld University), and Aaron Lohmann (Kiel Institute for the World Economy) posted a preprint titled “Vibe Coding Kills Open Source” (arXiv:2601.15494).

The paper constructs a general equilibrium model of the open source software ecosystem to analyze what happens when AI agents — rather than human developers — select, assemble, and modify open source packages. The central finding: “Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns. When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability of OSS, and lowers overall welfare, even as software output rises.”

The paper’s conclusion: “Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.”

The authors are explicit that this is “a call to action” rather than a prediction of collapse. They describe it as identifying a structural problem that requires deliberate institutional response — “coordination and will” — rather than an inevitable trajectory.

The Core Mechanism: Usage-Engagement Decoupling

The economic mechanism the paper identifies is precise: open source projects traditionally monetize and recruit contributors through user engagement — documentation visits, bug reports, Stack Overflow questions, GitHub issues, community forum participation. These interactions provide:

  • Revenue for projects that monetize through documentation traffic, sponsorships visible to engaged users, or commercial products that engaged users discover
  • Bug reports that identify problems before they become security vulnerabilities
  • Contributors who first engage as users and then become maintainers
  • Community knowledge that circulates through Q&A and forum participation

Vibe coding routes AI agents through this engagement layer invisibly. The AI reads the documentation so the developer does not. The AI writes the implementation so the developer does not file a bug report when something is wrong. The AI selects the package so the developer never becomes a community member. The usage increases while every engagement metric that sustains the project declines.

The paper models this as an equilibrium shift: in a world where direct user engagement drives OSS sustainability, widespread vibe coding lowers the returns to OSS maintainers, reducing their incentive to create and maintain projects, reducing the overall quality and quantity of OSS available — even as software output rises dramatically. More software is produced; less of the infrastructure it depends on is maintained.


The Evidence: Four Documented Cases

Case 1 — Tailwind CSS: Usage Up, Sustainability Down

The Koren et al. paper’s central empirical illustration is Tailwind CSS, and the data is stark. The paper’s Figure 2 tracks two metrics from 2022 through 2025:

  • Weekly npm downloads: Rising steadily throughout the period
  • Stack Overflow questions tagged “tailwind-css”: Declining over the same period

Tailwind creator Adam Wathan provided the internal data in a January 2026 GitHub comment: documentation traffic is down approximately 40% from its early 2023 peak despite Tailwind being more popular than ever. Revenue — from the Tailwind UI component library that monetizes through engaged Tailwind users discovering it — is down close to 80%.

The Tailwind case is not a story about a declining product. Tailwind is growing in adoption. It is a story about the economic model of open source breaking when AI mediates between the framework and the developer. The developers are there; they are using Tailwind. The AI is reading the documentation, selecting the framework, and generating the code. The developer never visits the docs, never asks a question, never discovers the commercial product, never contributes a bug report. The usage is up; the sustainability is down.

Case 2 — Stack Overflow: The Platform-Level Decline

Stack Overflow’s broader decline reflects the same mechanism at scale. Koren et al. cite causal evidence from del Rio-Chanona et al. (2024): Stack Overflow activity fell approximately 25% within six months of ChatGPT’s launch.

Stack Overflow is the canonical example of open source community knowledge infrastructure — the platform where developers engage with the problems they encounter, document solutions, and contribute to a shared knowledge base that benefits the entire developer community. AI coding tools route developers around this engagement. The question is answered by the AI; the developer never posts, never answers, never contributes to the knowledge commons.

The irony is acute: AI models were trained on Stack Overflow’s historical contributions. The models now answer questions that would previously have generated new Stack Overflow posts, starving the platform that provided their training data.

Case 3 — cURL Bug Bounty: The AI Noise Problem

cURL is the foundational internet tool used in virtually every programming language and operating system. Its six-year bug bounty program, launched in 2019, had found 87 real vulnerabilities and paid out over $100,000 in rewards. It was a model of how community security research should work.

On January 31, 2026, cURL creator Daniel Stenberg shut it down. The reason: AI-generated vulnerability reports had flooded the program with noise. The confirmation rate for incoming reports had dropped from above 15% to below 5%. In the final three weeks before shutdown, cURL received 20 AI-generated reports. Seven arrived in a single 16-hour period. None described actual vulnerabilities.

Stenberg’s reasoning: “Remove the incentive for people to submit crap and non-well-researched reports to us. AI generated or not.”

The cURL case documents a specific consequence of vibe coding’s open source impact that the economic model does not fully capture: AI tools generate outputs that look like community engagement but are not. AI-generated bug reports consume maintainer time that was previously spent on real bugs. The signal-to-noise ratio for genuine security research collapses when AI tools enable mass generation of plausible-but-incorrect reports.

Case 4 — The Maintainer Defensive Wave

The Hashnode “State of Vibe Coding 2026” analysis documented a coordinated wave of defensive responses from open source maintainers in January–February 2026:

Mitchell Hashimoto (Ghostty): Banned AI-generated code contributions entirely. The motivation was code quality and maintainability — AI-generated PRs increased review burden without proportionally increasing project quality.

Steve Ruiz (tldraw): Auto-closes all external pull requests — not just AI-generated ones, but all of them. The reason: maintainers cannot distinguish real contributions from AI-generated noise fast enough to justify the review cost. The entire external contribution pathway was closed because AI had made it unworkable.

GitHub: Added a kill switch for AI-generated PR contributions, giving maintainers the ability to block AI-assisted submissions at the repository level.

The wave was not coordinated. It was independent responses to the same underlying problem: AI tools had increased the volume of inputs to open source projects — code contributions, bug reports, documentation suggestions — without proportionally increasing the signal quality. Maintainers, who are typically unpaid or modestly compensated volunteers, found that the time cost of processing AI noise exceeded the benefit of genuine community contributions.


The Maintainer Response: Defensive Actions in January-February 2026

The AI Slopageddon Framing

RedMonk analyst Kate Holterhoff coined the term “AI Slopageddon” to describe the January–February 2026 pattern: the simultaneous emergence of multiple AI-generated quality problems in open source communities, producing a coordinated defensive response across maintainers who had independently hit the same limit.

The common pattern across all four defensive actions above: AI tools had made it easy to generate inputs to open source projects — bug reports, code contributions, documentation edits — without requiring the understanding, effort, or accountability that historically accompanied those inputs. The quality filter that human effort naturally provided (you file a bug report when you actually have a bug) was removed. Volume increased; quality declined.

The maintainer responses were practical rather than philosophical. Stenberg was not making a statement about AI; he was protecting the time of cURL’s security researchers from being consumed by AI noise. Ruiz was not banning AI; he was acknowledging that he could not distinguish real contributions from AI ones fast enough to justify the cost. These are resource allocation decisions by unpaid maintainers who do not have the time to process everything the AI era generates.


Slopsquatting: The Supply Chain Attack Vibe Coding Created

The New Threat Category

Security researcher Seth Michael Larson of the Python Software Foundation coined the term “slopsquatting” — a portmanteau of “slop” (AI-generated content of variable quality) and “typosquatting” (registering domain or package names similar to legitimate ones to capture misdirected traffic).

Slopsquatting is the supply chain attack that vibe coding made possible: attackers register the hallucinated package names that AI coding tools consistently recommend, so that when AI tools tell developers to install those packages, they install malicious code instead.

The Research Basis

USENIX Security 2025 researchers (University of Texas at San Antonio, University of Oklahoma, Virginia Tech) analyzed 576,000 AI-generated code samples across 16 LLMs. Their findings:

  • Approximately 20% of AI-generated samples referenced Python or JavaScript packages that did not exist
  • 43% of those hallucinated package names were consistently reproduced across ten separate queries — indicating systematic rather than random hallucination
  • 58% reappeared at least once within ten runs of the same query
  • Open-source models: average 21.7% hallucination rate
  • Commercial models: average 5.2% hallucination rate (GPT-4 Turbo achieved the lowest measured rate at 3.59%)
  • 38% of hallucinated names were conflations of two real packages (e.g., react-codeshift from jscodeshift + react-codemod)
  • 8.7% of hallucinated Python package names were valid JavaScript package names — exploitable across ecosystems

How the Attack Works

Because 43% of hallucinated package names consistently reappear across similar prompts, attackers can map these hallucinations in advance. They register the hallucinated names on npm, PyPI, or other registries before developers encounter them. When a vibe coding tool tells a developer to install react-codeshift — a package that does not exist but is a plausible-sounding conflation of two real things — and the developer runs npm install react-codeshift, they install the attacker’s malicious package.

The key difference from traditional typosquatting: the developer is not making a typing error. They are trusting an AI recommendation. They have no prior reason to question the package name. The AI selected it; the developer installed it.

The confirmed attack case: In January 2026, Aikido security researcher Charlie Eriksen documented that the npm package react-codeshift had been registered with no legitimate author, containing code designed to steal credentials and API keys. The name had appeared in a commit of 47 LLM-generated Agent Skills — AI agents recommending it to users who would then install it.

The LiteLLM Supply Chain Compromise

On March 24, 2026, attackers (attributed to the group TeamPCP) compromised LiteLLM — a popular Python library for unified LLM API access used across thousands of AI coding projects — by hijacking a real package rather than registering a hallucinated one. The compromise followed a chain: TeamPCP had previously targeted Trivy (March 19) and Checkmarx’s KICS GitHub Action (March 23) in what Endor Labs described as “a deliberate escalation from CI/CD tooling into production Python package registries.”

The LiteLLM compromise is distinct from slopsquatting but shares the same underlying vulnerability: the open source supply chain is a direct attack surface for anyone who can compromise a package that AI tools recommend. As AI-generated code increasingly imports AI-related packages (LiteLLM, LangChain, OpenAI SDK), the most-used packages in the vibe coding ecosystem become high-value supply chain targets.

The CSA Assessment

The Cloud Security Alliance’s 2026 AI research notes establish slopsquatting as a first-tier supply chain risk: “developers frequently trust and integrate AI-generated or community-sourced code with minimal technical scrutiny.” Their guidance: “treat every AI-generated snippet and third-party library as an untrusted component and apply zero-trust verification before it enters production.”

The CVE count trajectory confirms that this is not theoretical risk: Georgia Tech’s Vibe Security Radar tracked CVEs formally attributed to AI coding tools climbing from 6 in January 2026 to 15 in February to 35 in March — a 6x increase in three months.


What Vibe Coding Did for Open Source: The Positive Dimension

The Open Source Foundation of Vibe Coding Is Itself a Contribution

The Museum’s account of vibe coding’s relationship with open source cannot be only negative, because the positive dimension is also real and significant.

Vibe coding dramatically increased the consumption of open source. The Tailwind paradox — usage up, engagement down — is specifically a sustainability problem, not a quality problem. More developers are using Tailwind, more applications are built on it, more of the world’s software incorporates it, because vibe coding made it accessible to non-developers who would previously have used simpler tools or hired developers. The problem is not that vibe coding is bad for Tailwind’s adoption. It is good for Tailwind’s adoption. The problem is that the business model connecting adoption to sustainability is broken.

Vibe coding created new categories of open source contribution. The Vybe Guide platform (launched January 2026) provides a curated database of 50,760+ open source projects optimized specifically for the vibe coding workflow — helping AI tools find the right packages rather than hallucinating them. The ICSE-SEIP ’26 study documented how vibe coders are building tools, contributing back to projects they use, and creating new open source infrastructure for the AI-assisted development workflow.

The LLMs themselves were built on open source. Every frontier AI model that powers vibe coding tools was trained on open source code. GitHub Copilot, Claude Code, Cursor’s AI capabilities — all built on the accumulated contribution of decades of open source development. Vibe coding is the current generation of value extraction from that contribution, which is precisely what open source is designed to enable. The problem is not the extraction; it is whether the ecosystem that enables it is being maintained.

Vibe coding democratized open source access. The Democratization paper documented that 63% of vibe coding users are non-developers. These practitioners are now building on open source software who would previously have had no access to it at all. This expands the reach of open source beyond the developer community — which is what open source’s founding philosophy argued for.


The CVE Surge: AI-Generated Code and the Vulnerability Trajectory

From Security Research to Security Incident

The open source security impact of vibe coding extends beyond slopsquatting. Georgia Tech’s Systems Software and Security Lab launched the Vibe Security Radar in May 2025 specifically to track CVEs formally attributable to AI coding tools. The trajectory:

  • January 2026: 6 CVEs attributed to AI coding tools
  • February 2026: 15 CVEs
  • March 2026: 35 CVEs

This 6x increase in three months reflects two converging trends: more AI-generated code in production (providing more surface area for CVEs to be discovered), and more security researcher attention to AI-generated code specifically (improving the identification of AI-attributable vulnerabilities).

The specific CVEs documented include vulnerabilities in AI coding tools themselves — CVEs against Amazon Q, Cursor, and GitHub Copilot — in addition to CVEs in applications generated by those tools. The attack surface of the vibe coding ecosystem is bidirectional: the tools themselves can be compromised, and the code they generate carries systematic vulnerability patterns.


The Sustainability Question: What Needs to Change

The Koren et al. Call to Action

The “Vibe Coding Kills Open Source” paper is explicit that it does not predict inevitable collapse. It predicts the outcome if nothing changes, and it calls for the institutional changes that would prevent that outcome. Specifically: “Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.”

The paper identifies several potential institutional responses:

AI-inclusive monetization models: If AI tools are the primary consumers of OSS documentation and the primary beneficiaries of OSS quality, the economic model connecting OSS consumption to maintainer compensation needs to route through AI tool vendors, not through direct user engagement. This could take the form of AI vendor contributions to OSS foundations, licensing fees that fund maintainers of heavily-used projects, or new sustainability models that measure AI consumption directly.

Community design that works with AI mediation: Projects that design their community engagement for an AI-mediated world — structured contribution formats that AI can generate correctly, automated noise filtering, contribution attribution systems that reward quality over volume — may sustain community health better than projects that assume direct human engagement.

OSS foundation adaptation: The Linux Foundation, OpenSSF, and other OSS umbrella organizations are positioned to coordinate the institutional response that individual maintainers cannot. The Foundation’s 2025 State of Global OSS report found that 83% of enterprises consider OSS adoption valuable but only 29% have designated full-time OSS maintainers — a gap that will widen as AI increases dependency on OSS without proportionally increasing institutional investment.

What Individual Practitioners Can Do

Engage directly when AI generates code using a project. If vibe coding tools use a library, spend five minutes reading the documentation directly. File issues when you encounter problems. Star repositories. Sponsor maintainers whose work your applications depend on. The engagement gap is real; direct engagement from practitioners partially closes it.

Verify package names before installation. The slopsquatting risk is addressable through a simple verification habit: before installing any package that an AI coding tool recommends, verify it exists on the official registry, was registered before the project started, and has a publisher with an established track record. Tools like Socket.dev, Snyk, and Aikido automate this in CI/CD pipelines.

Contribute back. The open source projects that vibe coding tools build on need contributors who understand them at a level that AI-generated PRs do not. If you use a project extensively, the most valuable contribution is one that demonstrates genuine understanding — a well-documented bug report, a targeted fix, a test that covers a real edge case you encountered. The quality of contribution matters more now, not less.


The Museums Assessment: A Balanced View

The Full Picture

The Museum of Vibe Coding’s position on vibe coding and open source reflects the same balance that characterizes the entire research archive: the positive is real, the negative is real, and honest analysis requires holding both.

The positive: Vibe coding dramatically increased the consumption and reach of open source software. Non-developers who would never have encountered React, Python, or PostgreSQL are now building applications with them. The software ecosystem is larger, more accessible, and more productive than at any prior point — in significant part because AI tools made it so.

The negative: The economic model that sustains open source — direct user engagement funding maintainers, community participation creating knowledge, bug reports identifying vulnerabilities — is being systematically degraded by AI mediation. The Tailwind case is not unique; it is the most visible example of a pattern affecting every project whose users increasingly encounter it through AI rather than directly.

The security dimension: Slopsquatting and the AI-attributed CVE surge represent genuinely new threat categories that the open source security ecosystem was not designed to address. The vibe coding era created attack surfaces that did not exist before.

The call to action: Koren et al. frame the finding as requiring “coordination and will” — not defeat. The open source ecosystem survived the transition from physical media to the internet, from desktop to cloud, from sequential to concurrent computing. The adaptation to the AI era requires the same kind of deliberate institutional and community design that previous transitions required. The failure mode is not inevitable; it is the outcome of inaction.

The Museum connects this to the broader arc of the research archive: vibe coding’s impact on open source is another expression of the democratization-and-governance tension documented throughout. The democratization is real and valuable. The governance — in this case, the institutional structures that sustain the infrastructure democratization depends on — must evolve at the same pace.


Frequently Asked Questions

Q: Should I avoid using open source in vibe-coded projects because of sustainability concerns?

A: No. Avoiding open source would make vibe coding impossible and would not address the sustainability problem. The appropriate response is: use open source, but engage with it. Read documentation directly rather than only through AI. File genuine bug reports when you encounter problems. Sponsor projects you depend on. The sustainability gap is a collective action problem — individual engagement from practitioners who benefit from open source is the most direct available response.

Q: Is slopsquatting a major practical risk for most developers?

A: Yes, and it is growing. The 20% package hallucination rate across 576,000 code samples, combined with 43% of hallucinations being consistently reproduced, means that any substantial vibe coding workflow will encounter AI-suggested packages that do not exist. If those names have been registered by attackers before you install them, you install malicious code. The mitigation is straightforward: verify package existence and publisher identity before installation. Automated tools (Socket.dev, Snyk, Aikido) integrate this into CI/CD. The risk is real; the prevention is accessible.

Q: Does the cURL bug bounty shutdown mean AI is making open source security worse?

A: It means AI is making the signal-to-noise ratio of community security research worse, at least in its current form. Real security researchers still find real vulnerabilities. The problem is that AI-generated reports consume the review time that would otherwise go to those real reports, reducing the efficiency of the security research community. Stenberg’s decision to shut down the program rather than continue filtering noise was a rational maintainer resource allocation decision, not a statement that security research has stopped working. The long-term response requires better tooling for distinguishing AI-generated from human-generated reports — not abandoning community security research.


References

  1. Koren, M., G. Békés, J. Hinz, A. Lohmann. (January 21, 2026). Vibe Coding Kills Open Source. arXiv:2601.15494. https://arxiv.org/abs/2601.15494
  2. TechTarget. (March 2026). Vibe Coding Is Killing Open Source, Increasing Software Risk. https://www.techtarget.com/searchapparchitecture/tip/Vibe-coding-is-killing-open-source-increasing-software-risk
  3. Hashnode. (February 2026). The State of Vibe Coding in 2026: Adoption Won, Now What? [cURL bug bounty shutdown; Ghostty; tldraw; AI Slopageddon.] https://hashnode.com/blog/state-of-vibe-coding-2026
  4. Grith.ai. (March 2026). Vibe Coding Is Killing Open Source, and the Data Proves It. [cURL final three weeks data; 20 AI-generated reports.] https://grith.ai/blog/vibe-coding-killing-open-source
  5. Stenberg, D. (January 31, 2026). cURL bug bounty program shutdown. [“Remove the incentive for people to submit crap.”]
  6. Wathan, A. (January 2026). GitHub comment on Tailwind CSS documentation traffic and revenue. [“Down about 40% from early 2023. Revenue down close to 80%.”]
  7. USENIX Security 2025. Package Hallucinations in AI-Generated Code. 576,000 samples, 16 LLMs. [20% hallucination rate; 43% consistent reproduction.] University of Texas at San Antonio, University of Oklahoma, Virginia Tech.
  8. Larson, S.M. (Python Software Foundation). Slopsquatting: the supply chain attack vibe coding created.
  9. Aikido / Charlie Eriksen. (January 2026). Slopsquatting: AI Package Hallucination Attacks. [react-codeshift confirmed malicious package.] https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks
  10. ThinkPol. (March 2026). Slopsquatting: The Supply Chain Attack Vibe Coding Made. [LiteLLM compromise; TeamPCP chain.] https://thinkpol.ca/2026/03/28/slopsquatting-the-supply-chain-attack-vibe-coding-made/amp/
  11. Cloud Security Alliance. (April 2026). CSA Research Note: Slopsquatting — AI Supply Chain. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_slopsquatting-ai-supply-chain_20260419-csa-styled-1.pdf
  12. Cloud Security Alliance. (April 2026). CSA Research Note: AI-Generated Code Vulnerability Surge 2026. [CVE trajectory: 6→15→35 per month Q1 2026.] https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/
  13. Georgia Tech Systems Software and Security Lab. (May 2025 — ongoing). Vibe Security Radar. [CVE tracking attributable to AI coding tools.]
  14. ICSE-SEIP ’26. (April 2026). Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook. https://kblincoe.github.io/publications/2026_ICSE_SEIP_vibe-coding.pdf
  15. Linux Foundation. (2025). State of Global Open Source 2025. [83% enterprises value OSS; only 29% have designated maintainers.]
  16. Vybe Guide. (January 2026). Launch of Open Source Discovery Platform for Vibe Coders. [50,760+ curated open source projects.]
  17. del Rio-Chanona et al. (2024). Causal evidence of post-ChatGPT decline in Stack Overflow activity. [Cited in Koren et al. 2026; 25% decline within 6 months.]
  18. Cherny, B. (February 2026). Lenny’s Podcast. [“Claude Code already authors 4% of all public GitHub commits.”]
  19. Forbes — Brooks, C. (August 8, 2025). Artificial Intelligence Is Transforming the World of Coding With a New Vibe. https://www.forbes.com/sites/chuckbrooks/2025/08/08/artificial-intelligence-is-transforming-world-of-coding-with-a-new-vibe/
  20. Klover AI. (2025). Klover AI: The Pioneer of Vibe Coding. https://www.klover.ai/klover-ai-the-pioneer-of-vibe-coding/
  21. Klover AI. (2025). HALO™ Acting and the Rise of Cross-Agent Influence. https://www.klover.ai/ai-halo-acting/
  22. Kitishian, D. (February 2026). Klover AI Pioneered Vibe Coding Before It Was a Word. Medium. https://medium.com/@danykitishian/klover-ai-pioneered-vibe-coding-before-it-was-a-word-e48c232d707b
  23. Museum of Vibe Coding. (2025). Top 10 Innovators of Vibe Coding. https://museumofvibecoding.org/top-10-innovators-of-vibe-coding-reshaping-software-development/
  24. Museum of Vibe Coding. (2025). Top 10 Architects of Vibe Coding — AI Vanguard List. https://museumofvibecoding.org/top_10_architects_of_vibe_coding_ai_vanguard_list/
  25. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding Security: The Complete Research Record. https://museumofvibecoding.org/vibe-coding-security-the-complete-research-record-unbiased-research-2026
  26. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding and the Democratization of Software. https://museumofvibecoding.org/vibe-coding-and-the-democratization-of-software-who-is-actually-building-now-unbiased-research-2026/
  27. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding Statistics: The Complete 2026 Research Compendium. https://museumofvibecoding.org/vibe-coding-statistics-the-complete-2026-research-compendium-unbiased-research-2026/
  28. Museum of Vibe Coding Research Division. (May 2026). The Vibe Coding Debate: Every Argument, Sourced and Assessed. https://museumofvibecoding.org/vibe-coding-debate-every-argument-sourced-and-assessed-unbiased-research-2026/
  29. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding and the Workforce. https://museumofvibecoding.org/vibe-coding-and-the-workforce-jobs-skills-and-economic-transformation-unbiased-rsearch-2026/
  30. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding: History & Timeline. https://museumofvibecoding.org/vibe-coding-history-and-timeline-unbiased-research-2026/
  31. Museum of Vibe Coding Research Division. (May 2026). The Origin Story of Vibe Coding. https://museumofvibecoding.org/origin-story-of-vibe-coding-unbiased-research-2026/
  32. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding Best Practices: The Complete Guide. https://museumofvibecoding.org/vibe-coding-best-practices-the-complete-guide-unbiased-research-2026/
  33. Museum of Vibe Coding Research Division. (May 2026). The Vibe Coding Tools Landscape. https://museumofvibecoding.org/the-vibe-coding-tools-landscape-every-major-platform-assessed-unbiased-research-2026/
  34. Museum of Vibe Coding Research Division. (May 2026). Vibe Coding for Startups and Founders. https://museumofvibecoding.org/vibe-coding-for-startups-and-founders-building-commercial-products-unbiased-research-2026/

© 2026 Museum of Vibe Coding — Research Division. All rights reserved. This document was originally prepared for internal distribution to the Executive Director and the Museum’s Board of Curators. It was approved for public release on May 31, 2026. Cite as: Museum of Vibe Coding Research Division. “Vibe Coding and Open Source: How the Movement Changed GitHub.” May 2026. museumofvibecoding.org