Open-source, not open-contribution | Hacker News Reader

Open-source, not open-contribution

github.com

661 pointsfarslan321 comments

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.

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)

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.

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.

Thanks for the explanation.

It would certainly more work for you to maintain CLA for your project, but why does sqlite setup CLA? It is sufficiently big project and they could easily setup CLA if they wanted to.

why does sqlite does not setup CLA*

Have you thought about having an application process to accept new members to the "core" team? The idea that people contribute isn't wrong in itself. It's usually the lack of commitment from the contributor that causes the stress on the maintainer side.

Yes, that'd be a good option and something I would consider if the workload increases to an unmaintainable level.

Unfortunately, I think you have to start that process before you get to that point. Otherwise you'll be overworked and attempting to onboard someone on a project for the first time. That probably won't go well.

Why would trying to create a process for theoretical onboarding of members be less work than actually onboarding someone? I disagree. Leave the consideration of onboarding someone until you need it, and then focus on just that for the month or whatever they need to get up to speed, and then switch back to main contribution.

Reading code is harder than writing code. It is also not very fun. So when someone files a PR against your project, it means a bunch of not-very-fun effort. It also comes with a social obligation, because someone presumably put a lot of effort into the PR and you don't want to have wasted their time. Obligation + not fun work on a side project that you're probably doing to help stave off burnout turns that project into just another source of burnout. Project management in general just isn't very fun.

If you feel a large degree of ownership over the codebase, you'll also be irritated at including someone else's code/design style. Like having someone else's voice in your head. You could go through the PR and request changes to conform to your code/design preferences, but that would take a lot of your time and also a lot of the contributor's time (and be very likely to frustrate the contributor). It would probably just be easier to rewrite it yourself in your own style. Or just let all that stuff slide. But then your project is less "your" project, and you might not get the same sense of gratification working in the codebase.

Suppose you go to clean up your local park and a monk walks up to you and hands you a book. They then ask you for a small donation. If this kept happening, would it discourage you from cleaning up your park?

If the monk constantly talks about how the park isn't clean enough [0] then yes. It certainly would.

[0] Your software is missing feature X = your park isn't clean enough

Even if the monk wasn't doing that, I'd be annoyed.

The next week, the cleaner returned. The monk offered him the book again, whereupon the cleaner held out his trash bag, that he might toss it in. At this moment, the monk was enlightened.

And the cleaner collected many such books, from various monks, in his trash bag, until eventually he had enough books to start a reasonably large fire, burning the park down, his cat enjoying the heat from the fire

I'm trying to figure out HOW this is an analogy for the comment you are replying to and can't. Can you explain?

The person going to clean the park is the maintainer of some Open source software, offered for the public good.

The monk handing over the book is the person who has done the work to write a pull request and gift it to the maintainer.

The request for a donation is the cultural expectation of reciprocity. A maintainer now feels pressure to accept the work of reviewing the PR. Yes, they can say no, but it feels bad and can motivate someone to stop maintaining open source software.

That makes no sense, the analogy is wrong on all counts.

An open source project I initiate is not a "public good". I'm sharing it; I still own the copyright.

The monk handing over the book in the park has done no work on the park, they are a user NOT a contributor. In fact, probably a bunch of the trash I'm picking up are those pamphlets. I'm an atheist so the pamphlet is equivalent, at best, to a spam pull request.

> The request for a donation is the cultural expectation of reciprocity.

This is a completely different expectation that the open source expectation. I, personally, feel no guilt at all for telling people proselytizing to go away as I've done nothing to give them the expectation that their proselytizing would be welcome and most people proselytizing expect to be rejected constantly. Contributing back to open source is expected and usually desirable so the expectation that the contribution will be accepted.

Also, the monk is ASKING FOR A CONTRIBUTION not giving one.

Not OP, but here are the (non-license-based) problems I see with open contribution.

1. It limits tight design. PRs are often going to be for things that the user wants but that aren't on your design plan. Accepting these PRs causes design creep and leads to code complexity, even if each individual PR is written well.

2. It takes time to review PRs. People submit all sorts of code of various quality. Doing several rounds of reviews to get a PR up to snuff (or decide to reject it) takes time out of your day. If your team is small, this is a major cost.

3. It can set the wrong expectations. People get mad when their PR is rejected. Often really mad. Closing 50% of PRs, even for totally valid reasons, ends up with a nontrivial number of people sending you really terrible emails calling you nasty things.

Those make a lot of sense. Thank you!

I also want to point out that there's an emotional aspect to this.

Lots of open source is done as a passion project, and passion is a notoriously fickle beast. Things that inspire people to work on passion projects - a sense of ownership, velocity (no need for meetings and jira et al when it's just you. 100% efficient communication!), "shipping"/accomplishment, pride and respect - are all going to be really vulnerable to having to share headspace and ownership with someone else.

I'm personally feeling this. I have a project I'm working on for my homelab that I think other homelabbers, and maybe even some SMBs, will be interested. And I want to give back to the community / have no qualms about someone "stealing" my code. I have an AGPLv3 sticker on my laptop. But the main thing giving me pause is - "but what if people are like 'neat, now please do this feature next!'". Then I'm thinking about it and worrying about disappointing users. And plus, we know that "please do this feature next" is absolutely the *nicest* way that that request will ever be phrased on the internet.

I honestly would feel better if github had a way to let me say:

1. Here's the code, but please don't fork it (but leave the fork button functional. I don't want to actually stop anyone. I just want them to know what I won't be super thrilled.)

2. Please only open issues or PRs for small fixes. An extra if-statement, etc. Please don't add features or redesign anything or "fix my code" at a cosmetic or architecture level.

I know this sounds kinda whiny and entitled and anti-free-software, but I do think it's real and respectful from a human perspective. Locke said that anything you put effort into, you feel ownership of. And by that logic, if someone puts effort into something you currently own "100%" of, they're going to feel some sort of ownership too and you'll feel some part of loss of ownership.

> Please only open issues or PRs for small fixes. An extra if-statement, etc. Please don't add features or redesign anything or "fix my code" at a cosmetic or architecture level.

Another way of putting it might be to encourage them to describe the problem or other desired change rather than send code, and let you deal with it as you see fit.

For instance: instead of raising a PR to fix an open injection vector, raise an issue that says "when responding to X your code doesn't properly sanitise input Y meaning Z can happen".

> I know this sounds kinda whiny and entitled and anti-free-software

Not at all IMO. The word "free" covers many overlapping concepts, and your way of thinking about the freeness of your personal project is no less right than many others. You aren't stopping anyone doing what they want, you are just choosing to be selective about how you interact (which you are, or should be, free to do). Giving other people freedom to do things with your code does not mean you have to give up the freedom to do (or not do) what you want with it.

A long as you are up front and polite about it, there shouldn't be a problem. If anyone did have a problem with it, it is their problem not yours!

If I ever pull my finger out and make progress on my many possible personal projects to the point where there is something worth sharing, for the most part I'll probably take a very similar stance.

#2 is perfectly reasonable, but I don't understand #1 at all. You don't want to accept other people's changes, which is fine, but then you're also asserting a moral right to prevent them from making those changes on their own? It seems like open source is fundamentally not what you want.

I'm not though, they can still click it and have the right to. I won't deny them that freedom.

I just also want to express that I won't be thrilled about someone forking the project and trying to go their own direction with it or something. It'd be demotivating if someone thinks they can do your project better than you can, right?

> It'd be demotivating if someone thinks they can do your project better than you can, right?

This would be valid thinking though should the project go inactive.

> It'd be demotivating if someone thinks they can do your project better than you can, right?

If it is a labour of love, then maybe.

If you had plans to monetise then I expect it would be rather annoying too.

But if the project is at least partly "scratching an itch", to make something you want because it doesn't already exist in quite the form you want/need, then someone coming along and doing it better is great. Your itch is scratched and someone else is dealing with maintenance, so you can get on with your next plaything! And if you are counting life karma points, you can claim at least a few for having inspired the other person's/group's work.

Then why would you put the code in a public repo with an open source license?

I get what you are saying in 2), but anybody who wants to fork the code, let them have at it.

Don't want to contradict you, but here is how I feel as a drive-by PR-er:

1. Some projects have a list of goal and non-goals. Rejecting a PR because I didn't read the non-goals is perfectly fine and should be encouraged.

2. I agree. But can't this be solved by putting the "burden of PR" on the PR-er? A long checklist of "I have read this" and "I have tested this" should raise the PR bar high enough to make the code review cost worth it.

3. I understand that bad people are a problem on the Internet, but this feels orthogonal to the "no PR policy". Won't those people "do shit" anyway?

> can't this be solved by putting the "burden of PR" on the PR-er? A long checklist of "I have read this" and "I have tested this" should raise the PR bar high enough to make the code review cost worth it.

People definitely do not read those. The less useful their PR is, the less likely they are to have read any of the stuff in the template.

And, also, it doesn't matter that much if the submitter has done all manual test steps (if any) -- the maintainer mostly needs to verify everything him/herself anyway

I think there should totally be a commonly agreed philosophy of developers being able to say:

"Here's my hobby project, that I write for my own satisfaction. I'm happy for others to use it, and to license it under my choice of open source license. I am not though, going to feel obliged to change anything about my work on it in response to demands, requests, ideas, advice, or pull requests - or even acknowledge or read any of those. This repo will continue to be my hobby project to accomplish my goals in my timeframes for my personal amusement. If you find it useful? Great! If you want something different? I hope you make it yourself and maybe share it to, or at least find what you are looking for somewhere else, good luck."

There's a fundamental difference between "scratching your own itch" and "becoming a software project manager and community leader". I'd much rather people who only ever want to do the first of those, don't feel the need to keep all their code hidden out of fear of being pushed into the second of those.

Some in the music business are more candid:

The crux of the biscuit is: If it entertains you, fine. Enjoy it. If it doesn't, then blow it out your ass. I do it to amuse myself. If I like it, I release it. If somebody else likes it, that's a bonus.

-- Frank Zappa

Heh.

I wonder if Bandcamp or Soundcloud artists get driveby commenters saying things like "It needs more cowbell" or "Here, I recorded a string arrangement for the second chorus, please add it in and republish!"

No question, just want to say that I fully understand and support your choice. I run a tiny open source project and literally the first PR was just a terrible experience. A one liner that fixed a bug but introduced new issues. So we wrote our own fix and then got insulted to not use the original PR. Yes, being able to switch of external PRs would be a bliss.

Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no.

Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so.

The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead.

It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?

Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice.

I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.

> I like the tools and workflow that GitHub offers personally.

Worth a side note since you mentioned sqlite that Fossil was built to support the "open-source, not open-contribution" workflow. One of the leading criticisms of Fossil is that it's not designed to support the open contribution approach.

I think that most experienced open source maintainers would probably understand this approach, and it's definitely something I've considered making explicit rather than implicit.

I don't find rejecting people too difficult or mentally taxing, though, personally, so I haven't felt the need to reach for an explicit policy. I can point to this as an example, at least, if I ever do. I found your wording to be sufficiently explanatory. Good luck with the project.

If I had a feature I wanted to put in, I would just fork your project and add it, right? Then your project (presumably with out that feature) would be competing with mine, but each time you added another release I can just merge it into mine, but you won't do that?

If so, don't you see yourself getting outcompeteted by forks?

Your position is extremely reasonable and realistic. I commend you for stating it openly.

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 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?

Gitlab is a nice option

I've transitioned to gitlab for new projects about a month ago, and so far the experience has been great.

It might be me, but I don't see an option to disable Merge Requests in GitLab?

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-an... You can also disable the repository feature, and use the project for issue management only.

Heh, got it - I was looking under "Merge requests" :) Thanks both!

In your project "Settings" -> "General" -> "Visibility, Project features, permissions" -> "Merge Requests".

IIRC, you must be owner of the project.

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.

I think you mean sourcehut:

https://sr.ht

I hope so! If he really meant Sourceforge is alpha-quality after decades, I fear he'd forever be disappointed with the state of all software...

I hope so too, but mainly because sourceforge burned all reputation and trust for me, when they sneakily bundled adware to OSS installers.

lol, oops, yes, I did indeed mean sourcehut.

I like GitLab but it has to be the only product I've used that gives you a different form of navigation almost every time you visit the site.

Will it be at the top? Down the side? Tab based? Drop downs? Who knows!?

Meanwhile, Github's UI is so stable (outside of the super infrequent redesigns) you basically develop a muscle memory for it.

Gitlab is meant to be an alternative to entire suites of products from competitors so it makes sense. At work we make use of most of the features of gitlab so its a really great thing they include them all.

Honestly I'm not sure how you could even be confused by it as an individual developer either. I used it for my individual projects before getting a real development job and didn't have any issues. It different to github but not worse or less correct. Its just github has become the standard on what the default layout and names should be.

I mean, if you're an individual contributor who just sticks to making merge requests it's still more confusing than GitHub et al, but I'll grant that it's at least livable. If you have to touch literally any other part of it, or (in my case) are the person setting it up though it's just about impossible.

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.

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.

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.

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.

I guess this would probably solve the problem of you getting unsolicited contributions – by making you come off as such a gigantic raging arsehole that nobody would want to work with you again.

Perhaps? But if someone had that attitude, and couldn't be bothered to discuss design impacting changes with the devs who are making sweeping changes impacted by the contributor's change? In that case I don't want them on my project, because they are toxic, and probably toxic in other ways.

More people need to realize that Open Source projects are a gift from the authors to the software community. Other developers do not have the right to make changes, push for the development to go in a certain direction, etc. If an author wants that they'll turn stewardship over to a committee and maybe be part of such a committee. You have only two rights with Open Source work you want to work differently: fork it or forget about it (i.e., not use it). Anything else is a massive gift from the maintainer(s) and should be viewed as such.

And yeah, as you can tell from the last paragraph I'll proudly wear an Arsehole button to avoid wearing a Burnout button. Heck, to borrow from Bruce Lee in Snowcrash, I'd even wear a "12 Gauge" button to avoid burnout (button only though, the behavior is not for me).

That didn't work for Torvalds.

SourceForge is still around. I would suggest SourceHut over SourceForge these days though (not sure if SourceHut can turn off contributions).

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.

The flexibility is cool, but why would you want to fragment your bug trackers, for example, like that?

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.

So you can have a separate one for "internal" and "external" customers perhaps?

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.

Gotcha, that makes sense. Thanks!

SourceForge can do that too.

SourceForge is still around, but since they were caught adding adware/malware to downloads (2015, I think), I wouldn't trust them at all.

They've since changed ownership and the new owner seemed to put a lot of effort into cleaning it up.

I had the same feeling, but just the other day I found that a bunch of pretty critical stuff (the underpinnings of very popular NAS solutions like openmendiavault) is still rooted there. They also seem to have dialed down their "ADS ADS ADS!!!!!111!" strategy, probably as a result of that scandal and subsequent takeover.

I'm still pissed at Filezilla for jumping on that particular adware bandwagon though...

I'm not really sure I'd use either. I did attempt to host my own SourceHut but after joining their channel on Freenode and mentioning Kubernetes/containers twice (because I didn't get a response a day later.) I got a message saying, "We don't take too kindly to Kubernetes around here." which didn't come off very well. This wasn't the same as, "you're on your own."

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.

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.

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.

> It should be just the other way around

It should not be just the other way around

Asking the maintainer if you are allowed to provide a fix is an option?

Open pull requests are better than no pull requests. If the maintainers don't want them merged to their code base, other users can still merge them to their base.

The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected.

You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out.

The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.

rightfully -> understandibly

i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.

I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR.

I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.

No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is.

Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.

absolutely. im on the side of documenting and reiterating to get this across.

>> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected.

I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted.

Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration.

Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.

Putting in effort unfortunately doesn't mean creating positive value (https://en.wikipedia.org/wiki/The_Mythical_Man-Month).

The good thing with FOSS is that the effort isn't _wasted_ since that code is still around in a fork, if not in upstream.

Yes this. These days, I'm not gonna bother without communication directly from a maintainer that a PR to do whatever I'm interested in doing would be welcome and can be reviewed and merged in a decent timeframe.

This is the approach I want to take as well - but I give up so many times because I can’t track down a method of communicating with that person. I looked a while ago and I couldn’t find a way to send a message to a user on GitHub. Any recommendations on effective ways of reaching out to project owners?

It's usually fine to open an issue on the repo. It should have a detailed description of what's wrong, reproduction steps if appropriate etc, basically enough to show that you know what you're doing, have put some effort into it, and care about the project. Perhaps you'll get a response from a project maintainer, and can ask if they're open to a PR to fix it. IME, there's pretty good chances of positive engagement and eventual PR merge if you're fixing an actual bug in a good way, and not trying to add some massive new feature or completely change the way the thing works or something.

If it's excessively difficult to find a way to communicate with a project maintainer, well, maybe there's your sign that this is not a good project to contribute to.

> rightfully get angry

Why? You've taken the time to fix a problem you are having in code that you are using. You've made that patch available to the upstream maintainer, but if they don't accept it that doesn't stop you (or anyone else) from doing what you want to do with the code. I don't see how you're any worse off.

I contract for a lot of large enterprise, and I’ve written a lot of patches for open source projects in that capacity (to fix issues my large enterprise customers were having). My default position for this has always been that I’m going to get the benefit of fixing the problem regardless of whether my changes are merged. If the project maintainer chooses to merge my changes, then that’s even better, because that’s a tacit commitment from the project maintainer to maintain my changes into the future.

> a tacit commitment from the project maintainer to maintain my changes into the future

Sometimes. Depends on the norms of the project. Depends on the scope of the changes.

Of course. A lot of the time there’s not even a commitment that the project isn’t going to be entirely abandoned at some point in the future. But if you make your improvements available for other people to benefit from, you’re greatly increasing the chances that other people are also going to help maintain them (or maybe just devote some effort to avoid breaking them).

Pull requests are the best form of communication. Have you ever had a user propose a feature, agree to contribute it, and go dark? A pull request says "I did this work, I think you might want to use it". Even for repos that aren't accepting contributions, it's better to have pull requests so that users can fork and apply PRs themselves than not have anything. Even if the original organization isn't interested in open collaboration and just wants to code dump, the community can still fix their own bugs and if it becomes frequent enough a maintained fork might appear.

That's fair, but I think there should be another feature for this that lists out the forks and the change they bring.

Or at least there should be a clear way to indicate on a repo, PRs are not looked at and won't be merged. So if you make a PR you understand all you're doing is just advertising your fork.

> Asking the maintainer if you are allowed to provide a fix is an option?

It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.

Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.

The vocabulary already exists. For example, the lua project clearly states lua is free software but it is not open development, all development happens behind closed doors.

What if somebody sends you an email patch?

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.

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.

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.

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?

This GitHub article may be useful:

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

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.

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.

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...

Doesn't make sense they'd allow you to disable Issues but not PRs if they only cared about engagement

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.

Github allowing you to disable PRs would be a bit like Facebook allowing you to opt out of ad-tracking...

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.

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.

> 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)

> 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.

> 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.

> 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.

only somebody with a ridiculously thin skin...

People like that are very common and often very vocal.

Depends on how much work they put in, doesn't it?

Surely someone invested enough to submit a PR would have read the readme which explains they won’t accept a PR

Reading stories from open-source maintainers, I have 0 difficulty believing many would not.

I really wish that were true!

You are free to disbelieve the answer, but it still stands.

The other day I opened an issue on a project to mention that the project is not respecting some powerful convention (by dumping stuff when the user's configuration is to not dump stuff), and the project maintainer replied by saying that he doesn't care... that he thinks his choice is better.

I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.

Don't underestimate that "fork" button. If the software otherwise does what you want, but you need some particular change, fork away.

Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it.

It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.

> If the software otherwise does what you want, but you need some particular change, fork away.

You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated

Microsoft or Oracle will be glad to sell you something then. Geeze the babies around here.. not every project maintainer is going to agree with you as was apparently the crux of the original complaint. You don’t always get your way. And Apparently just having the ability to fork the source and do whatever the fuck you want is not enough for these pratts.

Obviously, one needs to be judicious with this.

It might not work with big projects but libraries and other smaller software is perfectly fine.

Presumably the project you mention is open source, so you've not lost your time – the time spent investigating the issue puts you in a better position to fork the project an implement the change to your specifications without involving the maintainer.

I don't understand the anger, are you angry because he doesn't have the same opinion as you and doesn't want to make the implementation behave according to your opinion?

it's.. not your project. if you disagree, fork away. your anger is on you.

> I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.

I guess the lesson is that there is always someone angry over something unreasonable.

Most projects should have a readme and most readme's on github should have a constributing section that everyone hopefully reads before creating a PR. Failing to do so tbh means that person probably failed to comply with coding standards or whatever else is in there. It's just as likely to have the PR closed for those reasons as for the reason "No PR's please".

That said, I agree with the idea of simply removing the possibility to make external PR's. The possibility to view (internal) PR's must be there though, so that external viewers can see PRs from the mainainer(s).

You can't enforce a readme. If it says "PRs are not accepted", and you create a pull request template that says "please be aware your PR will get closed automatically", folks will still file PRs in the hopes that their work is special enough to consider, and they still get their hopes crushed when that their PR gets closed without ever having been looked at.

If someone either willfully or through purposeful negligence both doesn’t read a README or PR template that outline PRs aren’t welcome and submits a PR hoping against hope for a different outcome, I think we can assume that absolutely nothing will prevent them from having their hopes crushed.

I don’t think optimizing for that edge case makes a ton of sense. Having the ability to hide PRs might be a nice feature, but some people use that for stuff other than straight pull requests.

Then maybe those folks should get a better feature for that, too. More than one thing can be suboptimal about the same feature-as-implemented.

Totally valid, and I'm not opposed to an option to turn it off, I was just saying I can understand why some people might need to keep it on, even if they do have a README and PR template that makes it clear they don't accept PRs. I just think the "crushing the hopes of people that don't read" aspect is probably the lowest priority in that sort of situation.

That's not the only thing.

A few of those who didn't read the README, and get their PRs auto closed, might get upset at the maintainers, and write something a bit angry, making it less pleasant to be a maintainer.

It's not just about that, though. I want to avoid crushing people's hopes, yes, but in the event that they are absolutely set on submitting a PR, I don't want to have to deal with getting a notification and having to manually close it. (And no, I don't want to take the time to set up a bot to do it either. I have better things to do with my time.)

I mean, I get that, and I'm not opposed to having a method to turn off PRs. I'm just saying that if the impetus is avoiding crushing people's hopes because a README and template isn't clear enough, I think there are people that will still create an issue or send an email about why they can't submit a PR.

Enforcing the readme is simply closing/ignoring the PR's.

You can easily do that, but what you can't do is prevent people from being angry. You can do everything in your power to prevent people from accidentally wasting their time, and you should. This is where "hide the feature" would come in.

If there is one constant on the internet, it's that people don't read. You can say whatever you like, there will be tons of people who brush past it and just go and send PRs anyway.

Then let them learn their lesson. The thing is I have done stupid shit due to carelessness, but I’m not so entitled to blame it on someone else. If a potential source code contributor cannot read the contributing guidelines AT ALL that is on them, lesson learned. Really fuck em if they’re gonna stay butt hurt about it.. this should have been cleared up in kindergarten.

Some of them might get upset at the maintainers tough, and write something a bit angry, making it less pleasant to be a maintainer

> Really fuck em if they’re gonna stay butt hurt about it.. this should have been cleared up in kindergarten.

Such an attitude from a maintainer can piss people of and make them write angry things to the maintainer, causing him/her to quit.

Why not just leave them open for some other people who might find them useful, but never accepting them?

Ten year later someone will post it here, as a proof that the maintainer of the project is not doing his/her "job".

Also, I remember a case where after some time someone decided that since the maintainer was not answering, it was fine to add insults and threats.

Surely having a disabled or hidden pull request button is also very solid proof that the maintainer is not accepting pull requests.

> Am I missing anything?

In order to keep the IP for a project pristine (for the sake of downstream users), I would prefer never to see somebody else's copyrighted solution to a problem. If I see their contribution but I don't want to accept it, I'm forced to come up with a new creative solution that a court would (maybe, hopefully) consider original.

This is especially important for CC0/public-domain projects, where many contributors will not fully understand the implications of contributing and may not be in a position to release code into the public domain.

> I would prefer never to see somebody else's copyrighted solution to an issue

You are doomed, then. They can always sent a (unrequested) email to you, Cc'd to a public mailing list. The PR interface is just another equivalent way for people to send messages to you, like email.

Somebody's really going to have to go out of their way to email a patch — they might even read the `CONTRIBUTING` document which says "Thanks but no!".

The Github Pull Request interface is an attractive nuisance, like an unfenced swimming pool. You can't keep people out with warning signs, they won't read them. Put up a fence, though, and even the obtuse will get discouraged.

> Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut.

That is an interesting observation. Can you elaborate on what you mean? Thanks!

Read https://blog.brixit.nl/git-email-flow-versus-github-flow/ and lots of articles by ddevault/sircmpwn about git-send-email on various discussion boards including HN.

> * 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?*

I don't want to have to set up an auto-close bot when I should be able to just untick a checkbox in the project's settings.

I don't want to have to click through PR notifications and manually close them when I should be able to just untick a checkbox in the project's settings.

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.

The problem with archive is that it looks like "not maintained anymore"/"deprecated", which is not the case here.

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).

Amazon CodeCommit works great for me.

Like all of AWS, the pricing seems opaque and without hard limits:

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.

> 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)

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.

You want other people to do work for you, for free. That's completely understandable.

>> 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.

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.

I'm sorry I simply cannot understand how you can read the entirety of my comment and see that as entitled and wanting something for free.

I could fork a project and make the fix in my own repo. In fact you have to do that to make a pull request. I even specifically lay out scenarios where I absolutely agree it's not a good return on time invested for the maintainers to bother. But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. My point is that even though I fully understand and support where the litestream policy is coming from, for anything beyond a personal project I think some flexibility in accepting outside contributions is a win for everyone. I'll do all the work I can without having rights on the project. I'll sign over all my rights. Have tests? I'll run them and post the results. But a rigid "love it or fork it" attitude is a lose-lose.

> But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone.

Who is 'everyone'? Does that include the maintainer? If so, why is it worse for them?

> a rigid "love it or fork it" attitude is a lose-lose.

How so? Who exactly is losing, and what exactly are they losing?

"Everyone" includes other users who would benefit from the fix, the PR author who can continue using the same version as everyone else, and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch. As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts.

edit: And to be clear, I freely acknowledge the inverse in my original comment. As TFA explains they were seeing a lot of PRs with unintended side-effects that were complex and counter-intuitive. At no point have I said people MUST accept this as part of the terms of a copyleft license as the original replier seems to think. I used phrases like "I do wish" and "I'd so much rather" and "They don't have to", so obviously it's preference I have. But that's my preference as not only a user of open-source software, but as a committer / PMC member on multiple Apache projects and other open-source projects. It's not remotely coming from a position of entitlement for free-as-in-beer software or ignorance of what it takes to develop and maintain open-source software.

> "Everyone" includes other users who would benefit from the fix,

They can still benefit from it by getting the fixed version from the PR author.

> the PR author who can continue using the same version as everyone else,

In other words, the PR author is expecting the maintainer to do the work of upstreaming and supporting their (the PR author's) fix for free.

> and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch.

And that is their prerogative. If they actually really want that fix they can always get it later. But as said by OP, chances are really good that the way the fix was done would conflict with the direction they want to take the project. And that would actually be a net loss for the maintainer.

> As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts.

This basically boils down to, expecting an open source maintainer to do the work--for free--of maintaining other people's patches in a patchwork codebase that they no longer have total control over.

> The parent wants the project to do that so that s/he does not have to fork it him/herself.

That doesn't make a lot of sense. To create a pull request, one must have already done the work to fork the repo themselves. The pull request is an offer to contribute that work back. If the project owners cannot or do not wish to do the work to even triage pull requests, that's fine, but in that case it's pretty clear that a public GitHub repo is the wrong place to be.

Hosting it in public at least gives others the opportunity to fork it if they have a change they want to see happen. But even reading PRs is work that maintainers shouldn’t be forced into, so GitHub should just allow the PR feature to be turned off.

> Even if I have to sign over all my rights of the code

Even if people sign over the rights, there can still be admin to prove that they have those rights to sign over in the first place, or the responsibility for any fall-out if it turns out they didn't later, which some will not want to take on.

Also, some projects are personal and while the authors are perfectly happy to share they want to keep their version theirs, as in entirely created by them. People release their code open source for a variety of reasons, sometimes contributions back in that manner are not actually desired and we shouldn't take offence at that (it isn't intended to raise offence).

> ought to be made very clear in README.md or CONTRIBUTING.md or something too

This is a large part of the answer, I'd agree with you there.

The default assumption on github, and more generally, is that contributions are likely to be welcome and in fact actively desired. Politely explaining that this isn't the case in obvious places removes the confusion (and if someone hasn't read the usual places before submitting the PR that is their mistake not something to blame the project owner for). A sentence or two of text, as seen in the example that started this thread, in the README or similar documentation, should be sufficient. Perhaps also add it to the LICENSE file if you think that is more likely to be checked than someone reading the whole of the README (though if the readme is long enough for that to be a significant issue, perhaps look to streamline it and move some detail off to supplementary files).

> 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.

I think you're missing an important point here: the right to fork is the primary point of Open Source. Sure, it's nice if you don't have to fork, but ultimately the reason Open Source is important is so that you can fork if you have to. The other parts, about projects being able to accept contributions from others and so on, are nice to haves, but not essential. The right to fork is what is essential, so that when a project has a bug, and the project owners aren't fixing it, which is expected to be the most common case (see below for why), you, as an individual, can at least fix the bug for yourself, instead of being stuck with a proprietary system with a bug you can't fix at all.

Why is it expected to be the most common case that the project owners won't fix the bug? Because the tradeoff between benefit and cost from the project's point of view is very different than it is from yours. For you, it's much easier, as you say, for the upstream project to accept your PR than for you to have to maintain your own fork. But from the project's point of view, it's much harder to accept your PR than to just ignore it. Sure, you might be convinced that you've fixed an important bug and your code will be a net gain to the project. But how do they know that? To them, you're just some random person on the Internet. It's not like they have people sitting around just waiting for random people on the Internet to make contributions. Any time spent on evaluating your code is time not spent on something the project has already committed to doing. And if they aren't feeling any pain from the bug themselves (which they won't be if you, a random person on the Internet, have had the time to see it and code a fix for yourself), fixing it won't be on the list of things they are already committed to doing.

This is all true, I just wish that commits to my forks of dead/strict projects showed up on my activity graph. I’m strangely proud of that thing and half my work doesn’t end up on it because things are no longer maintained upstream. :/

Does this not serve the purpose?

Repo -> Settings -> Moderation Settings -> Limit to repository collaborators

"Disable pull requests while keeping issues"

This cannot be enabled permanently. Max duration is 6 months.

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...

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.

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.

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-communit...

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:$br...

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.

It's a widely-known practice for companies to internally fork and vendor software they use.

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.

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.

To be fair, MS only bought GitHub after it became very popular.

> 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

> 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.

I guess you can add a PR template that says "PLEASE DON'T SEND ME PRS"

There is https://sr.ht/

"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.

Ya Github just needs a way to disable everyone to create issues and/or PRs.

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

> 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.

And sometime these most vocal participants are all talk and no code.

> 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.)

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.

No, because if a contributor is legally not entitled to agree to the CLA and does anyway, it’s now your problem.

Nemo dat quod non habet, nobody gives what they don’t have.

I never understood the legal issues there. Contributor License Agreements exist to solve that very problem. Want to make all contributions that are merged back into the project count as your own? No problem, simply put it in a CLA and make all PR authors sign it. If you get a takedown notice because the author of the PR actually included code they didn't write? You have a binding agreement from them, claiming that they had the right to sign over the code. You remove the code and move on with your life while they get prosecuted directly. It's like buying something at a pawn shop that turns out to have been stolen - you aren't responsible and if they did everything right, neither is the pawn shop.

We have a contract downstream where we provide turnkey delivery of software that uses the project as a base. The contract say we must own all the software delivered and we're liable for it.

We don't want to be liable for code not written in-house.

Fair enough, I can definitely see how reviewing contributed code to the required level of scrutiny would probably take at least as long, probably longer, as writing it in-house.

I would add that is not only code contributor did not write.

It might be that contributor does not understand his legal obligations to his current employer and I think probably no one is going to attach note from their company that they are allowed to contribute to the project.

In the end paw shop is responsible if they are buying stolen goods, signing a paper is not a "get out of the jail free card" because a thief would sign on anything anyway just to sell stuff. Even if you get the paper that contribution is legal there is still a chance of legal trouble.

The code could be copied from elsewhere, owned by the contributor’s employer, found to be an asset not eligible to be unilaterally signed away in a divorce proceeding, or any number of circumstances in which the contributor is not legally entitled to agree to the CLA. And now you can be sued for damages.

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/

[2] https://github.com/franciscop/picnic/pull/203/files

[3] https://github.com/franciscop/picnic/pull/202

> 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.

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)

Yes they have said this is the aim.

Here's a thought that could potentially have bad consequences but is there a TOS for people commenting on issues on github? Can people be banned for repeated offenses?

GitHub encourages projects to add codes of conduct, the most popular of which are very much open to interpretation. So I guess you could just claim any given issue comment was a CoC violation.

You want to ban people from github for asking low-quality questions? Who is going to determine when a user's questions are low-quality enough?

> 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.

I would contend that Stack Overflow hasn't solved it. The "close poor questions" and "why are there so many people who don't search first?"

As users felt that their questions weren't answered as promptly enough on SO or that closing their questions was equivalent to gatekeeping. This lead many of the people frustrated with not getting support type questions answered on Stack Overflow to go to other places to ask those support type questions. As the tooling around GitHub issues as support has been poor (and the number of people asking questions far outstrips the number of people offering support), this is leading to burnout.

This is very much a "push it over there" problem. There's been a good bit of history of companies and libraries trying to make Stack Overflow their support site ( https://meta.stackoverflow.com/search?q=reach+out+is%3Aq )

> 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.

Absolutely - though that only delays the problem until the entitled developers overwhelm that tooling.

I sometimes fantasize about disabling Issues for one of my more popular GitHub repos, but since I also have a disturbing number of users who find my email from early git logs and send me emails like "why didn't you respond to me on github", I keep them open in the hopes that it prevents more people from doing the same.

That being said, I'd pay good money to never have to see another person submit another "bug" report where they remove all contents from the bug template I created and just write "why doesn't X do Y. plz fix" followed by an "any updates?" comment <24 hours later.

I wouldn't say the whole thing has necessarily led to burnout, since I still enjoy working on the project, but it has led to me never logging into GitHub and turning off all notifications.

> That being said, I'd pay good money to never have to see another person submit another "bug" report where they remove all contents from the bug template I created and just write "why doesn't X do Y. plz fix" followed by an "any updates?" comment <24 hours later.

There are GitHub bots for that. The one I’ve seen (I forget the name) comments afterwards if the template isn’t followed. Perhaps it even allows you to directly close and lock the issue in those situations.

Alternatively, if you’d truly “pay good money” it shouldn’t be hard to find someone to do it for you, reviewing issues and pinging you on the actionable ones. I’d enjoy that work; I like keeping repositories clean.

GitHub allows you to customize what kind of issues your project accepts [1]. Did you ever try setting up an issue template for bugs only? I'm considering doing that for my own project and I hope it will be effective.

[1] https://github.com/github/hub/issues/new/choose

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...

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.

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,...

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.

>There are countless web frontends[^1] to expose a git tree on the internet,

I didn't study your cited list extensively but it looks like a list of tools instead of free repo hosting. E.g. Gitweb and WebGitNet are not analogous to "github.com".

Most devs are not interested in self-hosting a git repo so looking at a list of web frontends for git isn't solving the problem.

>, without the community/social aspect of github.

There are at least 3 categories of social interactions on github:

+ Issues

- PRs

+ Discussions

... and for the repo of this particular thread, the developer is still using +Issues and +Discussions. He just wants to opt out of PRs for the reasons stated in README.md.

> Most devs are not interested in self-hosting a git repo

I mean, the _old_ way of sharing source code was to upload it to an FTP mirror, and then once the Internet got "modern," a personal website. GitHub is not the only way to get a project on the Internet, it's just the most popular way at the moment.

The _old_ way costs money :) which actually limited the FOSS community to people who can either afford hosting or have access to some kind of free hosting through their job/school.

The fact GitHub itself has become one of the easiest ways to setup a personal website says a lot about the availability of good, free, managed static hosting without ads.

Github is free, easy to use, and reliable. Lots of developers use it for private repositories, which obviously don't benefit from community contributions. It's easier than setting up your own server.

Putting the code on Github also makes the project easier to discover and makes the source code easy to navigate.

Finally, note that the author of this post still welcomes bug reports and feature requests.

Talking about the PR tab, that page is hella unreliable lately. It hides being unreliable by putting some page load progress bar on top of the page. That progress stalls at 95%. Then you need to click again to retry. On bad days it breaks >50% of the time.

Seriously, that progress bar is hiding the read problem here: some timeout of a 50X error or something. We --GH users-- are devs! We know that your hiding this, it's not very respectful I think.

Oh, and, we pay for GH.

Perhaps you wish to have both your collaborative and your presentational works on the same (in this case near de facto) hosting provider.

I'm reminded a little bit of an experience I once had trying to give away a graphing calculator I didn't need anymore.

I posted it on Freecycle, and found someone who was interested within a day or so. But, in communicating with them, it turned out they didn't just want a free calculator. They wanted me to drive an hour out of town to drop it off at their house, and to spend time teaching them how to use it, and to share my phone number so that they could call me if they had any questions. And, when I tried to set some boundaries and say, "Look, I'm just giving away a calculator, that is all," they started getting abusive.

When I put stuff up on GitHub, it's like that. I'm just trying to share some code. I'm really not interested in doing much beyond that, and I'm definitely not interested in people assuming that, just because I've decided to share some code, I'm also giving away product and project management services, or training, or anything like that.

I'm constantly amazed by the examples on /r/choosingbeggars. We need to be careful during sweeping conclusions from it due to selection bias, but the number of people giving things away who have clearly learned to put "I will not deliver it to you" etc. on their posts does paint a picture.

If you look at giving away stuff as a transaction, it might make more sense.

You get to feel better about not creating waste and helping someone else -- if that was worth nothing to you, you'd throw it away. They get a calculator at the expense of having to deal with a human, coordinate details and potentially troubleshoot a device that may not be in perfect condition. In that sense you've reached a market price for the transaction. The person on the other end is just trying to negotiate a better deal for themselves after you thought the agreement was already done. Being aggressive can be very effective because avoiding conflict is also pretty valuable for a lot of people.

The fundamental issue seems twofold:

1) that a more fragmented society results in more transactional thinking versus feeling like we're all on the same team.

2) we're in an increasingly disposable society where the cost of second hand goods can be higher than new items, depending on how valuable your time is (again, if the calculator malfunctioned they might spend a few hours troubleshooting at greater opportunity cost than the price of a new one).

I think there are good and bad aspects to an economically focused transactional society, but there’s also a lot of evidence we are getting less transactional over time. Similar for disposability, where everyone is becoming painfully aware of externalities due to climate change.

“Economic man” was a 19th century concept, where philosophers dreamt of a society where everything was broken into transactions and property. This is still the dream of some libertarians, and is one of the delusions that made the US so economically successful for so long in spite of its social and environmental costs.

However, we are an increasingly interconnected world, isolated disposable transactions certainly still happen at scale, but I see a lot of evidence this is being curtailed.

An interesting observation: most successful enterprise software companies have a large portion of their sales as “not” transactional, and these tend to have the highest repeatable revenue streams.

Consumers are also incredibly studying how the organization would use a contribution. Who they politically donate to, etc. Vs, just letting price and features dictate a purchase decision.

I don't really buy that hypothesis.

Evidence: I ultimately did get rid of the calculator, by selling it for $1. It's the same trick that many of my acquaintances have set on. Any transfer of cash at all seems to eliminate this kind of behavior.

If it were really just about rational economic agents trying to negotiate a better deal, then you would expect the opposite. The person, having now given money in exchange for the item, would expect to get even more in return.

It honestly doesn't sound like that is the wrong strategy. Selling something far below its value is still a form of indirect charity. That calculator probably could have fetched a little more. Maybe $20.

I would put my stuff in github too even though I'm skipping the social feature because it is simple and familiar and it is legal to do so

> There are countless web frontends[^1] to expose a git tree on the internet, without the community/social aspect of github.

Github provides a number of things:

Git hosting Collaboration with your team Community collaboration CI Issue tracking

It is reasonable to still want most of these and not want one.

(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.

On that list, there are projects like https://github.com/Hypercubed/git2html . It makes a set of static files, which could be uploaded to any static hosting provider, including github pages.

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.

It’s not about a lack of other options. It’s about discoverability of your work, and authority.

Github does a great job of indexing your content on Google.

Also, the fact that the code is hosted on Github is, for me personally, a good indication that the code is probably valid. I have never, so far, pulled a package which source code was not on Github.

> It’s about discoverability of your work, and authority.

The discoverability I admit. Authority is debatable.

> Github does a great job of indexing your content on Google.

Really? Every single time I compare search inside github vs outside (google, ddg, anything), the difference is massive towards more and better results from github itself.

I’m not talking about the search inside Github, but indexing your work on the search engines. All my code, through a search on Google, appears on the top results, thanks to the fact that Github has great metadata around my code to let the search engines eat them.

1. You migh thave N projects where a few want contributions and a few don't. You don't want several sites to manage them.

2. The code part of github (a git tree on a webpage) isn't even the key functionality. It's PR's, CI. You may accept feature requests and bug requests but still not want PR's.

3. Having collaborative development with a small team of e.g. 2 people means internal pull requests, reviews, discussions etc are important (and could still be useful to see or contribute to by external users), so taking away PR's isn't the same as going under ground with the project.

4. GitHub is a well known site, people will find your project there.

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.

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.

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.

> 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.

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.

Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again.

The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself.

If you'd like a version of the project that takes pull requests, then you can always create a fork that accepts pull requests and comments. This puts the burden go testing, merging and quality control on you, but most of the work you'll be doing is what you're expecting the developers of a product to do for you anyway. If your energy pays off and your fork has less bugs, more features and becomes more popular, the original developers may turn around and cooperate with you instead.

> Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again.

OK, so your argument here is that maintainer doesn't want to create CI checks because it takes time and he knows the code style and doesn't need those.

> The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself.

But why close yourself to others? It is like throwing mic, or as if you would mark this thread as closed and no one would be allowed to comment - antisocial behavior.

You don't need to merge PRs, but come one, if you are a sole maintainer of a project, this project is not that big, and you for sure aren't getting that many PRs.

And also, one could consider PRs because you could find another person that understands your project goals and would be your co-maintainer.

Why such strange attitude here on HN? I found this place as very open and what I see in this thread praising of close-minded people.

Most projects seek contributors not alienate them.

For me it is open-closed principle I am open to hearing people but I am closed to including their work into mine unless I feel like it. Notice that it is "mine" work not theirs.

Whole discussion here is about toxic behavior of people whose PR's are closed. It is not about closing yourself to contributions, idea is that everyone can still make a feature requests. One can still propose changes but there should be less pressure on integrating piece of code on maintainer, option to remove PR's on repo would do that.

I see why GH would not consider option to disable PR's because it is a killer feature of GH and it would be bad for their marketing when a lot of repositories would become 'read-only'.

Yeah, having that feature would prevent a lot of misunderstandings. I’m absolutely open to that (also so I don’t waste time creating PR’s).

Reviewing and testing multiple PRs is an enormous amount of work for anything but the most simple one liner changes.

To be fair, simple one-liner changes can be just as impactful as an entire package rewrite. I've reviewed a few one-liners that seemed innocent at the time, but had massive impact downstream.

As the project and the userbase grows, small conditional changes can be the most difficult to test because they require a very specific setup to test and verify.

Often times the only person that can reproduce the issue is the person submitting the PR.

Code is never free. Code that exists in a project continuously costs energy in maintenance. This is why deleting code is valuable.

PR is not always about adding code.

If the argument is "well, the PR comes with free code so you should be thankful" then a PR that deletes code or whatever isn't super relevant.

OK, for me code = diff, it can add lines and it can remove lines.

My point is that one shouldn't be close minded on others. Disalowwing PRs is just like closing your ears because you don't want to hear the other person arguments - IRL you avoid such peoples, in virtual one you should avoid them too.

Why is this an unacceptable choice? Yes, accepting PRs from the broader community and spending time on them has a good chance of making the product superior over time. But just like how it is probably good for me to understand the impact of my purchasing choices on the environment, I can't listen to it all the time. I don't think it is unreasonable to say "in this context, I do not have the bandwidth to manage unsolicited advice from others". That isn't "being close minded". It isn't saying that nobody else has good ideas. It is saying that you are busy right now.

> If you close those, you are basically closed-source with an option to peak at the code.

Oh no. Closed-source with an option to peak the code does exist.

This is not it. Because it is licensed GPL. Which means you have the option to copy the code into your own project. In whole, or just looking at particular parts that are useful. You have the option to fork it and do whatever you want to it.

If you got some people together that thought "gee, we like this, but we wish it took PR requests", you are legally allowed to copy the code into a different project (ie fork it) that takes PR requests, and become the maintainers of that project.

This is *HUGE*. You can't do that with closed source even if they let you see the code. There is a very big difference between "closed source that lets you see the code" (which does exist, but this isn't it) and "open source". And it's not whether they take PR's -- closed source can take PR's too. The a proprietary company will let you volunteer your time to submit improvements to their code does not make it open source. It's about who (if anyone) controls the code and can decide who is allowed to use it or not, not just see it.It's about the license.

It is important that we as developers and decision-makers about what code to use understand this difference.

If paying the reviewer for an hour or two of work would get them to look at and merge the PR right away, that’s absolutely something I would consider.

Not to mention that my company would likely pay it, not me.

I see this as more of a branding choice than a "contribution limiting" choice. It's rather impossible to truly prevent contributions in FOSS (someone can always just make a fork).

Instead, this seems to me as a kind of branding where the maintainers are saying that for the upstream they would like to dictate the style the code is developed with including how/if "bugs" are fixed. This seems reasonable to me. Even the best style guides can't convey styles of ideas about code structure, so having this branding of "Upstream is written according to my thought processes that I can't put into words" seems like a pretty reasonable approach for projects maintained by individuals or small teams.

Also, in this case the dev is still open to bug reports/feature requests. The only thing they're asking for is to not have their style of thought be disturbed.

The other option you didn't mention is forking. It's got a GPL license, you can fork if you want. Like a public fork you encourage others to submit PR's to also.

Yeah, that's a lot of work. That's exactly the point.

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.

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.

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.

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

Fair enough for me.

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.”

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. :)

Do you mean MIT?

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,

(https://opensource.org/licenses/MIT)

Similar language is also in basically every other license.

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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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-communit...

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.

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.

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.

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.

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

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.

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.

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?

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

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

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. "

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

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)

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.

> 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?

Well then why are they obligated to create a test suite?

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.

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.

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.

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.

In my case, I've never allowed contributions to the current iteration (which has a completely new code base), so that question doesn't apply.

For others, though... I don't see a reason why forking a project would be a bad thing. Yes, it fragments the community, but it also means different ideas can be tested and implemented by the people that care about them.

There aren't enough competent people around, and even fewer who prefer the same workflow as the original author.

What really happens if you open up the code base: Mediocre people who want something for their resume flock to it, work on unimportant issues, add bloat, CoCs and generally make your life hell.

I believe that is anti-community in spirit and non-conductive to solving the issue you claim exists. Many developers breath of knowledge extends only to that they have experience with personally. Maybe they joined the project because they want to learn something which you can only do by diving in, making mistakes, and learning as you gain experience. How many developers that could evolve into great developers have been stunted because someone denied them the opportunity to become competent? Once you open something up to contributors, it becomes everyone's responsibility to learn how to work together effectively and productively and changes should be discussed and adopted based on what is best for everyone. I am certain it would be possible to establish mentorship and technical review committees that can both ensure the quality of the end product and encourage growth in the particular specialty area the project addresses.

I think your reply makes he same mistakes as some popular ideologies in the last century. They look good on paper, but fail to acknowledge reality and human nature.

If you think mentorship and technical review committees can solve anything: They cannot. People who are warming the chairs in those committees never do any actual work on the issue trackers and try to bully the real workers.

> I believe that is anti-community in spirit and non-conductive to solving the issue you claim exists.

You presumably haven't encountered this issue with your own open-source projects, but that doesn't mean the problem doesn't exist.

> How many developers that could evolve into great developers have been stunted because someone denied them the opportunity to become competent?

Nobody is denying anyone. The code is there to read as an example. If an aspiring developer hasn't got the initiative to develop at least a basic level of competence on their own, that's their problem. What happened to self-reliance?

> spirit of open-source

> whole point of open-sourcing code

I don't think there is a single "spirit" or that open source in any way must necessarily include any collaboration at all. Perhaps a maintainer/project owner feels the work of even approaching other maintainers or delegating even a single unit of work to be unwanted. It's their choice. Putting code on github isn't an automatic invitation for contribution or collaboration, it's merely making it public. Top reasons I put code on github (I can't know, but I think this is pretty common):

1) To make it searchable and readable by others 2) To use the issue management tools (usually by myself, as TODOs) 3) To make what's built from the code usable by others who can build it themselves or download binaries. 4) To back up the code 5) To use CI tools 6) To get feedback like bug reports from users 7) As a portfolio

> 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?

That requires people the original maintainer can trust. They have to be competent enough, honest enough, easy enough to work with, and the maintainer has to know that.

Moreover, many project shouldn't grow big to begin with. Sometimes much of their value comes from their small size: they're easier to learn, easier to deploy, easier to port, and most of all easier to maintain.

> 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 ).

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.

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.

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.

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.

Does that really happen that often? Best practice is you only add more tests and don't touch existing tests unless absolutely necessary.

Any change that involves a refactor is going to end up modifying the tests. The higher your test coverage, the more the test suite churns.

This is a good _start_ but nowhere near being sufficient for reducing workload of reviewing PRs.

If a patch is a bugfix then clearly none of the past tests caught the bug <_<... If the patch is a new feature then it will certainly need new tests to validate its own behavior is correct...

If a patch is a bugfix, it should include a test that fails before the patch, but passes after the patch (along with all of the other tests).

Yes, the idea is that the effort isn't really eliminated. It's just shifted from reviewing the code to reviewing the new tests, which sometimes can be just as hard as reviewing the code when complex bugs are involved.

I’ve used this in the past and its great. Most PRs change something that requires new tests to be written, so I have a rule that any PRs must add unit tests verifying the new behaviour. If your feature really matters to you then it also matters that it’s correct. I don’t want to spend my time triaging bugs in a feature I didn’t write and don’t use.

For some reason this rule weeds out about 80% of contributions - including almost all low quality PRs. It’s delightful.

I have an anecdote contributing to a testing framework (of all things) that had similar policies. Turns out it's pretty hard to write tests making sure something asynchronously executed never happens sans introducing (flaky) "timeout"-based tests.

At some point the maintainers were like, "yeah, this draft PR looks like it's doing the right thing so let's just merge it without a working behavior test"

Yeah I make exceptions too when the PR is something I personally care about. (Or I sometimes help out writing tests when someone finds a high priority bug they struggle to reproduce). But I think its a good baseline expectation. Keeping code bug-free is difficult work.

What if the bug fix is right and the tests are wrong?

It's easier to spot bugs in tests.

It can be hard to get TDD/BDD to cover enough of the aspects of a code-base (depending on what the code is doing). SQLite is special particularly in just how comprehensive their test suite. In particular, note that SQLite's full test suites is very much their secret sauce (and is not open-source). You can get a sense of the amount of effort it takes the create and maintain that type of test suite for something like SQLite.

Reply on news.ycombinator.com