It seems particularly galling that their response to GitHub was to essentially throw their hands up and say "We don't want to change anything, fix it for us". I think GitHub had a near perfect response to this, they analyzed the problem, came up with a set of changes that could be made to help fix it (both short and long term), and pointed to steps they've taken to help out. CocoaPods on the other hand (or at least one of their developers) did not handle this particularly well. When presented with the evidence of why they were seeing slow responses and long queues and suggestions of how to fix it, they complained that they didn't want to fix it and didn't have the time or resources to do so.
Honestly if I was GitHub, I'd be tempted to just increase the throttling on CocoaPods and call it done, it isn't their problem if the users of that project have a bad experience. GitHub has provided solutions to the problem, it's CocoaPods that's resisting implementing those solutions.
Yeah, I'd have to agree. I was not at all impressed by the CocoaPods response here, especially since it was made clear by the GitHub staff that CocoaPods is using up a lot of CPU and terabytes of bandwidth. If you get all that for free, I'd expect you to be a little more open to changes that make it easier for your provider to continue giving you all that for free.
I think that's pretty unfair. It's really obvious that the initial reply didn't really understand what was going on, and what was being explained. A couple followup additional explanations later, the same dev grokked the problem, CocoaPods' responsibility for the problem, and outlined a list of how they're going to solve it. Seemed to me to be a pretty nice example of professional and helpful candor between GH and an OSS project working to figure out a long-term solution.
I don't know, maybe I'm being overly pessimistic here, but to me it just screams of backpedaling once they saw the reaction they were receiving in this thread. The position shifted from "it's the way we architected things, how can you fix this for us" to "okay, here's some things we can do" pretty quickly and dramatically when the HN thread went up and people were reacting to the response. Cocoapods is using Github resources for free, so the appropriate response from the start should have been what it eventually came down to, not pushing back on Github because they don't want to invest in an actual CDN solution. But, as I said, maybe I'm being overly pessimistic in my analysis here, that's just how it came off to me.
I get where you're coming from. I also had a similar initial reaction. However, as I read through the subsequent discussion, it began to read as though the commenter was really not grokking the problem—and, more importantly, what to do to fix it. I thought it was very impressive that none of the GH participants reacted like some of the HN commenters here. Instead, they showed a great deal of patience and restraint in fully explaining the technical details, offering actionable solutions, and keeping everything very civil and supportive. Then the same guy who sounded like he was possibly being a jerk came back and sounded totally different because he seemed to actually know what to do to fix his project. Maybe the CP commenter read this HN thread and reacted to it, but I'll admit HN is the last place I'd think of finding one of my GH issues discussed.
Perhaps I'm just being too charitable. Either way, the project rather rapidly seemed to come to the right conclusion and jump on board fixing their problem.
On a related note, I feel like this issue could be turned into a great teachable moment for OSS projects; one agH could use as a tech blog and guides for how to be a good citizen and avoid things that can make your project get rate-limited without you knowing.
Yeah, I really just think it went a bit too far in the other direction and overcompensated somewhat, which is what was giving me that view. The comment with the heart emoji really stood out to me as a "huh, this might be because of HN" since it basically touched on exactly what was being criticized in here, that they weren't really appreciating what GitHub was providing for free. That said, I can totally see it just that alloy realized it on his own and wanted to make it clear. It's just that the timing of it all and the fact that it's hitting the same point kind of led me to believe that it was a reaction.
Obviously, that's not to say the sentiment isn't genuine. The eventual conclusion makes it seem that yeah, they do appreciate what GH is providing and are trying to make it less strenuous on the servers to get a better experience all round. Making it work well is really in their best interests since the users are seeing a degraded experience until something can be done about it. Definitely also happy that the right conclusion was eventually reached.
I don't understand how you can read "our use of git as our package manager is better than some other package managers we won't name :wink:" is an example of not understanding the problem. It looks more like someone who doesn't want to accept that the problem is on their end.
To me, that comment shows precisely that someone isn't really understanding the problem in full. It feels to me to be a deflection—of responsibility, sure, but also of admitting one doesn't understand what's really going on, and how one is at fault.
Given how rapidly the same commenter changed gears, it strikes me as plausible there was an "ohhhhh eureka" moment, and suddenly the guy got it. His followup comments began dealing with the problem after a couple other GH participants explained further what was happening and why (as well as some actionable steps to take to correct the problem for good).
> It's really obvious that the initial reply didn't really understand what was going on, and what was being explained.
If you are in such a position, then it seems like the best course action would be to ask questions rather than list off reasons that you don't want to deal with it.
If he can't understand that his project's resources are consuming 5 whole nodes and terabytes of throughput on Github's infrastructure, then I question his skills as a developer. Even if all of the other technical details are completely obtuse to him, he should at the very least be able to understand the sheer scope of the resources their project is consuming on Github's infrastructure.
Honestly if I was GitHub, I'd be tempted to just increase the throttling on CocoaPods and call it done, it isn't their problem if the users of that project have a bad experience. GitHub has provided solutions to the problem, it's CocoaPods that's resisting implementing those solutions.