1. 14

This happened to me not once, but twice (and I saw it happen with colleagues and friends as well), and it strikes me as quite odd, so I wanted to ask your opinion on the matter.

I found an open-source project which helps me directly with something I’m working on, and I went to dig through it, which led me to find a mistake on one of the documentation files.

My first reaction was to immediately submit a patch (pull request) with the correction, explaining on the issue about it and asking if the authors thought it made sense to them.

As a surprise, they replied not only with a nice comment, thanking me for finding the bug, but also with a couple of commits attached to it, actually fixing the mistake themselves, pretty much doing the same thing I did on my patch.

Now, I understand that no project is required to accept community patches at all, but as far as I understand, there should be a way for us, the community, to actually differentiate between the projects which are open for contributions from the ones that are not (or maybe have restrictions, limitations).

Anyway, I thought it would be nice to get your thoughts on it all.

  1.  

  2. 28

    I have been in a similar spot and I can understand this kind of small disappointment. I will offer a few thoughts that may or may not help!

    This can be hard, but understand that by the maintainer setting aside your commit, they were surely not making a personal slight. By instead using their own commits for the fix, they are NOT saying your proposal was “wrong” or “not good enough”.

    Remember the only social expectation a good open source maintainer could owe you for an unsolicited proposed contribution is a hearty thanks. You made the valiant choice to give freely of your time and talent. You should feel good about that! What you offered was a gift, and when we offer any gift, we must be mindful that we cannot expect reciprocation. That would make it a transaction, not a gift!

    There are a variety of causes for why the maintainer did not merge your patch as you may have imagined they would.

    You didn’t say what project it was, which is fine, but if it’s a big project or from a large organization, consider they often have strict contribution guidelines that are necessary for legal reasons, such as a “contributor license agreement”.

    If your report was just a small typo or a few words, it would be a little silly for them to ask you to sign a big CLA before merging your patch. It’s possible they might have read your report, ignored the patch, and made their own fix. If that’s what happened, they actually did you a favor, by saving both of you that overhead effort.

    Most large projects have a file in the repo named CONTRIBUTING or similar, that would lay this out.

    It’s also possible they wanted to make the fix a slightly different way, and it was easier for them to do it directly rather than merge your patch and then make another commit on top of it. Maybe they want the commit message writtem a certain way, so the git history is more to their liking. Projects do not get points based on how many commits they merge in! :)

    As a takeaway, remember that what you offered did have value – you saw the pothole, and then your intended impact was achieved, in that it got fixed. The question of whose version of the fix made it to the git history becomes irrelevant. Future strangers will no longer trip over this particular pothole thanks to your report.

    For myself, I am glad the open source community has people doing things like you did!

    1. 4

      I think this comment is spot on but I wanted to add a few points.

      When I first started getting into free/libre/open source, I had a default understanding of what it meant to be “open” and allow for community contributions in that I thought these type of “drive-by” patches/bug fixes/etc. were the norm. Free software projects are varied and have different ideas of what it means to allow for community involvement and this “bazaar” approach of folding in changed proposed by community members with low engineering involvement are one style of contribution. The “cathedral” approach is another, whereby the developers are the ones with sole access to the repository and only allow contributions from their inner circle and extend their inner circle selectively with folks who commit to having a deeper involvement in the project.

      Remember that “The Cathedral and the Bazaar” [1] talks about an Emacs/Stallman type style of contribution (the “cathedral”) vs. Linux/Torvalds style of contribution (the “bazaar”). I had only really heard the title and, in my ignorance, assumed that Raymond was making a “Linux vs. Microsoft” argument.

      From my personal experience, when people submit patches to my own (very small and not very popular) FOSS projects, I have an initial reaction of “not quite like that, like this”. I want to practice a more “bazaar” like methodology and so it’s something I’m trying to ween myself off of but it’s a natural reaction that I have to overcome and one, I imagine, many other people feel. I think accepting contributions of this sort also provide a welcoming approach to people, so they get positive re-enforcement and pave the way for more substantial contributions.

      I think [tedchs] correctly points out that having a CONTRIBUTING file for guidelines (or something similar) is sometimes present and should maybe be the norm (maybe with some type of template people can choose from) but this is a layer of process that needs to be created. For small projects, especially ones that don’t have a concrete idea of how to accept contributions, this is a layer of process infrastructure that adds complexity and might not be appropriate for the scale or scope that the project is currently.

      As a general rule of thumb, when trying to contribute to other projects, I usually create an issue with an offer to help and, only after confirmation, proceed to contribute. I violate this all the time but this is one tactic to differentiate between whether the project is “cathedral-like” or “bazaar-like”

      [1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

      1. 3

        To add a different voice:

        I, as a maintainer ,think this is disrespectful.

        If I receive PR, it’s not even a question for me whether I acknowledge the contributor’s work and retain his/her authorship.

        If the PR needs to be adjusted, I either tell the contributor, or do it myself in a separate commit. If the adjustment is very small, I may do it in the original commit, but still retain him/her as the author.

        1. 2

          If your report was just a small typo or a few words, it would be a little silly for them to ask you to sign a big CLA before merging your patch.

          It sometimes happens even for non-trivial patches and even if you sign CLA. Example: Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java. (later implemented internally).

          Nobody is obliged to accept your contribution (which is OK – on the other hand, nobody can force you to merge his code).

          1. 2

            If your report was just a small typo or a few words, it would be a little silly for them to ask you to sign a big CLA before merging your patch.

            Copyright rights in the U.S. can be terminated by the estate after the author dies. This is one of the reasons that most corporate open source projects require a CLA. Here is a post by a lawyer that describes other problems solved by a CLA.

          2. 15

            I’ve done this before. I’m very particular about code performance, compatibility and readability and will sometimes ignore a PR and implement it myself so that the codebase reads as “one voice” rather than a hodgepodge of authors and styles. There’s no malice or ill will involved, just my own style of project ownership.

            1. 4

              What I do for Oil is to review the patch for basic things, and then merge after initial revisions.

              But at least 50% of the time, there needs to be some more followup, and I usually do that myself. I feel some people might feel weird at me changing the same code right afterward. I don’t know of a good way around this, and am open to feedback …


              For example in a review for a recent commit, I missed the fact that the test harness wasn’t working, so the patch didn’t actually pass the tests. So I fixed the test harness and fixed the tests, and fixed the code. It took like 3 followup commits…

              Another instance is that we prefer to write Python in a style that can’t use certain constructs, and uses less memory allocation (due to mycpp, etc.)

              So sometimes I feel like there is a balance between explaining all these rules… and just moving things forward.

              And to be honest it helps me understand what other people have done by “fixing” their code.


              FWIW I have been on the other side of this. I contributed to a C project, and they “fixed” my commit by introducing memory safety bugs … And they rejected my patch to add ASAN to the build system.

              So I never contributed to that project again.

              Oil is very test driven, and I hope that can resolve a lot of differences. But I noticed that many open source devs are not used to working in a test driven style! Especially when the tests are shell scripts and not Python or C++ programs.

              1. 2

                I have very similar experiences, including the bit about „fixing“: it’s very hard for me to do a proper code review without actually tweaking the code myself to check for alternatives. In theory, this should be solved by better review tools: the review tool at JaneStreet, for example, doesn’t have separate „review comments“, instead the review is done by checking in the code and writing actual code comments.

                In practice, with GitHub‘s existing tooling, I resort to just documenting the „optimistic merging&followup fixups“ approach: https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/dev/style.md

                1. 1

                  Yeah that’s exactly how I would describe it – “optimistic merging and “fast followup”. If something is going to save me effort, or somebody wants it and it works, I will merge it. And I continuously refactor the code.

                  However I tend to do some follow-up fixes right away, which I suppose can be jarring because if the person is going to work on that code again, then they may need to merge. But I would say >50% of the time they’re not going to work on the code again.

                  If I wait too long, then I’ll have moved something else, so I do it right away …

                  But it’s good that you documented that, and I will do the same explicitly!

              2. 3

                At first, I missed the part about how they ignored your patch. That’s weird. I know personally that it’s very hard to let someone else’s code into a project you’ve worked hard on. The bottom line is, do your part to make sure your own projects are the ones you would feel good contributing to.


                I originally wrote the following response:

                I generally look over a repository before I try to contribute. It’s important to me that the maintainers have put effort into the project, and are responsive to new issues and pull requests.

                Here are some things I look for:

                • Are there contributing guidelines, or is there a detailed readme?
                • How many issues are open with no responses? There’s no harm in being busy, but make sure PRs are likely to be seen.
                • Are there open PRs? I’m guilty of letting PRs stay open, but it’s no excuse.
                • Is there a license? I don’t want legal trouble.
                1. 2

                  I think they stole your patch. “THANK YOU HEARTY LOL!”

                  Don’t contribute again to them, maybe it was a small thing in the first place, but reading around here proposes this is done to avoid contracts being formed.

                  Edit: Oh, you probably know that. You want to distinguish between projects that do this and that do not.

                  1. 2

                    Yes, there is such a way. It’s the norm nowadays that projects have a CONTRIBUTING document which tells you how to contribute. If the project does not have such a document, don’t assume that it will accept contributions. Instead, ask.

                    1. 2

                      I would counter by saying that this is, or should be, the “norm”. Open-source maintainers, myself included, have a responsibility to the community that has formed around their software. It is our duty to ensure that anyone who feels the need to contribute code, documentation, or anything else should be encouraged to do so.

                      GitHub has a way of doing this, you can disable issues and pull requests but allow the code to be visible. This is what I would refer to as “source-available”, but not “open-source”, since it doesn’t allow modification of the codebase or discussion around the direction it’s going. Additionally, GitHub has built in some other ways of letting people know what the “rules” are (like having to sign some kind of CLA to make a patch) around contributing.

                      1. 14

                        I would counter by saying that this is, or should be, the “norm”. Open-source maintainers, myself included, have a responsibility to the community that has formed around their software. It is our duty to ensure that anyone who feels the need to contribute code, documentation, or anything else should be encouraged to do so.

                        So if I create a tool in my spare time for my own reasons, put it on the internet, and enough people like it and start using it, then I’m automatically “responsible” and “have a duty” to respond to everything that comes my way?

                        This is what I would refer to as “source-available”, but not “open-source”, since it doesn’t allow modification of the codebase or discussion around the direction it’s going.

                        Nowhere do I see anything in the OSI that I need to accept “discussions around the direction it’s going” of my spare time hobby project. It’s my spare time and hobby, and I don’t owe you or anyone else one microsecond of it.

                        you can disable issues and pull requests

                        You can’t disable Pull Requests in GitHub by the way, only issues.

                        1. 1

                          So if I create a tool in my spare time for my own reasons, put it on the internet, and enough people like it and start using it, then I’m automatically “responsible” and “have a duty” to respond to everything that comes my way?

                          If you make it seem like you accept pull requests and issues, then yes. Responding to issues and PRs is not hard. I’m not the best at it, but I still manage. If you don’t want people to do that, then why are you making it open-source? Why not just offer downloads on your own site?

                          Nowhere do I see anything in the OSI that I need to accept “discussions around the direction it’s going” of my spare time hobby project. It’s my spare time and hobby, and I don’t owe you or anyone else one microsecond of it.

                          The OSI doesn’t define what open-source means to me, but I see what you’re saying. A hobby project doesn’t tend to have the same issues as a large-scale project depended on by thousands. But in the unlikely event that your project grows enough traction for it to be a maintenance problem, would it make more sense to hand control over to someone else? If that’s not desirable or possible, then your best strategy is to make it very clear that the repo will not be accepting any PRs, and (perhaps automatically) close any that get created.

                          I don’t think the solution is to give people the idea that they can contribute, only to tell them that you’re not going to accept their contribution after they’ve already done all the work.

                          You can’t disable Pull Requests in GitHub by the way, only issues.

                          I guess that’s true. Was probably thinking of the ability to make a repo “read-only”. In that case, I would say that GitHub (and/or GitLab) should endeavor to make that possible. It would definitely solve a lot of community interaction problems that some larger projects have to deal with.

                          1. 12

                            Responding to issues and PRs is not hard.

                            I think you might benefit from hearing an alternative perspective: https://blog.burntsushi.net/foss/

                            Otherwise, this is an incredibly shallow view. Responding to PRs isn’t just a matter of hitting a merge button. They require review. Debate. Design work. And of course, managing the personality on the other side. Most folks are pleasant to deal with but some are not.

                            If you don’t want people to do that, then why are you making it open-source? Why not just offer downloads on your own site?

                            Not all PRs are created equal. Some PRs are easy to merge. Some are not. And sometimes I just run out of time.

                            And there are plenty of other advantages to putting projects on GitHub as opposed to just offering a download somewhere else.

                            But in the unlikely event that your project grows enough traction for it to be a maintenance problem, would it make more sense to hand control over to someone else?

                            Pretty much all of my open source projects are “hobby” projects in the sense that I work on them in my free time. Several of them have grown quite popular and others have become foundational components in their respective ecosystem. I maintain many projects and it is absolutely a time sink that I alone cannot really keep up with.

                            The “hand it over to someone else” suggestion is repeated a lot without giving much thought to what it actually means in practice. That “someone else” might end up being a worse maintainer than you were. And then there’s supply chain attacks to consider, which have actually happened because the new maintainer wasn’t properly vetted. Which basically means that handing over a project to someone else is not the panacea that it appears to be. Arguably, it might be better to just let someone fork the project and inject life that way.

                            I say this as someone who has handed maintenance of projects over to others on several occasions. While there have been a couple successes, most of those handovers have been failures.

                            If that’s not desirable or possible, then your best strategy is to make it very clear that the repo will not be accepting any PRs, and (perhaps automatically) close any that get created.

                            Again, easier said than done. A project rarely becomes unmaintained due to an explicit decision. It’s more often that the project languishes until it becomes de facto unmaintained. And admitting to yourself that this is not only the current state but its indefinite state can be difficult. Often, we intend to get back to the project, but for one reason or another, it just doesn’t happen. Or doesn’t happen on a time scale that is suitable for users.

                            I don’t think the solution is to give people the idea that they can contribute, only to tell them that you’re not going to accept their contribution after they’ve already done all the work.

                            This is why I’ve always advocated that people file issues discussing larger changes before doing the work of the change itself. There have been several occasions where folks will dump a >1,000 line diff without any prior discussion at all, only to have it rejected because I’m not interested in adding that feature. (Either because I think it’s a bad fit or because I think it will compromise my ability to maintain the project.) Most folks take that kind of response in stride, but still, it sucks to see people put in so much work without ever getting any kind of idea about whether it would be accepted or not.

                            1. 7

                              Responding to issues and PRs is not hard. I’m not the best at it, but I still manage. If you don’t want people to do that, then why are you making it open-source? Why not just offer downloads on your own site?

                              Actually, it is hard, sometimes.

                              People who ask very basic questions can be quite time-consuming to deal with, and don’t always feel like doing so. And people who open PRs that are just not very good aren’t fun to deal with either. Sometimes I don’t want to merge something just because I don’t like it; I don’t really want to write an in-depth explainer on why; it’s both time-consuming and emotionally draining.

                              Oh, and the last time I rejected an issue without writing an entire explainer on why, this person went on Lobsters to tell everyone what a horrible person I am and that I can’t be trusted.

                              I don’t want to cut off all avenues to contact me; GitHub just has a nice UI for things and a lot would be lost by just offering a download. It’s like a letter box or email address: just because you have one, doesn’t mean you need to respond to everything that comes in. If an author publishes a book with “send corrections to […]” doesn’t mean they have to respond to everything that comes in. Some will be thoughtful and worthwhile, other things … not so much.

                              Now, I actually do respond to most issues, PRs, and emails I get, but I strongly reject that I have a responsibility to do so merely because I offered people an opportunity to contact me.

                              A hobby project doesn’t tend to have the same issues as a large-scale project depended on by thousands.

                              When I maintained vim-go it was used by much more than “thousands” of people; I wouldn’t be surprised if the number of users touched 100,000. But at its “height” it never had more than two active maintainers (me and Billy; Fatih already stepped down by that time). Yet, it’s still just a hobby thing we all worked on in our spare time. And not infrequently people felt they had the right to tell us how things “should” be done, or that we really needed to work on X “because it’s important”.

                            2. 1

                              I’m not sure what’s bugging you about this.

                              So if I create a tool in my spare time for my own reasons, put it on the internet, and enough people like it and start using it, then I’m automatically “responsible” and “have a duty” to respond to everything that comes my way?

                              Legally, no. However, they’ve begun to appreciate your work. Pay it forward.

                              It’s my spare time and hobby, and I don’t owe you or anyone else one microsecond of it.

                              I’ve begun to put a notice on the readme if it’s a side-project.

                              1. 7

                                Legally, no. However, they’ve begun to appreciate your work. Pay it forward.

                                So because someone appreciates my work I need to listen to them? I find that a very curious reasoning.

                                1. 2

                                  I think it’s a good idea to set expectations explicitly. That reasoning is indeed curious, but it’s not uncommon. Moreover, just a little over a decade ago that reasoning would be correct most of the time.

                                  Well, it would never be correct to think that the author owes you anything, but it was much more likely that is a project is public and has some kind of a development infrastructure, the author wants it to be widely adoped and is ready to work in that direction. Even first generation code hosting services (SourceForge, Tigris etc.) didn’t allow creating a project in one click like modern ones do.

                                  Now that it’s easy to make a project available online, you indeed cannot expect anything. But, people need to know what the author’s intent is. For my project, I try to say it explicitly if I don’t care about other people’s needs, so that people don’t assume it’s more of a “serious” project than it really is.

                            3. 2

                              I agree. I dislike open-source projects which are effectively open-code & closed-source.

                              For example, VS Code (and I’m not trying to bash them) states on their wiki that they close issues which “the team” can’t “afford to implement”.

                              Open-source programming isn’t about teams. It’s about giving every developers in the world the chance to contribute to your project. Your can have core contributors or lead maintainers. You can have a team, as long as you don’t limit it to the team.

                              1. 15

                                Open-source programming isn’t about teams. It’s about giving every developers in the world the chance to contribute to your project.

                                I respectfully and politely disagree (with the second sentence). Open source means freedom to redistribute and clear attribution/derivation, but there is no obligation or expectation to accept contributions. If owners decline to accept contributions, it’s up to them.

                                I’m not dissing anyone who cares about community, or saying it’s “good” or “bad” if someone does or does not accept contributions. If there is a community around something and the author isn’t into it, it’s ok to fork (for that or any other reason really).

                                1. 4

                                  People nowadays are very confused about open source. I’m not blaming you, but you don’t understand what open source is. It’s a term with a very specific, well-defined meaning. You can see it here: https://opensource.org/osd

                                  Now, you might argue that I’m being prescriptivist, and words take on new meanings based on common vernacular. And normally, I’d agree with you; I’m mostly not a prescriptivist. But when it comes to open source, people twist its meaning to, effectively, ‘You need to make yourself available to do free work for me’. Free work including:

                                  • Respond to my issues
                                  • Respond to my PRs
                                  • Explain why you did not merge my PR
                                  • Explain the roadmap and future direction of the project
                                  • Etc.

                                  And that is what I take issue with.

                                  1. 6

                                    It’s about giving every developers in the world the chance to contribute to your project.

                                    No, open source is about appropriating the good vibes generated by the free software movement to subsidize corporate software development.

                                2. 2

                                  You should have no expectations that the maintainer will use your patch as-is. If they are taking maintainership seriously, they will do any adjustments they find necessary to integrate your patch into the project’s coding style and conventions.

                                  I will confess I have sometimes submitted “Cunningham’s Law” patches, which solve my issue in an obviously ugly and hacky way, It gets my issue taken care of faster than just a bare bug report, and I don’t have to learn all the conventions and interactions of the project.

                                  1. 1

                                    Interesting responses in this thread, and it has inspired me to make sure I have a CONTRIBUTING file for terminator.

                                    Personally, I inherited the terminator code so I don’t feel the same kind of possessiveness around the codebase as others here seem to have. If you want to add functionality to terminator and I agree that it would be useful and I don’t see anything terribly wrong with the code, I’ll just pull it in. There are some PRs sitting in the queue because I have concerns, but I’m not willing to shut it down yet. Most PRs are merged in with very little red tape.

                                    My feeling is, that if you feel a feature is necessary, enough to actually write code to implement it, you’re probably not the only one who would find that feature useful.

                                    As for the OP, I agree that it was kinda shitty to basically copy your patch and apply their version.