Live data from Hacker News

Give up GitHub: The time has come

sfconservancy.org

191–200 of 585 posts

Re: Give up GitHub: The time has come

#191

GitHub is a business and currently provides free storage and a pretty nice interface to it. It’s easy to say “our rights are being stripped away” but the view that businesses should operate like non profits or government services with the common good in mind is ludicrous!

Realistically I'm not leaving GitHub anytime soon and I do agree that businesses need a way of making money. I'm generally fine with a free service that also restricts certain features to paying customers and I think that GitHub worked well with that formula so far. But I don't like the double standard highlighted in this article about Copilot: they are training their IA on Open Source repos and using the result without taking into account possible licenses incompatibilities by making an argument about this being comparable to a compiler's output, but at the same time they are not using their proprietary codebase to train it to protect their own intellectual property. I'm not saying that businesses have to provide stuff for free, I'm just saying that there are if not more legal at least more ethical ways of making money, because as it stands now it seems to me that Copilot is in a legal gray area.

Re: Give up GitHub: The time has come

#192
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.

Does a typical enterprise need a distributed source control system? It makes a lot of sense for open source. Doesn't the uptake in Github which centralizes this distributed system kind of invalidate its main tenant? I haven't been a hundred percent sure the overhead was ever worth it at most other types of paid gigs over the years. Adding complexity without value is a mistake imo. Maybe it's my own fault I haven't se…

I find distributed version control super useful for the enterprise. I have way more private repos than public.

It’s useful because it makes it easy to have multiple copies of a repo and merges and branches are trivial. Just for my own project I might have clones on multiple machines. When I mess up and make a change, it’s not a big problem and merging is easy.

For team collaboration, I find it better than centralized because it makes it easier to work on multiple branches. It also encourages merge requests from people outside the team.

Re: Give up GitHub: The time has come

#193
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.

I say this as a senior dev with 8+ years of experience working with git: git is nightmarishly complex. Highly stateful, insanely large CLI surface, huge amounts of terminology/concepts relative to the complexity of what you're actually trying to do with it. I've learned to navigate its waters over the years, fully appreciate the difference between git and GitHub, etc etc, and I don't blame anybody for being scared aw…

The more relevant point is: do you refuse to work on some code or use a VCS on your code because of this complexity?

That was the GP's point. He acknowledged it's complex. But it's a very clear and very large amount of value left on the table, so people that gets scared away by it will probably practice other kinds of harmful behavior.

(Of course, the option of just using a simpler VCS doesn't tell anything bad about people. Why did we standardize on git again?)

Re: Give up GitHub: The time has come

#194
post #186
post #134

This isn't very compelling to me. SourceForge went bad ... and everyone left. That doesn't seem like a bad thing and there's no reason for me to think any given site / service will or won't go bad too. I expect that for any number of reasons I might need to move from one site to the next. The rest too is kinda hollow to me. The fact that they're for profit doesn't upset me. I figured they wanted to make a profit when…

It's been years, but as I remember it SourceForge's primary downfall was the bundling of malware with binaries. That's why people I know stopped using it completely rather than because it was run on a proprietary platform.

Yup that's how I remember it. Suddenly I didn't touch anything on SourceForge.

Re: Give up GitHub: The time has come

#195

Earlier quoted context omitted.

That scenario plays itself out time and time again. 1. Base technology arrives and is adopted en masse 2. Some entity wraps it in an easier-to-use interface 3. After some time, that interface becomes the de facto standard 4. Developers who started developing after #2 and especially #3 don't understand how the underlying technology works or even that the wrapper is just a wrapper I'm reminded of how many Juniors I tra…

I find this so weird, I always feel like I have to at least a bird's eye view of how bits and bytes are flowing through the system. Not that a lot of boxes I don't just label as "magic", but at least I need to know the box exists

I'm having a difficult time picturing how these hypothetical juniors will fare without that underlying curiosity driving them forward. Likely they'll wash out of the industry or see enough success to be promoted to a management position.

Re: Give up GitHub: The time has come

#196

> What case law, if any, did you rely on in Microsoft & GitHub's public claim, stated by GitHub's (then) CEO, that: “(1) training ML systems on public data is fair use, (2) the output belongs to the operator, just like with a compiler”? In the interest of transparency and respect to the FOSS community, please also provide the community with your full legal analysis on why you believe that these statements are true. >…

Good point, but also with FOSS licenses you can have incompatibilities if you take code distributed under a certain license and you use it into a project distributed under a different license. So I still think there is a double standard here.

Re: Give up GitHub: The time has come

#197

Would love to see Fossil get wider adoption: https://www.fossil-scm.org/ Single 6mb executable with a version control system, web server, bug database, forums, import/export/sync with git, repo browser, much saner CLI than git, etc. Been using it for 2+ years for all my projects and love it.

I use Fossil. It has some advantages:

1. Hashes are computed without adding any additional headers, so it will be the same as computing the hash normally.

2. The /raw capability is a good thing to have.

3. The deck format is not bad.

4. The command-line interface is less confusing than git.

5. It is written in C.

It isn't perfect, but it is more than good enough. (If I do have to change it, I would do "Generalized Fossil" (I already wrote the specification, although no implementation exists yet as far as I know), which will have the same five advantages listed above, and is compatible with the same /raw capability and deck format of existing Fossil repository, too (except old technote edits, but fortunately I do not have any).)

Re: Give up GitHub: The time has come

#199

> 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…

There is absolutely a need for moral panic if, like me, you believe that code and industry quality of product is more important than onboarding more people into the profession.

I can't think of a worse idea than subconsciously letting the idea "By default, the way we are supposed store and write code is by putting it in the hands of a deeply centralized third party that will exploit you and owes you nothing" just sort of be the default deal.

Re: Give up GitHub: The time has come

#200
post #82

Earlier quoted context omitted.

> 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.

JS being required for the interactive features would be fine. My personal problem is that I end up on some random gitlab instance to just take a look at the source or issues for some library, and get a blank white page. For the read-only public view there should be no need for any JS.

This is my opinion, too. The JavaScripts should not be required just to read the documents, files, list of files, etc; even if some of the other features do use it.
Post reply on HN