I think the paper looks at the wrong problem.
It treat gating like the thing that breaks the contributor pipeline, but I think a lot of this pipeline was already gone before anyone closed the door.
The old way worked because when you write a patch and you had to learn the codebase before.
And talking in the review made a relationship with the maintainer. But a PR someone make in ten minutes don't do this.
The person who submit learns nothing about the architecture, and maintainer learns nothing about the other person.
The review is just the maintainer doing the work two times. The form is still there, but not the substance. Gating just shows this. For me, it is more interesting where motivation comes from now. When an AI agent write the code, writing a good issue is much closer to real work than a PR ever was. You need to understand the project really good to describe the problem, the context, and edge cases.
Getting credit when a bug is fixed, test pre-releases, feedback buttons inside the app: this feels like much better places to invest instead of trying to save the PR as social ritual.
I had a few own projects, and it was really not easy to get people contributing. But getting good feedback to make the project better was much more easy.
So maybe we need a less technical way for engaging with the community.
Where the authors are right, I think, is succession. A person who write great issues still don't know the
code good enough to take over if the maintainer leaves. People can engage with issues and feedback,
but maintainability don't work like that. And I haven't seen a good answer yet how the next maintainer should learn the system if they never had reason to read it.
Maybe we need a way to give the users a better way to give feedback to the project and make their feedback showable in the project. This is also important for many people.
I think the paper looks at the wrong problem. It treat gating like the thing that breaks the contributor pipeline, but I think a lot of this pipeline was already gone before anyone closed the door. The old way worked because when you write a patch and you had to learn the codebase before. And talking in the review made a relationship with the maintainer. But a PR someone make in ten minutes don't do this. The person who submit learns nothing about the architecture, and maintainer learns nothing about the other person. The review is just the maintainer doing the work two times. The form is still there, but not the substance. Gating just shows this. For me, it is more interesting where motivation comes from now. When an AI agent write the code, writing a good issue is much closer to real work than a PR ever was. You need to understand the project really good to describe the problem, the context, and edge cases.
Getting credit when a bug is fixed, test pre-releases, feedback buttons inside the app: this feels like much better places to invest instead of trying to save the PR as social ritual. I had a few own projects, and it was really not easy to get people contributing. But getting good feedback to make the project better was much more easy.
So maybe we need a less technical way for engaging with the community. Where the authors are right, I think, is succession. A person who write great issues still don't know the code good enough to take over if the maintainer leaves. People can engage with issues and feedback, but maintainability don't work like that. And I haven't seen a good answer yet how the next maintainer should learn the system if they never had reason to read it.
Maybe we need a way to give the users a better way to give feedback to the project and make their feedback showable in the project. This is also important for many people.
Maintaining Open Source Software in the age of AI...
[flagged]