11 ms·

It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fi

It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse And so on...

bachmeier 5y ago
I don't understand. You have "developer forks". Everything after that is irrelevant. That's the whole point of open source.
- kccqzy 5y ago
  On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
  - bachmeier 5y ago
    Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
    - Nadya 5y ago
      Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine). > You don't need to push to the original repo because open source allows you to make your fork available to others. This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
      - bachmeier 5y ago
        > This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source. Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states: "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." You are referring to "source available", for which they offer the clarification: "Open source doesn't just mean access to the source code."
        Nadya 5y ago
        There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.debian.org/debian-devel/1999/02/msg01641.html https://web.archive.org/web/20140716055445/https://lists.deb... This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since. Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
        jrochkind1 5y ago
        The post you cite by Perens doesn't seem to mention the term "FLOSS" (or spelled out), right? I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
        Nadya 5y ago
        It doesn't use the term directly, no. Because to hackers, especially back in 1999, Free and Open Source were one in the same. It was just a difference of branding. However Bruce differentiates between "Open Source" and "Free Software" in writing and he only does so because public perception of what "Open Source" actually means had already been muddied in the year since OSI's founding and the freedoms afforded by FLOSS were already being de-emphasized and put on the back burner. To quote Bruce: > Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software..... > ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it. There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software. OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties. > We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with. Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1] Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly. >I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU." [0] http://web.archive.org/web/19981206185148/http://www.opensource.org/history.html http://web.archive.org/web/19981206185148/http://www.opensou... [1] https://web.archive.org/web/20170630183629/http://www.linuxtoday.com/developer/1999062802310NWSM https://web.archive.org/web/20170630183629/http://www.linuxt...
    - tremon 5y ago
      Just as I don't understand the original comment, I also don't understand yours The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate. The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository. Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
      - theobeers 5y ago
        “Feature branch hosted in a separate repository” is a very good way of putting it.
      - cxr 5y ago
        > The common-use term of "fork" on github [i]s just a band-aid for lack of contributor access control More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors. When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth. It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
    - jlokier 5y ago
      > I fail to see why it matters that your PR isn't accepted. Making their code useful to other people is a strong motivator for many altruistic open source developers. The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes. Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway. If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that. (Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)
jenscow 5y ago
Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.
- rectang 5y ago
  The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
  - chii 5y ago
    what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors. The contributors aren't entitled to the time of the maintainers.
jrochkind1 5y ago
If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?
- brunoborges 5y ago
  Here's how I propose a better PR flow in GitHub: https://news.ycombinator.com/item?id=30705581 https://news.ycombinator.com/item?id=30705581

bachmeier 5y ago

I don't understand. You have "developer forks". Everything after that is irrelevant. That's the whole point of open source.

kccqzy 5y ago
On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
- bachmeier 5y ago
  Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
  - Nadya 5y ago
    Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine). > You don't need to push to the original repo because open source allows you to make your fork available to others. This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
    - bachmeier 5y ago
      > This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source. Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states: "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." You are referring to "source available", for which they offer the clarification: "Open source doesn't just mean access to the source code."
      - Nadya 5y ago
        There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.debian.org/debian-devel/1999/02/msg01641.html https://web.archive.org/web/20140716055445/https://lists.deb... This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since. Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
        jrochkind1 5y ago
        The post you cite by Perens doesn't seem to mention the term "FLOSS" (or spelled out), right? I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
        Nadya 5y ago
        It doesn't use the term directly, no. Because to hackers, especially back in 1999, Free and Open Source were one in the same. It was just a difference of branding. However Bruce differentiates between "Open Source" and "Free Software" in writing and he only does so because public perception of what "Open Source" actually means had already been muddied in the year since OSI's founding and the freedoms afforded by FLOSS were already being de-emphasized and put on the back burner. To quote Bruce: > Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software..... > ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it. There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software. OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties. > We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with. Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1] Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly. >I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU." [0] http://web.archive.org/web/19981206185148/http://www.opensource.org/history.html http://web.archive.org/web/19981206185148/http://www.opensou... [1] https://web.archive.org/web/20170630183629/http://www.linuxtoday.com/developer/1999062802310NWSM https://web.archive.org/web/20170630183629/http://www.linuxt...
  - tremon 5y ago
    Just as I don't understand the original comment, I also don't understand yours The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate. The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository. Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
    - theobeers 5y ago
      “Feature branch hosted in a separate repository” is a very good way of putting it.
    - cxr 5y ago
      > The common-use term of "fork" on github [i]s just a band-aid for lack of contributor access control More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors. When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth. It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
  - jlokier 5y ago
    > I fail to see why it matters that your PR isn't accepted. Making their code useful to other people is a strong motivator for many altruistic open source developers. The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes. Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway. If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that. (Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)

jenscow 5y ago

Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.

rectang 5y ago
The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
- chii 5y ago
  what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors. The contributors aren't entitled to the time of the maintainers.

jrochkind1 5y ago

If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?

brunoborges 5y ago
Here's how I propose a better PR flow in GitHub: https://news.ycombinator.com/item?id=30705581 https://news.ycombinator.com/item?id=30705581