23 ms·

Open-source, not open-contribution

661 points by farslan 6y ago

alexellisuk 6y ago
I think this is interesting. Burn-out is real - I remember when Ben stepped away from boltdb. I guess he's learned his lessons and isn't as interested in contributions being part of his vision for his SQLite sync tool. I'd be interested to see if this gets normalised beyond the SQLite community. One of the things I did recently and haven't regretted is turning off email notifications on GitHub.
- skohan 6y ago
  I think it's a perfectly fair option. I have projects which I have considered open-sourcing, but haven't because I don't want to deal with the public maintenance and community management aspects. I think there is sometimes too much pressure around what is the "right way" to do open source, that a project has to tick certain boxes to be a valid open-source project, and I think it's perfectly fine for an individual to want to tinker away at a pet project on their own, and share the results with others.
phendrenad2 6y ago
Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. https://github.com/isaacs/github/issues/1191 https://github.com/isaacs/github/issues/1191 3 years and counting. Some people are resorting to adding bots which auto-close PRs with a message like "Sorry, I'm not accepting PRs at this time", but that only triggers once the person has put in the effort to patch your project, at which poi t they may get annoyed to be suddenly told that PRs aren't welcome. Best solution is to keep code somewhere other than github. Is sourceforge still around?
- tecnocriollo 6y ago
  Gitlab is a nice option
  - skohan 6y ago
    I've transitioned to gitlab for new projects about a month ago, and so far the experience has been great.
  - Vinnl 6y ago
    It might be me, but I don't see an option to disable Merge Requests in GitLab?
    - dnsmichi 6y ago
      Hi, GitLab team member here. You can find it in the project settings in the "sharing and permissions" section: https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions https://docs.gitlab.com/ee/user/project/settings/#sharing-an... You can also disable the repository feature, and use the project for issue management only.
      - Vinnl 6y ago
        Heh, got it - I was looking under "Merge requests" :) Thanks both!
    - algo_cheese 6y ago
      In your project "Settings" -> "General" -> "Visibility, Project features, permissions" -> "Merge Requests". IIRC, you must be owner of the project.
  - SamWhited 6y ago
    With apologies to the GitLab team, our views of how to make good software vary drastically and yours may be more in line with other peoples, but not mine: Maybe Gitlab's gotten better recently, but it's probably the most annoying piece of software I've ever used (well, second to Confluence maybe). It does everything which might be appealing to some, but for me it just meant everything was confusing, inconsistently labeled and documented, and/or buried under 5 levels of menus or under buttons that made no sense. The way I explain it is you know how when your computer illiterate parents ask you to do some simple task that you have literally no idea how to do, but you look at some menus that have vaguely similar sounding titles based on your years of building up intuitions about how computer UIs work, click those menus, find what you need and do the task? GitLab breaks all those intuitions so easy tasks become hard. YMMV, of course. I've been using Sourceforge recently and am pretty happy with it overall, though it's still very alpha quality.
- Communitivity 6y ago
  If you are writing something to contribute it to a project, then you should discuss the idea with the current committers/maintainer on the project's mailing list, or discord, or however they communicate. If you don't, and you submit a PR, you should expect the PR to be closed with a "Unfortunately, this change was not discussed. As a result it may clash with other efforts underway, or our future roadmap. Also, not having discussed it prior to the PR increases the suspicion that you have not followed our coding guidelines. Consequently this PR is closed. Please propose the change on the mailing list and take part in the discussion before revising this patch and resubmitting the PR." Because of this I think an auto-close is fine. I also do think Github should allow disabling the PR tab.
  - gus_massa 6y ago
    I agree, but I'd make an exception for fixing typos, obvious bugs and tiny additional features. Sometimes the change takes less time that discussing in other channels, and sometimes it's easier to explain with code if you are not a native speaker. I think that spending more of a weekend in a PR without checking before with the maintainers is a bad idea, because there is a big risk that is not merged and is a waste of time. Also, each project has it's own weird rules, like code style, space vs tabs, changing whitespace in unrelated lines, adding tests, ... and a long list. Some are written explicitly, and some are just implicit rules. So sometimes it's difficult to make a PR that follows all the rules.
    - Communitivity 6y ago
      100% agreed. Things that are obvious to fix and have no design impact should be ok to PR and get accepted quickly. Every rule has exceptions, and this is definitely one for the rule I described. Thank you for pointing reminding me and clarifying.
    - phkahler 6y ago
      Yep. We had a PR for a single character typo. The submitter went to a lot of trouble, but the burden to the project really was as small as could be. No discussion, no open issue, just a PR with a one liner that could be reviewed in seconds and accepted with a click. Any other process would have been more work for the maintainers.
- pabs3 6y ago
  SourceForge is still around. I would suggest SourceHut over SourceForge these days though (not sure if SourceHut can turn off contributions).
  - ddevault 6y ago
    SourceHut has you opt-in to anything you want - bug trackers, mailing lists for patches, git or hg repos, etc. The source code repository isn't the singular source of truth for a project like it is on GitHub. You can have a project with a dozen bug trackers, two mailing lists, and five source code repositories, organized in whatever way makes sense for your project.
    - andrepd 6y ago
      The flexibility is cool, but why would you want to fragment your bug trackers, for example, like that?
      - JosephRedfern 6y ago
        I think this was just an example, really, but I know some projects have an external bug tracking tool to document customer-reported issues, and closed, employee only ones to discuss the issue internally.
      - callmeal 6y ago
        So you can have a separate one for "internal" and "external" customers perhaps?
      - ddevault 6y ago
        Sometimes it makes sense to have different bug trackers for each sub-product, but also one for support, and one for your infrastructure issues, and a locked-down one for security tickets, and maybe another for packaging issues - any of which may not have associated source repos. Whatver organizational model meets your project's needs best, you have the flexibility to apply it. And people often do! A lot of the projects on sr.ht, given this flexibility, haven't recreated the same model as GitHub shoehorns you into. It goes beyond bug trackers, too. One other detail is that different projects can share resources with one another. I use one mailing list to slurp up all patches for my smaller side projects into one place, for example.
- massysett 6y ago
  Yes, for just this reason I am beginning to remove my projects from Github. I have "given back" by posting my Haskell libraries to Hackage, where they may be used and inspected by all. I'm not going to "give back" by maintaining software to the specifications of others, free of charge. This level of "giving back" is not trivial: I have often benefitted from seeing the source code of other projects and deciding I don't want to use the library, or seeing the code and deciding to modify it or take a different approach - or seeing the library and realizing that I wanted to try something similar, but this library shows me why I shouldn't do it. Maybe others will similarly benefit from seeing my stuff. If they see my stuff and think it's deficient, wonderful! Alter it to make it fit your needs, or use it as an inspiration for your own fresh rewrite. But I'm not maintaining software for other people. God bless people who do; that's wonderful. But it's perfectly OK to just post stuff up in case someone else wants to use it. When people see the code on Github they think "oh I can make feature requests" or "I can send a PR." Fair enough - Github is "social coding" after all. So I just won't put code on Github.
  - cies 6y ago
    This is important. We need some vocabulary definitions for all different levels/aspects of "open". Open Access, or not. Open for contribution... or not. Commit ownership transferals, or not. In some cases there are whole steering committees.
    - mumblemumble 6y ago
      The vocabulary is already there. What is out of place is the perception of where the defaults lie. Right now we seem to assume that, unless someone takes the time to write out rules explicitly saying what they're not willing to do, then they must be willing to do it. It should be just the other way around. If a project wants contributions, for example, then they can communicate that by posting contribution guidelines in the README.
      - peteretep 6y ago
        > It should be just the other way around It should not be just the other way around
- chmaynard 6y ago
  Isn't that what archiving and mirroring are for? If you archive it or call it a mirror, GitHub users will understand that contributions to the repo are not accepted.
  - kodah 6y ago
    Kind of. Archiving means you can't commit to it either, from what I know. Mirroring doesn't necessarily mean that you can't contribute to it, it just means you can't contribute to it on GitHub.
  - sudhirj 6y ago
    No, archiving implies that no more code changes will be made. The author’s intention is not that that project is “finished”, it’s that they are the only ones going to make changes to it. Archiving will lock the authors out of making changes as well.
  - qhwudbebd 6y ago
    I think archiving stops anyone pushing to a repo at all, but an option to label a repo as a mirror (and thereby block pull requests on GitHub) would be perfect for me - it pretty much exactly describes the situation for my GitHub repos. Your post implies this option exists, but I can't find it in the interface - am I missing something obvious?
    - chmaynard 6y ago
      This GitHub article may be useful: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository https://docs.github.com/en/github/creating-cloning-and-archi... I'm not sure if a mirror repo actually blocks pull requests. Check with GitHub Support for more information: support@githubsupport.com
      - qhwudbebd 6y ago
        This article isn't about creating a repository with non-standard properties I'm afraid. It's just a set of instructions for copying one repository into another. The resulting repo isn't any different from any other Github repository and doesn't have any kind of 'mirror' status.
- bityard 6y ago
  I don't blame Github here, their WHOLE spiel is open collaboration for community software projects. If want to share your project online but don't want to engage with your users as peers, then GitHub was never the right place to post the repo anyway.
  - jabbany 6y ago
    Pretty sure the repo maintainer still wants to engage with users as peers (via bug reports and feature requests as they mention) just not through code contributions. In fact, if you only look at the "issues" framework, GitHub does a pretty good job of making things easy to use compared to the other bug trackers...
  - trinovantes 6y ago
    Doesn't make sense they'd allow you to disable Issues but not PRs if they only cared about engagement
  - SulfurHexaFluri 6y ago
    This is rubbish. Github is massively more useful than dumping the source on your own webserver even if you do not want PRs. It would be a fairly simple change to simply add a button and remove the PR tab.
- toyg 6y ago
  Github allowing you to disable PRs would be a bit like Facebook allowing you to opt out of ad-tracking...
  - johannes1234321 6y ago
    I don't get the analogy. Also mind: Even if pull requests are off somebody else might emerge and maintain a fork, which becomes more successful. Maybe even going as far that that the original owner can safely outsource the maintenance of the thing he created.
    - toyg 6y ago
      The whole business model of GitHub is to get you to use its proprietary social features, so that 1) you get locked-in, and 2) you generate and maintain adoption virality. The minute they become just another dumb git host, their relevance disappears.
      - sofixa 6y ago
        > 1) you get locked-in, How do you get locked in? PRs, once merged, are just regular commits. You lose the history and discussion around the PR itself, but that's all, but it's not like any alternative allows you to migrate ( e.g. the abomination that is using email for git collaboration is stuck in unreadable, unsearchable, unindexed emails somewhere; you can copy the data pretty much the same way as from GitHub, but both are unexploitable without a lot of tinkering / adaptation)
- enriquto 6y ago
  > Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. I'm not the one to defend GitHub, but what's the big deal about not accepting pull requests? If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything? Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut.
  - darkwater 6y ago
    > Am I missing anything? Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.
    - enriquto 6y ago
      > it's far less welcoming Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.
      - onion2k 6y ago
        only somebody with a ridiculously thin skin... People like that are very common and often very vocal.
      - DangitBobby 6y ago
        Depends on how much work they put in, doesn't it?
        tombot 6y ago
        Surely someone invested enough to submit a PR would have read the readme which explains they won’t accept a PR
- rectang 6y ago
  Is it possible to "archive" and then "unarchive" a Github repo using the Github API? If so, one possible solution is to maintain the primary repo elsewhere (Source Hut, Gitlab. wherever), and run a sync routine on a cron (or perhaps every push): 1. unarchive Github mirror repo 2. Push changes from primary repo to Github mirror 3. archive Github mirror repo There's a race condition where someone might see the unarchived repo and start a pull request during the brief period where the sync is taking place, but the possibility that they'd both start and then fisish a pull request during sync periods seems remote.
  - gregoriol 6y ago
    The problem with archive is that it looks like "not maintained anymore"/"deprecated", which is not the case here.
    - rectang 6y ago
      I agree, it's a hack. This hack competes with the "auto-close all pull requests" hack. Which hack you would choose depends on how important it is never to see pull requests (e.g. for IP reasons as described elsethread).
- fortran77 6y ago
  Amazon CodeCommit works great for me.
  - bcfalconer 6y ago
    Like all of AWS, the pricing seems opaque and without hard limits: https://aws.amazon.com/codecommit/pricing/ https://aws.amazon.com/codecommit/pricing/ "Our transaction and storage quotas are designed to handle the most common developer workflows without incurring overages. For most workflows where CodeCommit users are manually using Git operations, these quotas are rarely breached." "$0.001 per Git request" I need an option that is limited to $5 a month, with DDoS being their problem.
    - sofixa 6y ago
      > I need an option that is limited to $5 a month, with DDoS being their problem DDoS is always their problem. AWS and co always waive charges due to attacks or significant errors on user's part ( e.g. writing an infinite loop that results in a huge bill)
- macksd 6y ago
  I like the idea of reducing the stigma, but honestly if I haven't realized they don't accept PRs by the time I'm looking for the PR tab, I've already done all the same work, kinda for nothing. It ought to be made very clear in README.md or CONTRIBUTING.md or something too. I do wish people weren't completely closed to PRs though. I think companies are often misled when they think they'll get free labor out of open source, etc. and I think the free-as-in-libre aspect is more important relative to community aspect than a lot of people, but still - I hate it when my only option if I want a bug fixed is to wait for the company to do it themselves or fork. Even if I have to sign over all my rights of the code, I'd so much rather they at least consider taking my PR and be done with it. They don't have to do it for features they don't like or fixes that have downsides. But for a straightforward fix, at least look at it. It might be all the free help you ever get from the community.
  - massysett 6y ago
    You want other people to do work for you, for free. That's completely understandable.
    - phkahler 6y ago
      >> You want other people to do work for you, for free. That's completely understandable. The parent poster was talking about submitting a Pull Request. In other words, contributing the work for free. I suppose expecting someone to look at it might be asking them to do something for free, but if that's a problem then I agree that Github should have the option of not having the button on a project at all. Or maybe you thought PR stood for Problem Report, in which case expecting it to be looked into by someone is an expectation of free labor.
      - massysett 6y ago
        Examining the pull request is work, as is integrating it into the software and maintaining it in the future. The parent wants the project to do that so that s/he does not have to fork it him/herself. In other words, the parent wants someone else to do work, for free. Free Software is about the freedom of the user - freedom to distribute, freedom to study, freedom to use, freedom to modify. Somehow people have managed to pervert this so that it not only means "free as in free beer so that I can use it" but even "free beer so that OTHER PEOPLE can do work that I want done, for free." There is absolutely no entitlement to this.
- mathnmusic 6y ago
  Does this not serve the purpose? Repo -> Settings -> Moderation Settings -> Limit to repository collaborators
  - Footkerchief 6y ago
    "Disable pull requests while keeping issues"
  - dbrgn 6y ago
    This cannot be enabled permanently. Max duration is 6 months.
- _jal 6y ago
  Seems weird to me to blindly fire off a PR to a project I've never communicated with. I've always asked first, mainly because I don't want to waste my time if they won't give it any consideration. And also because maybe they're already working on whatever I was thinking of, or are doing it in a different way, or...
  - publicola1990 6y ago
    That ok, but there is also the thought that if you see a picture hanging in the wall is tilted, it is better to jt straighten it without waiting to ask permission. It is easier to ask for forgiveness than for permission.
  - mhitza 6y ago
    My contributions are fixes that I need now. So after I fix the issue for my usecase I fire off a PR upstream. As a maintainer you are free to close my PR, or work togheter with me to bring it in line with your project standards.
- Joeri 6y ago
  If the contributing.md says no PR’s are welcome and there is a pull request template which just says in big letters “PLEASE DON’T!” I doubt many people would get confused. https://docs.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository https://docs.github.com/en/github/building-a-strong-communit...
  - Arnavion 6y ago
    How does anyone even see the PR template? If you fork, push a branch with your fix to your fork, go to your fork in the browser and click the "Compare & Pull Request" button to make a PR from your branch [1], you don't see the template at all. The UI is auto-filled with the text from your commit message. I thought everyone filed PRs this way; is there another workflow I haven't heard of? [1]: It takes you to https://github.com/$upstream/$repo/compare/master...$you:$branch?expand=1 https://github.com/$upstream/$repo/compare/master...$you:$br...
- TheRealPomax 6y ago
  Also the "fork" option. If you want the source, pull the official source, but there are plenty of projects where people should not be creating their own copy that is on equal footing as the authoritative repo.
  - yawaramin 6y ago
    It's a widely-known practice for companies to internally fork and vendor software they use.
    - TheRealPomax 6y ago
      Sure? But that doesn't mean you can't give people the power to turn off that "one-click, no thinky thinky effort effort" option.
- kminehart 6y ago
  It's crazy to me that the open source world has completely standardized on a closed (and now Microsoft) product like GitHub. I'm sure someone would have implemented this feature for them by now if it was free software.
  - Jkvngt 6y ago
    To be fair, MS only bought GitHub after it became very popular.
- trynewideas 6y ago
  > Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. It's more of a workaround than a solution, and depends on how much you trust GitHub Actions, but this one will autoclose all issues and/or PRs. https://github.com/marketplace/actions/repo-lockdown https://github.com/marketplace/actions/repo-lockdown > Best solution is to keep code somewhere other than github. Is sourceforge still around? Aside from Sourceforge and self-hosting (simply via gitweb, or with GitHub-like features in Gitea, Phabricator), there are the big ones like GitLab and Bitbucket, cloud repo services on AWS and Azure, and smaller/indie services like Sourcehut (sr.ht), Launchpad, and RhodeCode.
- pizzazzaro 6y ago
  This is why our tools for Open Software need to be Open themselves. Have a problem being unable to disable PRs? A PR that fixes it would be embarassing for Github if it were simply Closed. How many such PRs for distinct code could we get submitted at once?
- whateveracct 6y ago
  I guess you can add a PR template that says "PLEASE DON'T SEND ME PRS"
- justaguy88 6y ago
  There is https://sr.ht/ https://sr.ht/
- hutzlibu 6y ago
  "Best solution is to keep code somewhere other than github. Is sourceforge still around? " How about just stating in README about your PR policy in big letters? And if then people get angry because they were too lazy to read, .. well you cannot and should not please everyone. Anyway, and what bothers me with GitHub is Microsoft, even though so far I cannot really complain. At least they have not sneakily bundled adware with OSS installers, like sourceforge did. So they really lost all reputation and trust for me and are never a alternative again. I rather go with microsoft and that says something.
- didibus 6y ago
  Ya Github just needs a way to disable everyone to create issues and/or PRs.
franciscop 6y ago
I've disabled Issues in some of my popular UI libraries and I couldn't be happier. Specially notorious was Picnic CSS[1] where many of the issues were on the level of "hey can you give me the code for X" or "how do you do X" where X was a general CSS question and not related to the library at all. I've also received unkind words when I closed some of my repos issues as a PR [2][3]: > If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM). > part of offering these to the public through open software is maintaining them and allowing feedback from users. > It seems umbrella.js project suffers the same desease. I've noticed there was a strong push around 2016-2018 to recommend newbie programmers NOT to go to Stackoverflow, but instead to ask the questions straight in the Github issues. Turns out, the problem was low quality questions all along, and that just converted an issue that StackOverflow had solved long ago into burnout for open source developers on Github. Github needs to step up their game and give authors more powerful tools, there's so many entitled developers out there that will come and demand changes. It might make new devs feel less welcome, but the balance is tipped way too much to allow anyone to create massive spam for projects right now. [1] https://picnicss.com/ https://picnicss.com/ [2] https://github.com/franciscop/picnic/pull/203/files https://github.com/franciscop/picnic/pull/203/files [3] https://github.com/franciscop/picnic/pull/202 https://github.com/franciscop/picnic/pull/202
- lol768 6y ago
  > Github needs to step up their game and give authors more powerful tools This is presumably what the discussions feature is meant to allow? A place to ask questions and discuss things rather than report bugs.
  - franciscop 6y ago
    That is great if you are e.g. Facebook and pour a lot of resources into the community. But there are multiple archetypes of open source developers, and for most others reducing the amount of noise is more important than adding more channels. For many tools that add friction, thus increasing the quality would be much better. Some random examples: - Requiring any Issue to have some mandatory fields (version number, output, etc) - Add some sort of "reputation" like StackOverflow for devs and require a minimum threshold - Limit issues to those who actively contribute on Open Source (PRs, own open source, etc) All of these would be opt-in by the maintainers of the project. Could also kill two birds with one stone by limiting Issues and/or Discussions to Sponsors only (and collaborators)
webmobdev 6y ago
> Writing databases & low-level replication tools involves nuance and simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them ... I've made the decision to keep this project closed to contributions for my own mental health and long term viability of the project. While I understand the burden of accepting and evaluating code from others and the very real possibility of a burn-out due to it, can't test-driven development (or even Behavior-driven development) reduce a lot of this burden? (Related: How SQLite is tested - https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html ).
- Aeolun 6y ago
  Yeah, just ignore any PR that doesn’t pass the tests. Also a good way to weed out the people that don’t care enough to fix it if they break something.
  - swiftcoder 6y ago
    You also have to reject any PR that modifies the tests. Otherwise the maintainer now has to validate test suite integrity any time they accept a PR.
    - hoseja 6y ago
      I don't understand the obsession with testing. You can't test for unknown unknowns, that is, non-obvious bugs. Sure it's nice "automated documentation" but I feel like the reverence it gets is overstated.
      - webmobdev 6y ago
        From what I understand - you don't test for all unknowns as that is humanly impossible. You test for realistic "known" only. This largely prevents regression bugs as new fixes or features are added. When a bug reveals itself and is fixed, it becomes a known case that you can decide to create a test for (if necessary) and prevent its recurrence in the future. Personally, I feel it improves the code quality and readability for others as the tests also help them better understand the functionality of the code within a project.
davidjgraph 6y ago
This was a problem for us and the lack of the ability to switch off PRs continues to cause problems. Community submissions are virtually always throw away, particularly on a complex code base. We ended up saying it's a legal problem [1], which it partly is. But throw away not only because of quality issues, always because of project scope issues. Yes, you feel the project is completely useless unless emoji icons animate in diagrams. That's great, fork the project and kill ours off by adding the feature (which they won't and it won't). When you know what the project scope is, tight enforcement of that scope is critical to prevent the complexity of the project from running away and ultimately killing the project entirely. https://github.com/jgraph/drawio https://github.com/jgraph/drawio
- j1elo 6y ago
  > When you know what the project scope is, tight enforcement of that scope is critical to prevent the complexity of the project from running away and ultimately killing the project entirely. Which is why I believe a "benevolent dictatorship" style of governance has more chances (nitpick prevention: more, not all the chances) to become successful and thrive. If you let too many community members decide on what is in and out of scope, the project ends up being a conglomerate of the most random favorite features from the most vocal participants.
  - distalx 6y ago
    And sometime these most vocal participants are all talk and no code.
- drej 6y ago
  > Note: We cannot accept non-trivial PRs for legal reasons. We need to retain copyright over the entire codebase. Does a CLA solve this? (Genuine question, I don't know.)
  - MayeulC 6y ago
    Yes, this is what a CLA solves. And I tend to refrain from contributing to projects that have a CLA, although it might not be reasonable: there's little difference with licensing your contribution under MIT, I think. However, if you license your project under AGPL, you probably deemed AGPL comfortable for your needs. I did too, so licensing my contribution under something else feels a bit uncomfortable, especially if it is substantial.
Aeolun 6y ago
While I respect this, it annoys me to no end when I can use a piece of software, see the code of a piece of software, fix a piece of software, but not contribute that fix back up. So I’m doomed to an eternity of either merging all upstream changes, or waiting for the maintainer to fix it on his own. I generally just pick something else, but it isn’t always immediately clear.
- franciscop 6y ago
  IF the maintainer(s) offer contracting and it bothers you so much, have you considered paying them 1-2 hours to have a look at the issue/solution? If you are putting food on my mouth AND potentially fixing an issue, that'd be normally much better. Any patch review is extra work for the maintainer, which they are in their right of not wanting to do it.
  - krzyk 6y ago
    But besides the review it is also free code. I don't get this sentiment of disallowing pull requests or issues. Just because one gets bunch of useless issues or PRs doesn't mean that he/she won't receive a valuable one. If you close those, you are basically closed-source with an option to peak at the code.
    - pessimizer 6y ago
      > If you close those, you are basically closed-source with an option to peak at the code. No, you are completely open source. FOSS doesn't have anything to do with the right to contribute upstream. It gives you rights over the code, not the servers that house the code.
    - jabbany 6y ago
      This is not the case and the maintainer outlines why. (1) FOSS means you (the "licensee") can do what you want with the code, not that I (the "licenser") am somehow obliged to take your input on it. If the maintainers find that code contributions are reducing their maintenance effort, which is often the case, then sure. But if on the other hand reviewing the contributions themselves _increases_ effort, then it literally is a net-negative to accept PRs. (2) It's also very possible that PRs create extra work. Sometimes reading and understanding someone else's solution to a problem is harder than coming up with your own! Of course, one could take a laissez faire approach to maintenance and just assume good intent and do light reviews, but that doesn't necessarily make for a better codebase.
pmlnr 6y ago
Unpopular question: if this is the case, why put it on github? There are countless web frontends[^1] to expose a git tree on the internet, without the community/social aspect of github. [^1]: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces https://git.wiki.kernel.org/index.php/Interfaces,_frontends,...
- jabbany 6y ago
  (1) Running your own web service costs money (hosting fees) and time (setup, patching security issues). Often quite significant amounts of both, making it unattractive for small FOSS projects. Github provides a free and managed service. (2) The maintainer _wants_ the community/social aspects like Issues and Discussions. They just don't want code contributions. Of course, one can run their own bug tracker and forum... but... see (1). (3) GitHub has been branding itself as more and more of a package manager too (and in many areas it has become the de-facto one). Placing things on Github v.s. self hosting can also be seen as an SEO/advertising move for an FOSS project.
  - pmlnr 6y ago
    On that list, there are projects like https://github.com/Hypercubed/git2html https://github.com/Hypercubed/git2html . It makes a set of static files, which could be uploaded to any static hosting provider, including github pages.
    - jabbany 6y ago
      This kind of stuff takes a nontrivial amount of time and effort to setup and _automate_. Plus at the end of the day you still need to host the repo itself somewhere (not just the web UI), which means you will need a hosted place you can write to via Git's push mechanisms... It's not impossible but finding free managed hosting for this seems nontrivial too.
- jgilias 6y ago
  I don't see why the question should be unpopular. It's valid. I think because having a project on github aids discoverability. Also, the project mentions that they would stop accepting pull requests, not that there would be no interaction with users whatsoever. Quite the contrary, it is stated that the author is thankful for bug reports and feature requests. Having the issue tracker is still of importance then.
okokwhatever 6y ago
It's my code, i don't want you to modify my codebase but I'll give it for free. Fair enough for me.
- mikepurvis 6y ago
  Or, “you’re welcome to fork it and make changes for use by yourself and others, but please don’t have any expectation that I will review or merge the changes you propose.”
  - okokwhatever 6y ago
    Like it too. The "don't have any expectations" part should be included in the name of the license: Dont-have-any-expectations-Open-Source License. :)
    - gnud 6y ago
      Do you mean MIT? > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, (https://opensource.org/licenses/MIT https://opensource.org/licenses/MIT) Similar language is also in basically every other license.
noobermin 6y ago
One way in the middle is to significantly raise the threshold for accepting a patch but that makes it harder.
notacoward 6y ago
It's interesting how this flips the relationship between the original author and subsequent forks. Let's say that a fork is created, and adds some substantial new feature. It's properly tested, and perhaps even proven in production. So Ben decides he wants it to be part of the base project, and starts pulling the pieces in. Now which is the OG and which is the fork? Which should people trust more? It will be interesting to see how that plays out, in this or some other project organized in a similar way.
- bityard 6y ago
  All of the open source BSDs derive from the same original code base and have survived as forks doing exactly what you describe. They each have different communities and different goals but still frequently borrow patches from one another.
  - notacoward 6y ago
    Interesting point. I'm not super familiar with the open-source BSD world (my last serious involvement with BSD was 4.3 Tahoe in 1991-2) but it seems like at least in that case the outcome has been pretty positive.
- mannykannot 6y ago
  Presumably, we should evaluate a pair of such forks as if they were independent - at least, it is not obvious to me that knowing the history of patches provides a basis for evaluating them any differently than if they were independent.
andi999 6y ago
Also if you do not accept contributions you can easily perform a license change later.
geoah 6y ago
Question for the OP (farslan). I do apologise in advance if this is something you wouldn't want to discuss, but do you think a notice such as this would have prevented you from burning out in regards to your open source projects? You have contributed immensely to the go community and I expect the decision to take a step back from open source contributions was hard and that you probably have revisited it often. I wonder if you have thought of things that might improve the process for other maintainers. Would the ability for example to disable pull requests help? Maybe a way to ask/find people to help moderate the issues or PRs before they reach you? Thank you both (Fatih and Ben) for all the hard work you've put into open source. --- ps. For people who might not know what I'm talking about, this might help. https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical-from-my-projects/ https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical...
- farslan 6y ago
  Hi geoah, Looking back, I think following this contribution model of open source but no contribution would definitely help me. In the beginning, I hadn't a lot of experience managing a large open source project. I would accept all kinds of feature PR's or tried to implement all the features people suggested and wanted from me. Obviously that was one of the main drivers of vim-go's popularity. However, this popularity also brought me down and I had a burnout. The problem with this one-person/popular projects are, it's not scalable. People recommend finding a maintainer, but that's not always possible and pretty hard. The main problem is, it's a niche product. Like you need to find someone who loves Vim, loves Go and also wants to be a part of a project. (I was lucky to find someone like that though, thank you Billie!). I still enjoy writing software on the side, but I think I've lost the energy and appetite to work +4 hours (on top of my full time job) every single day. Having two kids, getting older probably contributed to it :) I'm happy though how things have evolved right now. I found my inner peace.
beowulfey 6y ago
Reading through this thread, I've been introduced to a lot of excellent takes on this issue that I hadn't thought about before. In thinking about how to balance the two sides, I wonder if maintaining a master branch and a "community" branch would be one way to do it; all pull requests for new features could be added to the community branch, and the branch would always contain all the features of the master, but with the caveat that community would be untested. This would allow me to focus on the project goals as I see fit, but rely on the community to bug test and update the additional features. It would offload the work of maintenance without the need to split the codebase for every single individual feature request. Curious if something like this is used for any larger projects! I'm sure it wouldn't always work but maybe on certain types of projects it could.
patrickhulce 6y ago
I feel this so hard. Accepting nd reviewing contributions is far more work than it is worth in many cases and there's only so much benevolent helping time a person has. Especially if running multiple projects, sometimes you gotta cut the cord.
0xbadcafebee 6y ago
There is a middle way: continuous integration quality gates. For projects with a small core team and lots of contributors, you can write tests which analyze the submission for quality. Linting tests, code quality tests, smoke tests, unit tests, functional tests, ChangeLog tests, etc. Each one will halt the PR and inform the user what failed and how to fix it. The user can then gradually improve the quality of their PR until it passes all tests, and then someone will review it. I've used this method on projects before, and both as a contributor and a maintainer, I love it. As a contributor, it is a seamless feedback cycle that tells me how to improve my contribution before I bother anybody. As a maintainer, most contributors just don't put in the effort, so I don't get bothered. You can also put other quality gates in place, like asking someone to sign your contribution agreement, confirming they have read documentation ("what's the secret phrase?") or that their change includes documentation. It takes some work to set up at first, but it really improves productivity and quality.
- bacongobbler 6y ago
  Keep in mind that this discussion is about one's personal project. The situation changes if you have a small team of maintainers dedicated on a project. But most personal projects won't write a full acceptance suite just to start accepting contributions.
Tepix 6y ago
The README states: > I've made the decision to keep this project closed to contributions for ... long term viability of the project. Here's hoping he will open it up if he stops maintaining it (or slightly earlier)
- mkj 6y ago
  If he stops maintaining he's even less likely to accept contributions isn't he? Sure it's open source so you can fork it, same as ever.
benbjohnson 6y ago
Hi, Litestream author here. I'm happy to answer any questions about the policy or the project itself. I was apprehensive about adding the closed-contribution policy but I've seen overwhelmingly positive support for it since I released. Some commenters have noted that I could use another free code hosting platform. That's a valid criticism. However, I like the tools and workflow that GitHub offers personally. The GitHub Discussions feature in particular has been a nice step toward improving communication. GitHub Actions have been really nice for a CI workflow too.
- __henil 6y ago
  Can you ELI5 why open-contribution is a problem? Doesn't the person opening a PR on your project agree with the license your project is licensed with? (sorry for the unintended tongue twister)
  - jhare 6y ago
    Efforts from non-experts would likely hamper a complicated project like a database. Even though the hypothetical denied efforts being earnest well-meant efforts, I can't suggest a riff to bands I like.
  - benbjohnson 6y ago
    The main reason is that it takes a lot of time and energy to review pull requests—especially for this kind of software. For example, I have a server that continuously runs Litestream on a database that's constantly producing load. Every time I make a change in how Litestream works, I create and push up a new build to that server and run it for at least 24 hours. After that, I review metrics about performance and throughput and go through the logs to check for any abnormalities. Finally, I have a separate runbook that I go through for manual testing every CLI command and their various options. It's a slow process but it helps catch weird bugs that aren't apparent from automated testing. As for the license, yes, the PR author agrees with the license but it makes it harder in the future to change the license and then I need to maintain a Contributor License Agreement (CLA) which is more work. I don't have any plans to change the license but I also don't know if that will change in the future.
matsemann 6y ago
I'm curious why Elm gets such flak for doing the same?
trboyden 6y ago
I can't help but think this is self-inflicted. If we really are to apply the spirit of open-source, wouldn't the community-pro action here be to open the project up to additional maintainers to pick up the slack and delegate out the work? Isn't that how popular projects grow? And when they do get really big, isn't that the time they should be transitioned to an organization like Apache or Canonical to manage the day-to-day management efforts of a large project? I think the idea that a founder of a project is responsible to maintain it into infinity and beyond is missing the whole point of open-sourcing code. That founder is putting unfounded pressure on themselves rather than letting the project grow and evolve in an organic way. Much like a helicopter-parent that micro-manages their children's lives, rather than letting them make mistakes, learn, and mature into independent adults. Obviously, there are a number of open-source project methods for handling this, forking being a common one that the community itself can apply. But I would think it would be beneficial to the project community to have an honest discussion about it an entertain offers to take the project over rather than breaking the community spirit of contribution that is core to the ideals of open-source programming. If there comes a time when no one is willing to step up, the community and more importantly repository providers, should offer a way to put a project into maintenance mode, and allow someone to come along and take over maintenance of code that has the time and willingness to do so. This comment is not an effort to criticize the founders of the mentioned projects, but an open-ended question to the community at-large to ponder and reflect upon how we manage and grow the spirit of open-source, while taking care of the maintainers/contributors that help keep it going.
- bovermyer 6y ago
  My Iron Arachne projects are open source and closed to contributions. They're closed to contributions because they're my personal projects. They serve a very specific purpose - my playground, my mental space. But they're open source, because if others are curious about how they were built, I don't mind if they want to see the source.
  - trboyden 6y ago
    I think that is totally fine! Especially if it is organized that way from the start. But as soon as you allow contributions, is the project really yours anymore? Is it fair to the community that has contributed to your project, all of a sudden to be locked out from it, and forced to fork it to continue it's evolution? Why not hand it over to the community and start your own fork for personal development? I think that is the larger debate to be had.
bgpl10 6y ago
This is a great decision by the author, and the way he states it makes it socially acceptable in the current climate, where hordes of entitled and clueless people have the upper hand over the experienced and productive classes. The latter part is the real reason why people burn out;it wasn't that much of an issue when you could just tell people to stop bothering you with unimportant issues. These days it is like walking around in a train station where random people can ask you to carry their suitcases. If you don't politely oblige, they shout "privilege" and report you to the station's political officer.
shirakawasuna 6y ago
For a project where a sole primary maintainer is the only option, this makes perfect sense. For long-term viability of a popular project, I think you'll eventually need more maintainers, which brings back most of the problems of having multiple contributors.
bjarneh 6y ago
> Small contributions typically required hours of my time to properly test and validate them. Exactly, a small patch can be very time consuming to review. Fully understand the author.
tyingq 6y ago
It's not ideal, but the support for pull request templates is there, such that you can pre-fill the pull request with some text like "THIS WONT DO ANYTHING, PULL REQUESTS ARE AUTO DELETED" https://docs.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository https://docs.github.com/en/github/building-a-strong-communit...
bluefox 6y ago
GitHub's "archive" and this guy's "closed for contributions" is easily solved by forking: congratulations, you're the new maintainer. That's all there is to it.
DrFell 6y ago
The amount of rookie webdevs who think contributing to an open-source project is a normal part of learning now is so baffling. How are you supposed to make significant contributions to any project worth a darn without any significant experience? It sounds mean, but the trend should probably be discouraged. It's unnecessary, anyhow. Open-source projects are not practice projects. You make those up yourself.
makecheck 6y ago
Being able to turn off pull requests would help for cases like this. Though the default GitHub setup also makes contributions unnecessarily difficult to manage. For example, a project can tell if it has been forked but otherwise has no idea what the forker is currently doing! Is the forker working on a possible future contribution (and worse, could that work be duplicating something that is already in progress elsewhere?). There are also plenty of forks that seem to never evolve, not even taking the minimal effort of pulling recent upstream changes. The contribution mechanism could be broken up into different phases, something like: 0. Visitor forks project but this should be invisible, i.e. it is not “your repository” for all to see, since you haven’t actually contributed anything to it yet. 1. Visitor clicks button stating “intention to contribute” that notifies upstream project immediately. This includes information such as the nature of the proposed change. 2. The project maintainer then has the opportunity to communicate immediately, e.g. “sure!” or “please don’t do this, $SOMEONE_ELSE is already doing it” or “I don’t think that is a good idea” or whatever. Then the project can put this into a visible state on the GitHub page so that everyone knows about this in-progress work. 3. Eventually the work is done, and is converted to a Pull Request as opposed to just appearing out of the blue. 4. Once accepted, the repository is publicly listed on your profile since you have made an actual contribution to it.
- deleted 6y ago
  [deleted]
teddyh 6y ago
> simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them. Isn’t this a simple case of not having a good enough test suite?
- Jonnax 6y ago
  Well then why are they obligated to create a test suite?
  - teddyh 6y ago
    Huh, what? Nobody is “obligated” to create a test suite. But they wrote that a simple change could take hours to review. Creating a test suite might pay for itself (time-wise, that is) in the long run, if they want to accept external patches. Having patch reviews take hours is not the only option.
GizmoSwan 6y ago
Tech companies have been extracting cash via crowd sourcing and open-source is no longer an exception. A lot corporate software is sitting on top of open source and they are monetizing it and talk it down at the same time. And in some cases they have been able to take open source or ex free licensed software private too if they can muscle the take over by injecting cash incentives into hands of those who have inhered the means to change the rules via new versions. How did Oracle get to take over java? I think that Microsoft is in the game too by purchasing Github. They are billions of dollars in free code that they can take over. So IBM owns Redhat and Redhat is taking over whatever it can muscleiin their space.
jitendrac 6y ago
Duel licensing the contribution is always an option. you can add contribution agreement with statement like "all the contributed code will be under duel licensed, original commit will should grant all rights and ownership of it to the XYZ INC/LLP. the copy of it will automatically be commuted to GPL licensed source repository under original contributor's name. "
deleted 6y ago
[deleted]
mcguire 6y ago
Wasn't this the stand that caused people to be very angry with GCC, fork the project into EGCS, and eventually jump on LLVM as the the new favorite open compiler?
Ericson2314 6y ago
These types of things are funny to me, because I exclusively[1] contribute to other people's projects and don't really have any of my own. [1]: The maybe-exception being projects I then get commit-bit too.
signaru 6y ago
I've seen some repos put "mirror" in their descriptions. Like others, I wish GitHub has a way of blocking PRs. But I think, what I can do eventually is have my version of your "Open-source, not open-contribution" paragraph. Hopefully the term will become popular and more widely recognized. Furthermore, I think it is helpful to have a public roadmap of features not implemented yet. Others (especially colleagues) might feel ownership because they were able to guess what's on your long mental to-do list and make that their "ground breaking" request.
johnchristopher 6y ago
Between this stance and the "where's the patch?" crowd there's a hostile sentiment brewing against open-source users on HN.

661 points by farslan 6y ago

I think this is interesting. Burn-out is real - I remember when Ben stepped away from boltdb. I guess he's learned his lessons and isn't as interested in contributions being part of his vision for his SQLite sync tool. I'd be interested to see if this gets normalised beyond the SQLite community. One of the things I did recently and haven't regretted is turning off email notifications on GitHub.

skohan 6y ago
I think it's a perfectly fair option. I have projects which I have considered open-sourcing, but haven't because I don't want to deal with the public maintenance and community management aspects. I think there is sometimes too much pressure around what is the "right way" to do open source, that a project has to tick certain boxes to be a valid open-source project, and I think it's perfectly fine for an individual to want to tinker away at a pet project on their own, and share the results with others.

phendrenad2 6y ago

Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. https://github.com/isaacs/github/issues/1191 https://github.com/isaacs/github/issues/1191 3 years and counting. Some people are resorting to adding bots which auto-close PRs with a message like "Sorry, I'm not accepting PRs at this time", but that only triggers once the person has put in the effort to patch your project, at which poi t they may get annoyed to be suddenly told that PRs aren't welcome. Best solution is to keep code somewhere other than github. Is sourceforge still around?

tecnocriollo 6y ago
Gitlab is a nice option
- skohan 6y ago
  I've transitioned to gitlab for new projects about a month ago, and so far the experience has been great.
- Vinnl 6y ago
  It might be me, but I don't see an option to disable Merge Requests in GitLab?
  - dnsmichi 6y ago
    Hi, GitLab team member here. You can find it in the project settings in the "sharing and permissions" section: https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions https://docs.gitlab.com/ee/user/project/settings/#sharing-an... You can also disable the repository feature, and use the project for issue management only.
    - Vinnl 6y ago
      Heh, got it - I was looking under "Merge requests" :) Thanks both!
  - algo_cheese 6y ago
    In your project "Settings" -> "General" -> "Visibility, Project features, permissions" -> "Merge Requests". IIRC, you must be owner of the project.
- SamWhited 6y ago
  With apologies to the GitLab team, our views of how to make good software vary drastically and yours may be more in line with other peoples, but not mine: Maybe Gitlab's gotten better recently, but it's probably the most annoying piece of software I've ever used (well, second to Confluence maybe). It does everything which might be appealing to some, but for me it just meant everything was confusing, inconsistently labeled and documented, and/or buried under 5 levels of menus or under buttons that made no sense. The way I explain it is you know how when your computer illiterate parents ask you to do some simple task that you have literally no idea how to do, but you look at some menus that have vaguely similar sounding titles based on your years of building up intuitions about how computer UIs work, click those menus, find what you need and do the task? GitLab breaks all those intuitions so easy tasks become hard. YMMV, of course. I've been using Sourceforge recently and am pretty happy with it overall, though it's still very alpha quality.
Communitivity 6y ago
If you are writing something to contribute it to a project, then you should discuss the idea with the current committers/maintainer on the project's mailing list, or discord, or however they communicate. If you don't, and you submit a PR, you should expect the PR to be closed with a "Unfortunately, this change was not discussed. As a result it may clash with other efforts underway, or our future roadmap. Also, not having discussed it prior to the PR increases the suspicion that you have not followed our coding guidelines. Consequently this PR is closed. Please propose the change on the mailing list and take part in the discussion before revising this patch and resubmitting the PR." Because of this I think an auto-close is fine. I also do think Github should allow disabling the PR tab.
- gus_massa 6y ago
  I agree, but I'd make an exception for fixing typos, obvious bugs and tiny additional features. Sometimes the change takes less time that discussing in other channels, and sometimes it's easier to explain with code if you are not a native speaker. I think that spending more of a weekend in a PR without checking before with the maintainers is a bad idea, because there is a big risk that is not merged and is a waste of time. Also, each project has it's own weird rules, like code style, space vs tabs, changing whitespace in unrelated lines, adding tests, ... and a long list. Some are written explicitly, and some are just implicit rules. So sometimes it's difficult to make a PR that follows all the rules.
  - Communitivity 6y ago
    100% agreed. Things that are obvious to fix and have no design impact should be ok to PR and get accepted quickly. Every rule has exceptions, and this is definitely one for the rule I described. Thank you for pointing reminding me and clarifying.
  - phkahler 6y ago
    Yep. We had a PR for a single character typo. The submitter went to a lot of trouble, but the burden to the project really was as small as could be. No discussion, no open issue, just a PR with a one liner that could be reviewed in seconds and accepted with a click. Any other process would have been more work for the maintainers.
pabs3 6y ago
SourceForge is still around. I would suggest SourceHut over SourceForge these days though (not sure if SourceHut can turn off contributions).
- ddevault 6y ago
  SourceHut has you opt-in to anything you want - bug trackers, mailing lists for patches, git or hg repos, etc. The source code repository isn't the singular source of truth for a project like it is on GitHub. You can have a project with a dozen bug trackers, two mailing lists, and five source code repositories, organized in whatever way makes sense for your project.
  - andrepd 6y ago
    The flexibility is cool, but why would you want to fragment your bug trackers, for example, like that?
    - JosephRedfern 6y ago
      I think this was just an example, really, but I know some projects have an external bug tracking tool to document customer-reported issues, and closed, employee only ones to discuss the issue internally.
    - callmeal 6y ago
      So you can have a separate one for "internal" and "external" customers perhaps?
    - ddevault 6y ago
      Sometimes it makes sense to have different bug trackers for each sub-product, but also one for support, and one for your infrastructure issues, and a locked-down one for security tickets, and maybe another for packaging issues - any of which may not have associated source repos. Whatver organizational model meets your project's needs best, you have the flexibility to apply it. And people often do! A lot of the projects on sr.ht, given this flexibility, haven't recreated the same model as GitHub shoehorns you into. It goes beyond bug trackers, too. One other detail is that different projects can share resources with one another. I use one mailing list to slurp up all patches for my smaller side projects into one place, for example.
massysett 6y ago
Yes, for just this reason I am beginning to remove my projects from Github. I have "given back" by posting my Haskell libraries to Hackage, where they may be used and inspected by all. I'm not going to "give back" by maintaining software to the specifications of others, free of charge. This level of "giving back" is not trivial: I have often benefitted from seeing the source code of other projects and deciding I don't want to use the library, or seeing the code and deciding to modify it or take a different approach - or seeing the library and realizing that I wanted to try something similar, but this library shows me why I shouldn't do it. Maybe others will similarly benefit from seeing my stuff. If they see my stuff and think it's deficient, wonderful! Alter it to make it fit your needs, or use it as an inspiration for your own fresh rewrite. But I'm not maintaining software for other people. God bless people who do; that's wonderful. But it's perfectly OK to just post stuff up in case someone else wants to use it. When people see the code on Github they think "oh I can make feature requests" or "I can send a PR." Fair enough - Github is "social coding" after all. So I just won't put code on Github.
- cies 6y ago
  This is important. We need some vocabulary definitions for all different levels/aspects of "open". Open Access, or not. Open for contribution... or not. Commit ownership transferals, or not. In some cases there are whole steering committees.
  - mumblemumble 6y ago
    The vocabulary is already there. What is out of place is the perception of where the defaults lie. Right now we seem to assume that, unless someone takes the time to write out rules explicitly saying what they're not willing to do, then they must be willing to do it. It should be just the other way around. If a project wants contributions, for example, then they can communicate that by posting contribution guidelines in the README.
    - peteretep 6y ago
      > It should be just the other way around It should not be just the other way around
chmaynard 6y ago
Isn't that what archiving and mirroring are for? If you archive it or call it a mirror, GitHub users will understand that contributions to the repo are not accepted.
- kodah 6y ago
  Kind of. Archiving means you can't commit to it either, from what I know. Mirroring doesn't necessarily mean that you can't contribute to it, it just means you can't contribute to it on GitHub.
- sudhirj 6y ago
  No, archiving implies that no more code changes will be made. The author’s intention is not that that project is “finished”, it’s that they are the only ones going to make changes to it. Archiving will lock the authors out of making changes as well.
- qhwudbebd 6y ago
  I think archiving stops anyone pushing to a repo at all, but an option to label a repo as a mirror (and thereby block pull requests on GitHub) would be perfect for me - it pretty much exactly describes the situation for my GitHub repos. Your post implies this option exists, but I can't find it in the interface - am I missing something obvious?
  - chmaynard 6y ago
    This GitHub article may be useful: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository https://docs.github.com/en/github/creating-cloning-and-archi... I'm not sure if a mirror repo actually blocks pull requests. Check with GitHub Support for more information: support@githubsupport.com
    - qhwudbebd 6y ago
      This article isn't about creating a repository with non-standard properties I'm afraid. It's just a set of instructions for copying one repository into another. The resulting repo isn't any different from any other Github repository and doesn't have any kind of 'mirror' status.
bityard 6y ago
I don't blame Github here, their WHOLE spiel is open collaboration for community software projects. If want to share your project online but don't want to engage with your users as peers, then GitHub was never the right place to post the repo anyway.
- jabbany 6y ago
  Pretty sure the repo maintainer still wants to engage with users as peers (via bug reports and feature requests as they mention) just not through code contributions. In fact, if you only look at the "issues" framework, GitHub does a pretty good job of making things easy to use compared to the other bug trackers...
- trinovantes 6y ago
  Doesn't make sense they'd allow you to disable Issues but not PRs if they only cared about engagement
- SulfurHexaFluri 6y ago
  This is rubbish. Github is massively more useful than dumping the source on your own webserver even if you do not want PRs. It would be a fairly simple change to simply add a button and remove the PR tab.
toyg 6y ago
Github allowing you to disable PRs would be a bit like Facebook allowing you to opt out of ad-tracking...
- johannes1234321 6y ago
  I don't get the analogy. Also mind: Even if pull requests are off somebody else might emerge and maintain a fork, which becomes more successful. Maybe even going as far that that the original owner can safely outsource the maintenance of the thing he created.
  - toyg 6y ago
    The whole business model of GitHub is to get you to use its proprietary social features, so that 1) you get locked-in, and 2) you generate and maintain adoption virality. The minute they become just another dumb git host, their relevance disappears.
    - sofixa 6y ago
      > 1) you get locked-in, How do you get locked in? PRs, once merged, are just regular commits. You lose the history and discussion around the PR itself, but that's all, but it's not like any alternative allows you to migrate ( e.g. the abomination that is using email for git collaboration is stuck in unreadable, unsearchable, unindexed emails somewhere; you can copy the data pretty much the same way as from GitHub, but both are unexploitable without a lot of tinkering / adaptation)
enriquto 6y ago
> Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. I'm not the one to defend GitHub, but what's the big deal about not accepting pull requests? If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything? Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut.
- darkwater 6y ago
  > Am I missing anything? Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.
  - enriquto 6y ago
    > it's far less welcoming Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.
    - onion2k 6y ago
      only somebody with a ridiculously thin skin... People like that are very common and often very vocal.
    - DangitBobby 6y ago
      Depends on how much work they put in, doesn't it?
      - tombot 6y ago
        Surely someone invested enough to submit a PR would have read the readme which explains they won’t accept a PR
rectang 6y ago
Is it possible to "archive" and then "unarchive" a Github repo using the Github API? If so, one possible solution is to maintain the primary repo elsewhere (Source Hut, Gitlab. wherever), and run a sync routine on a cron (or perhaps every push): 1. unarchive Github mirror repo 2. Push changes from primary repo to Github mirror 3. archive Github mirror repo There's a race condition where someone might see the unarchived repo and start a pull request during the brief period where the sync is taking place, but the possibility that they'd both start and then fisish a pull request during sync periods seems remote.
- gregoriol 6y ago
  The problem with archive is that it looks like "not maintained anymore"/"deprecated", which is not the case here.
  - rectang 6y ago
    I agree, it's a hack. This hack competes with the "auto-close all pull requests" hack. Which hack you would choose depends on how important it is never to see pull requests (e.g. for IP reasons as described elsethread).
fortran77 6y ago
Amazon CodeCommit works great for me.
- bcfalconer 6y ago
  Like all of AWS, the pricing seems opaque and without hard limits: https://aws.amazon.com/codecommit/pricing/ https://aws.amazon.com/codecommit/pricing/ "Our transaction and storage quotas are designed to handle the most common developer workflows without incurring overages. For most workflows where CodeCommit users are manually using Git operations, these quotas are rarely breached." "$0.001 per Git request" I need an option that is limited to $5 a month, with DDoS being their problem.
  - sofixa 6y ago
    > I need an option that is limited to $5 a month, with DDoS being their problem DDoS is always their problem. AWS and co always waive charges due to attacks or significant errors on user's part ( e.g. writing an infinite loop that results in a huge bill)
macksd 6y ago
I like the idea of reducing the stigma, but honestly if I haven't realized they don't accept PRs by the time I'm looking for the PR tab, I've already done all the same work, kinda for nothing. It ought to be made very clear in README.md or CONTRIBUTING.md or something too. I do wish people weren't completely closed to PRs though. I think companies are often misled when they think they'll get free labor out of open source, etc. and I think the free-as-in-libre aspect is more important relative to community aspect than a lot of people, but still - I hate it when my only option if I want a bug fixed is to wait for the company to do it themselves or fork. Even if I have to sign over all my rights of the code, I'd so much rather they at least consider taking my PR and be done with it. They don't have to do it for features they don't like or fixes that have downsides. But for a straightforward fix, at least look at it. It might be all the free help you ever get from the community.
- massysett 6y ago
  You want other people to do work for you, for free. That's completely understandable.
  - phkahler 6y ago
    >> You want other people to do work for you, for free. That's completely understandable. The parent poster was talking about submitting a Pull Request. In other words, contributing the work for free. I suppose expecting someone to look at it might be asking them to do something for free, but if that's a problem then I agree that Github should have the option of not having the button on a project at all. Or maybe you thought PR stood for Problem Report, in which case expecting it to be looked into by someone is an expectation of free labor.
    - massysett 6y ago
      Examining the pull request is work, as is integrating it into the software and maintaining it in the future. The parent wants the project to do that so that s/he does not have to fork it him/herself. In other words, the parent wants someone else to do work, for free. Free Software is about the freedom of the user - freedom to distribute, freedom to study, freedom to use, freedom to modify. Somehow people have managed to pervert this so that it not only means "free as in free beer so that I can use it" but even "free beer so that OTHER PEOPLE can do work that I want done, for free." There is absolutely no entitlement to this.
mathnmusic 6y ago
Does this not serve the purpose? Repo -> Settings -> Moderation Settings -> Limit to repository collaborators
- Footkerchief 6y ago
  "Disable pull requests while keeping issues"
- dbrgn 6y ago
  This cannot be enabled permanently. Max duration is 6 months.
_jal 6y ago
Seems weird to me to blindly fire off a PR to a project I've never communicated with. I've always asked first, mainly because I don't want to waste my time if they won't give it any consideration. And also because maybe they're already working on whatever I was thinking of, or are doing it in a different way, or...
- publicola1990 6y ago
  That ok, but there is also the thought that if you see a picture hanging in the wall is tilted, it is better to jt straighten it without waiting to ask permission. It is easier to ask for forgiveness than for permission.
- mhitza 6y ago
  My contributions are fixes that I need now. So after I fix the issue for my usecase I fire off a PR upstream. As a maintainer you are free to close my PR, or work togheter with me to bring it in line with your project standards.
Joeri 6y ago
If the contributing.md says no PR’s are welcome and there is a pull request template which just says in big letters “PLEASE DON’T!” I doubt many people would get confused. https://docs.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository https://docs.github.com/en/github/building-a-strong-communit...
- Arnavion 6y ago
  How does anyone even see the PR template? If you fork, push a branch with your fix to your fork, go to your fork in the browser and click the "Compare & Pull Request" button to make a PR from your branch [1], you don't see the template at all. The UI is auto-filled with the text from your commit message. I thought everyone filed PRs this way; is there another workflow I haven't heard of? [1]: It takes you to https://github.com/$upstream/$repo/compare/master...$you:$branch?expand=1 https://github.com/$upstream/$repo/compare/master...$you:$br...
TheRealPomax 6y ago
Also the "fork" option. If you want the source, pull the official source, but there are plenty of projects where people should not be creating their own copy that is on equal footing as the authoritative repo.
- yawaramin 6y ago
  It's a widely-known practice for companies to internally fork and vendor software they use.
  - TheRealPomax 6y ago
    Sure? But that doesn't mean you can't give people the power to turn off that "one-click, no thinky thinky effort effort" option.
kminehart 6y ago
It's crazy to me that the open source world has completely standardized on a closed (and now Microsoft) product like GitHub. I'm sure someone would have implemented this feature for them by now if it was free software.
- Jkvngt 6y ago
  To be fair, MS only bought GitHub after it became very popular.
trynewideas 6y ago
> Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. It's more of a workaround than a solution, and depends on how much you trust GitHub Actions, but this one will autoclose all issues and/or PRs. https://github.com/marketplace/actions/repo-lockdown https://github.com/marketplace/actions/repo-lockdown > Best solution is to keep code somewhere other than github. Is sourceforge still around? Aside from Sourceforge and self-hosting (simply via gitweb, or with GitHub-like features in Gitea, Phabricator), there are the big ones like GitLab and Bitbucket, cloud repo services on AWS and Azure, and smaller/indie services like Sourcehut (sr.ht), Launchpad, and RhodeCode.
pizzazzaro 6y ago
This is why our tools for Open Software need to be Open themselves. Have a problem being unable to disable PRs? A PR that fixes it would be embarassing for Github if it were simply Closed. How many such PRs for distinct code could we get submitted at once?
whateveracct 6y ago
I guess you can add a PR template that says "PLEASE DON'T SEND ME PRS"
justaguy88 6y ago
There is https://sr.ht/ https://sr.ht/
hutzlibu 6y ago
"Best solution is to keep code somewhere other than github. Is sourceforge still around? " How about just stating in README about your PR policy in big letters? And if then people get angry because they were too lazy to read, .. well you cannot and should not please everyone. Anyway, and what bothers me with GitHub is Microsoft, even though so far I cannot really complain. At least they have not sneakily bundled adware with OSS installers, like sourceforge did. So they really lost all reputation and trust for me and are never a alternative again. I rather go with microsoft and that says something.
didibus 6y ago
Ya Github just needs a way to disable everyone to create issues and/or PRs.

franciscop 6y ago

I've disabled Issues in some of my popular UI libraries and I couldn't be happier. Specially notorious was Picnic CSS[1] where many of the issues were on the level of "hey can you give me the code for X" or "how do you do X" where X was a general CSS question and not related to the library at all. I've also received unkind words when I closed some of my repos issues as a PR [2][3]: > If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM). > part of offering these to the public through open software is maintaining them and allowing feedback from users. > It seems umbrella.js project suffers the same desease. I've noticed there was a strong push around 2016-2018 to recommend newbie programmers NOT to go to Stackoverflow, but instead to ask the questions straight in the Github issues. Turns out, the problem was low quality questions all along, and that just converted an issue that StackOverflow had solved long ago into burnout for open source developers on Github. Github needs to step up their game and give authors more powerful tools, there's so many entitled developers out there that will come and demand changes. It might make new devs feel less welcome, but the balance is tipped way too much to allow anyone to create massive spam for projects right now. [1] https://picnicss.com/ https://picnicss.com/ [2] https://github.com/franciscop/picnic/pull/203/files https://github.com/franciscop/picnic/pull/203/files [3] https://github.com/franciscop/picnic/pull/202 https://github.com/franciscop/picnic/pull/202

lol768 6y ago
> Github needs to step up their game and give authors more powerful tools This is presumably what the discussions feature is meant to allow? A place to ask questions and discuss things rather than report bugs.
- franciscop 6y ago
  That is great if you are e.g. Facebook and pour a lot of resources into the community. But there are multiple archetypes of open source developers, and for most others reducing the amount of noise is more important than adding more channels. For many tools that add friction, thus increasing the quality would be much better. Some random examples: - Requiring any Issue to have some mandatory fields (version number, output, etc) - Add some sort of "reputation" like StackOverflow for devs and require a minimum threshold - Limit issues to those who actively contribute on Open Source (PRs, own open source, etc) All of these would be opt-in by the maintainers of the project. Could also kill two birds with one stone by limiting Issues and/or Discussions to Sponsors only (and collaborators)

webmobdev 6y ago

> Writing databases & low-level replication tools involves nuance and simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them ... I've made the decision to keep this project closed to contributions for my own mental health and long term viability of the project. While I understand the burden of accepting and evaluating code from others and the very real possibility of a burn-out due to it, can't test-driven development (or even Behavior-driven development) reduce a lot of this burden? (Related: How SQLite is tested - https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html ).

Aeolun 6y ago
Yeah, just ignore any PR that doesn’t pass the tests. Also a good way to weed out the people that don’t care enough to fix it if they break something.
- swiftcoder 6y ago
  You also have to reject any PR that modifies the tests. Otherwise the maintainer now has to validate test suite integrity any time they accept a PR.
  - hoseja 6y ago
    I don't understand the obsession with testing. You can't test for unknown unknowns, that is, non-obvious bugs. Sure it's nice "automated documentation" but I feel like the reverence it gets is overstated.
    - webmobdev 6y ago
      From what I understand - you don't test for all unknowns as that is humanly impossible. You test for realistic "known" only. This largely prevents regression bugs as new fixes or features are added. When a bug reveals itself and is fixed, it becomes a known case that you can decide to create a test for (if necessary) and prevent its recurrence in the future. Personally, I feel it improves the code quality and readability for others as the tests also help them better understand the functionality of the code within a project.

davidjgraph 6y ago

This was a problem for us and the lack of the ability to switch off PRs continues to cause problems. Community submissions are virtually always throw away, particularly on a complex code base. We ended up saying it's a legal problem [1], which it partly is. But throw away not only because of quality issues, always because of project scope issues. Yes, you feel the project is completely useless unless emoji icons animate in diagrams. That's great, fork the project and kill ours off by adding the feature (which they won't and it won't). When you know what the project scope is, tight enforcement of that scope is critical to prevent the complexity of the project from running away and ultimately killing the project entirely. https://github.com/jgraph/drawio https://github.com/jgraph/drawio

j1elo 6y ago
> When you know what the project scope is, tight enforcement of that scope is critical to prevent the complexity of the project from running away and ultimately killing the project entirely. Which is why I believe a "benevolent dictatorship" style of governance has more chances (nitpick prevention: more, not all the chances) to become successful and thrive. If you let too many community members decide on what is in and out of scope, the project ends up being a conglomerate of the most random favorite features from the most vocal participants.
- distalx 6y ago
  And sometime these most vocal participants are all talk and no code.
drej 6y ago
> Note: We cannot accept non-trivial PRs for legal reasons. We need to retain copyright over the entire codebase. Does a CLA solve this? (Genuine question, I don't know.)
- MayeulC 6y ago
  Yes, this is what a CLA solves. And I tend to refrain from contributing to projects that have a CLA, although it might not be reasonable: there's little difference with licensing your contribution under MIT, I think. However, if you license your project under AGPL, you probably deemed AGPL comfortable for your needs. I did too, so licensing my contribution under something else feels a bit uncomfortable, especially if it is substantial.

Aeolun 6y ago

While I respect this, it annoys me to no end when I can use a piece of software, see the code of a piece of software, fix a piece of software, but not contribute that fix back up. So I’m doomed to an eternity of either merging all upstream changes, or waiting for the maintainer to fix it on his own. I generally just pick something else, but it isn’t always immediately clear.

franciscop 6y ago
IF the maintainer(s) offer contracting and it bothers you so much, have you considered paying them 1-2 hours to have a look at the issue/solution? If you are putting food on my mouth AND potentially fixing an issue, that'd be normally much better. Any patch review is extra work for the maintainer, which they are in their right of not wanting to do it.
- krzyk 6y ago
  But besides the review it is also free code. I don't get this sentiment of disallowing pull requests or issues. Just because one gets bunch of useless issues or PRs doesn't mean that he/she won't receive a valuable one. If you close those, you are basically closed-source with an option to peak at the code.
  - pessimizer 6y ago
    > If you close those, you are basically closed-source with an option to peak at the code. No, you are completely open source. FOSS doesn't have anything to do with the right to contribute upstream. It gives you rights over the code, not the servers that house the code.
  - jabbany 6y ago
    This is not the case and the maintainer outlines why. (1) FOSS means you (the "licensee") can do what you want with the code, not that I (the "licenser") am somehow obliged to take your input on it. If the maintainers find that code contributions are reducing their maintenance effort, which is often the case, then sure. But if on the other hand reviewing the contributions themselves _increases_ effort, then it literally is a net-negative to accept PRs. (2) It's also very possible that PRs create extra work. Sometimes reading and understanding someone else's solution to a problem is harder than coming up with your own! Of course, one could take a laissez faire approach to maintenance and just assume good intent and do light reviews, but that doesn't necessarily make for a better codebase.

pmlnr 6y ago

Unpopular question: if this is the case, why put it on github? There are countless web frontends[^1] to expose a git tree on the internet, without the community/social aspect of github. [^1]: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces https://git.wiki.kernel.org/index.php/Interfaces,_frontends,...

jabbany 6y ago
(1) Running your own web service costs money (hosting fees) and time (setup, patching security issues). Often quite significant amounts of both, making it unattractive for small FOSS projects. Github provides a free and managed service. (2) The maintainer _wants_ the community/social aspects like Issues and Discussions. They just don't want code contributions. Of course, one can run their own bug tracker and forum... but... see (1). (3) GitHub has been branding itself as more and more of a package manager too (and in many areas it has become the de-facto one). Placing things on Github v.s. self hosting can also be seen as an SEO/advertising move for an FOSS project.
- pmlnr 6y ago
  On that list, there are projects like https://github.com/Hypercubed/git2html https://github.com/Hypercubed/git2html . It makes a set of static files, which could be uploaded to any static hosting provider, including github pages.
  - jabbany 6y ago
    This kind of stuff takes a nontrivial amount of time and effort to setup and _automate_. Plus at the end of the day you still need to host the repo itself somewhere (not just the web UI), which means you will need a hosted place you can write to via Git's push mechanisms... It's not impossible but finding free managed hosting for this seems nontrivial too.
jgilias 6y ago
I don't see why the question should be unpopular. It's valid. I think because having a project on github aids discoverability. Also, the project mentions that they would stop accepting pull requests, not that there would be no interaction with users whatsoever. Quite the contrary, it is stated that the author is thankful for bug reports and feature requests. Having the issue tracker is still of importance then.

okokwhatever 6y ago

It's my code, i don't want you to modify my codebase but I'll give it for free. Fair enough for me.

mikepurvis 6y ago
Or, “you’re welcome to fork it and make changes for use by yourself and others, but please don’t have any expectation that I will review or merge the changes you propose.”
- okokwhatever 6y ago
  Like it too. The "don't have any expectations" part should be included in the name of the license: Dont-have-any-expectations-Open-Source License. :)
  - gnud 6y ago
    Do you mean MIT? > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, (https://opensource.org/licenses/MIT https://opensource.org/licenses/MIT) Similar language is also in basically every other license.

noobermin 6y ago

One way in the middle is to significantly raise the threshold for accepting a patch but that makes it harder.

notacoward 6y ago

It's interesting how this flips the relationship between the original author and subsequent forks. Let's say that a fork is created, and adds some substantial new feature. It's properly tested, and perhaps even proven in production. So Ben decides he wants it to be part of the base project, and starts pulling the pieces in. Now which is the OG and which is the fork? Which should people trust more? It will be interesting to see how that plays out, in this or some other project organized in a similar way.

bityard 6y ago
All of the open source BSDs derive from the same original code base and have survived as forks doing exactly what you describe. They each have different communities and different goals but still frequently borrow patches from one another.
- notacoward 6y ago
  Interesting point. I'm not super familiar with the open-source BSD world (my last serious involvement with BSD was 4.3 Tahoe in 1991-2) but it seems like at least in that case the outcome has been pretty positive.
mannykannot 6y ago
Presumably, we should evaluate a pair of such forks as if they were independent - at least, it is not obvious to me that knowing the history of patches provides a basis for evaluating them any differently than if they were independent.

andi999 6y ago

Also if you do not accept contributions you can easily perform a license change later.

geoah 6y ago

Question for the OP (farslan). I do apologise in advance if this is something you wouldn't want to discuss, but do you think a notice such as this would have prevented you from burning out in regards to your open source projects? You have contributed immensely to the go community and I expect the decision to take a step back from open source contributions was hard and that you probably have revisited it often. I wonder if you have thought of things that might improve the process for other maintainers. Would the ability for example to disable pull requests help? Maybe a way to ask/find people to help moderate the issues or PRs before they reach you? Thank you both (Fatih and Ben) for all the hard work you've put into open source. --- ps. For people who might not know what I'm talking about, this might help. https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical-from-my-projects/ https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical...

farslan 6y ago
Hi geoah, Looking back, I think following this contribution model of open source but no contribution would definitely help me. In the beginning, I hadn't a lot of experience managing a large open source project. I would accept all kinds of feature PR's or tried to implement all the features people suggested and wanted from me. Obviously that was one of the main drivers of vim-go's popularity. However, this popularity also brought me down and I had a burnout. The problem with this one-person/popular projects are, it's not scalable. People recommend finding a maintainer, but that's not always possible and pretty hard. The main problem is, it's a niche product. Like you need to find someone who loves Vim, loves Go and also wants to be a part of a project. (I was lucky to find someone like that though, thank you Billie!). I still enjoy writing software on the side, but I think I've lost the energy and appetite to work +4 hours (on top of my full time job) every single day. Having two kids, getting older probably contributed to it :) I'm happy though how things have evolved right now. I found my inner peace.

beowulfey 6y ago

Reading through this thread, I've been introduced to a lot of excellent takes on this issue that I hadn't thought about before. In thinking about how to balance the two sides, I wonder if maintaining a master branch and a "community" branch would be one way to do it; all pull requests for new features could be added to the community branch, and the branch would always contain all the features of the master, but with the caveat that community would be untested. This would allow me to focus on the project goals as I see fit, but rely on the community to bug test and update the additional features. It would offload the work of maintenance without the need to split the codebase for every single individual feature request. Curious if something like this is used for any larger projects! I'm sure it wouldn't always work but maybe on certain types of projects it could.

patrickhulce 6y ago

I feel this so hard. Accepting nd reviewing contributions is far more work than it is worth in many cases and there's only so much benevolent helping time a person has. Especially if running multiple projects, sometimes you gotta cut the cord.

0xbadcafebee 6y ago

There is a middle way: continuous integration quality gates. For projects with a small core team and lots of contributors, you can write tests which analyze the submission for quality. Linting tests, code quality tests, smoke tests, unit tests, functional tests, ChangeLog tests, etc. Each one will halt the PR and inform the user what failed and how to fix it. The user can then gradually improve the quality of their PR until it passes all tests, and then someone will review it. I've used this method on projects before, and both as a contributor and a maintainer, I love it. As a contributor, it is a seamless feedback cycle that tells me how to improve my contribution before I bother anybody. As a maintainer, most contributors just don't put in the effort, so I don't get bothered. You can also put other quality gates in place, like asking someone to sign your contribution agreement, confirming they have read documentation ("what's the secret phrase?") or that their change includes documentation. It takes some work to set up at first, but it really improves productivity and quality.

bacongobbler 6y ago
Keep in mind that this discussion is about one's personal project. The situation changes if you have a small team of maintainers dedicated on a project. But most personal projects won't write a full acceptance suite just to start accepting contributions.

Tepix 6y ago

The README states: > I've made the decision to keep this project closed to contributions for ... long term viability of the project. Here's hoping he will open it up if he stops maintaining it (or slightly earlier)

mkj 6y ago
If he stops maintaining he's even less likely to accept contributions isn't he? Sure it's open source so you can fork it, same as ever.

benbjohnson 6y ago

Hi, Litestream author here. I'm happy to answer any questions about the policy or the project itself. I was apprehensive about adding the closed-contribution policy but I've seen overwhelmingly positive support for it since I released. Some commenters have noted that I could use another free code hosting platform. That's a valid criticism. However, I like the tools and workflow that GitHub offers personally. The GitHub Discussions feature in particular has been a nice step toward improving communication. GitHub Actions have been really nice for a CI workflow too.

__henil 6y ago
Can you ELI5 why open-contribution is a problem? Doesn't the person opening a PR on your project agree with the license your project is licensed with? (sorry for the unintended tongue twister)
- jhare 6y ago
  Efforts from non-experts would likely hamper a complicated project like a database. Even though the hypothetical denied efforts being earnest well-meant efforts, I can't suggest a riff to bands I like.
- benbjohnson 6y ago
  The main reason is that it takes a lot of time and energy to review pull requests—especially for this kind of software. For example, I have a server that continuously runs Litestream on a database that's constantly producing load. Every time I make a change in how Litestream works, I create and push up a new build to that server and run it for at least 24 hours. After that, I review metrics about performance and throughput and go through the logs to check for any abnormalities. Finally, I have a separate runbook that I go through for manual testing every CLI command and their various options. It's a slow process but it helps catch weird bugs that aren't apparent from automated testing. As for the license, yes, the PR author agrees with the license but it makes it harder in the future to change the license and then I need to maintain a Contributor License Agreement (CLA) which is more work. I don't have any plans to change the license but I also don't know if that will change in the future.

matsemann 6y ago

I'm curious why Elm gets such flak for doing the same?

trboyden 6y ago

I can't help but think this is self-inflicted. If we really are to apply the spirit of open-source, wouldn't the community-pro action here be to open the project up to additional maintainers to pick up the slack and delegate out the work? Isn't that how popular projects grow? And when they do get really big, isn't that the time they should be transitioned to an organization like Apache or Canonical to manage the day-to-day management efforts of a large project? I think the idea that a founder of a project is responsible to maintain it into infinity and beyond is missing the whole point of open-sourcing code. That founder is putting unfounded pressure on themselves rather than letting the project grow and evolve in an organic way. Much like a helicopter-parent that micro-manages their children's lives, rather than letting them make mistakes, learn, and mature into independent adults. Obviously, there are a number of open-source project methods for handling this, forking being a common one that the community itself can apply. But I would think it would be beneficial to the project community to have an honest discussion about it an entertain offers to take the project over rather than breaking the community spirit of contribution that is core to the ideals of open-source programming. If there comes a time when no one is willing to step up, the community and more importantly repository providers, should offer a way to put a project into maintenance mode, and allow someone to come along and take over maintenance of code that has the time and willingness to do so. This comment is not an effort to criticize the founders of the mentioned projects, but an open-ended question to the community at-large to ponder and reflect upon how we manage and grow the spirit of open-source, while taking care of the maintainers/contributors that help keep it going.

bovermyer 6y ago
My Iron Arachne projects are open source and closed to contributions. They're closed to contributions because they're my personal projects. They serve a very specific purpose - my playground, my mental space. But they're open source, because if others are curious about how they were built, I don't mind if they want to see the source.
- trboyden 6y ago
  I think that is totally fine! Especially if it is organized that way from the start. But as soon as you allow contributions, is the project really yours anymore? Is it fair to the community that has contributed to your project, all of a sudden to be locked out from it, and forced to fork it to continue it's evolution? Why not hand it over to the community and start your own fork for personal development? I think that is the larger debate to be had.

bgpl10 6y ago

This is a great decision by the author, and the way he states it makes it socially acceptable in the current climate, where hordes of entitled and clueless people have the upper hand over the experienced and productive classes. The latter part is the real reason why people burn out;it wasn't that much of an issue when you could just tell people to stop bothering you with unimportant issues. These days it is like walking around in a train station where random people can ask you to carry their suitcases. If you don't politely oblige, they shout "privilege" and report you to the station's political officer.

shirakawasuna 6y ago

For a project where a sole primary maintainer is the only option, this makes perfect sense. For long-term viability of a popular project, I think you'll eventually need more maintainers, which brings back most of the problems of having multiple contributors.

bjarneh 6y ago

> Small contributions typically required hours of my time to properly test and validate them. Exactly, a small patch can be very time consuming to review. Fully understand the author.

tyingq 6y ago

It's not ideal, but the support for pull request templates is there, such that you can pre-fill the pull request with some text like "THIS WONT DO ANYTHING, PULL REQUESTS ARE AUTO DELETED" https://docs.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository https://docs.github.com/en/github/building-a-strong-communit...

bluefox 6y ago

GitHub's "archive" and this guy's "closed for contributions" is easily solved by forking: congratulations, you're the new maintainer. That's all there is to it.

DrFell 6y ago

The amount of rookie webdevs who think contributing to an open-source project is a normal part of learning now is so baffling. How are you supposed to make significant contributions to any project worth a darn without any significant experience? It sounds mean, but the trend should probably be discouraged. It's unnecessary, anyhow. Open-source projects are not practice projects. You make those up yourself.

makecheck 6y ago

Being able to turn off pull requests would help for cases like this. Though the default GitHub setup also makes contributions unnecessarily difficult to manage. For example, a project can tell if it has been forked but otherwise has no idea what the forker is currently doing! Is the forker working on a possible future contribution (and worse, could that work be duplicating something that is already in progress elsewhere?). There are also plenty of forks that seem to never evolve, not even taking the minimal effort of pulling recent upstream changes. The contribution mechanism could be broken up into different phases, something like: 0. Visitor forks project but this should be invisible, i.e. it is not “your repository” for all to see, since you haven’t actually contributed anything to it yet. 1. Visitor clicks button stating “intention to contribute” that notifies upstream project immediately. This includes information such as the nature of the proposed change. 2. The project maintainer then has the opportunity to communicate immediately, e.g. “sure!” or “please don’t do this, $SOMEONE_ELSE is already doing it” or “I don’t think that is a good idea” or whatever. Then the project can put this into a visible state on the GitHub page so that everyone knows about this in-progress work. 3. Eventually the work is done, and is converted to a Pull Request as opposed to just appearing out of the blue. 4. Once accepted, the repository is publicly listed on your profile since you have made an actual contribution to it.

deleted 6y ago
[deleted]

teddyh 6y ago

> simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them. Isn’t this a simple case of not having a good enough test suite?

Jonnax 6y ago
Well then why are they obligated to create a test suite?
- teddyh 6y ago
  Huh, what? Nobody is “obligated” to create a test suite. But they wrote that a simple change could take hours to review. Creating a test suite might pay for itself (time-wise, that is) in the long run, if they want to accept external patches. Having patch reviews take hours is not the only option.

GizmoSwan 6y ago

Tech companies have been extracting cash via crowd sourcing and open-source is no longer an exception. A lot corporate software is sitting on top of open source and they are monetizing it and talk it down at the same time. And in some cases they have been able to take open source or ex free licensed software private too if they can muscle the take over by injecting cash incentives into hands of those who have inhered the means to change the rules via new versions. How did Oracle get to take over java? I think that Microsoft is in the game too by purchasing Github. They are billions of dollars in free code that they can take over. So IBM owns Redhat and Redhat is taking over whatever it can muscleiin their space.

jitendrac 6y ago

Duel licensing the contribution is always an option. you can add contribution agreement with statement like "all the contributed code will be under duel licensed, original commit will should grant all rights and ownership of it to the XYZ INC/LLP. the copy of it will automatically be commuted to GPL licensed source repository under original contributor's name. "

deleted 6y ago

[deleted]

mcguire 6y ago

Wasn't this the stand that caused people to be very angry with GCC, fork the project into EGCS, and eventually jump on LLVM as the the new favorite open compiler?

Ericson2314 6y ago

These types of things are funny to me, because I exclusively[1] contribute to other people's projects and don't really have any of my own. [1]: The maybe-exception being projects I then get commit-bit too.

signaru 6y ago

I've seen some repos put "mirror" in their descriptions. Like others, I wish GitHub has a way of blocking PRs. But I think, what I can do eventually is have my version of your "Open-source, not open-contribution" paragraph. Hopefully the term will become popular and more widely recognized. Furthermore, I think it is helpful to have a public roadmap of features not implemented yet. Others (especially colleagues) might feel ownership because they were able to guess what's on your long mental to-do list and make that their "ground breaking" request.

johnchristopher 6y ago

Between this stance and the "where's the patch?" crowd there's a hostile sentiment brewing against open-source users on HN.