Correcting an assumption can hardly be termed as 'lashing out', maybe a 'robust' response.
Rather have founders like wtarreau speak their mind than adopt some fake passive aggressive tone or have a 'dev relations manager' spinning, at least here.
> Correcting an assumption can hardly be termed as 'lashing out', maybe a 'robust' response.
'correcting an assumption' seems orthogonal to 'lashing out'.
also, it's not clear he even addressed the op's point, insofar as i understand. haproxy enterprise does seem to contain features unavailable in the 'community' version:
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!
To me, it seems that one could read an (unsaid) implication in your original comment that is “and those advanced features will only ever be behind a paywall” — as I think in nginx’s case that’s actually true for some features (but I might be remembering incorrectly!), and by listing and comparing HAproxy and nginx in that manner I can see that implication. But that’s being kinda nit
picky, though if I was an HAproxy dev and all features were developed in the open and released into the mainline for free in a new stable version in the future, I would probably read it that way and be a little miffed, I suppose
All the features developed in HAProxy, are pushed in the -dev branch of the community version. They are available for free at your own risk (running a -dev code in prod), or you have to wait until -dev become stable.
HAProxy Enterprise users might already benefit from this feature in a stable way.
On the opposite, in nginx, some features are developed only in their proprietary solution. Sometime, nginx inc passes for heroes because they open source some of them...
Rather have founders like wtarreau speak their mind than adopt some fake passive aggressive tone or have a 'dev relations manager' spinning, at least here.