Live data from Hacker News

GitHub’s Large File Storage is no panacea for Open Source

medium.com

51–60 of 66 posts

Re: GitHub’s Large File Storage is no panacea for Open Source

#51

Earlier quoted context omitted.

I wouldn't necessarily describe a paid feature that breaks all forking for an entire repository a "value add".

Yes, my criticism was not that they're trying to make money from this, but rather that they are crippling their core product in an effort to monetize it some more.

No, they are trying to solve a problem for their customers - storing large files. They charge money for this feature. It's disingenuous to think that they are breaking their product on purpose to extract money from you.

Re: GitHub’s Large File Storage is no panacea for Open Source

#52
post #8

Shock and horror: commercial company has a paid value add. GitHub is not a charity.

I wouldn't necessarily describe a paid feature that breaks all forking for an entire repository a "value add".

If you value large file support over forking then its a value add.

Re: GitHub’s Large File Storage is no panacea for Open Source

#53
post #9

> I honestly couldn’t believe that GitHub would be willing to do something that shortsighted, visibly motivated by greed from the cash they thought they could extract from some of their users. They're a business. C'mon here.

My argument was that this was actually bad for their business. This is not a customer-friendly move.

People who make products make these sort of tradeoffs all the time and the tradeoff is rarely something thats permanent. For the fast majority of people who need this kind of functionality (LFS), breaking forking is a inconvenience compared to the value being added.

Re: GitHub’s Large File Storage is no panacea for Open Source

#54
post #46

Earlier quoted context omitted.

I am the author and yes this was very much unapologetically hyperbolic. At least it got the conversation started.

I don't think you needed paragraphs like "My guess is that some high-level greedy marketing dickwad, completely unaware of the asinine implications of his brilliant idea, signed off on this dumb-as-a-bag-of-rocks pricing model. He then directed the grunts to somehow implement his grand vision on GitHub’s servers. That’s when shit started to hit the fan." ... to get the conversation started. Your other points were sen…

It's his personal blog not some corporate blog or newspaper.

I'm not sure it's within your rights to ask him to change the way he writes within his own bubble because you don't like his word choice.

Re: GitHub’s Large File Storage is no panacea for Open Source

#55
post #48

Earlier quoted context omitted.

No, of course not. I have nowhere said github is evil. I've said it would be foolish to believe they never will be, because we have seen on a number of occasions that good companies turn bad (with varying definitions of "good" and "bad") when given sufficient monetary motivation to do so. SourceForge is the best past analog for github, and I think it's worth learning from history. SF.net didn't start out evil and unt…

Its not that I believe good forever, but rather that I think it (it being your first comment) was a weird way to take the conversation. Like, why did that even occur to you in this context?

I left some of the early parts of my thought process out of the conversation.

My thought process went something like this: "This is a feature that is currently, probably accidentally, causing vendor lock-in for github users, as there is no easy way to take a project in its entirety back out of github, if it has enabled this feature. That kind of lock-in has been used in the past, by vendors across a wide spectrum, for evil purposes. Github, were it ever to become evil, would find this the kind of thing that would screw users and produce profit."

I don't believe github today has evil intent (though the author of the article seemingly does believe that), but I reserve the right to be skeptical of what the company's intentions will be in the future. Just as I should have been more skeptical of the the future intentions of SourceForge in the past. I think my position on this is entirely fair to github (which is a company and product I like), but I'm also trying to not to be a total sucker and make the same mistakes over and over again.

Re: GitHub’s Large File Storage is no panacea for Open Source

#56
post #54
post #46

Earlier quoted context omitted.

I don't think you needed paragraphs like "My guess is that some high-level greedy marketing dickwad, completely unaware of the asinine implications of his brilliant idea, signed off on this dumb-as-a-bag-of-rocks pricing model. He then directed the grunts to somehow implement his grand vision on GitHub’s servers. That’s when shit started to hit the fan." ... to get the conversation started. Your other points were sen…

It's his personal blog not some corporate blog or newspaper. I'm not sure it's within your rights to ask him to change the way he writes within his own bubble because you don't like his word choice.

It's just as much within his rights to call someone out for it as it is for someone to write as he likes.

Clearly the post was written for an audience. Being needlessly inflammatory could certainly turn the audience off, and/or undercut the author's credibility. Ansiton's advice was both helpful and valid.

Re: GitHub’s Large File Storage is no panacea for Open Source

#57
post #9

> I honestly couldn’t believe that GitHub would be willing to do something that shortsighted, visibly motivated by greed from the cash they thought they could extract from some of their users. They're a business. C'mon here.

My argument was that this was actually bad for their business. This is not a customer-friendly move.

Customers are people who pay you.

Re: GitHub’s Large File Storage is no panacea for Open Source

#58
post #36

Earlier quoted context omitted.

OK, those are maybe a little vicious, and probably not entirely fair. Still, the implication of not being able to fork a whole project from github if you use LFS is a pretty big deal.

GitHub has added features, and made their product better for their customers, but have not yet made it possible to use from everywhere on their platform. Perhaps that is a big deal (I don't use LFS and until recently neither did anyone else), but it's a far cry from what you said in your original comment, such as "I do believe it is foolish to assume that the github we know today will be the github of tomorrow." They…

I wouldn't have characterized that as evil per se, but the fact that they are just not disclosing these restrictions is at the very least a communications failure, if not a shady business practice. It would have been completely understandable if they had just mentioned the existence of these restrictions, but they haven't.

If you start using LFS, you are effectively losing features and the product becomes worse for a lot of their users, a lot of them paying customers.

The question is not whether this was being just inflammatory (it was) but rather whether it was unwarranted criticism.

Disclaimer: I am the author of the article.

Re: GitHub’s Large File Storage is no panacea for Open Source

#59
post #51

Earlier quoted context omitted.

Yes, my criticism was not that they're trying to make money from this, but rather that they are crippling their core product in an effort to monetize it some more.

No, they are trying to solve a problem for their customers - storing large files. They charge money for this feature. It's disingenuous to think that they are breaking their product on purpose to extract money from you.

It is not disingenuous if it is exactly what they are doing. The entire cause of this problem, and the reason it breaks so many things, is because they are trying to monetize bandwidth usage. This model is unsustainable because free users only get a paltry 1GB/month and their attempt to enforce that is what breaks forks.

If they would just stop trying to do that, then we would have nothing to talk about.

It is not at all uncalled for to criticize the way they are trying to do business, especially when it affects you as an existing customer.

Re: GitHub’s Large File Storage is no panacea for Open Source

#60
post #53

Earlier quoted context omitted.

My argument was that this was actually bad for their business. This is not a customer-friendly move.

People who make products make these sort of tradeoffs all the time and the tradeoff is rarely something thats permanent. For the fast majority of people who need this kind of functionality (LFS), breaking forking is a inconvenience compared to the value being added.

I would completely agree with you if that was the way GitHub presented that feature, being open about the consequences of adopting it. They haven't done that, and as a result their customers are not properly informed on the trade-offs they are making.
Post reply on HN