Remember that blog post "I got robbed of my first kernel contribution" where a maintainer slightly rewrote a patch and took credit for it? Well, I decided to do something about it.
I co-authored a guide with Maria Matějka and some other folks on documenting how your project gives credit and otherwise handles contributions. If your project's policy is to lightly rewrite contributions and take credit for them, say so! Subscriber link (free) to the LWN article:
When I started work on a credit policy for open source projects, I was mostly thinking about preventing a particular kind of plagiarism, in which a maintainer edits or slightly rewrites someone else's work and takes primary (or sole) credit.
But then a lot of maintainers who try hard to give credit told me about situations that look similar but weren't their fault. Someone submits a patch that doesn't get a review , then another person writes the same feature and gets accused of plagiarism.
Another surprise approach to contributing to open source projects was finding projects with a policy of not accepting outside contributions or always rewriting them for security or correctness reasons. It's hard to insert a subtle backdoor like the xz one if a trusted person reimplements it. (Of course in this case the ethical thing to do is list the original author as primary or co-author.)
Some projects make it obvious that only the maintainer gets credit for the entire project. When I sent in a minor bug fix to xscreensaver as I described in the LWN article, I knew I would not get credit because no one other than the primary author was credited.
The problem is projects that make it look like contributors get credit for their work, but in reality the maintainers take as much credit as they can for other people's work and rely on a supply of naive new contributors to plagiarize.
Then there is the true grey area: one person worries a first draft, another person edits, rewrites, refactors, implements from scratch... at some point, they have done more work than the original author. When is that?
Our recommendation is to bias your credit policy in favor of rewarding the behavior you want to incentivize. Need more reviews? Maybe consider giving all reviewers co-author credit. Whatever you want people to do more of, make your contributions and credit policy reward that.
I want to thank and credit again all the people who helped develop this guide to writing a contributions and credit policy. They are in the credits file in the guide (link below) as well.
Maria Matějka: writing, editing, the naming policy, and making the git repo
Marcos Sanz and Martin Winter: several ideas, making space for it at the RIPE Open Source Working Group
Many members of the RIPE OS WG for comments, suggestions, and ideas
My goal is that this is becomes like codes of conduct: so many projects have a written contributions and credits policy that the ones that don't start to stand out. I suspect that most maintainers aren't bold enough to have a written policy that says, "If I think I can get away with it, I will slightly edit your contribution and take primary credit for it." :)
Add comment