Appendix J — Crazy Ideas

J.3 Development Completeness as a Second Axis of Openness

The book has made the governed engineering environment the primary engineering asset. One consequence lands on open source, and it wants stating carefully, because the reflex is to overclaim. Software firms have long shipped source while withholding what makes source easy to change — an absent design manual, internal build tooling, the operational know-how that never left the building. Agentic engineering does not invent that gap between having the code and being able to evolve it. It enlarges it. As more of an organization's effective development capability moves into models, skills, validators, policies, and context machinery, a larger fraction of what lets the originating team change the system quickly and safely comes to sit outside the production source tree.

The open-weights debate is the near analogy. Model weights without the training data, recipe, and evaluation regime are inspectable and modifiable, and still do not hand you the originating lab's capacity to produce the next version. Source without the governed environment is the software echo: forkable code that does not by itself reproduce the loop through which the upstream fleet reliably modifies it.

The literature already knows this shape, one layer at a time. The Open Source Definition ties openness to the "preferred form in which a programmer would modify the program" and rejects deliberately obfuscated source11. Open Source Initiative, “The Open Source Definition,” accessed August 7, 2026, https://opensource.org/osd. — openness has never meant "whatever artifact happens to be human-readable." Reproducible-build research makes the next move downstream: source availability does not by itself establish that a distributed binary corresponds to that source, so trustworthy reconstruction depends on the build environment and instructions too,22. Chris Lamb and Stefano Zacchiroli, “Reproducible Builds: Increasing the Integrity of Software Supply Chains,” IEEE Software 39, no. 2 (2021): 62–70.33. Marcel Fourn\'e et al., “It's Like Flossing Your Teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security,” in 2023 IEEE Symposium on Security and Privacy (SP) (2023). tooling exists to hunt the discrepancy between published sources and the packages actually shipped,44. Duc-Ly Vu et al., “Lastpymile: Identifying the Discrepancy between Sources and Packages,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) (2021). and rebuild studies at scale confirm that reproducibility hinges on controlling environmental detail, not on the source alone.55. Ludovic Courtès, “Building a Secure Software Supply Chain with GNU Guix,” The Art, Science, And Engineering of Programming 7, no. 1 (2023): 1, https://doi.org/10.22152/programming-journal.org/2023/7/1.66. Julien Malka et al., “Does Functional Package Management Enable Reproducible Builds at Scale? Yes.,” in Proceedings of the 22nd IEEE/ACM International Conference on Mining Software Repositories (2025), https://doi.org/10.1109/MSR66628.2025.00115.77. Aman Sharma et al., “Causes and Canonicalization of Unreproducible Builds in Java,” IEEE Transactions on Software Engineering, 2025, 1–15, https://doi.org/10.1109/TSE.2025.3627891. A separate strand shows that legally open code can still be hard to extend when the surrounding knowledge is missing — documentation and newcomer barriers impede contribution,88. Igor Steinmacher et al., “A Systematic Literature Review on the Barriers Faced by Newcomers to Open Source Software Projects,” Information and Software Technology 59 (2015): 67–85, https://doi.org/10.1016/j.infsof.2014.11.001. and feature knowledge is often scattered through prose with rare explicit links back to the code.99. Tim Puhlfürß et al., “An Exploratory Study of Documentation Strategies for Product Features in Popular Github Projects,” 2022. The Open Source AI Definition then met the same question one field over, extending "preferred form for modification" past weights to the data and process information a skilled person needs to rebuild a substantially equivalent system.1010. Open Source Initiative, “The Open Source AI Definition 1.0,” 2024, https://opensource.org/ai. MAGE suggests the analogous next step for agentic software: as environment artifacts become part of the effective means by which a project is modified, practical modifiability may increasingly depend on whether those artifacts are shared too.

Inset — the right-to-repair analogy. A machine can be owned outright and still be hard to repair without the maker's diagnostic tools and manuals. In July 2026 the FTC and five states settled with Deere & Company, requiring it to give farmers and independent shops the repair resources authorized dealers already held: diagnostic and fault-code tools, component reprogramming, restart capability, and technical documentation.1111. Federal Trade Commission, “Federal Trade Commission V. Deere & Company: Joint Motion for Entry of Stipulated Order for Permanent Injunction and Other Relief,” July 2026, https://www.ftc.gov/legal-library/browse/cases-proceedings/211-0191-deere-company-ftc-v. The owner already had the tractor; what was withheld was the capability to diagnose and restore it. Read as an engineering principle, not legal precedent, it names the distinction this note draws — possessing the artifact is not possessing the means to evolve it. The progression runs continuously: OSI ties openness to the form used for modification; reproducible builds show source alone may not rebuild the artifact; right-to-repair shows owning the artifact may not supply the tools to maintain it; MAGE suggests source alone may increasingly fail to reproduce the capacity to evolve a system safely at scale. So the open-software question becomes not only whether the source is available, but how much of the effective development environment is shared with it.

This does not redefine open source, and it should not. OSI openness concerns licenses and rights, and OSI itself treats reproducibility as a requirement layered on top of openness rather than identical to it. The cleaner move is a second axis. Source openness asks whether outsiders hold the legal and technical artifact they may modify. Development completeness asks how much of the originating team's capacity to modify it has been shared as well. That axis admits degrees:

  • source available → build reproducible → tests reproducible → engineering-knowledge available → governance reproducible → agentic-development-environment reproducible.

A project can be fully open at the first rung and progressively less complete at the later ones. The progression measures; it does not indict. Where a project stops describes it, and no rung is owed.

The supply-chain reading is the sharper half. Conventional supply-chain thinking already counts build tools, compilers, and CI systems: components that shape an artifact without shipping inside it. The extension is that judgment-bearing artifacts now join that chain. Third-party skills, MCP and tool servers, agent profiles, policy bundles, context providers, and validators can causally change what code an agent produces even though none of them ship in the product. This connects straight to the governance graph the book drew. An imported skill can collide with a local one; a vendor validator can carry assumptions the project's model rejects. Those are supply-chain composition problems inside the environment, not the artifact. Industry is beginning to treat them that way. A major vendor now runs third-party skills through a multi-stage supply chain of review, scanning, evaluation, signing, and provenance,1212. NVIDIA, “NVIDIA Verified Agent Skills Provide Capability Governance for AI Agents,” NVIDIA, 2026, https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/. and a study of policy-as-code adoption finds governance and configuration concerns already externalized into machine-readable project artifacts across hundreds of repositories.1313. Patrick Loic Foalem et al., “An Empirical Study of Policy-as-Code Adoption in Open-Source Software Projects,” Journal of Systems and Software 242 (2026): 113028, https://doi.org/10.1016/j.jss.2026.113028. Portions of the environment are becoming source-like artifacts in ordinary open source.

The commercial angle follows without sensation. Firms have long opened code while keeping operational expertise, internal infrastructure, and tooling; a proprietary governed environment is the agentic-era extension of that old asymmetry, with the moat sitting in accumulated engineering capital rather than in hidden source. A security-of-sharing corollary rides along: an organization may be able to publish larger, more consequential systems if the safety-critical engineering capability stays encoded in an environment it does not distribute. The flip side is equally real. If downstream users must then maintain the release without that environment, withholding it can make the release less sustainable rather than more secure — a recent treatment of the open-weights problem points the same direction, arguing that reconstructing an AI system may need code, data, weights, toolchain, and hardware configuration, not source alone.1414. Masayuki Hatta, “Reproducibility Is the New Copyleft: Defining AGI-Oriented Reproducible Builds,” 2026, https://doi.org/10.2139/ssrn.6886361.

Where the analogy stops is where the novelty sits, and it is narrow. Environment artifacts may constitute a new layer of a project's effective development form and its supply chain precisely because they encode the judgment through which autonomous agents modify the source. The source tree tells you what the system is; the governed engineering environment increasingly decides how fast and how safely it can become something else. Candidate research questions.

* What constitutes development completeness in an agentic open-source project? * Which environment artifacts should be counted part of the software supply chain? * Can commercial open source hold a durable advantage by opening the artifact while retaining parts of the engineering environment? * Behind all three: what does it mean to share enough of a governed engineering environment for an outsider to reproduce not merely the artifact, but the originating project's capacity to evolve it?

Works Cited

  1. Open Source Initiative. “The Open Source Definition.” Accessed August 7, 2026. https://opensource.org/osd.
  2. Lamb, Chris, and Stefano Zacchiroli. “Reproducible Builds: Increasing the Integrity of Software Supply Chains.” IEEE Software 39, no. 2 (2021): 62–70.
  3. Fourn\'e, Marcel, Dominik Wermke, William Enck, Sascha Fahl, and Yasemin Acar. “It's Like Flossing Your Teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security.” In 2023 IEEE Symposium on Security and Privacy (SP). 2023.
  4. Vu, Duc-Ly, Fabio Massacci, Ivan Pashchenko, Henrik Plate, and Antonino Sabetta. “Lastpymile: Identifying the Discrepancy between Sources and Packages.” In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 2021.
  5. Courtès, Ludovic. “Building a Secure Software Supply Chain with GNU Guix.” The Art, Science, And Engineering of Programming 7, no. 1 (2023): 1. https://doi.org/10.22152/programming-journal.org/2023/7/1.
  6. Malka, Julien, Stefano Zacchiroli, and Th\'eo Zimmermann. “Does Functional Package Management Enable Reproducible Builds at Scale? Yes..” In Proceedings of the 22nd IEEE/ACM International Conference on Mining Software Repositories. 2025. https://doi.org/10.1109/MSR66628.2025.00115.
  7. Sharma, Aman, Benoit Baudry, and Martin Monperrus. “Causes and Canonicalization of Unreproducible Builds in Java.” IEEE Transactions on Software Engineering, 2025, 1–15. https://doi.org/10.1109/TSE.2025.3627891.
  8. Steinmacher, Igor, Marco Aurélio Graciotto Silva, Marco Aurélio Gerosa, and David F. Redmiles. “A Systematic Literature Review on the Barriers Faced by Newcomers to Open Source Software Projects.” Information and Software Technology 59 (2015): 67–85. https://doi.org/10.1016/j.infsof.2014.11.001.
  9. Tim Puhlfürß et al., “An Exploratory Study of Documentation Strategies for Product Features in Popular Github Projects,” 2022.
  10. Open Source Initiative. “The Open Source AI Definition 1.0.” 2024. https://opensource.org/ai.
  11. Federal Trade Commission. “Federal Trade Commission V. Deere & Company: Joint Motion for Entry of Stipulated Order for Permanent Injunction and Other Relief.” July 2026. https://www.ftc.gov/legal-library/browse/cases-proceedings/211-0191-deere-company-ftc-v.
  12. NVIDIA. “NVIDIA Verified Agent Skills Provide Capability Governance for AI Agents.” NVIDIA, 2026. https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/.
  13. Foalem, Patrick Loic, Foutse Khomh, Leuson Da Silva, and Ettore Merlo. “An Empirical Study of Policy-as-Code Adoption in Open-Source Software Projects.” Journal of Systems and Software 242 (2026): 113028. https://doi.org/10.1016/j.jss.2026.113028.
  14. Hatta, Masayuki. “Reproducibility Is the New Copyleft: Defining AGI-Oriented Reproducible Builds.” 2026. https://doi.org/10.2139/ssrn.6886361.
© James C. Davis, 2026–present