Hacker News Reader

Comment by otterley | Hacker News Reader

Looks like both HAProxy and Nginx are going down the "pay for more advanced features" route:

https://www.haproxy.com/products/haproxy-enterprise-edition/

https://www.nginx.com/products/nginx/

What ? Are you kidding ? We're extremely open, we currently have 7 devs working full time for most of the stuff you'll have in 1.8, we provide all the sources with our packages (and some of our customers do their own builds), and all the stuff we add in the enterprise version is in fact a fine selection of stable enough features from the dev branch for people who need them right now without waiting for the next version to be released. When a customer asks for some specific feature we explain them that it first has to be in mainline so we can backport it and it gets a wider exposure to spot bugs. How can you be that insulting ? If it's a matter of unclear explanation on the web site, it's possible and then please report this to contact@ or something like this (I don't know the address). If it's just because you want to criticize without knowing, well, in this case I hope I'll never count you among our users!

It was an observation, not an insult. Many of us, myself included, are more than happy to pay for the software we use.

However, I would strongly consider hiring a mature developer relations manager. You're a fantastic developer, Willy, but you risk losing business by lashing out like this.

OK fine. But my business is not to sell products, it's to maintain haproxy the best load balancer. It's other people's task to present it as an eye candy thing that attracts and pleases customers. And obviously I give my opinion from both a user's and a developer's point of view.

We work hand-in-hand : if I fail at my task, the product dies and the company suffers as well. If the company fails, I will have to find another way to eat my daily steak and that will necessarily affect the project. That's why the company helps me in this difficult task by hiring the developers I need to help me on this job and why in turn I freely express my opinion when people attack the company's motivations in a way that I find really unfair.

And if you want to get a better sense of what I'm saying, just issues this in the master branch to see who fixes most of the bugs, resulting in haproxy being really usable in production by all of us :

$ git shortlog --grep BUG v1.7.0..

Nitpick: We're extremely open, ... compared to other COMPANY BACKED PROJECTS, but far away of totally OPENSOURCE projects that doesn't reserve any feature... we currently have...

https://www.haproxy.com/products/haproxy-community-vs-enterp...

Said that. Yes I'm grateful to be able to run and modify both HAproxy and Nginx for free, but parent is totally right in the comment. Both projects are going that route, compared with their beginnings.

Downvoting me, won't make those Enterprise features opensource, neither will make the parent comment wrong. Both projects are going that route.

Easy there, tiger. Not doing well for the brand of your team.

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:

http://www.haproxy.com/products/haproxy-community-vs-enterpr...

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!

What assumption was being corrected here? Please cite with specificity.

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...

there are separate 'community' and 'enterprise' versions, and there's even a comparison chart on the website.

You're not... he has a point.

Note, this feature will be in the free version when 1.8 is out. Early access is for enterprise customers.

no, this feature is already available in -dev community branch. So it's already available for free.

Note this feature has not yet been backported into HAProxy Enterprise...

is there official confirmation of this? it would seem like a change of pace given how the community vs enterprise feature lists play out:

http://www.haproxy.com/products/haproxy-community-vs-enterpr...

Well, nignx inc does first develop their proprietary software... Then, they "open" some features. With nginx plus, you're locked to nginx, like when you were using a F5 load-balancer!

HAProxy Technologies pushes first its developments in the -dev community branch. Check the commits for the feature given above (SRV records, non exhaustive list of patches): http://git.haproxy.org/?p=haproxy.git&a=search&h=HEAD&st=com...

HAProxy technologies simply makes the effort of maintaining a branch of HAProxy in which some -dev features are backported. That way, users of HAProxy Enterprise have the most stable and feature reach version of HAProxy. And as Willy stated, every user of HAProxy Enterprise also have access to the source packages.

So from a business point of view, the main difference between HAProxy and nginx is that HAProxy is the respects both its community and customers.

Reply on news.ycombinator.com