Live data from Hacker News

The GitHub Load Balancer

githubengineering.com

41–50 of 137 posts

Re: The GitHub Load Balancer

#41
post #37

Earlier quoted context omitted.

I'm not sure I agree, they mention HAProxy and Foo over UDP so they are leveraging existing open source technologies. Custom additions to suit ones particular use case isn't necessarily the same as NIH syndrome.

They mention HAProxy, but it doesn't look like it's based on it.

Joe from GitHub here, we'll talk about it later posts but GLB is based on a number of open source projects including, haproxy, iptables, FoU and pf_ring.

Many existing open source solutions are optimized for short lived HTTP requests and don't address the long running connection issue (like a large git clone). We wanted something better for our use case.

Re: The GitHub Load Balancer

#42
post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

here's an alternative interpretation: Due to their unique requirements, they were forced to investigate alternative approaches to the problem, and the approach they went with, they believe, is useful to a lot more people than just themselves. This is both plausible and matches the announcement, so why take a bad faith approach to someone releasing some code to the open source? Would you prefer if they kept it closed?

And since we're talking about github, haven't they already launched a highly successful pair of projects in atom/electron, in areas where both had competition? why start with negativity before we see what they come out with?

Re: The GitHub Load Balancer

#43
post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

It may not based on haproxy but they definitely used it prior to switching. If we're being generous in our interpretation that would indicate that they found that it didn't work for them. I'm not saying your overall point isn't valid but I wouldn't be so quick to judge.

Re: The GitHub Load Balancer

#44
post #17

Earlier quoted context omitted.

Why not? They could release community version at least.

I have never worked on a piece of proprietary software that would be in a state where it could be released publicly in any form without a very large outlay of development time and money. I'd be very surprised if github is any different. "Why not" is for things that are easy to do. Things that are hard and / or expensive to do require strong justification.

Honest question - do you think if the proprietary software you worked on had been planned from the beginning to be released publicly, a very large outlay would be unnecessary?

Re: The GitHub Load Balancer

#45
post #3

Given the title and the length of the post I was expecting a lot more detail. > Over the last year we’ve developed our new load balancer, called GLB (GitHub Load Balancer). Today, and over the next few weeks , we will be sharing the design and releasing its components as open source software. Is it common practice to do this? Most recent software/framework/service announcements I've read were just a single, longer po…

Joe from GitHub here, frankly there is a lot we want to talk about and release and it was simply too much for one post. We'd like to give it a proper treatment and single very long post won't do that. Also, it allows us to get folks interested in the project and give us time to prepare our code for release. It's a surprisingly big job.

Re: The GitHub Load Balancer

#46
post #17

Earlier quoted context omitted.

Why not? They could release community version at least.

Because if you say to management "hey, why don't we release the code that our entire business is built off of for anyone to host for themselves for free!" you'd be laughed out of the building on your way to the psych ward.

Their entire business is already built upon software that anyone can host themselves for free.

Re: The GitHub Load Balancer

#47
post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

basically a load balancer must often do special stuff and most companies building custom software around haproxy, nginx whatever to support their needs.

Re: The GitHub Load Balancer

#48
post #8

Earlier quoted context omitted.

I'm talking about entire GitHub not components or Load Balancer...

I think the model of "keep our core business software proprietary and open source all non-core software" is a good one, and one we should encourage all companies to share. If they open sourced their core site, how would they make any money?

It would eat into their enterprise "behind the firewall" sales, but github.com's biggest asset is that it's where people already have accounts and already have development tools integrated to. That doesn't change when you open source your platform.

Re: The GitHub Load Balancer

#49
post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

here's an alternative interpretation: Due to their unique requirements, they were forced to investigate alternative approaches to the problem, and the approach they went with, they believe, is useful to a lot more people than just themselves. This is both plausible and matches the announcement, so why take a bad faith approach to someone releasing some code to the open source? Would you prefer if they kept it closed?…

Huh? Atom/Electron is another great example of GitHub duplicating a ton of existing projects (whether dependencies such as CEF and node-webkit or high-level solutions such as ACE) without seemingly having any interest at all in joining those existing projects. Just because someone is successful at doing this does not make what they are doing any more reasonable: if anything it should just put them in a similar place in your mind to the Microsoft of the 90s which many people here would denigrate. GitHub's model of "open source"--the one which it is, devastatingly, teaching to an entire generation of developers--is only about code being available as opposed to being about community and collaborative design. Asking if one would prefer an alternative where the code is simply kept closed source ignores the premise of the compliant: that the code being an advertised separate project undermines the premise that working with an existing project to solve a problem tons of those users almost certainly also have. :/

Re: The GitHub Load Balancer

#50
post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

by that rationale, Apache httpd would have stayed Apache httpd, and we wouldn't have gotten nginx.
Post reply on HN