While Googling for more projects like this, I came across Litestream, which was initially closed to contribution and eventually opened for bug-fixes only.
Ben Johnson is the specialist of “here is my code, now leave me alone”. And to be honest, I find this refreshing. Another example, in a different category, is bolt, the state is basically “well I consider the project done, and mostly bugless, so I’m now freezing the code, if you want bug fixes, fork it.” I respect that…
I think it’s very common to not want drive-by PRs. It’s more than reasonable to say “don’t send patches without talking to me first”. And I think there are a fair few projects (especially solo ones) that can additionally say “when it comes down to it, even if I like your idea I would probably rather write it myself than accept a patch.” I know one maintainer like that — he’ll take PRs, especially for bug fixes, but they basically never get applied unmodified unless they’re absolutely trivial. Some people are bothered by that because it messes with their GitHub contribution stats, but the majority are more interested in landing a fix upstream so they can get on with their lives than they are in those kind of games.
This is what burned me out last time. Bug fixes are usually fairly trivial, so PRs are okay. Features, however, require so much more domain knowledge (especially around design) that every PR required multiple back-and-forths (or heavy modification from myself before merging).
I think it will help this time to have more restrictive contributing guidelines that I can point to when managing this stuff.
Calling PRs “drive-by” is like calling sending an email a “drive-by” email. There is nothing more abrupt with a PR than other types of communication. People can put effort into words they say or other text they write too.
As far as I’ve seen, “drive-by contributions” is used to mean contributions from contributors who don’t intend to maintain what they contributed or otherwise stay around as contributors, not contributions sent without much effort put into communication.
FWIW, when I’m doing drive-by PRs, always for trivial bugs and fixes, my thinking is I’m doing the maintainer a favour by giving them something they can merge with one click /if they think it’s OK/. I’m generally out of date and have low confidence in my abilities so I’m more than happy for them to junk the PR and fix the bug their own way!
Perhaps we need to rename Pull Requests to Pull Proposals?
Ehhh, a request is more like, “hey could you please do this, it’d really help me out”, a proposal is more like, “here’s an idea/suggestion that I think could help you, do what you will with it”.
It’s not that PRs as a medium can’t support meaningful communication. It’s that choosing them as a medium means opening the conversation with code. And that is abrupt.
There is simply a lot of perceived standard MO when sending a PR. I’d wager 3/4 of projects are simply “open to contributions” and people expect that, then are surprised when it’s not like that.
Asking beforehand is also not always easy. Some want to do that in a project channel or discord, some would appreciate a GH issue with “hey I have this idea, should I work on it?”.
This just made me think about one more way that “patches welcome” knee-jerk response to criticism is toxic. On the surface, it’s usually just dismissive about the issue brought up (have a problem? Send a patch, but make sure it’s up to our standards and expectations (some of the expectations are unwritten. If you don’t have the skill to come up with a good patch, it’s not even worth discussing). (I understand it’s often needed to shut down sealions or even distinguish them from people who genuinely want to bring up issues with the goal of improving the project for everybody / highlighting use cases that the maintainers haven’t considered, etc. “Code or STFU” is not a constructive approach).
The pervasiveness of “patch or STFU” kind of response creates an expectation that a PR is the generally accepted way of starting a discussion, whether it’s a one-liner bug fix, or an entirely new feature. Which leads to burnout on both sides: external contributor feels they have to come up with an implementation of feature without any support other than reading the source code and without any guidance from maintainers (or even confirmation that such a feature would be wanted in the project), just to be able to suggest the new feature. And then, the discussion is less about the feature that somebody needs and how to design it into the existing feature set an architecture, and whether it even works with the architecture of the project and its planned direction – the discussion is about how this specific implementation is broken, and when the feature is not trivial I’d expect it needs a full rewrite more often than not. This process generates a huge amount of throwaway work (creating the PR, reviewing it, phrasing / handling the rejection, etc).
If we could move from “patches welcome” / “contributions welcome” more towards “contributors welcome” (people, not artifacts), and the process would reflect that – I can imagine that it would be a more pleasant process for all involved:
“I feel the need of $FEATURE and would like to try implementing it. My rough idea is to add an entry point in this and that place, and make these places call a new module I’d add over there. Does that make sense? Is there anything I’m missing?” (No code yet. Maybe some pseudo-code, pointing at places to be changed)
“Mostly fine, you’ll also need to let user configure it, so there’s config file format and preferences UI. Make sure that the class you add in the new module implements interface Whatever, that way we can also expose it to the plugins. FYI, here’s a kinda similar change, and there are the general architecture guidelines”
Or: “We’ve already started work on that other feature which will support your use case” (or “which is important to us but will prevent whatever you need, sorry”)
Feels like this approach is less work and frustration for both sides. And this is where I can see the value of the old projects (FreeBSD, even the Linux kernel) sticking to the mailing lists, Bugzillas and sending patches. My few contributions to FreeBSD (mostly ports, but there was one kernel patch as well) were more like this: start a conversation in Bugzilla – with or without initial patch attached, the starting point is a question/report and a conversation, not a Request to Include My Changes. That was way more comfortable than throwing a PR at a GitHub project and having it ignored or rejected (without that initial discussion it probably wasn’t very good) or drowned in hundreds of other PRs the maintainers need to review; or giving up because of the expectation I’d first have to come up with the implementation on my own to even be worth a conversation.
I think you read a lot of hostility and runaround that just doesn’t exist on any reasonable project. I described the situation where a project is happy for your feature suggestion but isn’t really interested in your code. Well, it happens at least as often that the only possible response to a feature suggestion is “that sounds like a perfectly good idea, but we don’t have anyone who’s itching to work on it, and there are 100 more important things on the backlog. If you want to make it happen yourself, let’s talk. Otherwise, don’t hold your breath.” The abbreviated form of that statement is “patches welcome”, and on a decent project it encompasses all of your “how it should work” options. It’s not reasonable to think that it actually means “send a multi-kLOC patch adding a new feature without discussing approaches first”, of course that’s going to bomb!
I think patches are always helpful; the problem is if the submitter gets indignant when their patch isn’t accepted, or if the recipient feels bad when the submitter gets indignant.
How does the GitHub incentive structure work anyway? Are there stats based on how many lines of code are merged without modification? Then is there a different number that goes up for “landing a fix upstream” even if your code is rewritten?
From my experience, the problem arises when contributors think they can add anything they want to the codebase for their purpose. So, not accepting a PR means they can’t have the feature they wanted.
This time around, with Yaak, I’m focusing heavily on a plugin system to ensure these contributors can still build the functionality they want, without it having to be in the core codebase.
I have mixed feelings about this. On one hand, yes, it can be helpful to solve an immediate problem, and I do think we should be making it easier to include local patches. (Guix does this well, it makes it very straightforward to slightly modify one of the packages you’re installing.)
On the other hand, you can end up in a situation like we’ve had with Linux on ARM for a while where every vendor has their own kernel forks with varying degrees of support long-term.
So broadly I think I agree, but only up to a point (that has been reached before).
The problem with the linux on arm forks isn’t that they are not upstream, but that they are often not open source at all. Otherwise if necessary when one falls out of support someone who needs it could take it and continue to maintain it, etc.
The problem with forking is that forking the code is easy, forking the community/domain names/docs/etc is really hard.
If you just want to maintain a personal fork, that’s fine, but if you want to share your idea widely with other users, it’s very difficult without landing it in upstream.
There are various ways in which you can see your contributions quantified. One is the per-project contributors graph/listing (example), where authors are listed and sorted by total commit number, with line stats alongside. This probably counts commits/lines ‘authored’, as opposed to just committed, such that if someone rebases your commits, you’ll still get counted (although the UI will show “[you] authored and [they] committed” in the commit listing). If a line is modified before it’s merged, I assume it’ll still count as long as your commit wasn’t squashed away entirely.
Your own user page also shows the contribution graph (example, scroll down to “XYZ contributions in the last year”), which counts a variety of signals, commits landed in the main branch being a big one.
Some users also put graphics on their user profile which sum up a whole bunch of different stats (generated by third party things), but I’m guessing they’re mostly teenagers or very new to programming/open source and are trying to feel relevant!
There’s a number that goes up if a commit you authored is merged.
If you submit a PR, then maybe go through some rounds of review, and then the maintainer clicks the big green merge button, the commits that are merged are yours and the number goes up.
Otherwise, whether or not you get credit depends on whether the author’s method of surgery preserves authorship. If they rewrite it from scratch, it won’t (unless they go out of their way to attribute the new commit to you). If they use rebase it usually will.
I’ve seen some (hot?) takes recently that software where you’re not allowed to contribute is not “free” or “open”. I can’t blame the author for having fallen for that side of the narrative at first since it seems to be so prevalent, but I’m really glad they changed their mind and for this change.
I’ve also been burnt out by the social-networkization promoted by MS Github and everything it entails. I’m glad there’s more people that see it that way ^^
Open source is not open contribution, you’re always free (heck, encouraged!) to use, study and fork the source code! That’s the point. And I understand some people value the idea of community projects everyone can contribute to, but I’ve also seen way too many “community projects” being drawn on their own bureaucracy. It’s not always better.
I’ve seen some (hot?) takes recently that software where you’re not allowed to contribute is not “free” or “open”.
I’d say there are certainly cases where that take is valid - notably AOSP, where code is just thrown over the wall once a year. Major free versions of Android like LineageOS and GrapheneOS are basically forks that periodically get rebased on a new upstream release. But the upstream maintains complete control over the direction of the project, even/especially when it’s harmful to users. I’d rather this be the case than for Android to be completely closed, but it’s not great.
i was also thinking, for better or worse, one surefire way of getting peace while writing code is hosting it on your own sourceforge… nobody wants to deal w/ signing up onto someone’s self hosted GitLab or Gitea/Forgejo instance
I’ve already used the fact that this is open-source software to take a look at the code and see how the GUI component was implemented - which is useful to me for my own learning, even though I’m not currently in the market for an HTTP API developer client.
it looks like you’re using Tauri, which is a project I’ve been following with interest, although I think it’s still too immature for my use case (I mostly care about mobile, which I know is less mature than desktop use cases). I’m curious how you feel about it having built a real project with it, and in particular what sorts of performance or text-input usability issues you’ve run into, if any.
I haven’t even been able to get the Tauri example project to run on mobile so I think it’s still a ways away.
As far as issues, it’s just using the OS webview component, so it should be as accessible as any website in the default browser. I haven’t had any issues related to that, yet.
The main issues come from Tauri’s immaturity, mostly around niche bugs on Linux (eg. crashes with Nvidia cards) or simply missing features (auto-updater fails when using sandboxed macOS app).
What I like the most about open-source software is how diverse it is. There are plenty of free software projects out there, as well as projects whose contributions are only open in certain ways, and then of course projects who are not really accepting outside contributions but still make their source available so that people can understand their software better. It doesn’t really matter how hardcore you want to be, the open-source community is accepting of all kinds.
One thing that makes this a bit difficult to understand is how GitHub works fundamentally. GitHub doesn’t seem to allow you to not accept pull requests, but you can include a CONTRIBUTING.md document that lays out the requirements for making PRs, and/or set up bots to immediately close PRs that aren’t going to be accepted anyway. I do kinda wish they made it possible to disable PR contribution and simply make your source available, though.
I missed the original article but I’m very happy to see this. It’s interesting, most projects never get any contributions and sometimes people worry about that. It never occurred to me to fear too many contributions! But just not taking them is a good solution to prevent that unlikely problem.
i think it’s a completely fair misinterpretation of open source, actively maintained by some of the open source community
you can release source however you want. but there are people who go around shitting on projects for having a CLA, or using an insufficiently free license, etc. that might give people the wrong idea
I think this is great. Also I suggest looking into various licenses. MIT is a really good default. For a company that might be worried about freeloaders, making it GPL would at least force any competitors which clone your code to also open source any modifications they make to it.
So they could still do it, it’s just that any competitive advantage they might add via feature differentiation they would lose back to you (or anyone else).
I’m not a copy-left license die-hard, but I think it’s possibly a better fit for your intentions than MIT. If this is too much license nerdery for you right now I wouldn’t sweat it, maybe make a mental note to revisit it in a few months. Either way, congrats. I’m a fan of more open code in the world.
Ayyy, hopefully it works out well for you! And congrats on being able to admit you changed your mind, that’s never easy.
Thinks, I appreciate it. It definitely took a while to admit it, but I knew right when I saw the comments that my thinking was off.
Ben Johnson is the specialist of “here is my code, now leave me alone”. And to be honest, I find this refreshing. Another example, in a different category, is bolt, the state is basically “well I consider the project done, and mostly bugless, so I’m now freezing the code, if you want bug fixes, fork it.” I respect that…
lol I need to get shirts made that say this.
sqlite is another big one
I didn’t know they made Bolt as well. That’s awesome.
Previously, on Lobste.rs: Why Yaak is not open source (41 score, 43 comments)
Thanks for linking! I mentioned in the post, but thanks to the folks here for the great feedback on there.
I’m not familiar with Yaak, however I appreciate the author was able to step back and reconsider their perceptions of open source.
The bazaar model has become the norm I guess many people don’t even realise the cathedral is an option.
I think it’s very common to not want drive-by PRs. It’s more than reasonable to say “don’t send patches without talking to me first”. And I think there are a fair few projects (especially solo ones) that can additionally say “when it comes down to it, even if I like your idea I would probably rather write it myself than accept a patch.” I know one maintainer like that — he’ll take PRs, especially for bug fixes, but they basically never get applied unmodified unless they’re absolutely trivial. Some people are bothered by that because it messes with their GitHub contribution stats, but the majority are more interested in landing a fix upstream so they can get on with their lives than they are in those kind of games.
This is what burned me out last time. Bug fixes are usually fairly trivial, so PRs are okay. Features, however, require so much more domain knowledge (especially around design) that every PR required multiple back-and-forths (or heavy modification from myself before merging).
I think it will help this time to have more restrictive contributing guidelines that I can point to when managing this stuff.
Calling PRs “drive-by” is like calling sending an email a “drive-by” email. There is nothing more abrupt with a PR than other types of communication. People can put effort into words they say or other text they write too.
As far as I’ve seen, “drive-by contributions” is used to mean contributions from contributors who don’t intend to maintain what they contributed or otherwise stay around as contributors, not contributions sent without much effort put into communication.
FWIW, when I’m doing drive-by PRs, always for trivial bugs and fixes, my thinking is I’m doing the maintainer a favour by giving them something they can merge with one click /if they think it’s OK/. I’m generally out of date and have low confidence in my abilities so I’m more than happy for them to junk the PR and fix the bug their own way!
Perhaps we need to rename Pull Requests to Pull Proposals?
…what do you think request means?
Ehhh, a request is more like, “hey could you please do this, it’d really help me out”, a proposal is more like, “here’s an idea/suggestion that I think could help you, do what you will with it”.
a pull request without the request is just a patch.
So instead of a small pull request, there should be a small pull proposal? Imagine the abbreviations.
It’s not that PRs as a medium can’t support meaningful communication. It’s that choosing them as a medium means opening the conversation with code. And that is abrupt.
There is simply a lot of perceived standard MO when sending a PR. I’d wager 3/4 of projects are simply “open to contributions” and people expect that, then are surprised when it’s not like that.
Asking beforehand is also not always easy. Some want to do that in a project channel or discord, some would appreciate a GH issue with “hey I have this idea, should I work on it?”.
This just made me think about one more way that “patches welcome” knee-jerk response to criticism is toxic. On the surface, it’s usually just dismissive about the issue brought up (have a problem? Send a patch, but make sure it’s up to our standards and expectations (some of the expectations are unwritten. If you don’t have the skill to come up with a good patch, it’s not even worth discussing). (I understand it’s often needed to shut down sealions or even distinguish them from people who genuinely want to bring up issues with the goal of improving the project for everybody / highlighting use cases that the maintainers haven’t considered, etc. “Code or STFU” is not a constructive approach).
The pervasiveness of “patch or STFU” kind of response creates an expectation that a PR is the generally accepted way of starting a discussion, whether it’s a one-liner bug fix, or an entirely new feature. Which leads to burnout on both sides: external contributor feels they have to come up with an implementation of feature without any support other than reading the source code and without any guidance from maintainers (or even confirmation that such a feature would be wanted in the project), just to be able to suggest the new feature. And then, the discussion is less about the feature that somebody needs and how to design it into the existing feature set an architecture, and whether it even works with the architecture of the project and its planned direction – the discussion is about how this specific implementation is broken, and when the feature is not trivial I’d expect it needs a full rewrite more often than not. This process generates a huge amount of throwaway work (creating the PR, reviewing it, phrasing / handling the rejection, etc).
If we could move from “patches welcome” / “contributions welcome” more towards “contributors welcome” (people, not artifacts), and the process would reflect that – I can imagine that it would be a more pleasant process for all involved:
Feels like this approach is less work and frustration for both sides. And this is where I can see the value of the old projects (FreeBSD, even the Linux kernel) sticking to the mailing lists, Bugzillas and sending patches. My few contributions to FreeBSD (mostly ports, but there was one kernel patch as well) were more like this: start a conversation in Bugzilla – with or without initial patch attached, the starting point is a question/report and a conversation, not a Request to Include My Changes. That was way more comfortable than throwing a PR at a GitHub project and having it ignored or rejected (without that initial discussion it probably wasn’t very good) or drowned in hundreds of other PRs the maintainers need to review; or giving up because of the expectation I’d first have to come up with the implementation on my own to even be worth a conversation.
I think you read a lot of hostility and runaround that just doesn’t exist on any reasonable project. I described the situation where a project is happy for your feature suggestion but isn’t really interested in your code. Well, it happens at least as often that the only possible response to a feature suggestion is “that sounds like a perfectly good idea, but we don’t have anyone who’s itching to work on it, and there are 100 more important things on the backlog. If you want to make it happen yourself, let’s talk. Otherwise, don’t hold your breath.” The abbreviated form of that statement is “patches welcome”, and on a decent project it encompasses all of your “how it should work” options. It’s not reasonable to think that it actually means “send a multi-kLOC patch adding a new feature without discussing approaches first”, of course that’s going to bomb!
PRs are typically public, so everyone gets to judge you on how you deal with them.
I think patches are always helpful; the problem is if the submitter gets indignant when their patch isn’t accepted, or if the recipient feels bad when the submitter gets indignant.
How does the GitHub incentive structure work anyway? Are there stats based on how many lines of code are merged without modification? Then is there a different number that goes up for “landing a fix upstream” even if your code is rewritten?
From my experience, the problem arises when contributors think they can add anything they want to the codebase for their purpose. So, not accepting a PR means they can’t have the feature they wanted.
This time around, with Yaak, I’m focusing heavily on a plugin system to ensure these contributors can still build the functionality they want, without it having to be in the core codebase.
The fact that that expectation even exists explains so much about the code quality of the average “community developed” GitHub project.
We really need to normalize forking. So many people think they need to “land in upstream” to use something
I have mixed feelings about this. On one hand, yes, it can be helpful to solve an immediate problem, and I do think we should be making it easier to include local patches. (Guix does this well, it makes it very straightforward to slightly modify one of the packages you’re installing.)
On the other hand, you can end up in a situation like we’ve had with Linux on ARM for a while where every vendor has their own kernel forks with varying degrees of support long-term.
So broadly I think I agree, but only up to a point (that has been reached before).
The problem with the linux on arm forks isn’t that they are not upstream, but that they are often not open source at all. Otherwise if necessary when one falls out of support someone who needs it could take it and continue to maintain it, etc.
From a maintainer perspective, every new uboot and linux kernel needed for each new board makes doing board support way harder than it needs to be.
Want your thing to be easy? Make finding the software really easy.
The problem with forking is that forking the code is easy, forking the community/domain names/docs/etc is really hard.
If you just want to maintain a personal fork, that’s fine, but if you want to share your idea widely with other users, it’s very difficult without landing it in upstream.
There are various ways in which you can see your contributions quantified. One is the per-project contributors graph/listing (example), where authors are listed and sorted by total commit number, with line stats alongside. This probably counts commits/lines ‘authored’, as opposed to just committed, such that if someone rebases your commits, you’ll still get counted (although the UI will show “[you] authored and [they] committed” in the commit listing). If a line is modified before it’s merged, I assume it’ll still count as long as your commit wasn’t squashed away entirely.
Your own user page also shows the contribution graph (example, scroll down to “XYZ contributions in the last year”), which counts a variety of signals, commits landed in the main branch being a big one.
Some users also put graphics on their user profile which sum up a whole bunch of different stats (generated by third party things), but I’m guessing they’re mostly teenagers or very new to programming/open source and are trying to feel relevant!
interesting; thanks for the run-down
There’s a number that goes up if a commit you authored is merged.
If you submit a PR, then maybe go through some rounds of review, and then the maintainer clicks the big green merge button, the commits that are merged are yours and the number goes up.
Otherwise, whether or not you get credit depends on whether the author’s method of surgery preserves authorship. If they rewrite it from scratch, it won’t (unless they go out of their way to attribute the new commit to you). If they use rebase it usually will.
I’ve seen some (hot?) takes recently that software where you’re not allowed to contribute is not “free” or “open”. I can’t blame the author for having fallen for that side of the narrative at first since it seems to be so prevalent, but I’m really glad they changed their mind and for this change.
I’ve also been burnt out by the social-networkization promoted by MS Github and everything it entails. I’m glad there’s more people that see it that way ^^
Open source is not open contribution, you’re always free (heck, encouraged!) to use, study and fork the source code! That’s the point. And I understand some people value the idea of community projects everyone can contribute to, but I’ve also seen way too many “community projects” being drawn on their own bureaucracy. It’s not always better.
Too many cooks will spoil the broth.
I’d say there are certainly cases where that take is valid - notably AOSP, where code is just thrown over the wall once a year. Major free versions of Android like LineageOS and GrapheneOS are basically forks that periodically get rebased on a new upstream release. But the upstream maintains complete control over the direction of the project, even/especially when it’s harmful to users. I’d rather this be the case than for Android to be completely closed, but it’s not great.
[Comment removed by author]
There’s something to be said for asking contributors to send a patch series to the mailing list, he he.
i was also thinking, for better or worse, one surefire way of getting peace while writing code is hosting it on your own sourceforge… nobody wants to deal w/ signing up onto someone’s self hosted GitLab or Gitea/Forgejo instance
but then people still send patches via email. a more protective option is to keep the repo private and only publish releases as tarballs.
I’ve already used the fact that this is open-source software to take a look at the code and see how the GUI component was implemented - which is useful to me for my own learning, even though I’m not currently in the market for an HTTP API developer client.
it looks like you’re using Tauri, which is a project I’ve been following with interest, although I think it’s still too immature for my use case (I mostly care about mobile, which I know is less mature than desktop use cases). I’m curious how you feel about it having built a real project with it, and in particular what sorts of performance or text-input usability issues you’ve run into, if any.
I haven’t even been able to get the Tauri example project to run on mobile so I think it’s still a ways away.
As far as issues, it’s just using the OS webview component, so it should be as accessible as any website in the default browser. I haven’t had any issues related to that, yet.
The main issues come from Tauri’s immaturity, mostly around niche bugs on Linux (eg. crashes with Nvidia cards) or simply missing features (auto-updater fails when using sandboxed macOS app).
What I like the most about open-source software is how diverse it is. There are plenty of free software projects out there, as well as projects whose contributions are only open in certain ways, and then of course projects who are not really accepting outside contributions but still make their source available so that people can understand their software better. It doesn’t really matter how hardcore you want to be, the open-source community is accepting of all kinds.
One thing that makes this a bit difficult to understand is how GitHub works fundamentally. GitHub doesn’t seem to allow you to not accept pull requests, but you can include a
CONTRIBUTING.mddocument that lays out the requirements for making PRs, and/or set up bots to immediately close PRs that aren’t going to be accepted anyway. I do kinda wish they made it possible to disable PR contribution and simply make your source available, though.I missed the original article but I’m very happy to see this. It’s interesting, most projects never get any contributions and sometimes people worry about that. It never occurred to me to fear too many contributions! But just not taking them is a good solution to prevent that unlikely problem.
i think it’s a completely fair misinterpretation of open source, actively maintained by some of the open source community
you can release source however you want. but there are people who go around shitting on projects for having a CLA, or using an insufficiently free license, etc. that might give people the wrong idea
I think this is great. Also I suggest looking into various licenses. MIT is a really good default. For a company that might be worried about freeloaders, making it GPL would at least force any competitors which clone your code to also open source any modifications they make to it.
So they could still do it, it’s just that any competitive advantage they might add via feature differentiation they would lose back to you (or anyone else).
I’m not a copy-left license die-hard, but I think it’s possibly a better fit for your intentions than MIT. If this is too much license nerdery for you right now I wouldn’t sweat it, maybe make a mental note to revisit it in a few months. Either way, congrats. I’m a fan of more open code in the world.
Thanks for the comment! I’m not worried about freeloaders, though.