| HN Mirror

Sure but these are extra packages which help ease of deployment, management in an enterprise context etc. Some of them are side projects (eg: VRRP is provided by keepalived, route injection relies on Bird and some patches we tried to upstream and which were rejected as useless, but which we still provide in the source package). There are some internal development projects for some extra products as well (which appear in blue on the web page), and each time one of them requires any improvement from haproxy, the changes are mainlined before. Any single line of code of haproxy comes from the mainline sources, the source packages contains the patches, and all commit messages even contain the whole cherry-picked chain leading to the master tree's commit IDs first. We can hardly do better :-(

In fact, it's important to understand what enterprise users need : they never want to have to deal with patches or feature backports, most of them don't want to have to build anything, and instead they want to install regular pre-compiled packages from a permanently updated repository. That's exactly what we provide them. But providing pre-compiled packages is no excuse for not giving their sources at the same time, which we do.

Let me be very clear about something : a load balancer (and haproxy is no exception to this) is a very complex component and will always have bugs. And it happens that where it's deployed it's a critical component that must never fail, which is a bit incompatible with the first rule. For having dealt with proprietary LBs in the past, I'm well placed to know that you cannot and must never trust a non-fully opensource load balancer. And we've kept this spirit of full openness to achieve the highest possible reliability, and the GPL maintains this guarantee here. Some of the top contributors of the project are/have been working for enterprise customers and have brought very detailed analysis about certain issues, sometimes even proposing patches to fix them (or also small changes to make their life easier). As the project manager, I don't care where a patch comes from: any user, an occasional code reviewer, a customer, one of my coworkers etc. A fix is a fix, and if it addresses a real bug it must be merged, and the same rule as in the kernel applies here with no exception : mainline first. This guarantees that no patch is lost and the fact that the patch is the most possibly correct. And in order to get these fixes, you have to be the most open.

The situation as it is now benefits the two categories of users : - enterprise users don't have to wait for the next release to get certain features they need right now : some of the features from haproxy-1.8-dev are already present in HAPEE 1.6 or 1.7. So basically these users are encouraged to pick the most stable version which satisfies all their needs. - mainline code benefits from some feedback from the field (improvements and fixes) before the final release, which has allowed us quite a few time to adjust certain confusing things (option names, default behaviour, etc) before declaring them "stable" and having to maintain them forever.

The only advice I could give to people considering adopting a load balancer from a vendor : during the evaluation, ASK FOR THE SOURCES! If you can't have them, never use this product, one day or another you will regret it. And I'm not saying this just to try to place us in front when many other solutions are closed, but simply because I've been in this situation of using a closed product quite a few times in the past and hated it. That's even what led me to create haproxy in the first place!