Hi. I’m Damien, a contributor to the project currently working on the pydofo library that’s meant to replace Calibre’s PoDoFo binding.
Upon interacting with upstream to file a bug report, I found out that the developer and maintainer of the library is experimenting with using Copilot to author PRs. Per cgranade’s taxonomy, this means that unless the maintainer changes his(?) mind, the project is on track to become AI-vulnerable.
So what am I to do about it ?
One one hand, this seems very much contrary to the purpose and the ethos of the rereading project. On the other hand, the landscape looks grim and complete isolation from AI dependencies looks like an increasingly hard problem, the situation may repeat for any dependency at any point in time.
What do you think should be the course of action here ?
Update: the exchange on the github issue went a bit further and the maintainer clarified its position and “experiments”. https://github.com/podofo/podofo/issues/318#issuecomment-3967036898
In this case it would have been an experiment only. As long as I am the maintainer, I guarantee this library will be free of AI slop. […]
I’m not intellectually satisfied by the response, but I guess that exchange can be taken at face value and provides some sort of policy for AI contributions to the library.
The issue of having a policy for handling such cases in the rereading Project still persists.
Thanks for writing this up and for raising the question. For starters, I don’t think this is ever going to be an easy question to answer in general. Mypy, uv, pdm, and even Python itself all have at least one Claude commit at this point, so I don’t think it’s possible to have a dependency chain with absolutely no AI-vulnerable code, nor do I think it’s the best use of energy to pursue a literal zero there.
Rather, I’d suggest that a good goal is to completely and totally eliminate AI antifeatures (AI-encumbered in the taxonomy I’ve been trying to popularize) while minimizing AI-vulnerable code as much as is reasonable. To that effect, my immediate gut reaction is that PoDoFo may not meet the bar at which we should eliminate it as a dependency? Should it get to that point, and I sincerely hope that it does not, your earlier suggestion of pinning to a version without AI-vulnerable code may be the best path forward. Vendoring may also be reasonable, given that PoDoFo is fairly close to a pure CMake project?
I agree that pursuing an absolute zero isn’t likely to have a good value/effort ratio. A significant part of the whole ecosystem is getting colored by AI, that’s an unfortunate fact, but it’s still a fact.
However, feature-specific dependencies are not likely to receive the same level of scrutiny than CPython, Mypy and other more widespread or foundational parts of the software stack. A switch to “AI assisted development” should raise a flag and crank up the level of vigilance a notch for affected dependencies.
Also, one of the nagging questions that keeps echoing in my head is : given the amount of work done, should fitness for purpose be reassessed ? PoDoFo was introduced as a dependency 16 years ago. That’s a completely separate question, but one for which the perceived opportunity cost can shift because of a loss of trust in the stewardship of the dependency.