[HN Gopher] Open-source, not open-contribution
___________________________________________________________________
Open-source, not open-contribution
Author : farslan
Score : 558 points
Date : 2021-01-28 10:18 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| amzans wrote:
| I open sourced my previous SaaS a few years back, naively
| assuming I could fully support it myself on top of everything
| else I was doing.
|
| Long story short, I burned out, the SaaS failed, and here I am
| giving another try but without open sourcing the project.
|
| I now have great appreciation for the projects that managed to
| get it right. But in my case, I realized that nothing makes
| people disappear faster from a GitHub thread than asking them if
| they want to contribute the code changes themselves.
|
| I actually wrote about this experience in case someone finds it
| interesting:
|
| https://panelbear.com/blog/why-not-open-source/
| franciscop wrote:
| 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
| lol768 wrote:
| > 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.
| justincormack wrote:
| Yes they have said this is the aim.
| franciscop wrote:
| 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)
| hgs3 wrote:
| 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
| shagie wrote:
| > 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.
| dilDDoS wrote:
| 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.
| noobermin wrote:
| 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?
| lmm wrote:
| 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.
| jrochkind1 wrote:
| 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?
| Tepix wrote:
| The README states:
|
| > _I 've made the decision to keep this project closed to
| contributions for ... long term viability of the project._
|
| Here's hoping he will open it up if he stops maintaining it (or
| slightly earlier)
| mkj wrote:
| 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.
| jitendrac wrote:
| 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. "
| benbjohnson wrote:
| Hi, Litestream author here. I'm happy to answer any questions
| about the policy or the project itself. I was apprehensive about
| adding the closed-contribution policy but I've seen
| overwhelmingly positive support for it since I released.
|
| Some commenters have noted that I could use another free code
| hosting platform. That's a valid criticism. However, I like the
| tools and workflow that GitHub offers personally. The GitHub
| Discussions feature in particular has been a nice step toward
| improving communication. GitHub Actions have been really nice for
| a CI workflow too.
| __henil wrote:
| 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)
| UncleMeat wrote:
| 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.
| cashewchoo wrote:
| 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.
| orangecat wrote:
| #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.
| cashewchoo wrote:
| 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?
| dspillett wrote:
| _> 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.
| anticristi wrote:
| 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?
| __henil wrote:
| Those make a lot of sense. Thank you!
| jhare wrote:
| Efforts from non-experts would likely hamper a complicated
| project like a database. Even though the hypothetical denied
| efforts being earnest well-meant efforts, I can't suggest a
| riff to bands I like.
| benbjohnson wrote:
| 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.
| imtringued wrote:
| 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.
| benbjohnson wrote:
| Yes, that'd be a good option and something I would
| consider if the workload increases to an unmaintainable
| level.
| jancsika wrote:
| 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.
| __henil wrote:
| 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.
| ahelwer wrote:
| 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.
| afarrell wrote:
| 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?
| Igelau wrote:
| 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.
| imtringued wrote:
| 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
| afarrell wrote:
| Even if the monk wasn't doing that, I'd be annoyed.
| jansan wrote:
| 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.
| hk__2 wrote:
| 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?
| webmobdev wrote:
| > _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 ).
| icegreentea2 wrote:
| 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.
| Aeolun wrote:
| 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.
| auggierose wrote:
| What if the bug fix is right and the tests are wrong?
| swiftcoder wrote:
| You also have to reject any PR that _modifies_ the tests.
| Otherwise the maintainer now has to validate test suite
| integrity any time they accept a PR.
| hoseja wrote:
| 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.
| jabbany wrote:
| 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...
| cbm-vic-20 wrote:
| 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).
| jabbany wrote:
| 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.
| josephg wrote:
| 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.
| jabbany wrote:
| 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"
| josephg wrote:
| 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.
| GizmoSwan wrote:
| 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.
| davidjgraph wrote:
| 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
| j1elo wrote:
| > 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.
| drej wrote:
| > Note: We cannot accept non-trivial PRs for legal reasons. We
| need to retain copyright over the entire codebase.
|
| Does a CLA solve this? (Genuine question, I don't know.)
| MayeulC wrote:
| 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.
| franga2000 wrote:
| 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.
| ozim wrote:
| 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.
| davidjgraph wrote:
| 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.
| franga2000 wrote:
| 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.
| notacoward wrote:
| 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.
| mannykannot wrote:
| 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.
| bityard wrote:
| All of the open source BSDs derive from the same original code
| base and have survived as forks doing exactly what you
| describe. They each have different communities and different
| goals but still frequently borrow patches from one another.
| notacoward wrote:
| 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.
| phendrenad2 wrote:
| 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?
| massysett wrote:
| 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.
| vzaliva wrote:
| What if somebody sends you an email patch?
| cies wrote:
| This is important. We need some vocabulary definitions for
| all different levels/aspects of "open".
|
| Open Access, or not.
|
| Open for contribution... or not.
|
| Commit ownership transferals, or not.
|
| In some cases there are whole steering committees.
| mumblemumble wrote:
| 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.
| kenniskrag wrote:
| 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.
| imtringued wrote:
| 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.
| ufmace wrote:
| 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.
| Phil-bitplex wrote:
| 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?
| cies wrote:
| rightfully -> understandibly
| mitjak wrote:
| 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.
| anticristi wrote:
| 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.
| kelnos wrote:
| 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.
| throwawayboise wrote:
| > 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.
| AmericanChopper wrote:
| 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.
| ghaff wrote:
| > 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.
| AmericanChopper wrote:
| 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).
| jabbany wrote:
| 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.
| phkahler wrote:
| >> 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.
| emidln wrote:
| 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.
| yawaramin wrote:
| > 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.
| vorpalhex wrote:
| 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.
| [deleted]
| peteretep wrote:
| > It should be just the other way around
|
| It should not be just the other way around
| enriquto wrote:
| 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_.
| chmaynard wrote:
| 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.
| qhwudbebd wrote:
| 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?
| kodah wrote:
| Kind of. Archiving means you can't commit to it either, from
| what I know. Mirroring doesn't necessarily mean that you
| can't contribute to it, it just means you can't contribute to
| it _on GitHub_.
| sudhirj wrote:
| 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.
| kminehart wrote:
| 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.
| Joeri wrote:
| 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...
| whateveracct wrote:
| I guess you can add a PR template that says "PLEASE DON'T SEND
| ME PRS"
| pabs3 wrote:
| SourceForge is still around. I would suggest SourceHut over
| SourceForge these days though (not sure if SourceHut can turn
| off contributions).
| kodah wrote:
| 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."
| ddevault wrote:
| 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.
| pabs3 wrote:
| SourceForge can do that too.
| andrepd wrote:
| The flexibility is cool, but why would you want to fragment
| your bug trackers, for example, like that?
| callmeal wrote:
| So you can have a separate one for "internal" and
| "external" customers perhaps?
| ddevault wrote:
| 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.
| andrepd wrote:
| Gotcha, that makes sense. Thanks!
| JosephRedfern wrote:
| 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.
| MereInterest wrote:
| SourceForge is still around, but since they were caught
| adding adware/malware to downloads (2015, I think), I
| wouldn't trust them at all.
| toyg wrote:
| 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...
| eitland wrote:
| They've since changed ownership and the new owner seemed to
| put a lot of effort into cleaning it up.
| trynewideas wrote:
| > 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.
| enriquto wrote:
| > 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.
| rectang wrote:
| > 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.
| enriquto wrote:
| > 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.
| rectang wrote:
| 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.
| darkwater wrote:
| > 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.
| alkonaut wrote:
| 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).
| yawaramin wrote:
| 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.
| dialamac wrote:
| 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.
| TheRealPomax wrote:
| 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.
| filmgirlcw wrote:
| 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.
| TheRealPomax wrote:
| 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.
| kelnos wrote:
| 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.)
| Elhana wrote:
| Why not just leave them open for some other people who
| might find them useful, but never accepting them?
| gus_massa wrote:
| 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.
| tshaddox wrote:
| Surely having a disabled or hidden pull request button is
| also very solid proof that the maintainer is not
| accepting pull requests.
| enriquto wrote:
| > it's far less welcoming
|
| Oh please, only somebody with a ridiculously thin skin
| would be offended by seeing rejected his PR to a project
| that clearly states that does not welcome outside
| contributions.
| onion2k wrote:
| _only somebody with a ridiculously thin skin..._
|
| People like that are very common and often very vocal.
| DangitBobby wrote:
| Depends on how much work they put in, doesn't it?
| tombot wrote:
| Surely someone invested enough to submit a PR would have
| read the readme which explains they won't accept a PR
| qhwudbebd wrote:
| I really wish that were true!
| folkrav wrote:
| Reading stories from open-source maintainers, I have 0
| difficulty believing many would not.
| afarrell wrote:
| You are free to disbelieve the answer, but it still
| stands.
| gregoriol wrote:
| 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.
| jerf wrote:
| 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.
| MaxBarraclough wrote:
| > 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
| type0 wrote:
| It might not work with big projects but libraries and
| other smaller software is perfectly fine.
| dialamac wrote:
| 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.
| jerf wrote:
| Obviously, one needs to be judicious with this.
| mitjak wrote:
| it's.. not your project. if you disagree, fork away. your
| anger is on you.
| shock wrote:
| 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?
| whimsicalism wrote:
| > 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.
| [deleted]
| kelnos wrote:
| > * 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.
| Stratoscope wrote:
| > _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!
| Communitivity wrote:
| If you are writing something to contribute it to a project,
| then you should discuss the idea with the current
| committers/maintainer on the project's mailing list, or
| discord, or however they communicate.
|
| If you don't, and you submit a PR, you should expect the PR to
| be closed with a "Unfortunately, this change was not discussed.
| As a result it may clash with other efforts underway, or our
| future roadmap. Also, not having discussed it prior to the PR
| increases the suspicion that you have not followed our coding
| guidelines. Consequently this PR is closed. Please propose the
| change on the mailing list and take part in the discussion
| before revising this patch and resubmitting the PR."
|
| Because of this I think an auto-close is fine. I also do think
| Github should allow disabling the PR tab.
| gus_massa wrote:
| I agree, but I'd make an exception for fixing typos, obvious
| bugs and tiny additional features. Sometimes the change takes
| less time that discussing in other channels, and sometimes
| it's easier to explain with code if you are not a native
| speaker.
|
| I think that spending more of a weekend in a PR without
| checking before with the maintainers is a bad idea, because
| there is a big risk that is not merged and is a waste of
| time.
|
| Also, each project has it's own weird rules, like code style,
| space vs tabs, changing whitespace in unrelated lines, adding
| tests, ... and a long list. Some are written explicitly, and
| some are just implicit rules. So sometimes it's difficult to
| make a PR that follows all the rules.
| Communitivity wrote:
| 100% agreed. Things that are obvious to fix and have no
| design impact should be ok to PR and get accepted quickly.
|
| Every rule has exceptions, and this is definitely one for
| the rule I described. Thank you for pointing reminding me
| and clarifying.
| phkahler wrote:
| 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.
| matthewmacleod wrote:
| 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.
| Communitivity wrote:
| 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).
| young_unixer wrote:
| That didn't work for Torvalds.
| bityard wrote:
| I don't blame Github here, their WHOLE spiel is open
| collaboration for community software projects. If want to share
| your project online but don't want to engage with your users as
| peers, then GitHub was never the right place to post the repo
| anyway.
| jabbany wrote:
| Pretty sure the repo maintainer still wants to engage with
| users as peers (via bug reports and feature requests as they
| mention) just not through code contributions.
|
| In fact, if you only look at the "issues" framework, GitHub
| does a pretty good job of making things easy to use compared
| to the other bug trackers...
| trinovantes wrote:
| Doesn't make sense they'd allow you to disable Issues but not
| PRs if they only cared about engagement
| mathnmusic wrote:
| Does this not serve the purpose?
|
| Repo -> Settings -> Moderation Settings -> Limit to repository
| collaborators
| dbrgn wrote:
| This cannot be enabled permanently. Max duration is 6 months.
| Footkerchief wrote:
| "Disable pull requests while keeping issues"
| tecnocriollo wrote:
| Gitlab is a nice option
| Vinnl wrote:
| It might be me, but I don't see an option to disable Merge
| Requests in GitLab?
| dnsmichi wrote:
| 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.
| Vinnl wrote:
| Heh, got it - I was looking under "Merge requests" :)
| Thanks both!
| algo_cheese wrote:
| In your project "Settings" -> "General" -> "Visibility,
| Project features, permissions" -> "Merge Requests".
|
| IIRC, you must be owner of the project.
| SamWhited wrote:
| 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.
| scaladev wrote:
| I think you mean sourcehut:
|
| https://sr.ht
| toyg wrote:
| 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...
| hutzlibu wrote:
| I hope so too, but mainly because sourceforge burned all
| reputation and trust for me, when they sneakily bundled
| adware to OSS installers.
| ljm wrote:
| 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.
| skohan wrote:
| I've transitioned to gitlab for new projects about a month
| ago, and so far the experience has been great.
| rectang wrote:
| Is it possible to "archive" and then "unarchive" a Github repo
| using the Github API?
|
| If so, one possible solution is to maintain the primary repo
| elsewhere (Source Hut, Gitlab. wherever), and run a sync
| routine on a cron (or perhaps every push):
|
| 1. unarchive Github mirror repo
|
| 2. Push changes from primary repo to Github mirror
|
| 3. archive Github mirror repo
|
| There's a race condition where someone might see the unarchived
| repo and start a pull request during the brief period where the
| sync is taking place, but the possibility that they'd both
| start and then fisish a pull request during sync periods seems
| remote.
| gregoriol wrote:
| The problem with archive is that it looks like "not
| maintained anymore"/"deprecated", which is not the case here.
| rectang wrote:
| 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).
| TheRealPomax wrote:
| Also the "fork" option. If you want the source, pull the
| official source, but there are plenty of projects where people
| should not be creating their own copy that is on equal footing
| as the authoritative repo.
| yawaramin wrote:
| It's a widely-known practice for companies to internally fork
| and vendor software they use.
| macksd wrote:
| 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.
| dspillett wrote:
| _> 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).
| massysett wrote:
| You want other people to do work for you, for free. That's
| completely understandable.
| phkahler wrote:
| >> You want other people to do work for you, for free.
| That's completely understandable.
|
| The parent poster was talking about submitting a Pull
| Request. In other words, contributing the work for free. I
| suppose expecting someone to look at it _might_ be asking
| them to do something for free, but if that 's a problem
| then I agree that Github should have the option of not
| having the button on a project at all.
|
| Or maybe you thought PR stood for Problem Report, in which
| case expecting it to be looked into by someone is an
| expectation of free labor.
| massysett wrote:
| 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.
| macksd wrote:
| 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.
| yawaramin wrote:
| > 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?
| macksd wrote:
| "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.
| tshaddox wrote:
| > 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.
| pdonis wrote:
| _> 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.
| pizzazzaro wrote:
| This is why our tools for Open Software need to be Open
| themselves.
|
| Have a problem being unable to disable PRs? A PR that fixes it
| would be embarassing for Github if it were simply Closed. How
| many such PRs for distinct code could we get submitted at once?
| toyg wrote:
| Github allowing you to disable PRs would be a bit like Facebook
| allowing you to opt out of ad-tracking...
| johannes1234321 wrote:
| I don't get the analogy.
|
| Also mind: Even if pull requests are off somebody else might
| emerge and maintain a fork, which becomes more successful.
| Maybe even going as far that that the original owner can
| safely outsource the maintenance of the thing he created.
| toyg wrote:
| 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.
| hutzlibu wrote:
| "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.
| _jal wrote:
| 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...
| mhitza wrote:
| 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.
| publicola1990 wrote:
| 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.
| justaguy88 wrote:
| There is https://sr.ht/
| fortran77 wrote:
| Amazon CodeCommit works great for me.
| bcfalconer wrote:
| 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.
| bjarneh wrote:
| > 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.
| Aeolun wrote:
| 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.
| jabbany wrote:
| 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.
| franciscop wrote:
| IF the maintainer(s) offer contracting and it bothers you so
| much, have you considered paying them 1-2 hours to have a look
| at the issue/solution? If you are putting food on my mouth AND
| potentially fixing an issue, that'd be normally much better.
| Any patch review _is_ extra work for the maintainer, which they
| are in their right of not wanting to do it.
| krzyk wrote:
| But besides the review it is also free code.
|
| I don't get this sentiment of disallowing pull requests or
| issues.
|
| Just because one gets bunch of useless issues or PRs doesn't
| mean that he/she won't receive a valuable one.
|
| If you close those, you are basically closed-source with an
| option to peak at the code.
| pessimizer wrote:
| > 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.
| mschuetz wrote:
| Reviewing and testing multiple PRs is an enormous amount of
| work for anything but the most simple one liner changes.
| bacongobbler wrote:
| 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.
| jabbany wrote:
| 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.
| UncleMeat wrote:
| Code is never free. Code that exists in a project
| continuously costs energy in maintenance. This is why
| deleting code is valuable.
| krzyk wrote:
| PR is not always about adding code.
| UncleMeat wrote:
| 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.
| krzyk wrote:
| 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.
| UncleMeat wrote:
| 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.
| jrochkind1 wrote:
| > 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.
| jeroenhd wrote:
| 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.
| krzyk wrote:
| > 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.
| ozim wrote:
| 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'.
| jrochkind1 wrote:
| 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.
| alexellisuk wrote:
| I think this is interesting. Burn-out is real - I remember when
| Ben stepped away from boltdb. I guess he's learned his lessons
| and isn't as interested in contributions being part of his vision
| for his SQLite sync tool.
|
| I'd be interested to see if this gets normalised beyond the
| SQLite community.
|
| One of the things I did recently and haven't regretted is turning
| off email notifications on GitHub.
| skohan wrote:
| 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.
| DrFell wrote:
| 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.
| andi999 wrote:
| Also if you do not accept contributions you can easily perform a
| license change later.
| tyingq wrote:
| 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...
| trboyden wrote:
| 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.
| alkonaut wrote:
| > 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
| loup-vaillant wrote:
| > _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.
| bovermyer wrote:
| My Iron Arachne projects are open source and closed to
| contributions.
|
| They're closed to contributions because they're my personal
| projects. They serve a very specific purpose - my playground,
| my mental space.
|
| But they're open source, because if others are curious about
| how they were built, I don't mind if they want to see the
| source.
| trboyden wrote:
| 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.
| bovermyer wrote:
| 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.
| bgpl10 wrote:
| 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.
| trboyden wrote:
| 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.
| johnr2 wrote:
| > 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?
| johnr2 wrote:
| > 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.
| clellan wrote:
| 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.
| teddyh wrote:
| > _simple one line changes can have profound and unexpected
| changes in correctness and performance. Small contributions
| typically required hours of my time to properly test and validate
| them._
|
| Isn't this a simple case of not having a good enough test suite?
| Jonnax wrote:
| Well then why are they obligated to create a test suite?
| teddyh wrote:
| 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.
| pmlnr wrote:
| 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,...
| jgilias wrote:
| 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.
| rkangel wrote:
| > 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.
| jasode wrote:
| _> 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.
| bityard wrote:
| > 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.
| jabbany wrote:
| 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.
| sltkr wrote:
| 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.
| cies wrote:
| 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.
| jabbany wrote:
| (1) Running your own web service costs money (hosting fees) and
| time (setup, patching security issues). Often quite significant
| amounts of both, making it unattractive for small FOSS
| projects. Github provides a free and managed service.
|
| (2) The maintainer _wants_ the community/social aspects like
| Issues and Discussions. They just don't want code
| contributions. Of course, one can run their own bug tracker and
| forum... but... see (1).
|
| (3) GitHub has been branding itself as more and more of a
| package manager too (and in many areas it has become the de-
| facto one). Placing things on Github v.s. self hosting can also
| be seen as an SEO/advertising move for an FOSS project.
| pmlnr wrote:
| 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.
| jabbany wrote:
| 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.
| robinhood wrote:
| 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.
| pmlnr wrote:
| > 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.
| robinhood wrote:
| 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.
| gbrown_ wrote:
| Perhaps you wish to have both your collaborative and your
| presentational works on the same (in this case near de facto)
| hosting provider.
| mumblemumble wrote:
| 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.
| ballenf wrote:
| 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).
| mumblemumble wrote:
| 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.
| imtringued wrote:
| 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.
| parasubvert wrote:
| 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.
| [deleted]
| [deleted]
| rkangel wrote:
| 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.
| alkonaut wrote:
| 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.
| valand wrote:
| 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
| noobermin wrote:
| One way in the middle is to significantly raise the threshold for
| accepting a patch but that makes it harder.
| makecheck wrote:
| Being able to turn off pull requests would help for cases like
| this.
|
| Though the default GitHub setup also makes contributions
| unnecessarily difficult to manage. For example, a project can
| tell if it has been forked but otherwise has _no_ idea what the
| forker is currently doing! Is the forker working on a possible
| future contribution (and worse, could that work be duplicating
| something that is already in progress elsewhere?). There are also
| plenty of forks that seem to _never_ evolve, not even taking the
| minimal effort of pulling recent upstream changes.
|
| The contribution mechanism could be broken up into different
| phases, something like:
|
| 0. Visitor forks project but this should be _invisible_ , i.e. it
| is not "your repository" for all to see, since you haven't
| actually _contributed_ anything to it yet.
|
| 1. Visitor clicks button stating "intention to contribute" that
| notifies upstream project immediately. This includes information
| such as the nature of the proposed change.
|
| 2. The project maintainer then has the opportunity to communicate
| immediately, e.g. "sure!" or "please don't do this, $SOMEONE_ELSE
| is already doing it" or "I don't think that is a good idea" or
| whatever. Then the project can put this into a visible state on
| the GitHub page so that everyone knows about this in-progress
| work.
|
| 3. Eventually the work is done, and is _converted_ to a Pull
| Request as opposed to just appearing out of the blue.
|
| 4. Once accepted, the repository is publicly listed on your
| profile since you have made an actual contribution to it.
| [deleted]
| bluefox wrote:
| 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.
| geoah wrote:
| 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...
| farslan wrote:
| Hi geoah,
|
| Looking back, I think following this contribution model of open
| source but no contribution would definitely help me. In the
| beginning, I hadn't a lot of experience managing a large open
| source project. I would accept all kinds of feature PR's or
| tried to implement all the features people suggested and wanted
| from me. Obviously that was one of the main drivers of vim-go's
| popularity. However, this popularity also brought me down and I
| had a burnout.
|
| The problem with this one-person/popular projects are, it's not
| scalable. People recommend finding a maintainer, but that's not
| always possible and pretty hard. The main problem is, it's a
| niche product. Like you need to find someone who loves Vim,
| loves Go and also wants to be a part of a project. (I was lucky
| to find someone like that though, thank you Billie!).
|
| I still enjoy writing software on the side, but I think I've
| lost the energy and appetite to work +4 hours (on top of my
| full time job) every single day. Having two kids, getting older
| probably contributed to it :) I'm happy though how things have
| evolved right now. I found my inner peace.
| beowulfey wrote:
| 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.
| matsemann wrote:
| I'm curious why Elm gets such flak for doing the same?
| patrickhulce wrote:
| 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.
| bgpl10 wrote:
| This is a great decision by the author, and the way he states it
| makes it socially acceptable in the current climate, where hordes
| of entitled and clueless people have the upper hand over the
| experienced and productive classes.
|
| The latter part is the real reason why people burn out;it wasn't
| that much of an issue when you could just tell people to stop
| bothering you with unimportant issues.
|
| These days it is like walking around in a train station where
| random people can ask you to carry their suitcases. If you don't
| politely oblige, they shout "privilege" and report you to the
| station's political officer.
| shirakawasuna wrote:
| 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.
| 0xbadcafebee wrote:
| There is a middle way: continuous integration quality gates.
|
| For projects with a small core team and lots of contributors, you
| can write tests which analyze the submission for quality. Linting
| tests, code quality tests, smoke tests, unit tests, functional
| tests, ChangeLog tests, etc. Each one will halt the PR and inform
| the user what failed and how to fix it. The user can then
| gradually improve the quality of their PR until it passes all
| tests, and _then_ someone will review it.
|
| I've used this method on projects before, and both as a
| contributor and a maintainer, I love it. As a contributor, it is
| a seamless feedback cycle that tells me how to improve my
| contribution before I bother anybody. As a maintainer, most
| contributors just don't put in the effort, so I don't get
| bothered.
|
| You can also put other quality gates in place, like asking
| someone to sign your contribution agreement, confirming they have
| read documentation ("what's the secret phrase?") or that their
| change includes documentation. It takes some work to set up at
| first, but it really improves productivity and quality.
| bacongobbler wrote:
| 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.
| okokwhatever wrote:
| It's my code, i don't want you to modify my codebase but I'll
| give it for free.
|
| Fair enough for me.
| mikepurvis wrote:
| Or, "you're welcome to fork it and make changes for use by
| yourself and others, but please don't have any expectation that
| I will review or merge the changes you propose."
| okokwhatever wrote:
| Like it too. The "don't have any expectations" part should be
| included in the name of the license: Dont-have-any-
| expectations-Open-Source License. :)
| gnud wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-28 23:00 UTC)