QGIS, the open source mapping software, is blocking contributions written with AI…

Open source software remains one of the largest collaborative engineering efforts on record, yet it operates almost entirely on volunteer labor and informal social structures. When new tools change how contributions get made, the communities that maintain these projects face genuine questions about code reliability, legal liability, and cultural values. Understanding what's at stake requires looking at how open source evolved, what code review actually accomplishes, and why provenance matters. The history of open source review Open source projects emerged in the 1980s and 1990s as an alternative to proprietary software development. The early philosophy held that "given enough eyeballs, all bugs are shallow," meaning that community review of visible source code would catch errors better than secrecy could. This remains true in principle, but only if the eyeballs examining the code can actually understand what they're reading and who wrote it. From the start, open source maintainers developed implicit social practices around attribution, testing, and traceable contributions. These practices evolved partly to manage legal risk, partly to maintain code quality, and partly as cultural norms around intellectual honesty. What code review actually does When a volunteer maintainer reviews a code contribution, they're not just checking whether it works. They're verifying logic, spotting edge cases, understanding intent, and assessing whether the change fits the project's design philosophy. Code review is also an educational exchange: experienced maintainers teach newer contributors how the project thinks, what patterns it values, and why certain approaches get rejected. This knowledge transfer is largely invisible but essential to sustaining open source communities over decades. When a human writes code, their reasoning often appears in comments, commit messages, or discussion threads. A reviewer can ask why a particular approach was chosen, and the author can explain or defend their thinking. This dialog builds shared understanding and catches conceptual errors that automated testing misses. Provenance and liability Traceability matters legally and ethically in open source. If a bug causes harm, or if code accidentally includes someone else's intellectual property, project maintainers often face questions about where the code came from and whether proper review occurred. Open source licenses typically require attribution and transparency about origins. When a human submits code, they're implicitly stating that they wrote it or properly credited its sources. AI tools that generate code introduce a novel problem: the generated text may resemble existing code without clear attribution, may contain bugs no one fully understands, and raises questions about whether the person submitting it truly understands what they're contributing. A maintainer reviewing AI assisted code must now ask: did the human actually reason through this, or did they cop