This past week one of my open source students was presenting on a bug she'd fixed in a big project. Toward the end of her demo, she made an off-hand comment about how a maintainer had included her fix, but not the commit itself. Her code found its way into the project, but she didn't.
This is problematic on a number of levels. IANAL, so I won't spend a lot of time diving into the legal and copyright issues. However, I did want to say something practical about the community side of this.
When new people contribute to a project, part of what they're after is the chance to belong, to show up in the credits, and to be seen to be capable of doing work at this level. It's an important signal. I can't tell you how many former students come back to tell me about what it's like applying to jobs when you already have a significant open source contribution history. One story I love: a former student was in an interview with 3 senior dev leads, and one asked: "What kind of software have you worked on?" She causally pointed to his monitor, which was running VSCode. "That," she pointed. Enough said.
A developer who has been doing this day-in and day-out can become blasé about the whole thing. Facebook's devs land 100K commits a week, for example; so what's one more? If it's your first, or represents a major step forward, I think it's important that it get treated with some care and respect.
To that end, I wanted to take a moment to point out to my colleagues the usefulness of GitHub's Co-authored-by commit message parsing. In cases where you've somehow lost the original author info, this can allow you to still leave a note that more than one person worked on this. All you need to do is structure your commit message like so:
Fixing bug xyz
Co-authored-by: <name@example.com>
Co-authored-by: another-name <another-name@example.com>In GitHub, the commit will show all the various people involved in the work. It's a small thing, but it's really easy to add, and in so doing, visibly welcome someone into your project and community.