5 ms·

I wish there was a well-understood convention to opt out of "social coding". A way to put up a project under an open source license (or CC0/public-domain) alon

I wish there was a well-understood convention to opt out of "social coding". A way to put up a project under an open source license (or CC0/public-domain) along with a notice that says effectively, "feel free to fork, but don't file issues or submit patches." You can put that in a README, but people won't read it. Github won't let you disable i̶s̶s̶u̶e̶s̶ ̶l̶a̶s̶t̶ ̶I̶ ̶l̶o̶o̶k̶e̶d̶ pull requests, unless you archive the project (making it read-only). Is it possible on one of the other hosting services, like Gitlab? We need better ways to draw boundaries around open source projects and contributors. ETA: How can we counter the Bullshit Asymmetry Principle? https://en.wikipedia.org/wiki/Bullshit#Bullshit_asymmetry_principle https://en.wikipedia.org/wiki/Bullshit#Bullshit_asymmetry_pr... > The amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it.

ddevault 7y ago
You can do this on SourceHut, just make a git.sr.ht repo and don't make anything else (ticket tracking, mailing lists, etc, are opt-in). On GitHub you can disable issues but not pull requests.
- tejtm 7y ago
  I have never tried but perhaps someone could come up with a useless_machine[0] type of webhook[1] such that a pull request would do nothing but close itself [0] https://en.wikipedia.org/wiki/Useless_machine https://en.wikipedia.org/wiki/Useless_machine [1] https://developer.github.com/v3/activity/events/types/#pullrequestevent https://developer.github.com/v3/activity/events/types/#pullr...
deleted 7y ago
[deleted]
zamadatix 7y ago
GitHub let's you disable Issues but not PRs. Not sure since when.
deleted 7y ago
[deleted]
letstrynvm 7y ago
Assuming the author uses their own software, disabling the ability to hear about problems with it before you trip over it themselves is counterproductive. The minority of users would fix it and offer a PR in my experience, more would be willing to drop the author a note in an issue. Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.
Cthulhu_ 7y ago
There are some projects like that on GH but they're marked as abandoned or clones of e.g. Linux. I understand where you're coming from but whatever it is you've open sourced won't be very popular, because open source software is less about technical excellence and more about popularity, market- and mindshare. I mean I'm trying to pick an alternative to Ant Design (because Chinese) and there's a billion of them, but I'm having trouble deciding which one is the best option - Bootstrap, because most stars? Material UI because it shows up high in search results? And there's at least dozens more that will be objectively better (on a technical level) which I'll probably never see, and which I'll probably never use (because low popularity means low engagement and no guarantees that it'll still be around and maintained a few years down the line).
- doteka 7y ago
  re: Ant - If you’re using React and don’t need more than barebones mobile support, I’ve found Blueprint to be great.
dTal 7y ago
I'd be rather suspicious of pull requests from people too lazy to read the README, anyway.
beigeoak 7y ago
John Carmack had a similar issue. He solved it by calling the software "sample code" instead of "open source".
twic 7y ago
echo "Don't" >CONTRIBUTING git add CONTRIBUTING git ci -m "Clarify that contributions are not welcome" git push
imhoguy 7y ago
I would leave PRs available. Repo owner has no obligation to merge PRs however forks can still make use of upstream repo's PRs. That haplens usually when unmaintained repo accumulated a lot of popularity.
zozbot234 7y ago
This is what we call "unmaintained" software. 'Unmaintained' may sound like a value judgment, but it's not - it's exactly what you're talking about; a project where any attempt to contact the putative maintainer is likely to be ignored altogether, and the "proper" channel for enhancement involves forking it and perhaps maintaining a version yourself.
Chris2048 7y ago
A "license" covers the legal situation, maybe we need a "social statement" or something to that effect that communicates the authors philosophy?
Sean1708 7y ago
> Is it possible on one of the other hosting services, like Gitlab? Looks like you can on GitLab under "Settings" > "General" > "Visibility, project features, permissions".
- robotmay 7y ago
  (new) GitLab engineer here. This is correct, it can be set to allow merge requests from "Only Project Members", or disabled entirely. You can also disable pretty much everything else as well, if desired. Disclaimer: nobody submits contributions to my hobby projects anyway.
massysett 7y ago
Use the “No Maintenance Intended” badge: http://unmaintained.tech/ http://unmaintained.tech/
- roryokane 7y ago
  Exactly – put that badge or the similar “Repo Status: Unsupported” badge (https://www.repostatus.org/#unsupported https://www.repostatus.org/#unsupported) in your README to succinctly communicate what users should expect from the project.

ddevault 7y ago

You can do this on SourceHut, just make a git.sr.ht repo and don't make anything else (ticket tracking, mailing lists, etc, are opt-in). On GitHub you can disable issues but not pull requests.

tejtm 7y ago
I have never tried but perhaps someone could come up with a useless_machine[0] type of webhook[1] such that a pull request would do nothing but close itself [0] https://en.wikipedia.org/wiki/Useless_machine https://en.wikipedia.org/wiki/Useless_machine [1] https://developer.github.com/v3/activity/events/types/#pullrequestevent https://developer.github.com/v3/activity/events/types/#pullr...

deleted 7y ago

[deleted]

zamadatix 7y ago

GitHub let's you disable Issues but not PRs. Not sure since when.

deleted 7y ago

[deleted]

letstrynvm 7y ago

Assuming the author uses their own software, disabling the ability to hear about problems with it before you trip over it themselves is counterproductive. The minority of users would fix it and offer a PR in my experience, more would be willing to drop the author a note in an issue. Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.

Cthulhu_ 7y ago

There are some projects like that on GH but they're marked as abandoned or clones of e.g. Linux. I understand where you're coming from but whatever it is you've open sourced won't be very popular, because open source software is less about technical excellence and more about popularity, market- and mindshare. I mean I'm trying to pick an alternative to Ant Design (because Chinese) and there's a billion of them, but I'm having trouble deciding which one is the best option - Bootstrap, because most stars? Material UI because it shows up high in search results? And there's at least dozens more that will be objectively better (on a technical level) which I'll probably never see, and which I'll probably never use (because low popularity means low engagement and no guarantees that it'll still be around and maintained a few years down the line).

doteka 7y ago
re: Ant - If you’re using React and don’t need more than barebones mobile support, I’ve found Blueprint to be great.

dTal 7y ago

I'd be rather suspicious of pull requests from people too lazy to read the README, anyway.

beigeoak 7y ago

John Carmack had a similar issue. He solved it by calling the software "sample code" instead of "open source".

twic 7y ago

echo "Don't" >CONTRIBUTING git add CONTRIBUTING git ci -m "Clarify that contributions are not welcome" git push

imhoguy 7y ago

I would leave PRs available. Repo owner has no obligation to merge PRs however forks can still make use of upstream repo's PRs. That haplens usually when unmaintained repo accumulated a lot of popularity.

zozbot234 7y ago

This is what we call "unmaintained" software. 'Unmaintained' may sound like a value judgment, but it's not - it's exactly what you're talking about; a project where any attempt to contact the putative maintainer is likely to be ignored altogether, and the "proper" channel for enhancement involves forking it and perhaps maintaining a version yourself.

Chris2048 7y ago

A "license" covers the legal situation, maybe we need a "social statement" or something to that effect that communicates the authors philosophy?

Sean1708 7y ago

> Is it possible on one of the other hosting services, like Gitlab? Looks like you can on GitLab under "Settings" > "General" > "Visibility, project features, permissions".

robotmay 7y ago
(new) GitLab engineer here. This is correct, it can be set to allow merge requests from "Only Project Members", or disabled entirely. You can also disable pretty much everything else as well, if desired. Disclaimer: nobody submits contributions to my hobby projects anyway.

massysett 7y ago

Use the “No Maintenance Intended” badge: http://unmaintained.tech/ http://unmaintained.tech/

roryokane 7y ago
Exactly – put that badge or the similar “Repo Status: Unsupported” badge (https://www.repostatus.org/#unsupported https://www.repostatus.org/#unsupported) in your README to succinctly communicate what users should expect from the project.