10 ms·

Embrace, extend, and finally extinguish – Microsoft plays their hand

139 points by MartijnBraam 6y ago

api 6y ago
It’s not a conspiracy. If customers demanded decentralized, companies would be pushed down that path. They don’t. Customers demand ease of use, features, and speed, and all that is technically easier to deliver with a centralized model. Why impose extra engineering cost for decentralization almost nobody cares about? GitHub’s largest value add IMHO is search, and that is probably the hardest thing to decentralize.
- homarp 6y ago
  can you elaborate on the 'indexing git repo for search is hard to decentralize' part?
  - api 6y ago
    Fast search over huge data sets in distributed networks of unreliable and possibly untrustworthy nodes is really really hard. Nobody has all the data in one place and the indices are huge and cross cut the data. It can be done, but making it perform like GitHub search with sub-second returns on most queries and with full coverage of the entire data set would be an amazing achievement. The CAP theorem means you can’t do it without making some sacrifices. There is a reason nobody has even seriously attempted a decentralized web search engine despite the obvious motivations.
- Tarq0n 6y ago
  The whole point of "extend" is that the extensions are proprietary. If GitHub's fork and pull request features were standards that are portable and that other repository vendors could implement this wouldn't be a problem.
  - DenseComet 6y ago
    I see the same interface present on GitLab and Gitea, both great open source projects that provide selfhosted (and hosted) alternatives to Github. It was pretty novel when it was introduced, but not anymore.
    - Tarq0n 6y ago
      Just because others have copied the interface doesn't make it 1) portable 2) part of the standard 3) a protocol. You'd ideally want all three for a viable alternative to email-based patches.
      - sreevisakh 6y ago
        That's exactly what is needed. But we will likely just reinvent SMTP. Why not just build better interfaces (web, gui and cli) around SMTP? On the other hand, SMTP is starting to show its age - too many parts, lack of privacy and abuse. Wish there was a new protocol in the spirit of SMTP, but modern design - something like what Matrix is to IRC.
- bccdee 6y ago
  Github absolutely would not make itself interoperable just because users wanted it to. That would be a terrible business move -- it would lead to Github hemorrhaging users and projects as they left to other, smaller competitors while still begin able to interact with the users and projects that remain on Github. It's not Github's job to do what customers want. It's Github's job to do whatever will make them money, whether it's good for customers & the broader tech community or not. You're right that it's not a conspiracy though -- there's nothing secret about this at all. It's just business.
  - api 6y ago
    You can already mirror a repo easily to/from GitHub, and moving is pretty easy unless you are deeply invested in GitHub proprietary features. People use GitHub because people use GitHub. It’s a classic network effect.
    - bccdee 6y ago
      I mean like me forking your Github repo to Gitlab and then submitting a PR from my Gitlab fork to your Github repo. Can't do that. If I want to contribute to a Github project, I need a Github account. That doesn't apply to interoperable protocols like email -- you can use gmail and I can use yahoo mail, or even a self-hosted mail server, and we can still send messages to each other. This would certainly be doable, but they wouldn't do it, because it would damage their market share.
vikramkr 6y ago
What is Microsoft extinguishing here? Email?
- fnord123 6y ago
  Distributed git development. Moving us back to central repos.
  - dgrin91 6y ago
    But you can still do distributed repos with github... nothing it preventing you from changing your remote origin...
    - nikivi 6y ago
      Only issue is if you decide to use GitHub features like issues/prs or comments on code, those won't be transferrable I think. At least easily.
      - Pfhreak 6y ago
        Is it really though? The tools might be proprietary, but the workflow should be easy to move. E.g. You need to have a code review before a commit is merged. It happens that Github has a good set of tools for this, but if you decided that on date X you wanted to move away I don't think it would be that hard to shift away. You'd have the same mandate about code review, you just point people at a different tool set to do it.
      - kanox 6y ago
        Email archives are even harder to transfer, and to make sense of in general. For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
        angio 6y ago
        > Email archives are even harder to transfer, and to make sense of in general. Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0]. > For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title. In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit. [0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archive%20into%20a%20new%20mailing%20list%3F https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...
deleted 6y ago
[deleted]
belltaco 6y ago
>They embraced git, and then rather than building an interface on top of email — the collaboration mechanism that git was designed to use, and which is still used for Linux kernel development — they built their “pull requests” mechanism. How is git designed to use email? >Sarah Novotny, Microsoft employee, transitive owner of GitHub, and patroness saint of conflicts of interests Followed by: >I represent sourcehut, a GitHub competitor which does what GitHub wouldn’t — interoperate with open, distributed protocols, and in the form of 100% free and open-source software Yeah no conflict of interest there /s
- godzillabrennus 6y ago
  Love the pricing page. It literally doesn’t list features to distinguish the variations by...
  - trulyrandom 6y ago
    Isn't the whole point that there aren't any differences? All users get the same features. You choose how much you pay.
  - adsjhdashkj 6y ago
    If you read the big, ~read~ red and nearly glowing banner above it you'd see that: > Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site. There are no features to distinguish the variations by - they're all donations, effectively. Though i admit they could improve that UX further still. But, imo - the entire product is not super polished for "mainstream users" (of which i mean nothing against), so polish in this specific area might be cart-before-horse.
  - avery42 6y ago
    Literally the first lines of text on the page: > sr.ht is the hosted instance of sourcehut and provides paid services to its users. On sr.ht, all plans have access to the same features, at the same level. You should pick the plan which best matches your financial needs and best represents the level of investment you have in sourcehut. From: https://sourcehut.org/pricing/ https://sourcehut.org/pricing/
kanox 6y ago
Good: Fuck plain-text email. We should stop relying on duct-taped solutions from the 70s. Web-based code review solutions are vastly better.
- santoshalper 6y ago
  Agree. The problem with github is not that it is web-based instead of email-based. The problem is that it is a proprietary walled garden. An open source direct competitor to github is what's needed, not going back to email as the UX for development.
  - kanox 6y ago
    I don't see a shortage of github competitors. For example GitLab works well and also allows for self-hosting.
    - bccdee 6y ago
      But Gitlab is its own walled garden (albeit an open-source one). What we'd ideally have is a platform-agnostic PR protocol. Sadly, we're not likely to get one. That being said, I agree that "let's all use plain-text email" isn't a very good alternative. It's perfectly possible to use Gitlab or Gitea and have the web UI experience without marrying yourself to a proprietary ecosystem.
      - sreevisakh 6y ago
        Is the plain-text the problem? Because Gitlab/hub use them too - as markdown. Their UI layer is built on top of it. Why not do the same thing for emails? Plain-text in SMTP as a communication layer, but a rich UI layer on top of that at client level? Make a combined mail + list + git client?
        bccdee 6y ago
        I don't have any inherent problem with plain text, I just think that the pull/push/PR workflow is nicer than emailing patches to a mailing list.
chomp 6y ago
This feels like an advertisement wrapped in a bad take. Speaking as someone who has a couple commits in the Linux kernel, yes the email thing is a pain to get started. Configuring your client to do the text thing, keeping up with conversations, learning who's who, you definitely can't jump straight in. The only way I was able to stay sane is setting up a bunch of filters to tag conversations and people. And that's not even mentioning the different patch submission guidelines, perl scripts I have to run, and other random things to make the patch even just readable by the community. Configuring all this stuff is definitely a barrier to entry. Now what tooling looks like to make it easier, that's an entire different conversation. Email has worked for the Linux dev community for decades and that should be protected and not disrupted. However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.
- ddevault 6y ago
  >However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously. From TFA: > I agree that the UX of email-driven development could be better! This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding: https://git-send-email.io https://git-send-email.io
  - corobo 6y ago
    All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible
    - ddevault 6y ago
      This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-... After the initial setup, send-email is way faster.
      - 6y ago
rsweeney21 6y ago
This is an ad for sourcehut, a GitHub/Microsoft competitor.
- eterps 6y ago
  Sourcehut is competing with Github/Microsoft? That's new to me :-D Focusing on a niche hardly counts as competition to me. 'an alternative to Github' sounds more realistic.
eterps 6y ago
What has always suprised me about open source software is that the source is always 'out of band'. I can imagine a future where all open source software you use has an 'edit source' function (as opposed to a mere view-source function we have on the web currently). Even more useful would be the ability to make a change within a certain context, similar to how 'inspect element' works in the browser. A change in the source would result in a patch which can then stay 'personal' or be automatically shared with others looking for similar functionality, or getting noticed by the maintainers who might incorporate it in the main releases after a refactoring. Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future.
- Santosh83 6y ago
  There used to be an assembler called RosAsm in the early 00s, whose author insisted on including the full source of the assembler inside the PE executable. That way you could edit RosAsm's source (written in the same assembler dialect) and assemble it by itself and produce a new PE executable.
- andreareina 6y ago
  That's exactly how emacs works actually[1]. Getting the documentation on a function or variable contains a link to the file that defines it, which you can then edit. If you eval the expression then all later uses of the function will have the new behavior, otherwise it'll take effect on next startup. I've done exactly this to backport some changes from future versions. [1] http://prntscr.com/u6yfnp http://prntscr.com/u6yfnp
  - frank2 6y ago
    Yes, I really like how easy it is to view the definition (which might be written in Emacs Lisp or C) of any function callable from Emacs Lisp. (But I never edit any Emacs Lisp files that come with Emacs: sometimes though I will make sure such a file has been loaded, then override a function definition with one I wrote myself.)
    - 6y ago
toyg 6y ago
Don't particularly agree with the tone of this "advertorial" but I agree that the issue of the ecosystem becoming excessively github-centric is real. I wish Github, Gitlab, sourcehut and (why not) Atlassian, would sit down and hash out a bunch of formats and protocols that make it easy to collaborate across and off them. A galaxy of tools, with everyone using their favorite one, would be a fabulous step forward for developers everywhere. I know it's not going to happen anytime soon, but one can dream.
- kanox 6y ago
  It's already trivial to move code between git service providers, or even run your own. Code review and issue trackers are harder because they're effectively forums are only useful when centralized.
  - ashtonkem 6y ago
    They’re also fiendishly hard to design right.
  - ddevault 6y ago
    >Code review and issue trackers are harder because they're effectively forums are only useful when centralized. What? This claim requires evidence.
- mikepurvis 6y ago
  GitLab has been at least tracking federated instances as a wishlist item since 2018, and it was marked for a time as "Vision FY20": https://gitlab.com/gitlab-org/gitlab/-/issues/6468 https://gitlab.com/gitlab-org/gitlab/-/issues/6468 I doubt that GitHub would have much incentive to come to the table on any of this, but if GitLab can at least figure it out between instances of itself, it seems likely that sr.ht and BitBucket would be motivated to implement whatever the system is, and eventually social pressure would force GitHub to cooperate with it as well.
- bccdee 6y ago
  Yeah I think there's a strange focus on vindicating plain-text email in that article instead of criticizing GitHub for being a closed ecosystem. Plain-text email is kind of a huge pain in the ass to use, and the PR web GUI system is nice. The focus should be on interoperable PRs, not resurrecting plain-text email.
tboyd47 6y ago
Calls to mind the way Google, Facebook, etc. took over OAuth by flooding the committee with their own representatives and turned it into something completely different with OAuth2.
- sreevisakh 6y ago
  Reminded me of a quote from another one of Drew's blog posts: "The web and web browsers have become Lovecraftian horrors of an unprecedented scale. They’ve long since left “scope creep” territory and entered “oh my god please just stop” territory, and are trucking on through to hitherto unexplored degrees of obscene scope." [1]. I sometimes feel like many standards and software (incl open source) are designed to make it impossible for an individual or small team to implement or manage. [1] https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop.html https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop...
algorithmsRcool 6y ago
I have a hard time taking this seriously. Email is a pain to use compared to a dedicate feature UI. I think the real problem is the need for a standardized pull request protocol that people can wrap. Then let people use email, a website, an API or whatever they want.
- koluna 6y ago
  100% this. I will take GitHub’s PR process over emailing diffs any day. It’s just a matter of improving user productivity.
  - ddevault 6y ago
    Absolute nonsense. Emails are far more productive. I've made a video demonstrating the difference here: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
    - koluna 6y ago
      Literally nothing from what you showed is a pleasant customer experience. Overly complex workflow that can be simplified by what GitHub is doing. Think of a beginner developer who wants to learn how to contribute to an open source project. If they would be put through the process you showed, it will be a meat grinder that is going to be error prone. Zero need for that when GitHub has a great UX that focuses on getting shit done instead of fiddling with conventions from the 90s.
      - cnst 6y ago
        That's why there's shell completion, and history search; then with practice, keyboard shortcuts as well; all vastly improve productivity. I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. But that's not the case at all. Moreover, GitHub has so many quirks, that most Enterprise shops don't use it internally for their own internal projects (unless they release said projects into OSS); so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. Compare this with email. As the original article reveals, Linux and OpenBSD happen to have almost entirely identical workflows for patch submission, which is actually REALLY weird, considering that the two projects have entirely different histories, methodology, and use entirely different revision control systems, where OpenBSD still uses CVS, yet Linus Torvalds hated CVS so much, I recall that he refused to use it even before Git was ready and the licences for the predecessor system have already been withdrawn (I recall he hated CVS so much he simply used plain patches or tarballs).
martius 6y ago
Pull-requests and forks are only a piece here. It's not the only one implemented by tools that extend Git (Phabricator and Gerrit, for instance, support pre-commit workflow). Github also brings a bug tracker (albeit a simple one), discoverability, hosting (obviously) and integration with many useful tools (CI, documentation generators, etc). All of this is easy to use. These pieces greatly contribute to the success of many open-source projects (of various sizes). Github "extinguishes" alternative because of this, not because it designed an alternative to email-based workflows. I suppose that many projects (open-source or not) want to use tools that extends Git. Maybe what we need is a standard making these tools interoperable and open.
- bccdee 6y ago
  Yeah, I agree. There are open-source Github clones like Gitlab and Gitea that still follow Github's web UI model, so I think it's weird to pose this as a conflict between Github and plain-text email when it's two separate conflicts: one between proprietary Github software and other open-source hosted git systems, and the other between the plain-text email model and the more popular web UI model.
  - Seirdy 6y ago
    I responded to this argument in another comment: https://news.ycombinator.com/item?id=24295610 https://news.ycombinator.com/item?id=24295610 TLDR: the alternatives are also centralized and give you vendor lock-in since issues/PRs are tied to the instance.
simonkafan 6y ago
tl;dr: A Github competitor is looking for reasons to rage against Github/Microsoft.
nova22033 6y ago
I represent sourcehut, a GitHub competitor Maybe lead with that?
johnduhart 6y ago
The author took an article about somebody suggesting that having email be the only mechanism for contributing to the Linux kernel might be a barrier to entry for new developers, and construed it into this piece on how the evil Micro$oft is looking to dismantle distributed git development. From the original article: > Picking her words carefully, she said work is being done towards “moving from a more text-based, email-based, or not even moving from, but having a text-based, email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with." That seems like an entirely fair statement to make for somebody who is on the board of The Linux Foundation.
- cxr 6y ago
  The interesting thing to note is that the "way that developers who have grown up in the last five or ten years" refers to the way of working on GitHub, and that GitHub made it deliberately difficult to interoperate with other development models (like the kernel's, or old-style Bugzilla-and-patches) for business reasons. When you start out with trying to be a social network for developers, you'll happily take inspiration from the way Facebook divides the world into "Facebook" and "not Facebook", which naturally results in erecting barriers between your userbase and outsiders so long as those barriers can feed into your growth strategy of converting the outsiders into even more users. Having said that, this blog post is foremost not actually a criticism of Microsoft/GitHub, but instead trying to draw attention to Sourcehut. Sourcehut is not a good example of how to solve GitHub's problems; if we were in a hypothetical world where the choices were GitHub or Sourcehut, the skew would remain forever what it is today, and the lead developer doesn't seem capable of understanding why and fixing Sourcehut's flaws.
  - sreevisakh 6y ago
    I feel that the author is drawing attention to Sourcehut because there are no alternatives that use the workflow he is pitching. It's not as great as Github at the moment, but he is trying to show what it can be. He always comes off as incapable of fixing sourcehut's flaws because a lot of suggestions he gets are contradictory to the fundamental design he has in mind. Despite this, sourcehut is making steady improvements. Drew also puts up invaluable resources which helps people like me get into the email workflow. Sourcehut currently has a steep learning curve, after which you would immediately recognize the design as a safer bet in the long term.
mouldysammich 6y ago
There are an awful lot of people in the comments here calling this an advertisement and being upset about it. How are those that are upset about it not upset that this is an obvious conflict of interest and advertisement for microsofts github platform.
- cnst 6y ago
  This is the most upsetting part about it, IMHO. The reason Microsoft pays a salary to this person is precisely to get GitHub mentioned into these sorts of conversations -- even though it's widely known that GitHub doesn't support such usecases. But, of course, there's never any time to mention such facts; but here's an example if anyone's curious: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne.... Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source.
  - kasabali 6y ago
    > Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source. it's upsetting indeed. I'm 100% sure had he didn't mentioned SorceHut the same people would've complained instead that how there were no projects for improving mail based workflow, why didn't OP offer a suggestion, or that it's open source so why he didn't shut up and wrote a patch instead.
koluna 6y ago
This person seems very upset about something that customers actually love. Speaking for myself —- GitHub pull requests are amazing. I have an easy way to collaborate and propose changes to my projects through a human-friendly interface that doesn’t require me to use tech from early 90s. Surprise - technology evolves. We’re not all going to stick with BBS just because “it’s a standard everyone uses, ZOMG don’t extinguish it!”
- croes 6y ago
  Wait until you need a Microsoft account for accessing github, wait until your account gets blocked. All of sudden all of your code is out of reach.
  - koluna 6y ago
    Wait until your mail server goes down or experiences a malfunction that erases all mail threads. Wait until your hard drive fails and you lose all the code. There can be a lot of hypotheticals. GitHub does not preclude you from using git for what it’s intended to be - a distributed source control management system. If you don’t have backups, that’s on you.
    - croes 6y ago
      "GitHub does not preclude you from using git for what it’s intended to be", yet. Never trust MS, FB, Amazon, etc. Sooner or later they lock you in or kill the service you rely on.
    - sreevisakh 6y ago
      IMAP allows you to have multiple synchronized copies of the entire mailbox. And you can depend on multiple email servers (and IDs) if the mail server is unreliable. Email has fewer single point failures. Git may help you backup code against failure of Github/lab. But it doesn't prevent you from losing ability of issue PRs or accessing issue trackers.
    - ddevault 6y ago
      Ah yes, because apparently no one besides GitHub is qualified to run reliable services. https://status.sr.ht/ https://status.sr.ht/ https://www.githubstatus.com/ https://www.githubstatus.com/ https://sourcehut.org/blog/2020-07-03-how-we-monitor-our-services/ https://sourcehut.org/blog/2020-07-03-how-we-monitor-our-ser... https://drewdevault.com/2019/01/13/Backups-and-redundancy-at-sr.ht.html https://drewdevault.com/2019/01/13/Backups-and-redundancy-at... When your mail server goes down, nothing happens, the internet continues to function normally and then when it comes back up you will receive all of the emails that were sent to you when it was offline. If the mailing list goes down, you can still send emails and you're collagues probably won't even notice the outage because they were CC'd. When the mailing list comes back up, it'll receive all of those emails in the same way and get caught back up. When GitHub goes down, everything stops. And GitHub goes down often!
PaulDavisThe1st 6y ago
This is a bit tangential, but I wanted to mention how the (GPL'ed) ardour project decided to view github. We got burned by the SourceForge apocalypse back in the mid-2000's, which led to me (the BDFL) declaring that the project would never use a 3rd party host for our source code repository ever again. Granting a 3rd party the level of control that SF had (and then abused) is a non-starter for us. This means that github was never an option for us. .... as the canonical repository. However, we recognized the value of the tools that github offered, particularly allowing random 3rd party developers to create patches in quite effective ways. Some of the their other tools are useful, too. So, we self-host a gitlab instance at ardour.org, and that acts as our canonical repository, but we use hooks to push all commits to the github version automatically. Random 3rd parties can use any and all of the github toolset with our code (as can we), but we have no reliance on github in any important way. We don't even have much reliance on gitlab either - it exists only to provide access roles and account management on top of the bare git server. We don't use any of gitlab's "features" either. After about 5 years, this continues to work well for us.

139 points by MartijnBraam 6y ago

api 6y ago

It’s not a conspiracy. If customers demanded decentralized, companies would be pushed down that path. They don’t. Customers demand ease of use, features, and speed, and all that is technically easier to deliver with a centralized model. Why impose extra engineering cost for decentralization almost nobody cares about? GitHub’s largest value add IMHO is search, and that is probably the hardest thing to decentralize.

homarp 6y ago
can you elaborate on the 'indexing git repo for search is hard to decentralize' part?
- api 6y ago
  Fast search over huge data sets in distributed networks of unreliable and possibly untrustworthy nodes is really really hard. Nobody has all the data in one place and the indices are huge and cross cut the data. It can be done, but making it perform like GitHub search with sub-second returns on most queries and with full coverage of the entire data set would be an amazing achievement. The CAP theorem means you can’t do it without making some sacrifices. There is a reason nobody has even seriously attempted a decentralized web search engine despite the obvious motivations.
Tarq0n 6y ago
The whole point of "extend" is that the extensions are proprietary. If GitHub's fork and pull request features were standards that are portable and that other repository vendors could implement this wouldn't be a problem.
- DenseComet 6y ago
  I see the same interface present on GitLab and Gitea, both great open source projects that provide selfhosted (and hosted) alternatives to Github. It was pretty novel when it was introduced, but not anymore.
  - Tarq0n 6y ago
    Just because others have copied the interface doesn't make it 1) portable 2) part of the standard 3) a protocol. You'd ideally want all three for a viable alternative to email-based patches.
    - sreevisakh 6y ago
      That's exactly what is needed. But we will likely just reinvent SMTP. Why not just build better interfaces (web, gui and cli) around SMTP? On the other hand, SMTP is starting to show its age - too many parts, lack of privacy and abuse. Wish there was a new protocol in the spirit of SMTP, but modern design - something like what Matrix is to IRC.
bccdee 6y ago
Github absolutely would not make itself interoperable just because users wanted it to. That would be a terrible business move -- it would lead to Github hemorrhaging users and projects as they left to other, smaller competitors while still begin able to interact with the users and projects that remain on Github. It's not Github's job to do what customers want. It's Github's job to do whatever will make them money, whether it's good for customers & the broader tech community or not. You're right that it's not a conspiracy though -- there's nothing secret about this at all. It's just business.
- api 6y ago
  You can already mirror a repo easily to/from GitHub, and moving is pretty easy unless you are deeply invested in GitHub proprietary features. People use GitHub because people use GitHub. It’s a classic network effect.
  - bccdee 6y ago
    I mean like me forking your Github repo to Gitlab and then submitting a PR from my Gitlab fork to your Github repo. Can't do that. If I want to contribute to a Github project, I need a Github account. That doesn't apply to interoperable protocols like email -- you can use gmail and I can use yahoo mail, or even a self-hosted mail server, and we can still send messages to each other. This would certainly be doable, but they wouldn't do it, because it would damage their market share.

vikramkr 6y ago

What is Microsoft extinguishing here? Email?

fnord123 6y ago
Distributed git development. Moving us back to central repos.
- dgrin91 6y ago
  But you can still do distributed repos with github... nothing it preventing you from changing your remote origin...
  - nikivi 6y ago
    Only issue is if you decide to use GitHub features like issues/prs or comments on code, those won't be transferrable I think. At least easily.
    - Pfhreak 6y ago
      Is it really though? The tools might be proprietary, but the workflow should be easy to move. E.g. You need to have a code review before a commit is merged. It happens that Github has a good set of tools for this, but if you decided that on date X you wanted to move away I don't think it would be that hard to shift away. You'd have the same mandate about code review, you just point people at a different tool set to do it.
    - kanox 6y ago
      Email archives are even harder to transfer, and to make sense of in general. For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
      - angio 6y ago
        > Email archives are even harder to transfer, and to make sense of in general. Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0]. > For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title. In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit. [0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archive%20into%20a%20new%20mailing%20list%3F https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...

deleted 6y ago

[deleted]

belltaco 6y ago

>They embraced git, and then rather than building an interface on top of email — the collaboration mechanism that git was designed to use, and which is still used for Linux kernel development — they built their “pull requests” mechanism. How is git designed to use email? >Sarah Novotny, Microsoft employee, transitive owner of GitHub, and patroness saint of conflicts of interests Followed by: >I represent sourcehut, a GitHub competitor which does what GitHub wouldn’t — interoperate with open, distributed protocols, and in the form of 100% free and open-source software Yeah no conflict of interest there /s

godzillabrennus 6y ago
Love the pricing page. It literally doesn’t list features to distinguish the variations by...
- trulyrandom 6y ago
  Isn't the whole point that there aren't any differences? All users get the same features. You choose how much you pay.
- adsjhdashkj 6y ago
  If you read the big, ~read~ red and nearly glowing banner above it you'd see that: > Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site. There are no features to distinguish the variations by - they're all donations, effectively. Though i admit they could improve that UX further still. But, imo - the entire product is not super polished for "mainstream users" (of which i mean nothing against), so polish in this specific area might be cart-before-horse.
- avery42 6y ago
  Literally the first lines of text on the page: > sr.ht is the hosted instance of sourcehut and provides paid services to its users. On sr.ht, all plans have access to the same features, at the same level. You should pick the plan which best matches your financial needs and best represents the level of investment you have in sourcehut. From: https://sourcehut.org/pricing/ https://sourcehut.org/pricing/

kanox 6y ago

Good: Fuck plain-text email. We should stop relying on duct-taped solutions from the 70s. Web-based code review solutions are vastly better.

santoshalper 6y ago
Agree. The problem with github is not that it is web-based instead of email-based. The problem is that it is a proprietary walled garden. An open source direct competitor to github is what's needed, not going back to email as the UX for development.
- kanox 6y ago
  I don't see a shortage of github competitors. For example GitLab works well and also allows for self-hosting.
  - bccdee 6y ago
    But Gitlab is its own walled garden (albeit an open-source one). What we'd ideally have is a platform-agnostic PR protocol. Sadly, we're not likely to get one. That being said, I agree that "let's all use plain-text email" isn't a very good alternative. It's perfectly possible to use Gitlab or Gitea and have the web UI experience without marrying yourself to a proprietary ecosystem.
    - sreevisakh 6y ago
      Is the plain-text the problem? Because Gitlab/hub use them too - as markdown. Their UI layer is built on top of it. Why not do the same thing for emails? Plain-text in SMTP as a communication layer, but a rich UI layer on top of that at client level? Make a combined mail + list + git client?
      - bccdee 6y ago
        I don't have any inherent problem with plain text, I just think that the pull/push/PR workflow is nicer than emailing patches to a mailing list.

chomp 6y ago

This feels like an advertisement wrapped in a bad take. Speaking as someone who has a couple commits in the Linux kernel, yes the email thing is a pain to get started. Configuring your client to do the text thing, keeping up with conversations, learning who's who, you definitely can't jump straight in. The only way I was able to stay sane is setting up a bunch of filters to tag conversations and people. And that's not even mentioning the different patch submission guidelines, perl scripts I have to run, and other random things to make the patch even just readable by the community. Configuring all this stuff is definitely a barrier to entry. Now what tooling looks like to make it easier, that's an entire different conversation. Email has worked for the Linux dev community for decades and that should be protected and not disrupted. However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.

ddevault 6y ago
>However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously. From TFA: > I agree that the UX of email-driven development could be better! This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding: https://git-send-email.io https://git-send-email.io
- corobo 6y ago
  All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible
  - ddevault 6y ago
    This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-... After the initial setup, send-email is way faster.
    - 6y ago

rsweeney21 6y ago

This is an ad for sourcehut, a GitHub/Microsoft competitor.

eterps 6y ago
Sourcehut is competing with Github/Microsoft? That's new to me :-D Focusing on a niche hardly counts as competition to me. 'an alternative to Github' sounds more realistic.

eterps 6y ago

What has always suprised me about open source software is that the source is always 'out of band'. I can imagine a future where all open source software you use has an 'edit source' function (as opposed to a mere view-source function we have on the web currently). Even more useful would be the ability to make a change within a certain context, similar to how 'inspect element' works in the browser. A change in the source would result in a patch which can then stay 'personal' or be automatically shared with others looking for similar functionality, or getting noticed by the maintainers who might incorporate it in the main releases after a refactoring. Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future.

Santosh83 6y ago
There used to be an assembler called RosAsm in the early 00s, whose author insisted on including the full source of the assembler inside the PE executable. That way you could edit RosAsm's source (written in the same assembler dialect) and assemble it by itself and produce a new PE executable.
andreareina 6y ago
That's exactly how emacs works actually[1]. Getting the documentation on a function or variable contains a link to the file that defines it, which you can then edit. If you eval the expression then all later uses of the function will have the new behavior, otherwise it'll take effect on next startup. I've done exactly this to backport some changes from future versions. [1] http://prntscr.com/u6yfnp http://prntscr.com/u6yfnp
- frank2 6y ago
  Yes, I really like how easy it is to view the definition (which might be written in Emacs Lisp or C) of any function callable from Emacs Lisp. (But I never edit any Emacs Lisp files that come with Emacs: sometimes though I will make sure such a file has been loaded, then override a function definition with one I wrote myself.)
  - 6y ago

toyg 6y ago

Don't particularly agree with the tone of this "advertorial" but I agree that the issue of the ecosystem becoming excessively github-centric is real. I wish Github, Gitlab, sourcehut and (why not) Atlassian, would sit down and hash out a bunch of formats and protocols that make it easy to collaborate across and off them. A galaxy of tools, with everyone using their favorite one, would be a fabulous step forward for developers everywhere. I know it's not going to happen anytime soon, but one can dream.

kanox 6y ago
It's already trivial to move code between git service providers, or even run your own. Code review and issue trackers are harder because they're effectively forums are only useful when centralized.
- ashtonkem 6y ago
  They’re also fiendishly hard to design right.
- ddevault 6y ago
  >Code review and issue trackers are harder because they're effectively forums are only useful when centralized. What? This claim requires evidence.
mikepurvis 6y ago
GitLab has been at least tracking federated instances as a wishlist item since 2018, and it was marked for a time as "Vision FY20": https://gitlab.com/gitlab-org/gitlab/-/issues/6468 https://gitlab.com/gitlab-org/gitlab/-/issues/6468 I doubt that GitHub would have much incentive to come to the table on any of this, but if GitLab can at least figure it out between instances of itself, it seems likely that sr.ht and BitBucket would be motivated to implement whatever the system is, and eventually social pressure would force GitHub to cooperate with it as well.
bccdee 6y ago
Yeah I think there's a strange focus on vindicating plain-text email in that article instead of criticizing GitHub for being a closed ecosystem. Plain-text email is kind of a huge pain in the ass to use, and the PR web GUI system is nice. The focus should be on interoperable PRs, not resurrecting plain-text email.

tboyd47 6y ago

Calls to mind the way Google, Facebook, etc. took over OAuth by flooding the committee with their own representatives and turned it into something completely different with OAuth2.

sreevisakh 6y ago
Reminded me of a quote from another one of Drew's blog posts: "The web and web browsers have become Lovecraftian horrors of an unprecedented scale. They’ve long since left “scope creep” territory and entered “oh my god please just stop” territory, and are trucking on through to hitherto unexplored degrees of obscene scope." [1]. I sometimes feel like many standards and software (incl open source) are designed to make it impossible for an individual or small team to implement or manage. [1] https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop.html https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop...

algorithmsRcool 6y ago

I have a hard time taking this seriously. Email is a pain to use compared to a dedicate feature UI. I think the real problem is the need for a standardized pull request protocol that people can wrap. Then let people use email, a website, an API or whatever they want.

koluna 6y ago
100% this. I will take GitHub’s PR process over emailing diffs any day. It’s just a matter of improving user productivity.
- ddevault 6y ago
  Absolute nonsense. Emails are far more productive. I've made a video demonstrating the difference here: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
  - koluna 6y ago
    Literally nothing from what you showed is a pleasant customer experience. Overly complex workflow that can be simplified by what GitHub is doing. Think of a beginner developer who wants to learn how to contribute to an open source project. If they would be put through the process you showed, it will be a meat grinder that is going to be error prone. Zero need for that when GitHub has a great UX that focuses on getting shit done instead of fiddling with conventions from the 90s.
    - cnst 6y ago
      That's why there's shell completion, and history search; then with practice, keyboard shortcuts as well; all vastly improve productivity. I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. But that's not the case at all. Moreover, GitHub has so many quirks, that most Enterprise shops don't use it internally for their own internal projects (unless they release said projects into OSS); so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. Compare this with email. As the original article reveals, Linux and OpenBSD happen to have almost entirely identical workflows for patch submission, which is actually REALLY weird, considering that the two projects have entirely different histories, methodology, and use entirely different revision control systems, where OpenBSD still uses CVS, yet Linus Torvalds hated CVS so much, I recall that he refused to use it even before Git was ready and the licences for the predecessor system have already been withdrawn (I recall he hated CVS so much he simply used plain patches or tarballs).

martius 6y ago

Pull-requests and forks are only a piece here. It's not the only one implemented by tools that extend Git (Phabricator and Gerrit, for instance, support pre-commit workflow). Github also brings a bug tracker (albeit a simple one), discoverability, hosting (obviously) and integration with many useful tools (CI, documentation generators, etc). All of this is easy to use. These pieces greatly contribute to the success of many open-source projects (of various sizes). Github "extinguishes" alternative because of this, not because it designed an alternative to email-based workflows. I suppose that many projects (open-source or not) want to use tools that extends Git. Maybe what we need is a standard making these tools interoperable and open.

bccdee 6y ago
Yeah, I agree. There are open-source Github clones like Gitlab and Gitea that still follow Github's web UI model, so I think it's weird to pose this as a conflict between Github and plain-text email when it's two separate conflicts: one between proprietary Github software and other open-source hosted git systems, and the other between the plain-text email model and the more popular web UI model.
- Seirdy 6y ago
  I responded to this argument in another comment: https://news.ycombinator.com/item?id=24295610 https://news.ycombinator.com/item?id=24295610 TLDR: the alternatives are also centralized and give you vendor lock-in since issues/PRs are tied to the instance.

simonkafan 6y ago

tl;dr: A Github competitor is looking for reasons to rage against Github/Microsoft.

nova22033 6y ago

I represent sourcehut, a GitHub competitor Maybe lead with that?

johnduhart 6y ago

The author took an article about somebody suggesting that having email be the only mechanism for contributing to the Linux kernel might be a barrier to entry for new developers, and construed it into this piece on how the evil Micro$oft is looking to dismantle distributed git development. From the original article: > Picking her words carefully, she said work is being done towards “moving from a more text-based, email-based, or not even moving from, but having a text-based, email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with." That seems like an entirely fair statement to make for somebody who is on the board of The Linux Foundation.

cxr 6y ago
The interesting thing to note is that the "way that developers who have grown up in the last five or ten years" refers to the way of working on GitHub, and that GitHub made it deliberately difficult to interoperate with other development models (like the kernel's, or old-style Bugzilla-and-patches) for business reasons. When you start out with trying to be a social network for developers, you'll happily take inspiration from the way Facebook divides the world into "Facebook" and "not Facebook", which naturally results in erecting barriers between your userbase and outsiders so long as those barriers can feed into your growth strategy of converting the outsiders into even more users. Having said that, this blog post is foremost not actually a criticism of Microsoft/GitHub, but instead trying to draw attention to Sourcehut. Sourcehut is not a good example of how to solve GitHub's problems; if we were in a hypothetical world where the choices were GitHub or Sourcehut, the skew would remain forever what it is today, and the lead developer doesn't seem capable of understanding why and fixing Sourcehut's flaws.
- sreevisakh 6y ago
  I feel that the author is drawing attention to Sourcehut because there are no alternatives that use the workflow he is pitching. It's not as great as Github at the moment, but he is trying to show what it can be. He always comes off as incapable of fixing sourcehut's flaws because a lot of suggestions he gets are contradictory to the fundamental design he has in mind. Despite this, sourcehut is making steady improvements. Drew also puts up invaluable resources which helps people like me get into the email workflow. Sourcehut currently has a steep learning curve, after which you would immediately recognize the design as a safer bet in the long term.

mouldysammich 6y ago

There are an awful lot of people in the comments here calling this an advertisement and being upset about it. How are those that are upset about it not upset that this is an obvious conflict of interest and advertisement for microsofts github platform.

cnst 6y ago
This is the most upsetting part about it, IMHO. The reason Microsoft pays a salary to this person is precisely to get GitHub mentioned into these sorts of conversations -- even though it's widely known that GitHub doesn't support such usecases. But, of course, there's never any time to mention such facts; but here's an example if anyone's curious: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne.... Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source.
- kasabali 6y ago
  > Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source. it's upsetting indeed. I'm 100% sure had he didn't mentioned SorceHut the same people would've complained instead that how there were no projects for improving mail based workflow, why didn't OP offer a suggestion, or that it's open source so why he didn't shut up and wrote a patch instead.

koluna 6y ago

This person seems very upset about something that customers actually love. Speaking for myself —- GitHub pull requests are amazing. I have an easy way to collaborate and propose changes to my projects through a human-friendly interface that doesn’t require me to use tech from early 90s. Surprise - technology evolves. We’re not all going to stick with BBS just because “it’s a standard everyone uses, ZOMG don’t extinguish it!”

croes 6y ago
Wait until you need a Microsoft account for accessing github, wait until your account gets blocked. All of sudden all of your code is out of reach.
- koluna 6y ago
  Wait until your mail server goes down or experiences a malfunction that erases all mail threads. Wait until your hard drive fails and you lose all the code. There can be a lot of hypotheticals. GitHub does not preclude you from using git for what it’s intended to be - a distributed source control management system. If you don’t have backups, that’s on you.
  - croes 6y ago
    "GitHub does not preclude you from using git for what it’s intended to be", yet. Never trust MS, FB, Amazon, etc. Sooner or later they lock you in or kill the service you rely on.
  - sreevisakh 6y ago
    IMAP allows you to have multiple synchronized copies of the entire mailbox. And you can depend on multiple email servers (and IDs) if the mail server is unreliable. Email has fewer single point failures. Git may help you backup code against failure of Github/lab. But it doesn't prevent you from losing ability of issue PRs or accessing issue trackers.
  - ddevault 6y ago
    Ah yes, because apparently no one besides GitHub is qualified to run reliable services. https://status.sr.ht/ https://status.sr.ht/ https://www.githubstatus.com/ https://www.githubstatus.com/ https://sourcehut.org/blog/2020-07-03-how-we-monitor-our-services/ https://sourcehut.org/blog/2020-07-03-how-we-monitor-our-ser... https://drewdevault.com/2019/01/13/Backups-and-redundancy-at-sr.ht.html https://drewdevault.com/2019/01/13/Backups-and-redundancy-at... When your mail server goes down, nothing happens, the internet continues to function normally and then when it comes back up you will receive all of the emails that were sent to you when it was offline. If the mailing list goes down, you can still send emails and you're collagues probably won't even notice the outage because they were CC'd. When the mailing list comes back up, it'll receive all of those emails in the same way and get caught back up. When GitHub goes down, everything stops. And GitHub goes down often!

PaulDavisThe1st 6y ago

This is a bit tangential, but I wanted to mention how the (GPL'ed) ardour project decided to view github. We got burned by the SourceForge apocalypse back in the mid-2000's, which led to me (the BDFL) declaring that the project would never use a 3rd party host for our source code repository ever again. Granting a 3rd party the level of control that SF had (and then abused) is a non-starter for us. This means that github was never an option for us. .... as the canonical repository. However, we recognized the value of the tools that github offered, particularly allowing random 3rd party developers to create patches in quite effective ways. Some of the their other tools are useful, too. So, we self-host a gitlab instance at ardour.org, and that acts as our canonical repository, but we use hooks to push all commits to the github version automatically. Random 3rd parties can use any and all of the github toolset with our code (as can we), but we have no reliance on github in any important way. We don't even have much reliance on gitlab either - it exists only to provide access roles and account management on top of the bare git server. We don't use any of gitlab's "features" either. After about 5 years, this continues to work well for us.