Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Give up GitHub: The time has come

sfconservancy.org

Post reply on HN
Print view View original

251–260 of 585 posts

Re: Give up GitHub: The time has come

#251

Post by vnorilo »

BeetleB wrote: post #85
prepend wrote: post #56

Earlier quoted context omitted.

> refusal to use Git[1] due to its complexity I kind of like this friction. If a software developer finds git too complex, that’s an important signal that I should minimize my exposure to them. I’d never work in a team that dumb, and I wouldn’t want any dependencies on their code. Of course there are other reasons not to use git, but complexity is not one.

To be fair, most people who find it complex do so because Git has a very crappy UI. You don't need to understand the internals to use Mercurial, and I would imagine that's true for most other DVCS's. In that sense, I sympathize with them. I'm pretty sure half of the teams that find Git too complex wouldn't find Mercurial to be complex. But they haven't heard of Mercurial.

I'm the guy people at $work call to do git submodule reorganization, troubleshoot lfs or recover disasters. I'm certainly comfortable with git. It gets the job done. The same can be said of svn.

However my own projects always start with hg init. In addition to the UI being less insane it also feels consistent and nice to use.

At one point I was on a team using Darcs, which was another level of beautiful but clunky in many ways. It is why I'm rooting for the Pijul team. [1]

1: https://pijul.org/

Re: Give up GitHub: The time has come

#252

Post by devwastaken »

josephcsible wrote: post #173
ipaddr wrote: post #154

Earlier quoted context omitted.

My favorite answer is: if you included Microsoft source code the quality of suggestions drops below viable product.

The reasons that Windows is awful have nothing to do with code quality. Windows is awful because of intentional choices Microsoft made (e.g., bloatware that gets reinstalled with every update, mandatory Microsoft accounts, and mandatory telemetry).

Windows 11 is an example of poor code quality. Bugs everywhere, while the same things work on Ubuntu/popos.

Past MS engineers have been commenting for a decade on how MS has grown too big, can't manage, and has become a monolith "too big to fail". By nature when engineers are small pieces of a giant machine, they don't do their best work. And those with the experience move on to better things.

Re: Give up GitHub: The time has come

#253

Post by chrismorgan »

joshstrange wrote: post #54
pabs3 wrote: post #32

Earlier quoted context omitted.

GitLab is mentioned on the advocacy page https://giveupgithub.org/ . GitLab is an open-core business, which means there is a permissively licensed FOSS version and a proprietary version. The gitlab.com website uses the proprietary version. In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. They have swayed a lot of ostensibly FOSS, copyleft-leaning and privacy/sec…

> In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. I feel like the venn diagram of people who complain about JS being required and of people who have never had to code up a web /app/ that users expect rich interactions without a page-reload is just a circle.

I dislike JavaScript being gratuitously required, because it just generally makes things worse—slower to load, and less reliable. I occasionally complain about it, mostly in the places where there’s just no conceivable reason why it should have been done that way, because I do understand pragmatism.

I have also made and worked on multiple web apps where rich reload-free interaction is expected. In some cases, it has not been practical to support JavaScript-free operation at all, but in almost all cases where JavaScript-free operation has been feasible, I have provided at the very least partially-degraded operation—certainly on all green-field development.

A lot of the places where GitLab requires JavaScript are quite unnecessary, and should probably not have been done client-side at all in the first place, though I’d settle for server-side rendering with rehydration.

Re: Give up GitHub: The time has come

#254

Post by quadrifoliate »

seadan83 wrote: post #176

As a leader of a FOSS project that is on github, and migrated off of sourceforge because SVN and email patches were not scaling - I'm a bit confused by this article. Co-pilot has issues, ergo github is going the way of sourceforge, and so now we must abandon github? Do I have that reasoning correct? We need to: - migrate the bug queue - have all links in commit history break - application integration with githib for…

> As a leader of a FOSS project that is on github...Do I have that reasoning correct?

The way I read the article was that by being on GitHub, you are implicitly agreeing to no longer be a FOSS project as regards licensing. GitHub customers can use Copilot to generate proprietary code that's identical to your project's code (several articles I have read call this overall idea "laundering through Copilot", which sounds incendiary but accurate to me) without needing to respect your license.

The other stuff you said is...kind of irrelevant. Sure, you get a lot of convenience from GitHub. If you don't care about software freedoms in the libre/copyleft sense and regard a "do whatever you want" license as the best, then it's probably fine to keep using GitHub.

Re: Give up GitHub: The time has come

#255

Post by quadrifoliate »

TheRealPomax wrote: post #219
inetknght wrote: post #150

Earlier quoted context omitted.

> They make money from Co-Pilot? Great! OK let me take your projects and make money from them and not give you anything in return, not even credit. > They sell software to ICE? Good. Why wouldn’t they? I’m not interested in anti-immigration-enforcement politics. ICE policies aside, you should be interested in immigration politics because they're important to people and businesses. Apathy is a bad thing here. > They’r…

You mean two of the most successful pieces of commercial software in the history of modern computing? Because as easy as it is to pretend they're terrible: to millions of users and orgs, they simply aren't.

Eh, first mover advantage counts for a lot. It doesn't necessarily mean the software is good.

Burning coal for generating energy was very "successful" and had great adoption. It's still a terrible method for the environment, and we can feel free to regard it as negative.

In this analogy, Microsoft products would be like generating energy by burning garbage, aka a dumpster fire.

Re: Give up GitHub: The time has come

#256

Post by sreevisakh »

remram wrote: post #104
NoGravitas wrote: post #47

I publish my public FOSS work on a self-hosted Gitea. I don't allow account creation, and people can send me pull requests by email. That said, I think one thing (other than interface and brand loyalty) that keeps FOSS projects on GitHub is network effects. You can reasonably expect to search it and find the projects you're looking for, and your account lets you use the issue tracker and pull requests on other projec…

Gitea (and a few others) are working on federation for pull requests, which would allow someone to fork your project to their own server, and send a pull request offering you to merge from their server into yours. It also builds on top of ActivityPub which is supposed to allow federation with the greater ActivityPub ecosystem ("fediverse"). I guess this would allow people to like or comment your issue or pull request…

> I am not that excited about that last part, but federating pull requests sounds like a killer feature

Git already has a pull request feature [1] that's as federated as it can get. The 'request-pull' command can be used to request pull on upstream repositories hosted anywhere (or not at all). The only requirement is that the downstream clone must be online. I know that HN isn't particularly found of email-based workflows for git. But requesting a pull is as simple as copying the output and mailing it (or via any text messaging service) to the maintainer. And doing a pull as a maintainer is actually easier than doing local PR merges using Github.

[1] https://git-scm.com/docs/git-request-pull

Re: Give up GitHub: The time has come

#257

Post by _Algernon_ »

josephcsible wrote: post #122

> If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set? This is my favorite question about Copilot ever.

I mean the answer to that question is obvious: they're not under any obligation to include their own code in the training data. Why would they?

A better question would be whether they would take legal action against a competitor that creates a copilot equivalent and publicly states that they trained it on leaked, proprietary M$ source code. That would actually be an example of hypocrisy.

Re: Give up GitHub: The time has come

#258

Post by seadan83 »

quadrifoliate wrote: post #254
seadan83 wrote: post #176

As a leader of a FOSS project that is on github, and migrated off of sourceforge because SVN and email patches were not scaling - I'm a bit confused by this article. Co-pilot has issues, ergo github is going the way of sourceforge, and so now we must abandon github? Do I have that reasoning correct? We need to: - migrate the bug queue - have all links in commit history break - application integration with githib for…

> As a leader of a FOSS project that is on github...Do I have that reasoning correct? The way I read the article was that by being on GitHub, you are implicitly agreeing to no longer be a FOSS project as regards licensing. GitHub customers can use Copilot to generate proprietary code that's identical to your project's code (several articles I have read call this overall idea "laundering through Copilot", which sounds…

> The way I read the article was that by being on GitHub, you are implicitly agreeing to no longer be a FOSS project as regards licensing.

In this case, they have violated our license. The license states how it cannot be changed, and implicit changes by the hosting company is not one of them. Isn't there a legal case here? If no, then the license is not violated. This makes me wonder why not take Github to court vs a tamper tantrum (we're taking our marbles and going home!)

> the other stuff you said is...kind of irrelevant.

It goes to show that Github is providing really, an excellent service to FOSS. We could migrate to GitLab, though, why?

I know that sounds like 'fan-boy', but the list is large, useful, and all highly available and free to FOSS. By those measure, it's a good service.

> Sure, you get a lot of convenience from GitHub.

The items are more than convenience, they are core to our application and project. Uprooting them is not a small task.

The automatic integration with issues is excellent for example, before we did that - we had no idea how many users were seeing errors. We run a thick client that is downloaded and added an integration to upload error reports to github issues. That has been pretty invaluable. So, we have to move all that, to another host: who is to say that other host will always be a better FOSS steward? who is to say that other host has anyone near the level of features? An integrated CI/CD and hosting of release artifacts is huge.

So, on the premise that our license has been violated, instead of sue'ing, we should take our FOSS somewhere else? Again, the list is large, we need to migrate all of that. It took a long time to get out of sourceforge, it's not even more work to get out of github because we automated so much (to allow our team to scale better). It's not just a matter of 'convenience' to go somewhere that is feature-sub-par and spend the better part of a year to do that and nothing else.

[edits] Clarity, conciseness

Re: Give up GitHub: The time has come

#259

Post by laserlight »

brundolf wrote: post #70
travisgriggs wrote: post #5

> For its part, Git was designed specifically to make software development distributed without a centralized site. Just yesterday I had to explain the basic premise/history of Git to a young intern. I had asked him if he was using Git to manage his little pet project the company gave him to play with. “No”, he replied, he didn’t know what the company’s policy was to posting code in public on GitHub. As I explained to…

I don't think it's fair to frame this as specific to GitHub, or even as a thing to wring hands over. New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. Industry-standard ways to just get things done. That's how you get a job, that's how you get off the ground. This goes beyond source-control; languages/frameworks, tooling, etc. You enter the territor…

How difficult is it to teach “Git runs on everyone’s own machine. GitHub and GitLab run their own Git for their users to connect to and push code.”

Re: Give up GitHub: The time has come

#260

Post by nequo »

TheRealPomax wrote: post #219
inetknght wrote: post #150

Earlier quoted context omitted.

> They make money from Co-Pilot? Great! OK let me take your projects and make money from them and not give you anything in return, not even credit. > They sell software to ICE? Good. Why wouldn’t they? I’m not interested in anti-immigration-enforcement politics. ICE policies aside, you should be interested in immigration politics because they're important to people and businesses. Apathy is a bad thing here. > They’r…

You mean two of the most successful pieces of commercial software in the history of modern computing? Because as easy as it is to pretend they're terrible: to millions of users and orgs, they simply aren't.

Being successful as a business has as much or more to do with market power than with code quality.

I am lucky that I can avoid their products. But millions of users and orgs can't because that's what others around them use. So they're stuck with it no matter how much worse it is than open-source alternatives.

Post reply on HN