This blog post demonstrates why the syslog feature is ideal for segmenting Nginx's market.
Almost nobody cares about it, except the sort of place doing > tens of millions of requests per day. The sort of place that might have some money and the scale to realise that a few thousand bucks is cheaper than a bunch of engineer time.
>I don’t blame NGINX for wanting money in exchange for what is admittedly amazing software. I just don’t want any part of it.
Why not? You're using this awesome software whose value you appreciate and which is, you admit, open source. It's just not convenient enough for you. So why can't you pony up the money for your huge, high-traffic website?
>Yep, they took a feature that Apache httpd has had literally forever and put it behind a pay wall.
Charging for support is one thing, but this seems like it should be a basic feature.
And if I were running a server farm on FOSS software and then realized I'd need to cough up ($1350 * ~100) around $135k for the ability to disable obnoxious behavior, because the corporation arbitrarily decided that this particular feature (that most every other HTTP daemon worth a crap has had for ages) was the one that they're going to require you to pay for, I'd be a bit scandalized too, probably enough to write a blog post about how much it annoyed me.
It's perfectly reasonable to cringe at a $135K price tag. But if that's so onerous, why not spend a day compiling the source and setting it up for distribution on your servers? The answer is that you (or at least the hypothetical you) feel entitled to this software packaged how you want it with the features you want.
If you want to use Apache, use Apache. That's totally your right. Or you can fork NGINX and do whatever you want. It's even got a BSDish license to make that easy. You could even use the last version of the software that baked this feature into the standard distro. But you're using the official NGINX distro for a reason, and I don't see why the people who make it shouldn't demand a bunch of money for whatever that reason is.
To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that.
>To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that.
And you would be an anchor dragging the project down. You aren't considering the angle of external contributors. As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this. Especially if they rejected a patch because the feature in the patch was too 'useful'. Disgusting.
How long do you think you will keep getting external contributors when they can't even use the full software and are afraid to put the work into patches because they might conflict with the 'enterprise offering'?
If you open source something and allow external contributors, you are going to receive this entitled tone when you pull these shenanigans.
> As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this.
That's a good point, and I agree. But that's not the perspective being presented by this article, as far as I can tell.
It's pretty simple actually: We don't have an HTTP server software budget. The expectation is that the tech team will choose the right tools for the job and ask for paid tools when we need them (eg. New Relic). NGINX doesn't differentiate enough from the other HTTP servers out there to justify the cost.
What angst? That post reads more like a warning to others to me - after all, if they'd been aware of this issue from the start, they could've just used Apache from the beginning and avoided the hassle of having to migrate.
>NGINX doesn't differentiate enough from the other HTTP servers out there to justify the cost.
From the post:
>admittedly amazing software
It sounds, honestly, like you're never going to pay for OSS. That's fine if that's the way you want to do things, but to then write a post entitled "We should ditch NGINX" seems way over the top.
Because you depend on a tool that you're not willing to pay for .. is it so difficult to see that you are being viewed as a bit of a scrooge, given that you will profit greatly from software you don't own and haven't paid for .. ?
First, there is no proof of how much profit comes from nginx in a stack with PHP so you can drop the 'profit greatly' line.
Second, the entire point of open source software and the FOSS movement is that you shouldn't be extorted for functionality. Do you harass people that file bug reports or submit requests for features to the Linux Kernel for not paying?
The entire point of FOSS is being able to have the source code of the software you use. Period. That's it.
The people who write the software can do whatever the hell they want, as can the people using the software, as long as they abide by the licence. These are the only stipulations. Even RMS supports the right of creators to sell software.
People who write FOSS software aren't required to be a charity...
> People who write FOSS software aren't required to be a charity...
I think this is a point so many users of FOSS miss. I'm an ardent supporter of FOSS, but I don't get to act entitled unless I'm paying someone (and probably not even then).
Are you or are you not running a business with FOSS? It was Free: so any USE of the software that you get out of it, was profitable. What part of "this is free, so anything you do with it is profitable" do you not agree with?
Second: extortion, really? Thats what you're calling this, in the same breath as admitting that you won't/can't/are unwilling to pay for software that is a key part of the production line?
The over-the-top part is where you use the stigma from your story (how nginx spurned you by choosing to charge you for a particular feature, which does not seem fair to you because you need it) to try to get everybody to stop using it, when the issue is simply that it does not suit YOUR needs.
If nginx has no features that set it off feom other servers you could simply switch to Apache which has the syslog feature. But for some reason you do not seem to do this, or am I mistaken?
"NGINX Plus Standard" costs $1,350 annual subscription per server. It sounds like this company has a pretty strange setup, running "hundreds of VMs", presumably all running nginx, and it's the combined impact of those VM logging writes that are so burdening the NetApp devices.
In this case, if they kept the same setup, I can see that it would be prohibitively expensive to pay for nginx plus on every single one of those VMs. I'm not sure of the nginx's license terms but if they count VMs as a separate server - probably a no go.
A better solution might be to turn all those VMs into application servers and put a big meaty nginx reverse proxy in front of them; that sounds like it would reduce the nginx bill but could be an awful lot of work. Then again, I presume they have automation, you'd hope so with hundreds of VMs...
My point is that it's likely not quite as simple as a grand a year, which would likely be a no-brainer if it was a site license.
first, that price is almost certainly negotiable, particularly if you call and say "i'm running a ton of light vms for some strange reason"
second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!
>second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!
On the surface yes, but consider the betrayal to all of the external contributors. Is the money going to them too? What about the people that wasted time proposing a patch that overlapped with this 'enterprise feature'. Open source is not a one-way street.
So, I found myself in a similar position recently with a technically FOSS project. The patches I was submitting were being re-licensed under a commercial license and sold to enterprise customers. I had to sign contributors agreement before sending patches and after the fact I found myself having a philosophical issue with them selling my work. As a consequence, I stopped submitting patches to the main project and instead maintain my own patch repo now.
While I find the wholesale re-licensing of the codebase under a commercial license reprehensible, I agreed to that before committing code. That leaves me with one remedy, not committing additional code.
As a side note, this project had a basic FOSS version and an enterprise version with additional functionality. The only part of what they did that I took issue with is re-licensing the FOSS portion under a commercial license. Had they left the FOSS portion under the OSS license and simply added commercial code on top I would have 100% continued to commit patches.
I am not disagreeing that in this specific case that the licence structure might lead to unhappy arithmetic. I do however stand by my original point that syslog support is an excellent cleavage point to segment the customer base.
I'm slightly less happy about the HTTP live streaming being in the Plus package, though. I've been playing around a lot with a media app using HLS and I can't even trial using nginx for it - not that I'd be too happy paying $1300 a year since I don't have a single user yet. I can see how they are trying to get money out of the big streaming companies, but it's not too friendly to the little guy.
Segmentation is a lossy function, unfortunately. If you try too hard to fit the price/feature curve by creating too many segments, you wind up with nonsense like Windows Home Professional Premium Plus Ultimate Edition.
FYI, you might want to try nginx-rtmp-module (https://github.com/arut/nginx-rtmp-module); HLS support is one of its advertised features. I've been using it for RTMP and it's been working flawlessly.
>I do however stand by my original point that syslog support is an excellent cleavage point to segment the customer base.
Probably because you are not a systems engineer. Did you see what it resulted in here? Many of the people who have systems large enough to hit these issues will just work around it using the ramfs approach or by just dumping nginx. Either way you have a skilled engineer disappointed in your product.
Don't differentiate FOSS with paid on something that simple, especially something that has been supported by apache for almost a decade.
At these volumes, nobody really would multiply one server price tag per amount of VMs. That's when people negotiate. So 135k price tag is probably purely imagined.
Almost nobody cares about it, except the sort of place doing > tens of millions of requests per day. The sort of place that might have some money and the scale to realise that a few thousand bucks is cheaper than a bunch of engineer time.
It's a good case study in smart pricing.