3 ms·

I think that trying to impose some change into an OSS codebase is largely unproductive and in a way, very stupid. The codebase is bsd-license, it's as good (fo

by znpy 2y ago

I think that trying to impose some change into an OSS codebase is largely unproductive and in a way, very stupid. The codebase is bsd-license, it's as good (fork-wise) as it can be. So go ahead, fork it and explore your ideas... If they're good, they can still be merged back into upstream. People in the FLOSS scene nowadays are too much fork-a-phobic in my opinion.

pdimitar 2y ago
To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? "Can still be merged back into upstream" is a huge uphill battle. I understand the people who want to skip it.
- znpy 2y ago
  > To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? Actually this has been proven wrong in the real world. Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. > Who needs 100+ more UNIX almost-clones? Who needs 100+ GNU/Linux distros? and yet here we are and 100+ GNU/Linux distros is one of the strength of GNU/Linux. Other than this, 100+ more "UNIX almost-clones" are only an issue if they are long lived. If the clone serves the purpose of showing a PoC implementation you can get the PoC reworked and merged into mainline and just kill the fork (see my other comment)
  - pdimitar 2y ago
    > Actually this has been proven wrong in the real world. How so? TL;DR it for me and future readers, please? > Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. Nobody is "fork-a-phobic", this is childish talk and completely misses the otherwise clear point that I think I presented. Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping.
    - znpy 2y ago
      > Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping. I did, you keep missing the point. True gatekeeping is preventing people from exploring ideas by saying people should not fork. Quite literally, you’re the one pushing for the gate to be kept closed. I can’t help you with text comprehension, I’m sorry. Since you keep missing the point I won’t be replying any further, it’s wasted time. Good luck with everything.
      - pdimitar 2y ago
        You explained exactly nothing. You only said "do your homework" as if I am supposed to extract your exact meaning from a likely series of blog posts and videos. I get that you want to emerge the "winner" here but it's not going to work, HN readers are fairly well-educated. I asked for a summary, you refused it by also reaching for an ad hominem. It's very visible who is who in this situation. Good luck indeed.
        maxbond 2y ago
        > It's very visible who is who in this situation. To be frank, I think most of us just see two people failing to communicate.
        pdimitar 2y ago
        Ultimately, yes. When it's visible there's hostility and bad faith, I think we're excused for not putting the usual amount of effort.
        deleted 2y ago
        [deleted]
        maxbond 2y ago
        To be frank again, there wasn't really bad faith and hostility in the way you mean. You were snarky to them, and they escalated by insulting you. That doesn't really excuse anyone from anything; you both made your choices, and neither of you chose to descalate or to walk away. (To be clear, I have already read what happened, and I cannot be convinced otherwise. Any more than I can be convinced the sky is green. I'm just letting you know, because you invited the audience to pass judgment. If you feel compelled to justify yourself, just know that it's falling on deaf ears.)
orangeboats 2y ago
Forking (as opposed to branching which at least has community acknowledgement) should be taken as a last resort. Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.
- znpy 2y ago
  > Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often. If you rebase often enough you shouldn't have the mergeability problem. > It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork. The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me. Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary. Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.

by znpy 2y ago

pdimitar 2y ago

To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? "Can still be merged back into upstream" is a huge uphill battle. I understand the people who want to skip it.

znpy 2y ago
> To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? Actually this has been proven wrong in the real world. Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. > Who needs 100+ more UNIX almost-clones? Who needs 100+ GNU/Linux distros? and yet here we are and 100+ GNU/Linux distros is one of the strength of GNU/Linux. Other than this, 100+ more "UNIX almost-clones" are only an issue if they are long lived. If the clone serves the purpose of showing a PoC implementation you can get the PoC reworked and merged into mainline and just kill the fork (see my other comment)
- pdimitar 2y ago
  > Actually this has been proven wrong in the real world. How so? TL;DR it for me and future readers, please? > Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. Nobody is "fork-a-phobic", this is childish talk and completely misses the otherwise clear point that I think I presented. Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping.
  - znpy 2y ago
    > Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping. I did, you keep missing the point. True gatekeeping is preventing people from exploring ideas by saying people should not fork. Quite literally, you’re the one pushing for the gate to be kept closed. I can’t help you with text comprehension, I’m sorry. Since you keep missing the point I won’t be replying any further, it’s wasted time. Good luck with everything.
    - pdimitar 2y ago
      You explained exactly nothing. You only said "do your homework" as if I am supposed to extract your exact meaning from a likely series of blog posts and videos. I get that you want to emerge the "winner" here but it's not going to work, HN readers are fairly well-educated. I asked for a summary, you refused it by also reaching for an ad hominem. It's very visible who is who in this situation. Good luck indeed.
      - maxbond 2y ago
        > It's very visible who is who in this situation. To be frank, I think most of us just see two people failing to communicate.
        pdimitar 2y ago
        Ultimately, yes. When it's visible there's hostility and bad faith, I think we're excused for not putting the usual amount of effort.
        deleted 2y ago
        [deleted]
        maxbond 2y ago
        To be frank again, there wasn't really bad faith and hostility in the way you mean. You were snarky to them, and they escalated by insulting you. That doesn't really excuse anyone from anything; you both made your choices, and neither of you chose to descalate or to walk away. (To be clear, I have already read what happened, and I cannot be convinced otherwise. Any more than I can be convinced the sky is green. I'm just letting you know, because you invited the audience to pass judgment. If you feel compelled to justify yourself, just know that it's falling on deaf ears.)

orangeboats 2y ago

Forking (as opposed to branching which at least has community acknowledgement) should be taken as a last resort. Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.

znpy 2y ago
> Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often. If you rebase often enough you shouldn't have the mergeability problem. > It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork. The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me. Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary. Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.