174
GitHub Is Not Open Source, A Rant
(listed.to)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Apr 2024
174 points (100.0% liked)
Technology
34771 readers
114 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
Okay...
You don't know what a "monopoly" is.
Yeah, nothing you could do about it, other than moving to one of the many other git hosts. Monopoly!
And then after listing off a whole bunch of alternative git hosts...
You have plenty of ways to do that, and you know that because you just listed them. Github is not a monopoly.
Also, I don't see the concept of open source mentioned at any point in this rant.
What the author is probably searching for is "vendor-lockin", which is an anticompetitive practice for so long that it became the way many companies rely their business on. It favors established products over new-comers by making switching offerings difficult/expensive or even impossible, thus better products often have no chance of competing in a field, that was dominated by a single supplier for a while.
IMO there should be strict regulations and high fines associated with it, because it hinders innovation massively across all industries.
The cost of switching away from github for a project is high, but not as high as in other fields.
Imo github doesnt have that high of a vendor lock-in. Its git, you can clone and push it to another server. Sure, youll have to convert the ci's and templates, but thats about it really.
And a good yaml is easily converted as the ideas and actions are the same, only the action names are different.
But yes, i think that is what the author was getting at.
It has more than you expect, if your project is established on github and want to move away you have to deal with:
Ye, some of these i started thinking of after i made my comment, which is my bad. Its true a project that uses the full github stack is harder to move, its its still relatively easy. The only problem you'd have is redirecting traffic to a new host, but this problem exists in all platforms and not only in project management sites like github.
As for your bulletpoints, i have a few remarks. Mainly that github pages are silly and they should not be used as a website. And even if you are, there are tools out there to convert the markdown from github pages into html/css/js so moving that is easy. Same with wiki pages, they are just markdown. 90% of markdown is compatible with other sites, and the parts that arent probably have a site specific syntax that youll need to look up, nothing bad. Review comments i will disregard, as those are part of the PR process. Once a project is moved you could hide the PR tab on github or close all new ones redirecting them to the new host. All older ones can be handled and phased out. Once a pr is merged, get the commit from github and push it to the new host. Thanks git!
Random contributers have nothing to say imo. If a project's team feels the need to move away from github a true contributer/side team member/helper will move with them, and if they dont then so be it. Once a project team feels the need to move, something bad must be going on and moving will always be the better move for their mental health than to keep working with bad stuff.
As mentioned before ci/release pipelines are all yaml. Their odeas stay the same, only action names & their patameters change. Nothing complex there to move there...
So im short : only moving your traffic is a real problem, but is a problem on all websites and all communities, not just github or a project on github
As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.
If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.
For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, ...
There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.
Small aside: Microsoft GitHub’s proprietary Markdown fork is certainly not 90% compatible—most egregious IMO was overloading blockquote semantics with callouts which breaks semantics all over the web. Some providers & forks have had to support their fork due to the monopoly control MS GitHub asserts.
Ye fair, it all depends on what markup you have and what features you use. Personally i dont think my markup of priiloader has any weird stuff that is specific to github, but i will have to check to be honest. If there was any special stuff id try to steer away from github specifics as much as i can, because i believe and work in a way it should always be possible to take away any part of a project and replace it with something else. It makes projects very flexible to change
The real issue is the base Markdown spec is absolutely barren. Folks have tried to shoehorn Markdown into something general purpose so everyone & their brother needed to fork it to add some level of usability since base Markdown isn’t suitable for blogging, technical documentation, white papers, etc. which it was never designed to do
Do you mean admonitions? E.g. info, warning, etc? There's precedent for that in commonly-used open source implementations, e.g. obsidian.md (which uses the same syntax, and started before). What semantics does it break? It's designed to read well in plaintext and render nicely even if used in a renderer that doesn't support admonitions, e.g.
As opposed to other common markdownish implementations that use nonsensical plaintext which renders poorly in alternative renderers. Here's a discussion on the topic in the CommonMark forums.
Read the Markdown spec where it says the
>denotes a blockquote. There isn’t room to overload it without breaking that into something not backwards compatible (such as CommonmsMark which will follow the spec & render a blockquote—which, according to the HTML spec, must be text quoting a source). Just because some of the bigger players—namely the proprietary forks, Obsidian & MS GitHub—doesn’t mean it’s not breaking with the original spec. Go ahead & do it, but don’t lie & say it is Markdown or Markdown-compatible. Instead these entities try to push & sway everyone to adopt their syntax rather than working with say CommonMark with RFCs.CommonMark has the
:::block syntax, but folks using this are relying on stringly-typed, not-well-defined options when they do::: noteas it just becomes a CSS class where anyone could style it.As callouts are such an everpresent construct in technical writing, documentation, & so on, what you need is first-class support. Docbook as an output has first-class support, but sadly W3 shot down the last attempt at an element proposal (but can be properly by manually constructed with
role=note&aria-labelledby). reStructuredText & AsciiDoc are both lightweight markup syntaxes that support first-class callouts & other elements (definition lists, summary/details, figures, etc.) as well as having first-class metadata (like basically every other creative work format for images, audio, documents).All of this is to say what Microsoft is doing is no longer Markdown & only they hold the keys to the spec (you can complain in their forums, but you can’t submit an RFC or pull request). But also, Markdown / CommonMark are honestly ill-suited for the task of technical writing since it doesn’t support basic features for that task (embedding HTML defeats the purpose & portability)—and instead we have a lot of ad-hoc hacks & bad HTML output due to choosing the wrong tool for the job.
All of those issues would arise if you wanted to migrate an established project to Github as well.
Well the reason for that is the vendor-lockin and centralized technology.
If your project for instance uses a similar development method as the linux kernel does, e.g. sending and reviewing patches via mailing lists and providing url to push and pull git repos from, it is quite easy to switch out the software stack underneath, because your are dealing with quasi-standart data: Mbox, SMTP, HTTP(s) and DNS. So you can move your whole community to a different software stack by just changing some DNS entries and maybe provide some url rewrite rules without disrupting the development process.
I am not saying that the mailing list development process is the right one for every project, but it demonstrates how agnostic to the software stack it could be.
If vendor-lockin is made illegal, the service providers would have more incentives to use or create standardized APIs, so that their product can be replaced by competitors. So switching to or from github/gitlab/... becomes easier.
Gitea can migrate all issues, PRs, wiki, etc. It works very well.
Sure, I've done that. The problem is, it doesn't "migrate" the audience. The chances that people will contribute on your individual Gitea repositories versus Github is much much lower. Just clarifying to highlight it's not just a technical problem.
You gotta consider the inverse as well. There are a lot of folks that would more happily create an account with a free software service but will only reluctantly use MS GitHub. It’s the same community-dividing tactic as putting all other communications on Discord/Slack which cut off a part of the community that wants to live the ethos by using free software/services to create free software/services.
Sure except the install base isn't, sadly, comparable precisely because Microsoft has been using such tactics since its inception. That's why they've had problems with the justice for decades now.
To clarify, it's legally not the same to promote your own products when you are in a monopoly position versus when you are not.
Guess it works for codeforge then because it runs on a fork of gitea
Ye, i went to this post diagonally and it felt like a rant without any merit. Dont get me wrong, i dont fully like github either but this was just a waste of time to read...
So, is google not a monopoly because there are other search engines out there? Does Apple not have a monopoly among US teenagers because there are Android phones available? Does Microsoft not have a monopoly in desktop computing because Apple and Linux exist or because phones exist?
What is your definition of monopoly and how does Github not fit it? I'm genuinely curious.
Anti Commercial AI thingy
CC BY-NC-SA 4.0Inserted with a keystroke running this script on linux with X11
:::
Thing about sharing the internet with newly minted teenagers is that they haven't been around these streets nearly as long as us. They apparently dont know the history of the net as well as the timeline of the most popular sites.
Maybe schools need to start teaching internet history class or something. If only schools in the USA weren't terrible when it comes to anything tech.
This isn't even a problem with historical awareness, OP knows that Github isn't a monopoly. They listed off a bunch of alternatives in their rant. I'm really not sure what they were even complaining about.
Do you though? A clarification that most people miss : "In economics, a monopoly is a single seller. In law, a monopoly is a business entity that has significant market power, that is, the power to charge overly high prices, which is associated with a decrease in social surplus." (from Wikipedia) So are you 100% sure that the author was talking from an economical rather than legal viewpoint?
So sure, in theoretical economics GitHub is not a monopoly, rather it's part of an oligopoly. Yet, in law, it is in practice a monopoly. GitHub is so big that it does shape the market of collaborating on (open-source) software, even though alternatives do exist.
Not like you can just visit some other selfhosted community on lemmy or reddit and see how others started hosting a local git appliance for their scripts and what not.
Well, if you want to contribute to a project to github then you are pretty fucked if the gate keepers won't let you
You're not "pretty fucked". Just use one of the many other git hosts out there. OP himself lists some of them in his rant.
You didn't seem to read what I said. I can't force other projects that I don't own off github.
Actually, you can do exactly that. Fork them.
You can't force the people who are using Github to follow you, of course. But that's every individual's choice.
How do you contribute to project on Github from a different git host?
Oh, that's what you meant. How do you contribute to a project on any git host if that git host won't let you? In what way is GitHub any different from that?
Its different in that other platforms aren't run by evil corporations that could decide to deplatform a user.
You think Microsoft is the only "evil corporation" among these? That's very naive. Any hosting service will deplatform users when they can see a profit to be made from doing so.
My point is don't go with a corporation. Use open source software. Use codeberg.
Cut them some slack. They're at an age where they're trying to assert their independence and their brain is still developing. They've got time to mature and find more worthy fights over which to spill words. Or maybe they'll remain smooth-brained. But either way, right now they're not at their best.