9 ms·

Github does not need to be open source. Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies

Github does not need to be open source. Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies. Github may be the single greatest execution of embrace/extend/extinguish in computing history.

maccard 5y ago
Where are we seeing the extend or extinguish with GitHub? It's been 3.5 years and GitHub is just as compatible with git as it has ever been.
- blacktriangle 5y ago
  That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.
  - munk-a 5y ago
    That is somewhat fair - there aren't great alternatives to migrate issues and the like to today. But all of those bits of metadata are easy to pull out of the service via API hooks. If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. I don't disbelieve that it's possible for microsoft to severely restrict these - but entirely removing them is off the table unless they cut out a lot of value. Inter-service communication to third party review tools and CI/CD tools all depend strongly on those API hooks.
    - merpnderp 5y ago
      > If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. Like Gitlab? I assumed Gitlab would dominate after the MS purchase of Github, but I was incorrect that people wouldn't want to trust their data and personal projects to the epic abusers of privacy that is Microsoft.
      - munk-a 5y ago
        Well I don't think the personal projects are really a significant factor in terms of where MS's paychecks are coming from - they care more about the commercial subscribers. And, speaking as someone employed at a commercial subscriber, objecting to continuing to use github due to the microsoft acquisition when we use office for pretty much all document production is going to be a pretty hard argument.
    - gmueckl 5y ago
      There are really simple ways to play dirty with APIs like making sure that they are incomplete in subtle and inconvenient ways like leaving out some of the metadata. Hypothetical example: make it impossible to query tags on issues. You'd still be able to do most things through the API, but if you have a workflow that's heavily dependent on tags, the data is effectively siloed.
      - maccard 5y ago
        So to be clear, the proof the GitHub is extending is a hypothetical example of an incomplete api that is not based on an open standard?
        gmueckl 5y ago
        I didn't want to prove anything. I just pointed out what is possible.
        maccard 5y ago
        Sorry, I misread the username and assumed you were the commentor I replied to. Yes, these things are _possible_ but there is no evidence or indication that they are happening with Github.
        gmueckl 5y ago
        I agree that there are no signs at the moment. Companies change over time, so a certain risk - however small - is present, as with all 3rd party services.
  - whichquestion 5y ago
    Are there any foss initiatives to making these metadata bits portable?
    - harryvederci 5y ago
      https://fossil-scm.org/ https://fossil-scm.org/
  - treis 5y ago
    What is going to be extinguished?
  - maccard 5y ago
    By that logic any proprietary product that provides an interface with an open source tool is guilty. I think accusing MS of EEE in this case is a huge stretch; GitHub is a commercial product that uses a popular open source tool with 100% compatibility (that I'm aware of) and actively participates in the development and features of that tool. When Ms start implementing extensions to git that only work with GitHub, we can point fingers but accusing them of extending git to extinguish based on pull requests is baseless
    - fartcannon 5y ago
      there's never a stretch with Microsoft. It is always, and has always been the same play. You can make excuses all you like, but in the end they will attemtp to embrace, extend and extinguish all competition.
      - maccard 5y ago
        Wheh they show any signs of extending git, or extinguishing any other open source competitors, I will be standing there with you calling them out. Until then, they're developing an excellent product that people want to use, built with open tooling
        blacktriangle 5y ago
        Those who don't study history are doomed to repeat it.
        maccard 5y ago
        I'm arguing against soundbytes here, which is really unfortunate and something I hoped would be above HN. It's very easy to shut down an argument with a soundbyte or a famous quote when you don't have any actual proof that history is repeating itself. The situation and landscape is _very_ different from the mid 90s, Microsoft are showing _no_ indication of being bad actors whatsoever, (in fact they're showing the exact opposite) and haven't done for at least a decade.
- amatecha 5y ago
  You know how they added Github CLI[0], right? There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects. That would be the "extinguish" phase. Right now they have embraced and are extending (such as with Github CLI). [0] https://cli.github.com/ https://cli.github.com/
  - grepfru_it 5y ago
    If you wish to leverage the advanced features of github, the CLI gives you direct access rather than rolling your own api client. git will always be a first class citizen at GIThub.. but how do you open, close, or comment on PRs with a standard git client? Edit: The last part came across a bit snarky, but I’m trying to stimulate the thought process. Such as leveraging GitHub Actions to automate all aspects of PRs via gitops instead of using the GitHub client. Many ways to avoid dependence of the CLI!
    - rhn_mk1 5y ago
      That sounds very much like the "extend" part of the process.
    - Ygg2 5y ago
      As another commenter pointed out, we're at extend part of embrace, extend, extinguish. This part is just making Github tools work easier than non Github. In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.
    - robertlagrant 5y ago
      It feels like an open source standard on top of git that defines how to do this stuff would be helpful to reduce lockin. I wonder if Fossil or Gitlab have something.
  - maccard 5y ago
    I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy. > There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects So we're accusing MS of a slippery slope based on a phrase from 25 years ago, which there is absolutely zero proof or indication of them pursuing in the last decade (at least). When GitHub show the _slightest_ inclination to do anything of the sort, I will be standing there with you, screaming blue murder. As of right now, they're progressing the development of git, "embracing" the open standards that have been developed (lfs being exemplary) and have shown absolutely zero signs of extending git in incompatible ways. See elasticsearch [1] for what "extend" _actually_ looks like. > Right now they have embraced and are extending (such as with Github CLI). If they _hadn't_ embraced, people would be complaining that GH are forcing non-open standards to be used. I firmly disagree that the GH issue tracker and pull request management are an "extension" of git. They have nothing to do with git whatsoever. [0] https://news.ycombinator.com/item?id=28149098 https://news.ycombinator.com/item?id=28149098 [1] https://news.ycombinator.com/item?id=28110610 https://news.ycombinator.com/item?id=28110610
- prirun 5y ago
  Microsoft plays a very long game. 3-4 years is not enough time to boil a frog; it takes much longer or the frog will realize what's happening. Be patient. Give them 10-15 years after their "We love Linux" shift and you'll see. They love it so much, they will own it. Just think of Microsoft like the Borg.
  - ChicagoDave 5y ago
    Microsoft is a trillion dollar company in large part because they embraced open source. Azure is extraordinarily profitable. Why would they fuck with their number one audience, developers?
    - prirun 5y ago
      According to this site, Microsoft's profit is divided into thirds: https://www.investopedia.com/how-microsoft-makes-money-4798809 https://www.investopedia.com/how-microsoft-makes-money-47988... A third is for Office, a third for cloud, and a third is Windows. IMO Microsoft is a trillion-dollar company because of their long monopoly with Windows. It's so entrenched that their "punishment" for abusing their monopoly position (according to the DOJ) was to give all schools free copies of Microsoft Office, thereby forcing every parent to own a copy of Microsoft office to be able to read reports from their kids' schools. Ingenious! You know why they would fuck with developers? Because developers have choices now, and Microsoft doesn't like it when anyone has a choice besides Microsoft. They are remedying that.
scrollaway 5y ago
> Github may be the single greatest execution of embrace/extend/extinguish in computing history. Oh ffs are you even aware that MS didn't originally build GitHub? And your comment is super out of touch with what MS was doing in the 90s and early 00s. GitHub has plenty of competition, Gitlab for example is a fantastic platform, overall more powerful than GitHub as well. GH's strength is how much better it is for open source projects and if MS messes with that they'll be killing their golden goose. There is no all-powerful benevolent deity you can hand your code to and say "here, take care of this for me, for free, for all eternity". At some point private companies will have to get involved (or would you rather have your government get involved instead? Because I don't want your government hosting my code). So you want their incentives to be nicely aligned.
- antonvs 5y ago
  > Oh ffs are you even aware that MS didn't originally build GitHub? Purchasing a popular product is definitely qualifies for the "embrace" part of the strategy. But that's not unique to MS - AWS and Google follow similar playbooks, as does almost any large company that provide a platform-like product. The goal is to make the platform as sticky as possible for as many customers as possible.
austincheney 5y ago
Technically speaking, Microsoft is a public company. A private company implies not open to investment on a public market.
- munk-a 5y ago
  You are technically correct - but it's overly pedantic. Another commonly accepted definition of public companies outside of the US is companies that are partially or wholly owned by the government and thus act as a public service. This includes crown corporations in Canada or the USPS in the US. I think within the context they used that calling Microsoft a private company is fair since they have no obligation to "act in the public good".
- Biganon 5y ago
  This is not the first time I see this exact pedantry on HN and I can't help but feel the same way as with people who immediately yell "it's not free! Nothing in life is free!" when you talk about free healthcare or free public transportation. We know. We understand that it is technically correct. But it's completely useless in the discussion. You know perfectly well what the other person meant.
KronisLV 5y ago
> Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies. Well, for starters, there is GitLab which attempts to do a lot of what GitHub does, while allowing you to self host it: https://gitlab.com/gitlab-org/gitlab https://gitlab.com/gitlab-org/gitlab In some respects, i'd say that it does things better, for example, GitLab CI seems way easier to use in comparison to GitHub Actions: https://docs.gitlab.com/ee/ci/ https://docs.gitlab.com/ee/ci/ As far as alternative source code management platforms go, with some code review and issue management functionality added on top, there is also Gogs, which is a far more lightweight solution and better fits smaller deployments: https://github.com/gogs/gogs https://github.com/gogs/gogs It was also forked by the Gitea project, which is largely compatible with it but is also in active development: https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea Oh and there's also GitBucket which also attempts something similar to these: https://github.com/gitbucket/gitbucket https://github.com/gitbucket/gitbucket Now, you can probably hook those up with Jenkins or most other CI solutions, but personally i rather enjoyed how Gogs/Gitea integrated with Drone, which allowed for container based builds (no more plugin hell like in Jenkins): https://github.com/drone/drone https://github.com/drone/drone Then, you can throw in some additional tools, for example, for code analysis you could use SonarQube ( https://github.com/SonarSource https://github.com/SonarSource ) and for security scanning of infrastructure you could look at OpenVAS ( https://github.com/greenbone https://github.com/greenbone ). Oh, and on the organizational side something like Rocket.Chat ( https://github.com/RocketChat https://github.com/RocketChat ) or Mattermost ( https://github.com/mattermost https://github.com/mattermost ) for communication and perhaps OpenProject ( https://github.com/opf/openproject https://github.com/opf/openproject ) for project management. And there you have it! An open source based workflow that allows you to do most of the stuff that GitHub would let you! Of course, concessions might need to be made depending on what your definition of "open" is and whether you're okay with certain features being restricted to paid tiers in some software; if you do have a problem with that, there's also the possibility of looking at some libre alternatives, though that might lead to the occasional half-dead piece of software that doesn't really have financial incentives for maintenance anymore on anyone's part. That said, i believe that few choose this approach, because it's somewhat complicated to run all of that and all of the sudden you become responsible for your own SLAs, which many don't want. It's often the same reason why people just provision VPSes from AWS, instead of running their own servers in a server room. I think the amount of links to GitHub for open source above speaks volumes about the state of the industry. I don't think that there's an easy answer to the implications of this, maybe people should just familiarize themselves with the concept of "Service as a Software Substitute", so that they're at least aware of the trade-offs that their choices have: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...

maccard 5y ago

Where are we seeing the extend or extinguish with GitHub? It's been 3.5 years and GitHub is just as compatible with git as it has ever been.

blacktriangle 5y ago
That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.
- munk-a 5y ago
  That is somewhat fair - there aren't great alternatives to migrate issues and the like to today. But all of those bits of metadata are easy to pull out of the service via API hooks. If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. I don't disbelieve that it's possible for microsoft to severely restrict these - but entirely removing them is off the table unless they cut out a lot of value. Inter-service communication to third party review tools and CI/CD tools all depend strongly on those API hooks.
  - merpnderp 5y ago
    > If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. Like Gitlab? I assumed Gitlab would dominate after the MS purchase of Github, but I was incorrect that people wouldn't want to trust their data and personal projects to the epic abusers of privacy that is Microsoft.
    - munk-a 5y ago
      Well I don't think the personal projects are really a significant factor in terms of where MS's paychecks are coming from - they care more about the commercial subscribers. And, speaking as someone employed at a commercial subscriber, objecting to continuing to use github due to the microsoft acquisition when we use office for pretty much all document production is going to be a pretty hard argument.
  - gmueckl 5y ago
    There are really simple ways to play dirty with APIs like making sure that they are incomplete in subtle and inconvenient ways like leaving out some of the metadata. Hypothetical example: make it impossible to query tags on issues. You'd still be able to do most things through the API, but if you have a workflow that's heavily dependent on tags, the data is effectively siloed.
    - maccard 5y ago
      So to be clear, the proof the GitHub is extending is a hypothetical example of an incomplete api that is not based on an open standard?
      - gmueckl 5y ago
        I didn't want to prove anything. I just pointed out what is possible.
        maccard 5y ago
        Sorry, I misread the username and assumed you were the commentor I replied to. Yes, these things are _possible_ but there is no evidence or indication that they are happening with Github.
        gmueckl 5y ago
        I agree that there are no signs at the moment. Companies change over time, so a certain risk - however small - is present, as with all 3rd party services.
- whichquestion 5y ago
  Are there any foss initiatives to making these metadata bits portable?
  - harryvederci 5y ago
    https://fossil-scm.org/ https://fossil-scm.org/
- treis 5y ago
  What is going to be extinguished?
- maccard 5y ago
  By that logic any proprietary product that provides an interface with an open source tool is guilty. I think accusing MS of EEE in this case is a huge stretch; GitHub is a commercial product that uses a popular open source tool with 100% compatibility (that I'm aware of) and actively participates in the development and features of that tool. When Ms start implementing extensions to git that only work with GitHub, we can point fingers but accusing them of extending git to extinguish based on pull requests is baseless
  - fartcannon 5y ago
    there's never a stretch with Microsoft. It is always, and has always been the same play. You can make excuses all you like, but in the end they will attemtp to embrace, extend and extinguish all competition.
    - maccard 5y ago
      Wheh they show any signs of extending git, or extinguishing any other open source competitors, I will be standing there with you calling them out. Until then, they're developing an excellent product that people want to use, built with open tooling
      - blacktriangle 5y ago
        Those who don't study history are doomed to repeat it.
        maccard 5y ago
        I'm arguing against soundbytes here, which is really unfortunate and something I hoped would be above HN. It's very easy to shut down an argument with a soundbyte or a famous quote when you don't have any actual proof that history is repeating itself. The situation and landscape is _very_ different from the mid 90s, Microsoft are showing _no_ indication of being bad actors whatsoever, (in fact they're showing the exact opposite) and haven't done for at least a decade.
amatecha 5y ago
You know how they added Github CLI[0], right? There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects. That would be the "extinguish" phase. Right now they have embraced and are extending (such as with Github CLI). [0] https://cli.github.com/ https://cli.github.com/
- grepfru_it 5y ago
  If you wish to leverage the advanced features of github, the CLI gives you direct access rather than rolling your own api client. git will always be a first class citizen at GIThub.. but how do you open, close, or comment on PRs with a standard git client? Edit: The last part came across a bit snarky, but I’m trying to stimulate the thought process. Such as leveraging GitHub Actions to automate all aspects of PRs via gitops instead of using the GitHub client. Many ways to avoid dependence of the CLI!
  - rhn_mk1 5y ago
    That sounds very much like the "extend" part of the process.
  - Ygg2 5y ago
    As another commenter pointed out, we're at extend part of embrace, extend, extinguish. This part is just making Github tools work easier than non Github. In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.
  - robertlagrant 5y ago
    It feels like an open source standard on top of git that defines how to do this stuff would be helpful to reduce lockin. I wonder if Fossil or Gitlab have something.
- maccard 5y ago
  I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy. > There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects So we're accusing MS of a slippery slope based on a phrase from 25 years ago, which there is absolutely zero proof or indication of them pursuing in the last decade (at least). When GitHub show the _slightest_ inclination to do anything of the sort, I will be standing there with you, screaming blue murder. As of right now, they're progressing the development of git, "embracing" the open standards that have been developed (lfs being exemplary) and have shown absolutely zero signs of extending git in incompatible ways. See elasticsearch [1] for what "extend" _actually_ looks like. > Right now they have embraced and are extending (such as with Github CLI). If they _hadn't_ embraced, people would be complaining that GH are forcing non-open standards to be used. I firmly disagree that the GH issue tracker and pull request management are an "extension" of git. They have nothing to do with git whatsoever. [0] https://news.ycombinator.com/item?id=28149098 https://news.ycombinator.com/item?id=28149098 [1] https://news.ycombinator.com/item?id=28110610 https://news.ycombinator.com/item?id=28110610
prirun 5y ago
Microsoft plays a very long game. 3-4 years is not enough time to boil a frog; it takes much longer or the frog will realize what's happening. Be patient. Give them 10-15 years after their "We love Linux" shift and you'll see. They love it so much, they will own it. Just think of Microsoft like the Borg.
- ChicagoDave 5y ago
  Microsoft is a trillion dollar company in large part because they embraced open source. Azure is extraordinarily profitable. Why would they fuck with their number one audience, developers?
  - prirun 5y ago
    According to this site, Microsoft's profit is divided into thirds: https://www.investopedia.com/how-microsoft-makes-money-4798809 https://www.investopedia.com/how-microsoft-makes-money-47988... A third is for Office, a third for cloud, and a third is Windows. IMO Microsoft is a trillion-dollar company because of their long monopoly with Windows. It's so entrenched that their "punishment" for abusing their monopoly position (according to the DOJ) was to give all schools free copies of Microsoft Office, thereby forcing every parent to own a copy of Microsoft office to be able to read reports from their kids' schools. Ingenious! You know why they would fuck with developers? Because developers have choices now, and Microsoft doesn't like it when anyone has a choice besides Microsoft. They are remedying that.

scrollaway 5y ago

> Github may be the single greatest execution of embrace/extend/extinguish in computing history. Oh ffs are you even aware that MS didn't originally build GitHub? And your comment is super out of touch with what MS was doing in the 90s and early 00s. GitHub has plenty of competition, Gitlab for example is a fantastic platform, overall more powerful than GitHub as well. GH's strength is how much better it is for open source projects and if MS messes with that they'll be killing their golden goose. There is no all-powerful benevolent deity you can hand your code to and say "here, take care of this for me, for free, for all eternity". At some point private companies will have to get involved (or would you rather have your government get involved instead? Because I don't want your government hosting my code). So you want their incentives to be nicely aligned.

antonvs 5y ago
> Oh ffs are you even aware that MS didn't originally build GitHub? Purchasing a popular product is definitely qualifies for the "embrace" part of the strategy. But that's not unique to MS - AWS and Google follow similar playbooks, as does almost any large company that provide a platform-like product. The goal is to make the platform as sticky as possible for as many customers as possible.

austincheney 5y ago

Technically speaking, Microsoft is a public company. A private company implies not open to investment on a public market.

munk-a 5y ago
You are technically correct - but it's overly pedantic. Another commonly accepted definition of public companies outside of the US is companies that are partially or wholly owned by the government and thus act as a public service. This includes crown corporations in Canada or the USPS in the US. I think within the context they used that calling Microsoft a private company is fair since they have no obligation to "act in the public good".
Biganon 5y ago
This is not the first time I see this exact pedantry on HN and I can't help but feel the same way as with people who immediately yell "it's not free! Nothing in life is free!" when you talk about free healthcare or free public transportation. We know. We understand that it is technically correct. But it's completely useless in the discussion. You know perfectly well what the other person meant.

KronisLV 5y ago

> Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies. Well, for starters, there is GitLab which attempts to do a lot of what GitHub does, while allowing you to self host it: https://gitlab.com/gitlab-org/gitlab https://gitlab.com/gitlab-org/gitlab In some respects, i'd say that it does things better, for example, GitLab CI seems way easier to use in comparison to GitHub Actions: https://docs.gitlab.com/ee/ci/ https://docs.gitlab.com/ee/ci/ As far as alternative source code management platforms go, with some code review and issue management functionality added on top, there is also Gogs, which is a far more lightweight solution and better fits smaller deployments: https://github.com/gogs/gogs https://github.com/gogs/gogs It was also forked by the Gitea project, which is largely compatible with it but is also in active development: https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea Oh and there's also GitBucket which also attempts something similar to these: https://github.com/gitbucket/gitbucket https://github.com/gitbucket/gitbucket Now, you can probably hook those up with Jenkins or most other CI solutions, but personally i rather enjoyed how Gogs/Gitea integrated with Drone, which allowed for container based builds (no more plugin hell like in Jenkins): https://github.com/drone/drone https://github.com/drone/drone Then, you can throw in some additional tools, for example, for code analysis you could use SonarQube ( https://github.com/SonarSource https://github.com/SonarSource ) and for security scanning of infrastructure you could look at OpenVAS ( https://github.com/greenbone https://github.com/greenbone ). Oh, and on the organizational side something like Rocket.Chat ( https://github.com/RocketChat https://github.com/RocketChat ) or Mattermost ( https://github.com/mattermost https://github.com/mattermost ) for communication and perhaps OpenProject ( https://github.com/opf/openproject https://github.com/opf/openproject ) for project management. And there you have it! An open source based workflow that allows you to do most of the stuff that GitHub would let you! Of course, concessions might need to be made depending on what your definition of "open" is and whether you're okay with certain features being restricted to paid tiers in some software; if you do have a problem with that, there's also the possibility of looking at some libre alternatives, though that might lead to the occasional half-dead piece of software that doesn't really have financial incentives for maintenance anymore on anyone's part. That said, i believe that few choose this approach, because it's somewhat complicated to run all of that and all of the sudden you become responsible for your own SLAs, which many don't want. It's often the same reason why people just provision VPSes from AWS, instead of running their own servers in a server room. I think the amount of links to GitHub for open source above speaks volumes about the state of the industry. I don't think that there's an easy answer to the implications of this, maybe people should just familiarize themselves with the concept of "Service as a Software Substitute", so that they're at least aware of the trade-offs that their choices have: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...