4 ms·

It's a little funny to focus on GitHub's fork/pull-request model if you're trying to critique their centralization and lock-in. Every single successful open so

by 3JPLW 7y ago

It's a little funny to focus on GitHub's fork/pull-request model if you're trying to critique their centralization and lock-in. Every single successful open source project — on GitHub or not — has a canonical "source" branch and some sort of organization/leadership that decides what goes in. I'd argue that GitHub's behavior here isn't a power grab so much as a reflection of reality. The "real" lock-in is with the discussion model — on both issues and pull requests — and the organizational structure you're able to set up. It's easy to move the source code to another service. Heck, you can even email patches to maintainers of a project on GitHub without creating an account. It's not easy to move historical discussions/reviews or "commit bits"/maintainership roles, and of course you can't participate in reviews of an emailed patch that a maintainer PRs for you unless you create an account.

Sir_Cmpwn 7y ago
>Every single successful open source project — on GitHub or not — has a canonical "source" branch This isn't true at all, and I went into detail on this with Linux as an example in the article. Linux is far from the only example, though.
- 3JPLW 7y ago
  Yes, I did read that. But what is Linus' branch then, and why do folks aim to "upstream" changes to it? I'd argue that the other important Linux sources are _themselves_ cathedrals, each with their own form of centralized leadership — be it an individual or a group (like a distro or company). And these cathedrals happily work together. You can totally have this model with GitHub.
  - Sir_Cmpwn 7y ago
    I see your point. I alluded to a similar idea in an older draft which suggests that bazaar/cathedral style is a spectrum, with most projects not falling entirely within either camp, but clearly having more elements of one model than others. I think that GitHub actively encourages the cathedral model, though. It is possible to use either style on either platform, but the fork/PR model seems to me to be explicitly designed to strongly favor the cathedral model - to the benefit of GitHub's centralization goals, even if obliquely.
    - 3JPLW 7y ago
      I still respectfully disagree. If GitHub really wanted to deceitfully name this feature to foster the cathedral model they would have gone with "branch" instead. In fact, I recall them getting quite a bit of push back for naming it "fork" because it has historically been a pejorative term. Even further, I believe the actual operation is implemented as a branch on their backend for efficiency's sake. So why go so far as to call it a fork? Well, because you can treat it as a fully maintained source tree itself (and participating like a member in a bazaar). It's easy to turn on issues locally, add collaborators, accept pull requests, and trade commits back and forth between the forks. Now, yes, GitHub does by default "link" it to the upstream repository and it even keeps tabs on how its history differs, but I'd call these features that reflect real use-cases. Also amusing is how the repositories on kernel.org describe themselves; 149 use the word "fork". Sure, it's probably partly due to how GitHub uses this terminology, but I'd say it's a good thing that forking is no longer pejorative by default — now it's a "hard fork" that's a bad thing.
      - usrusr 7y ago
        Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps popping up all over the place, just like in the days of nondistributed VCS. There is no technical reason to do that, but that is insufficient in presence of social reasons: Someone wants to exploratory tinker around, maybe scratch some personal itch. No problem, check out, go wild in the working copy. Pretty soon they want it backed up in the cloud, maybe transfer it to another machine. VCS to the rescue. But do you want to create a branch on the official repository? Hell no, definitely not ready for that. git veterans will casually add another remote (and even that won't be as good as a branch/"github fork"), but a lot of people would choose the devil they know, rm .git and reinitialize. Everybody loses. The forker loses history, easy merges from upstream and almost all chances of getting merged back into upstream. The project loses a potential committer and general overview of what is going on at the fringes. Github wastes traffic and storage and loses the moat that socially linking up forker and project would have been. Github "fork" strikes the perfect balance between proximity and distance: all the benefits of a branch, all the freedom of working in your own personal account. With this github have solved the problem of source dump repos so hard that we easily forget that it ever existed.
- twic 7y ago
  I can't think of any open source project which isn't a hard fork (the traditional kind you mention, with renaming etc) which has multiple branches of equal maximum status. Many projects have research branches, integration branches, stabilisation branches, vendor branches, branches run by people with platforms or use cases not well served by the canonical branch, etc. But those examples are all either feeders for a canonical branch, or derivatives of it. Are there any projects where there are multiple branches right at the top? The closest i can come is in the various distros' versions of ancient common unix utilities, which are no longer maintained by their original creators. Distros will make fixes to them, and may exchange fixes, but there is no shared upstream. However, that is really a case of there being zero canonical branches, not more than one!
  - gowld 7y ago
    What does it mean to have more than 1 "canonical" of anything?
    - twic 7y ago
      Quite!
  - jimbo1qaz 7y ago
    In the retro console scene, sadly there are many programs with multiple independent forks which cannot be merged together. Famitracker is a NES composing program. It was originally a monolithic cathedral project written by jsr without a Git repo. There were several forks made, including HertzDevil's 0CC-Famitracker which had a Github repo and added features. Famitracker's creator released a "beta" without source code, then abandoned the project. 0CC-Famitracker reverse-engineered the binary to merge in some features. I maintained a "bugfix patch-set" on top of 0CC for several months, but kept running into merge conflicts, so I ended up forking an older revision of 0CC, calling it j0CC, because 0CC's maintainer was adding bugs and refused to accept contributions (including bug fixes). Then we both abandoned our forks... libgme is a library which emulates game-console sound chips, and is used in media players. It was originally written by blargg, but now has 2 active forks: A "linux" fork packaged in many Linux distros (including Ubuntu/Fedora), currently lightly-maintained by mpyne (which suffered a security vulnerability), and a "windows" fork used with foobar2000 (also builds on Linux via qmake) maintained by kode54, which is more ambitious with changes, including a slow but accurate SNES SPC700 emulator written by byuu and not affected by the security vulnerabilities. I heard Amiga emulation (UAE) has multiple forks too, and WinUAE is more popular? I would prefer if the forks had never happened, but it's not going to happen.
edflsafoiewq 7y ago
Is it any easier to move discussion that happened in an email thread?
- Sir_Cmpwn 7y ago
  It's very easy. lists.sr.ht, for example, supports importing and exporting mailing list archives as mbox files (a well-known format for email storage).
  - 3JPLW 7y ago
    Is it as easy to export tickets from Sourcehut? Can I participate in tickets on Sourcehut without creating an account?
    - shakna 7y ago
      > Is it as easy to export tickets from Sourcehut? I know Drew is working on a few email things for the `todo` section of the site. Opening tickets, and responding via email. > Can I participate in tickets on Sourcehut without creating an account? Depends. I set up most of my public ones to allow anonymous users to contribute, but it's up to the owner to decide whether they want that or not.
    - Sir_Cmpwn 7y ago
      It's not easy to export tickets right now, but I'm working on improving that. There's an API, so it's similar in capability to exporting tickets from GitHub, but I want to do better. I've put in about half the work necessary to file tickets without an account, the rest is just some database changes and should be live in the next few weeks.
perennate 7y ago
I'd argue that at least their API indicates they try to reduce rather than reinforce this lock-in. The API lets you build tools like https://github.com/colmsjo/github-issues-export https://github.com/colmsjo/github-issues-export to automatically export data from issues and other project data stored outside of git. Moving this data is still not trivial but I don't think GitHub could unilaterally make it much easier. (https://developer.github.com/v3/issues/ https://developer.github.com/v3/issues/)
- organsnyder 7y ago
  I'd love to see a standard develop for storing this information in-repo. GitHub could certainly drive such an initiative.
  - Ironchefpython 7y ago
    You might be thinking about fossil. Every feature is in-repo. https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
    - carlmr 7y ago
      That looks really cool. Is anybody already using this?
      - rkeene2 7y ago
        Well, SQLite is using it of course ;-) Other large projects include Tcl/Tk and many related extensions, as well as all the cool stuff I write: http://chiselapp.com/user/rkeene/ http://chiselapp.com/user/rkeene/
  - Pawamoy 7y ago
    There's git-bug: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
- erk__ 7y ago
theyinwhy 7y ago
This is especially true for projects like Kubernetes which cross references to github PRs in its commit logs. Have fun figuring out the change history when github is down. And yes, of course K8s commits do provide more information that that. But the community is way more reliant on github than it probably should be. You really start to see that when comparing K8s to Linux Kernel commit messages.
- erk__ 7y ago
  I use magit-forge for emacs then you can have a local copy of the pr's and issues. https://github.com/magit/forge https://github.com/magit/forge

by 3JPLW 7y ago

Sir_Cmpwn 7y ago

>Every single successful open source project — on GitHub or not — has a canonical "source" branch This isn't true at all, and I went into detail on this with Linux as an example in the article. Linux is far from the only example, though.

3JPLW 7y ago
Yes, I did read that. But what is Linus' branch then, and why do folks aim to "upstream" changes to it? I'd argue that the other important Linux sources are _themselves_ cathedrals, each with their own form of centralized leadership — be it an individual or a group (like a distro or company). And these cathedrals happily work together. You can totally have this model with GitHub.
- Sir_Cmpwn 7y ago
  I see your point. I alluded to a similar idea in an older draft which suggests that bazaar/cathedral style is a spectrum, with most projects not falling entirely within either camp, but clearly having more elements of one model than others. I think that GitHub actively encourages the cathedral model, though. It is possible to use either style on either platform, but the fork/PR model seems to me to be explicitly designed to strongly favor the cathedral model - to the benefit of GitHub's centralization goals, even if obliquely.
  - 3JPLW 7y ago
    I still respectfully disagree. If GitHub really wanted to deceitfully name this feature to foster the cathedral model they would have gone with "branch" instead. In fact, I recall them getting quite a bit of push back for naming it "fork" because it has historically been a pejorative term. Even further, I believe the actual operation is implemented as a branch on their backend for efficiency's sake. So why go so far as to call it a fork? Well, because you can treat it as a fully maintained source tree itself (and participating like a member in a bazaar). It's easy to turn on issues locally, add collaborators, accept pull requests, and trade commits back and forth between the forks. Now, yes, GitHub does by default "link" it to the upstream repository and it even keeps tabs on how its history differs, but I'd call these features that reflect real use-cases. Also amusing is how the repositories on kernel.org describe themselves; 149 use the word "fork". Sure, it's probably partly due to how GitHub uses this terminology, but I'd say it's a good thing that forking is no longer pejorative by default — now it's a "hard fork" that's a bad thing.
    - usrusr 7y ago
      Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps popping up all over the place, just like in the days of nondistributed VCS. There is no technical reason to do that, but that is insufficient in presence of social reasons: Someone wants to exploratory tinker around, maybe scratch some personal itch. No problem, check out, go wild in the working copy. Pretty soon they want it backed up in the cloud, maybe transfer it to another machine. VCS to the rescue. But do you want to create a branch on the official repository? Hell no, definitely not ready for that. git veterans will casually add another remote (and even that won't be as good as a branch/"github fork"), but a lot of people would choose the devil they know, rm .git and reinitialize. Everybody loses. The forker loses history, easy merges from upstream and almost all chances of getting merged back into upstream. The project loses a potential committer and general overview of what is going on at the fringes. Github wastes traffic and storage and loses the moat that socially linking up forker and project would have been. Github "fork" strikes the perfect balance between proximity and distance: all the benefits of a branch, all the freedom of working in your own personal account. With this github have solved the problem of source dump repos so hard that we easily forget that it ever existed.
twic 7y ago
I can't think of any open source project which isn't a hard fork (the traditional kind you mention, with renaming etc) which has multiple branches of equal maximum status. Many projects have research branches, integration branches, stabilisation branches, vendor branches, branches run by people with platforms or use cases not well served by the canonical branch, etc. But those examples are all either feeders for a canonical branch, or derivatives of it. Are there any projects where there are multiple branches right at the top? The closest i can come is in the various distros' versions of ancient common unix utilities, which are no longer maintained by their original creators. Distros will make fixes to them, and may exchange fixes, but there is no shared upstream. However, that is really a case of there being zero canonical branches, not more than one!
- gowld 7y ago
  What does it mean to have more than 1 "canonical" of anything?
  - twic 7y ago
    Quite!
- jimbo1qaz 7y ago
  In the retro console scene, sadly there are many programs with multiple independent forks which cannot be merged together. Famitracker is a NES composing program. It was originally a monolithic cathedral project written by jsr without a Git repo. There were several forks made, including HertzDevil's 0CC-Famitracker which had a Github repo and added features. Famitracker's creator released a "beta" without source code, then abandoned the project. 0CC-Famitracker reverse-engineered the binary to merge in some features. I maintained a "bugfix patch-set" on top of 0CC for several months, but kept running into merge conflicts, so I ended up forking an older revision of 0CC, calling it j0CC, because 0CC's maintainer was adding bugs and refused to accept contributions (including bug fixes). Then we both abandoned our forks... libgme is a library which emulates game-console sound chips, and is used in media players. It was originally written by blargg, but now has 2 active forks: A "linux" fork packaged in many Linux distros (including Ubuntu/Fedora), currently lightly-maintained by mpyne (which suffered a security vulnerability), and a "windows" fork used with foobar2000 (also builds on Linux via qmake) maintained by kode54, which is more ambitious with changes, including a slow but accurate SNES SPC700 emulator written by byuu and not affected by the security vulnerabilities. I heard Amiga emulation (UAE) has multiple forks too, and WinUAE is more popular? I would prefer if the forks had never happened, but it's not going to happen.

edflsafoiewq 7y ago

Is it any easier to move discussion that happened in an email thread?

Sir_Cmpwn 7y ago
It's very easy. lists.sr.ht, for example, supports importing and exporting mailing list archives as mbox files (a well-known format for email storage).
- 3JPLW 7y ago
  Is it as easy to export tickets from Sourcehut? Can I participate in tickets on Sourcehut without creating an account?
  - shakna 7y ago
    > Is it as easy to export tickets from Sourcehut? I know Drew is working on a few email things for the `todo` section of the site. Opening tickets, and responding via email. > Can I participate in tickets on Sourcehut without creating an account? Depends. I set up most of my public ones to allow anonymous users to contribute, but it's up to the owner to decide whether they want that or not.
  - Sir_Cmpwn 7y ago
    It's not easy to export tickets right now, but I'm working on improving that. There's an API, so it's similar in capability to exporting tickets from GitHub, but I want to do better. I've put in about half the work necessary to file tickets without an account, the rest is just some database changes and should be live in the next few weeks.

perennate 7y ago

I'd argue that at least their API indicates they try to reduce rather than reinforce this lock-in. The API lets you build tools like https://github.com/colmsjo/github-issues-export https://github.com/colmsjo/github-issues-export to automatically export data from issues and other project data stored outside of git. Moving this data is still not trivial but I don't think GitHub could unilaterally make it much easier. (https://developer.github.com/v3/issues/ https://developer.github.com/v3/issues/)

organsnyder 7y ago
I'd love to see a standard develop for storing this information in-repo. GitHub could certainly drive such an initiative.
- Ironchefpython 7y ago
  You might be thinking about fossil. Every feature is in-repo. https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
  - carlmr 7y ago
    That looks really cool. Is anybody already using this?
    - rkeene2 7y ago
      Well, SQLite is using it of course ;-) Other large projects include Tcl/Tk and many related extensions, as well as all the cool stuff I write: http://chiselapp.com/user/rkeene/ http://chiselapp.com/user/rkeene/
- Pawamoy 7y ago
  There's git-bug: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
erk__ 7y ago

theyinwhy 7y ago

This is especially true for projects like Kubernetes which cross references to github PRs in its commit logs. Have fun figuring out the change history when github is down. And yes, of course K8s commits do provide more information that that. But the community is way more reliant on github than it probably should be. You really start to see that when comparing K8s to Linux Kernel commit messages.

erk__ 7y ago
I use magit-forge for emacs then you can have a local copy of the pr's and issues. https://github.com/magit/forge https://github.com/magit/forge