Open Source's Triple Crisis: Funding, Trust, and the AI Contribution Flood

Open source is confronting three interlocking strains: inadequate funding, declining trust and a surge of machine-assisted contributions that is making software cheaper to produce but not necessarily cheaper to maintain. The financial problem predates generative artificial intelligence. Tidelift and The New Stack’s maintainer surveys have repeatedly found that many widely used projects depend on a small number of underpaid or unpaid contributors. GitHub Sponsors and Open Collective data show that donations remain concentrated among visible developers and marquee projects, leaving much of the less glamorous infrastructure beneath corporate software with limited recurring support. GitHub’s August 2026 reduction in public bug-bounty payments, disclosed in its program terms, has added to concern that independent security researchers are being asked to protect a growing software commons for diminishing compensation. The trust problem cuts in both directions. The Register reported that a prominent Haskell contributor was attacked by anti-AI purists after acknowledging the use of AI tools, illustrating how rigid authorship tests can alienate experienced developers. Yet skepticism toward machine-generated code isn’t merely cultural resistance. The Register separately reported that Zig creator Andrew Kelley called Bun’s Claude-assisted rewrite “unreviewed slop that nobody asked for,” while the Zig Software Foundation said reviewability and engineering accountability mattered more than the tool used to produce a patch. Volume magnifies both disputes. GitHub’s Octoverse 2025-2026 report described rapidly expanding use of AI development tools, while estimates synthesized from the Open Source Initiative’s annual survey and maintainer polling by Tidelift and The New Stack put the machine-assisted share of some projects’ incoming contributions at 40% to 60%. Those estimates aren’t a census, but they capture the operational imbalance: generation is nearly instantaneous, while review remains labor-intensive. Companies should regard the result as supply-chain risk rather than internet drama. The OSI survey links maintainer capacity and governance to project resilience, while OpenSSF guidance treats ownership, release practices and security response as measurable risk factors. Enterprises that rely on open source should therefore assess who can merge and publish code, how releases are reviewed, whether maintainers have succession plans and whether the project has durable financing. Without such support, businesses should expect more abandoned packages, contentious relicensing and vulnerabilities that remain unaddressed because nobody is paid to investigate them.

For maintainers, the central AI problem is asymmetrical labor. GitHub’s Octoverse 2025-2026 report found that AI-assisted development had moved into routine workflows, while the OSI annual survey and Tidelift and The New Stack’s maintainer research placed the estimated share of machine-assisted submissions in some active projects at 40% to 60%. A contributor can produce a polished pull request in minutes. A maintainer may need hours to determine whether it preserves compatibility, handles edge cases and includes meaningful tests. Weak submissions increasingly look competent. The Felony Bench analysis of “vibe coding” argued that fluent output can obscure whether an author understands a patch’s legal, security and operational consequences. The accompanying Hacker News debate exceeded 820 points, according to the site’s public ranking, suggesting that the ethical question has moved beyond tool preference: Who bears responsibility when a person submits code that he or she cannot explain? The answer shouldn’t be an authorship inquisition. The Register’s account of the Haskell contributor pilloried for using AI showed the risk of treating any assistance as misconduct. Conversely, Andrew Kelley’s criticism of Bun’s Claude rewrite, reported by The Register, reflected a legitimate concern about unreviewed changes presented as engineering progress. The Zig Software Foundation’s statements emphasize a more workable standard: contributors remain responsible for correctness, provenance and maintainability regardless of which tools they use. Repositories can translate that principle into policy. Maintainers should require contributors to describe the problem, explain key design choices, identify AI assistance and attest that they reviewed the output and have the right to submit it. High-risk changes should require evidence proportionate to their impact, such as benchmarks, fuzzing results, migration plans or failure-mode analysis. The Economist’s study finding that AI assistance improved homework performance but depressed unaided exam scores offers a useful warning: better immediate output doesn’t necessarily demonstrate durable understanding. Licensing is becoming an economic pressure valve. The OSI’s licensing materials distinguish approved open-source licenses from source-available arrangements such as the Business Source License, Elastic License 2.0 and Fair Source variants. Those models can restrict cloud providers from offering a project as a competing service, but OSI says they don’t satisfy the Open Source Definition. The trade-off is consequential: relicensing may help a vendor capture revenue, yet it can also trigger forks, complicate procurement and leave downstream users on older versions. Funding mechanisms carry different weaknesses. GitHub Sponsors data show that support tends to follow individual visibility, while Open Collective’s public ledgers demonstrate the benefits of transparent budgeting but also the volatility of donations. Tidelift’s surveys indicate that maintainers value predictable compensation for recurring work, including security response and release management, rather than occasional rewards. Foundations can provide continuity, though their dues and governance structures may be better suited to established projects than obscure dependencies. Enterprises should fund according to operational exposure, not stars or download counts alone. Procurement and security teams can identify dependencies with one active releaser, weak succession plans or no fiscal host, then provide unrestricted grants or contracts for defined maintenance outcomes. Payment per issue or pull request would reward the volume that AI makes cheapest. Better measures include maintained release branches, reproducible builds, documented response targets, signed artifacts, independent audits and succession planning. Corporate engineers can help, but they should work within maintainer-defined road maps. Funding should purchase capacity and resilience, not control disguised as sponsorship.

No detector can reliably establish that a patch was written by AI. The Felony Bench analysis found that apparent fluency and provenance are separable questions, while the Zig Software Foundation’s statements on AI-assisted code focus on reviewability rather than attempting to infer authorship. Maintainers should therefore build risk-scoring systems, not automated tribunals. Potential signals include abrupt changes in naming style, repetitive control flow, generic comments, unnecessary abstraction and tests that mirror implementation structure. Research summarized in the Felony Bench analysis suggests such patterns can support triage, but not attribution, because edited model output can resemble human work and human code can be highly formulaic. A defensible score should explain which observable features raised concern and should never return a purportedly precise verdict such as “87% AI-generated.” A pull-request pipeline can combine several evidence classes. GitHub’s branch-protection and CODEOWNERS documentation supports routing changes according to paths and required reviewers. The pipeline can add patch size, contributor history, sensitive ownership boundaries, new dependencies, static-analysis findings and secret-detection results. Changes to authentication, parsers, deserialization, build scripts, package manifests and release workflows should receive stricter review because CISA’s secure-software guidance identifies build systems, dependencies and privileged code paths as important supply-chain control points. A practical GitHub Actions job would check out the full history, calculate the diff against the target branch and run Semgrep, a secret scanner and repository-specific AST checks. Tree-sitter can parse supported languages into syntax trees, according to its project documentation, allowing a repository to measure patterns such as newly introduced broad exception handlers, disabled validation branches or duplicated test templates. The job should write a structured JSON report containing the feature, file, severity and reason, then post a nonblocking pull-request summary through the GitHub API. Risk should determine the required evidence. A documentation correction may need ordinary review, while a new parser may require fuzzing and differential tests. OpenSSF guidance recommends stronger controls around security-sensitive components, and mutation-testing tools can reveal tests that execute code without meaningfully checking behavior. For critical paths, branch protection should require approval from designated owners, successful security checks and evidence that changed behavior was tested independently of the implementation. Provenance controls are generally more durable than AI detection. GitHub supports signed commits and protected branches, while the SLSA framework specifies attestations connecting build artifacts to source and build processes. Projects can require contributors to disclose substantial AI assistance, certify that they reviewed the patch and identify any external material supplied to the model. Disclosure won’t prove ownership, but it creates an accountability record and gives reviewers grounds to request additional explanation. License analysis must remain separate from authorship analysis. The OSI’s guidance makes clear that source availability isn’t equivalent to open-source licensing, while SPDX documentation provides standardized identifiers for recording applicable licenses. AI output shouldn’t be presumed free of obligations: a patch that reproduces protected code may require notices or legal review, depending on the facts and jurisdiction. Organizations should use tools such as ScanCode Toolkit, FOSSology or ORT to identify substantial matches and preserve SPDX data, then send ambiguous findings to counsel rather than asking maintainers to make legal conclusions. Policy engines should also distinguish among license categories. OSI-approved permissive licenses, copyleft licenses and source-available terms such as BUSL and Elastic License 2.0 create different distribution and deployment considerations, according to OSI’s license materials and the licenses’ published texts. Automated checks can block unapproved dependencies, flag AGPL components for network-use review and record exceptions with an owner and expiration date. They shouldn’t assume that training on copyleft code automatically places every output under copyleft; that question depends on reproduction, derivation and applicable law. Supply-chain mapping begins with a machine-readable software bill of materials. CycloneDX and SPDX specifications define interoperable SBOM formats, while CISA recommends SBOMs as one element of software transparency rather than a complete security guarantee. Teams can run Syft against a repository or container to generate CycloneDX JSON, scan the result with OSV-Scanner and ingest it into Dependency-Track. For npm, lockfile analysis should be retained because resolved versions and transitive relationships may differ from top-level manifests. An SBOM should then be enriched with governance data. OpenSSF Scorecard evaluates signals including branch protection, dependency practices and release integrity; deps.dev and package registries provide dependency and version metadata; GitHub’s API exposes contributor and repository activity. GitHub Sponsors and Open Collective data can indicate whether a project has visible funding channels, although neither proves that maintainers receive sufficient or stable income. A funding-risk job can calculate active committers during the previous 12 months, release recency, number of authorized publishers, signed-release coverage, security-policy presence and fiscal-host links. Tidelift and The New Stack’s surveys support treating concentrated authority and unpaid maintenance as resilience concerns. Still, registry owners may be inactive, commits may not reveal publication authority and corporate contributors may disappear after a contract ends. The final assessment should combine automated evidence with governance documents and direct maintainer confirmation. The objective isn’t to determine whether each line came from a person or a model. It is to establish who reviewed the change, what evidence supports it, which license governs it, how the artifact was built and whether somebody has the capacity to maintain it. In an AI-heavy development environment, that evidence system is more valuable than any detector.