Page Not Found
Page not found. Your pixels are in another canvas.
Sitemap
A list of all the posts and pages found on the site. For you robots out there is an XML version available for digesting as well.
Pages
Page not in menu
This is a page not in th emain menu
Posts
Beyond Banning AI: How 67 Open Source Projects Are Governing GenAI Contributions
Published:
Over the past year, one question has dominated discussions about GenAI and open source:
Hello world
Published:
Hello world!
portfolio
publications
PyRadar: Towards Automatically Retrieving and Validating Source Code Repository Information for PyPI Packages
[CCF-A] FSE 2024, 2024
A package’s source code repository records the package’s development history, which is critical for the use and risk monitoring of the package. However, a package release often misses its source code repository due to the separation of the package’s development platform from its distribution platform. To establish the link, existing tools retrieve the release’s repository information from its metadata, which suffers from two limitations: the metadata may not contain or contain wrong information. Our analysis shows that existing tools can only retrieve repository information for up to 70.5% of PyPI releases. To address the limitations, this paper proposes PyRadar, a novel framework that utilizes the metadata and source distribution to retrieve and validate the repository information for PyPI releases. We start with an empirical study to compare four existing tools on 4,227,425 PyPI releases and analyze phantom files in 14,375 correct and 2,064 incorrect package-repository links. Based on the findings, we design PyRadar with three components, i.e., Metadata-based Retriever, Source Code Repository Validator, and Source Code-based Retriever, that progressively retrieves correct source code repository information for PyPI releases. In particular, the Metadata-based Retriever combines best practices of existing tools and successfully retrieves repository information from the metadata for 72.1% of PyPI releases. The Source Code Repository Validator applies common machine learning algorithms on six crafted features and achieves an AUC of up to 0.995. The Source Code-based Retriever queries World of Code with the SHA-1 hashes of all Python files in the release’s source distribution and retrieves repository information for 90.2% of packages in our dataset with an accuracy of 0.970. Both practitioners and researchers can employ the PyRadar to better use PyPI packages.
Download here
Internal Vulnerabilities, External Threats: A Grounded Framework for Enterprise Open Source Risk Governance
[CCF-A] arXiv (Major Revision at TOSEM), 2025
Enterprise engagement with open source has evolved from tactical adoption to strategic deep integration, exposing them to a complex risk landscape far beyond mere code. However, traditional risk management, narrowly focused on technical tools, is structurally inadequate for systemic threats like upstream “silent fixes”, community conflicts, or sudden license changes, creating a dangerous governance blind spot. To address this governance vacuum and enable the necessary shift from tactical risk management to holistic risk governance, we conducted a grounded theory study with 15 practitioners to develop a holistic risk governance framework. Our study formalizes an analytical framework built on a foundational risk principle: an uncontrollable External Threat (e.g., a sudden license change in a key dependency) only becomes a critical risk when it exploits a controllable Internal Vulnerability (e.g., an undefined risk appetite for single-vendor projects), which then amplifies the impact. The framework operationalizes this principle through a clear logical chain: “Objectives → Threats → Vulnerabilities → Mitigation” (OTVM). This provides a holistic decision model that transcends mere technical checklists. Based on this logic, our contributions are: (1) a “Strategic Objectives Matrix” to clarify goals; (2) a systematic dual taxonomy of External Threats (Ex-Tech, Ex-Comm, Ex-Eco) and Internal Vulnerabilities (In-Strat, In-Ops, In-Tech); and (3) an actionable mitigation framework mapping capability-building to these vulnerabilities. The framework’s analytical utility was validated by three industry experts through retrospective case studies on real-world incidents. This work provides a novel diagnostic lens and a systematic path for enterprises to shift from reactive “firefighting” to proactively building an organizational “immune system”.
To Ban or Not to Ban? How Open Source Projects Govern GenAI Contributions
[CCF-A] ASE 2026, 2026
Generative AI (GenAI) is playing an increasingly important role in open source software (OSS). Beyond completing code and documentation, GenAI is increasingly involved in issues, pull requests, code reviews, and security reports. Yet, cheaper generation does not mean cheaper review — and the resulting maintenance burden has pushed OSS projects to experiment with GenAI-specific rules in contribution guidelines, security policies, and repository instructions, even including a total ban on AI-assisted contributions. However, governing GenAI in OSS is far more than a ban-or-not question. The responses remain scattered, with neither a shared governance framework in practice nor a systematic understanding in research. Therefore, in this paper, we conduct a multi-stage analysis on various qualitative materials related to GenAI governance retrieved from 67 highly visible OSS projects. Our analysis identifies recurring concerns across contribution workflows, derives three governance orientations, and maps out 12 governance strategies and their implementation patterns. We show that governing GenAI in OSS extends well beyond banning — it requires coordinated responses across accountability, verification, review capacity, code provenance, and platform infrastructure. Overall, our work distills dispersed community practices into a structured overview, providing a conceptual baseline for researchers and a practical reference for maintainers and platform designers.
File-Level Copying Is an Implicit Dependency in Open Source
arXiv, 2026
File-level copying is a widespread but ungoverned form of software reuse. Copying files across repositories reduces supply-chain visibility: it removes the four observable signals a package manager provides for a declared dependency (provenance, maintenance, security, and compliance) with no mechanism to restore them. To characterize the scale and consequences of this unmanaged reuse, we present a mixed-method study of copying across the entire open-source ecosystem using World of Code (WoC). From a 0.1% commit sample, we extract 690,500 copy events and retain 3,912 rationale-bearing copy commits for intent labeling. We show that the 13 axial copy forms, spanning vendored dependencies, hardware/driver synchronization, scaffolding, UI assets, and direct source-code reuse, are unreliable proxies for developer intent: among rationale-bearing commits, hardware/driver copies are predominantly fork-maintenance work (78%), while dependency-vendoring copies more often signal upstream bypass (70%) than offline availability. These visibility gaps are form-specific: security and license risk concentrate in complementary copy forms. Copied sources are frequently stale (median 155 days; 38.5% over one year old) and seldom record a recoverable origin (4.3% documented), let alone a checkable version (2.0% versioned); even vendored copies record where they came from only 10% of the time. Security risk concentrates in vendored dependencies: 17,314 CVE-risk copy commits in the full-WoC graph, 88% in the dependency-vendoring form; 80% score CVSS ≥ 7.0 and upstream-fix adoption is only 47%-84%. License risk concentrates in direct source-code reuse: 41,777 pre-validation candidates, 66% in the source-code form, with 39 verified high-star violations (kappa = 0.752). Both risks reach packaged software and are invisible to dependency scanners operating on declared metadata alone.
AI Cannot Review What Humans Catch: An Empirical Study of Agent Instruction File Review
Preprint, 2026
Agents increasingly shape software, and instruction files steer them. Files such as AGENTS.md, CLAUDE.md, .cursorrules, and SKILL.md act as executable policy: prose that a machine reads and acts on. Unlike ordinary documentation, a single edit to one of these files can silently redirect how an agent behaves across an entire repository. Natural-language rules have no per-change oracle, so they slip past the compilers, type-checkers, and test suites that guard code. Review is therefore the only quality gate, but no prior work has studied how that review happens. We analyzed 2,870 instruction-file pull requests across 2,246 repositories. The gate is largely broken: over 70% of instruction-file changes receive no substantive review. When an AI reviewer substitutes for a human, it is structurally blind to the concerns that most need human judgment. It catches surface structure but misses factual errors, necessity questions, and staleness problems. We contribute the first taxonomy of instruction-file review concerns (16 categories), which exposes this sharp human/AI divergence, and a benchmark of 1,962 human-checked concerns across 468 PRs. We ran three widely-used agents (Codex, OpenCode, and Claude Code) against the benchmark, giving each reviewer the full repository at review time. They recovered only 1.3–3.9% of the concerns humans raise. Even the strongest current agents cannot substitute for human attention on these files.
From Collaboration to Regulation: Characterizing Governance Practice in Three Deep Learning Open Source Communities
arXiv, 2026
Collaboration in Open Source Software (OSS) projects creates substantial coordination and quality-control challenges across diverse contributor bases. Projects address these challenges through documented governance rules, yet maintainers have limited systematic guidance on what rules to codify, when to introduce or revise them, and how to organize them across documents. We conducted a mixed-methods empirical study of three mature deep learning frameworks: PyTorch, TensorFlow, and Paddle. Using the Institutional Analysis and Development framework, we analyzed 109 documents and identified 17 rule themes across seven rule types. Operational rules, such as workflows, appeared across all three projects, whereas structural rules, such as role hierarchies, varied more substantially. Tracing more than 1,700 commits, we found that operational rule themes generally appeared earlier and were revised more frequently, while many structural rule themes emerged later and changed less often. Rule-bearing content also became increasingly specialized across task- and role-specific files. We further identified four governance functions reflected in substantive rule changes: Norm Alignment, Workflow Refinement, Coordination Structuring, and Community and Governance Development. Synthesizing these findings, we derive 33 actionable governance practices for mature, large-scale OSS projects with substantial coordination demands and organizational involvement.
A First Look at Coding Agents’ Compliance with AI Contribution Rules in Open-Source Communities
arXiv, 2026
Open source communities have been flooded with AI-generated contributions. In defense, they have written contribution rules to regulate coding agents’ behavior, spanning from a total ban, mandatory disclosure, to verification gates and human sign-offs. Yet, whether coding agents read and follow those rules, and behave in open source repositories, remains unknown. To estimate real-world rule compliance of coding agents, we curate 106 issues from 49 repositories containing AI contribution rules into RepoComplianceBench. We judge the trajectory of each run against the repository’s rules, measuring whether the agent refuses to contribute, discloses its assistance truthfully, clears the required verification gates, or escalates critical steps to a human. We also test if extra prompts, rule disclosure, or feedback from the compliance verifier help with the situation. Our experiments on four frontier models show that today’s agents almost never proactively retrieve the contribution rules. Agents pick up disclosure and verification with reminder prompts, rule quotes, and verifier feedback; however, they never refuse to contribute in AI-banned repositories under any condition we tested. The status reveals that verification and disclosure issues are solvable with existing mechanisms, yet enforcing bans and human escalations remains an open problem.
talks
Building an Enterprise Open Source Risk Governance Immune System
Published:
Invited talk on enterprise open source risk governance at the CCF ChinaSoft 2025 conference, discussing how organizations can build systematic defenses against open source supply chain risks.
To Ban or Not to Ban? How Open Source Projects Govern GenAI Contributions Permalink
Published:
Invited talk at Community Over Code Asia 2026 in the Community track on how open source projects govern generative AI contributions.