7 ms·

The problem is with people's mindset that everything has to be on github. Large projects that dare to use self-hosted more fitting infrastructure like Phabricat

by cm3 11y ago

The problem is with people's mindset that everything has to be on github. Large projects that dare to use self-hosted more fitting infrastructure like Phabricator tend to be punished socially.

akerl_ 11y ago
I suspect what you're seeing as social punishment is people preferring the UX GitHub offers. That's just user choice in action
- yeukhon 11y ago
  Not really, the inconvenience of having to register another account (which often means another set of password) is quite a big deal for entry.
  - cm3 11y ago
    Usually you can log in with your github account.
    - deleted 11y ago
      [deleted]
  - fucking_tragedy 11y ago
    This. Github's UX is nice, but so is BitBucket's and other competitors'.
  - akerl_ 11y ago
    I'd consider "single sign on that connects me to tons of projects' repos to be great UX. Personally, it (and the centralized API) are big reasons I use GitHub to interact with projects whenever possible
    - cm3 11y ago
      Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
      - akerl_ 11y ago
        This gets brought up pretty much every time GitHub is mentioned on here, and I've never understood it. Using a hosted service like GitHub as a remote for your git repo doesn't "negate" the distributed aspect, any more than parking your car somewhere negates its ability to drive around. I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I can continue utilizing my git repo with all the distributed features it had before. I can (and have) continue to work while GitHub is down, I can export any of the additional data (issues, wiki, etc) that GitHub offers and store them just like I store all my backups, etc. Centralized hosting solutions can offer value, even to distributed tools. Where GitHub ends up conflicting with distributed workflows is when build pipelines or other systems are set up to rely on GitHub (Go dependencies, I'm looking at you). In cases like this, the user is making a choice to pin that piece of their infrastructure to a centralized service. And that's not always a bad call! If the value provided outweighs the harm done when the centralized service goes down or has other issues, it can be a good choice. It's up to the person designing their infrastructure to balance the risks and benefits, as with anything else. Specifically speaking to GitHub's lack of incentive to invest in extending distributed git features: that seems counter to actual events. They recently worked to develop their large file storage, and rather than release a closed source / centralized system, they released an open source extension that ties in with core git (https://git-lfs.github.com/ https://git-lfs.github.com/)
        cm3 11y ago
        I don't know how git-lfs is distributed. Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history properly without losing some details, so I firmly believe we have to make more of the git story distributed. Those features can be used by github in a friendly web interface, but like the git push and fetch model, it should exist in git itself. That way, it really won't matter where users make contributions, and it will solve the Phabricator vs github dilemma for big projects, plus allow for full archiving and porting of the data. Once your tickets and diff reviews are part of the git repository, you get features that enhance the user experience. I believe git-appraisal is using git's notes feature, and that's a good way to avoid extending the data model.
- cm3 11y ago
  Maybe, and even despite the missing code review functionality, if you compare it to stuff like Phabricator.
StevePerkins 11y ago
What does "punished socially" even mean? Unable to attract as many contributors? The cold reality is that most open source projects aren't really TRYING to attract contributors. Small-time hobbyists often don't want to play with others in their personal project sandboxes, and big-time projects with high profile usually put up high barriers to contribution. Unable to attract as many end-users, or as much public mindshare? Now this makes more sense. Many of the high-profile moves to GitHub are really about P.R., and signaling friendless to the developer community (e.g. Microsoft's recent image re-branding efforts). Not having a GitHub presence DOES make you less visible and more isolated from developers today. Either way, I would argue that GitHub is really just a sort of Facebook or Twitter-like presence for software organizations. A way to draw attention, publicity, or mindshare from the public... but often merely a hosting mirror, and not even the primary toolset through which the software is actually developed. This being the case, who cares if GitHub is dominant? Or SourceForge ten years ago, or whatever the next popular thing might be ten years from now? In most cases, it's effectively about as consequential as having to shift your focus from MySpace to Facebook when the audience moves.
- cm3 11y ago
  Projects that use github merely as a mirror always run into the issue that of all features pull requests are the only one that you cannot disable, and they have to deal with closing pull requests, pointing to the real contribution process. So far github has always rejected the possibility to disable pull requests. The problem with Sourceforge is that we now have a thousand unmaintained projects only available there as an archive and are risking to lose them if we're not careful. It seems easier to build a github-to-new_thing service as long as github cooperates (web api throttling). If git is to be the dominant tool, it should support a wiki, tickets, code review and more complete distribution. Kinda like Fossil++. I hope git-appraisal or at least the idea gets more popular.
- zanny 11y ago
  This is incredibly shortsighted, but the rebuttal is simple: > This being the case, who cares if GitHub is dominant? Or SourceForge, or whatever the next popular thing might be. For one, I do, and for two - why was sourceforge changing their business model to shady predation a problem? It was not because they were a website on the Internet - there are millions of URLs of clickjackers or other malware you could visit and harm your computer with, but you rarely see them. The problem was that a ton of open source software had mindshare on sourceforge, that remains a problem to this day, and it took years to move most projects away from that hostile environment. Plenty of very useful free software remains hosted on sourceforge, and there are plenty of reasons - developer inertia, community loss from switching, legacy systems in place that aren't portable, lack of interest in learning new tools, and many more - but the reasons matter less than the result - that we have thousands of projects staying on a website known to infect people with malware. Most of that software remains as portable as anything on gitub - often even moreso, because sourceforge offered many fewer developement ecosystem features than github now does - but has no switched for whatever reason. We can go after the individual projects and heckle them until we can get them off sourceforge, but that is a ton of effort and mental energy we could have better used making good software. Which is fundamentally why the decision between github and any open source alternative is so important. This is not a question of benevolence, or even time - Github, Inc is a private company hosting a proprietary website that has 11 million accounts and 29 million source repositories today. Any action they take can destroy either trust in the platform (why exactly do you trust a proprietary web service, again?) or its usability for whatever purpose you depend on it for, and since it is proprietary there is no recourse. You just have to repeat the sourceforge hell and somehow move off of it as a hosting platform - except you might have drunk the koolaid, and now have your issues, releases, build service, wiki, and website all bound to the github platform. If moving just the source control, release hosting, and a forum from Sourceforge was bad, trying to get away from Github would be much, much worse. But all these migrating projects should know better. They were already betrayed once by proprietary software they depended on, but are taking familiarity and mindshare over the security to never have that happen again. At least with gitlab, when Gitlab Inc jumps the shark, you - or anyone else could spin up the lifeboat to easily and seamlessly save your community with. And that collateral alone means Gitlab Inc. is much less likely to betray you for profit. It is not a question of if. Unless Github open sources itself, and that is impossibly unlikely considering how huge their code base must be now and how many football fields of lawyers they would need to prune their internal code, a proprietary software project must eventually act against your interests because you are not in control of it, no matter the intention of the creator. If you are going to have to bite the transition bullet, you might as well only have to do it once. Considering the parity between github and gitlab, I have never met anyone who would literally refuse to contribute to a project because its not on github, you just miss casual eyes that are more common there because the platform has captured more userbase. But that userbase control is so dangerous, and we should all care enough to try to correct for it when we can, if it doesn't negatively impact us much. And honestly, a project like Python would have been perfect for it - they won't see a dearth of developer interest just because they are using the second most popular source control web service out there.
technion 11y ago
I'm looking at projects like nginx that had to setup Github mirrors basically out of pressure. It serves no value for the project because they use a different system for version control, code review and ticketing, yet someone had to go setup a Github mirror because.... people expect to see you on Github?

by cm3 11y ago

The problem is with people's mindset that everything has to be on github. Large projects that dare to use self-hosted more fitting infrastructure like Phabricator tend to be punished socially.

akerl_ 11y ago

I suspect what you're seeing as social punishment is people preferring the UX GitHub offers. That's just user choice in action

yeukhon 11y ago
Not really, the inconvenience of having to register another account (which often means another set of password) is quite a big deal for entry.
- cm3 11y ago
  Usually you can log in with your github account.
  - deleted 11y ago
    [deleted]
- fucking_tragedy 11y ago
  This. Github's UX is nice, but so is BitBucket's and other competitors'.
- akerl_ 11y ago
  I'd consider "single sign on that connects me to tons of projects' repos to be great UX. Personally, it (and the centralized API) are big reasons I use GitHub to interact with projects whenever possible
  - cm3 11y ago
    Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
    - akerl_ 11y ago
      This gets brought up pretty much every time GitHub is mentioned on here, and I've never understood it. Using a hosted service like GitHub as a remote for your git repo doesn't "negate" the distributed aspect, any more than parking your car somewhere negates its ability to drive around. I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I can continue utilizing my git repo with all the distributed features it had before. I can (and have) continue to work while GitHub is down, I can export any of the additional data (issues, wiki, etc) that GitHub offers and store them just like I store all my backups, etc. Centralized hosting solutions can offer value, even to distributed tools. Where GitHub ends up conflicting with distributed workflows is when build pipelines or other systems are set up to rely on GitHub (Go dependencies, I'm looking at you). In cases like this, the user is making a choice to pin that piece of their infrastructure to a centralized service. And that's not always a bad call! If the value provided outweighs the harm done when the centralized service goes down or has other issues, it can be a good choice. It's up to the person designing their infrastructure to balance the risks and benefits, as with anything else. Specifically speaking to GitHub's lack of incentive to invest in extending distributed git features: that seems counter to actual events. They recently worked to develop their large file storage, and rather than release a closed source / centralized system, they released an open source extension that ties in with core git (https://git-lfs.github.com/ https://git-lfs.github.com/)
      - cm3 11y ago
        I don't know how git-lfs is distributed. Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history properly without losing some details, so I firmly believe we have to make more of the git story distributed. Those features can be used by github in a friendly web interface, but like the git push and fetch model, it should exist in git itself. That way, it really won't matter where users make contributions, and it will solve the Phabricator vs github dilemma for big projects, plus allow for full archiving and porting of the data. Once your tickets and diff reviews are part of the git repository, you get features that enhance the user experience. I believe git-appraisal is using git's notes feature, and that's a good way to avoid extending the data model.
cm3 11y ago
Maybe, and even despite the missing code review functionality, if you compare it to stuff like Phabricator.

StevePerkins 11y ago

What does "punished socially" even mean? Unable to attract as many contributors? The cold reality is that most open source projects aren't really TRYING to attract contributors. Small-time hobbyists often don't want to play with others in their personal project sandboxes, and big-time projects with high profile usually put up high barriers to contribution. Unable to attract as many end-users, or as much public mindshare? Now this makes more sense. Many of the high-profile moves to GitHub are really about P.R., and signaling friendless to the developer community (e.g. Microsoft's recent image re-branding efforts). Not having a GitHub presence DOES make you less visible and more isolated from developers today. Either way, I would argue that GitHub is really just a sort of Facebook or Twitter-like presence for software organizations. A way to draw attention, publicity, or mindshare from the public... but often merely a hosting mirror, and not even the primary toolset through which the software is actually developed. This being the case, who cares if GitHub is dominant? Or SourceForge ten years ago, or whatever the next popular thing might be ten years from now? In most cases, it's effectively about as consequential as having to shift your focus from MySpace to Facebook when the audience moves.

cm3 11y ago
Projects that use github merely as a mirror always run into the issue that of all features pull requests are the only one that you cannot disable, and they have to deal with closing pull requests, pointing to the real contribution process. So far github has always rejected the possibility to disable pull requests. The problem with Sourceforge is that we now have a thousand unmaintained projects only available there as an archive and are risking to lose them if we're not careful. It seems easier to build a github-to-new_thing service as long as github cooperates (web api throttling). If git is to be the dominant tool, it should support a wiki, tickets, code review and more complete distribution. Kinda like Fossil++. I hope git-appraisal or at least the idea gets more popular.
zanny 11y ago
This is incredibly shortsighted, but the rebuttal is simple: > This being the case, who cares if GitHub is dominant? Or SourceForge, or whatever the next popular thing might be. For one, I do, and for two - why was sourceforge changing their business model to shady predation a problem? It was not because they were a website on the Internet - there are millions of URLs of clickjackers or other malware you could visit and harm your computer with, but you rarely see them. The problem was that a ton of open source software had mindshare on sourceforge, that remains a problem to this day, and it took years to move most projects away from that hostile environment. Plenty of very useful free software remains hosted on sourceforge, and there are plenty of reasons - developer inertia, community loss from switching, legacy systems in place that aren't portable, lack of interest in learning new tools, and many more - but the reasons matter less than the result - that we have thousands of projects staying on a website known to infect people with malware. Most of that software remains as portable as anything on gitub - often even moreso, because sourceforge offered many fewer developement ecosystem features than github now does - but has no switched for whatever reason. We can go after the individual projects and heckle them until we can get them off sourceforge, but that is a ton of effort and mental energy we could have better used making good software. Which is fundamentally why the decision between github and any open source alternative is so important. This is not a question of benevolence, or even time - Github, Inc is a private company hosting a proprietary website that has 11 million accounts and 29 million source repositories today. Any action they take can destroy either trust in the platform (why exactly do you trust a proprietary web service, again?) or its usability for whatever purpose you depend on it for, and since it is proprietary there is no recourse. You just have to repeat the sourceforge hell and somehow move off of it as a hosting platform - except you might have drunk the koolaid, and now have your issues, releases, build service, wiki, and website all bound to the github platform. If moving just the source control, release hosting, and a forum from Sourceforge was bad, trying to get away from Github would be much, much worse. But all these migrating projects should know better. They were already betrayed once by proprietary software they depended on, but are taking familiarity and mindshare over the security to never have that happen again. At least with gitlab, when Gitlab Inc jumps the shark, you - or anyone else could spin up the lifeboat to easily and seamlessly save your community with. And that collateral alone means Gitlab Inc. is much less likely to betray you for profit. It is not a question of if. Unless Github open sources itself, and that is impossibly unlikely considering how huge their code base must be now and how many football fields of lawyers they would need to prune their internal code, a proprietary software project must eventually act against your interests because you are not in control of it, no matter the intention of the creator. If you are going to have to bite the transition bullet, you might as well only have to do it once. Considering the parity between github and gitlab, I have never met anyone who would literally refuse to contribute to a project because its not on github, you just miss casual eyes that are more common there because the platform has captured more userbase. But that userbase control is so dangerous, and we should all care enough to try to correct for it when we can, if it doesn't negatively impact us much. And honestly, a project like Python would have been perfect for it - they won't see a dearth of developer interest just because they are using the second most popular source control web service out there.

technion 11y ago

I'm looking at projects like nginx that had to setup Github mirrors basically out of pressure. It serves no value for the project because they use a different system for version control, code review and ticketing, yet someone had to go setup a Github mirror because.... people expect to see you on Github?