10 ms·

To me it totally sounds like 'all those features (some bizarrely so) we locked behind a commercial license to extract money from you' has resulted in people loo

To me it totally sounds like 'all those features (some bizarrely so) we locked behind a commercial license to extract money from you' has resulted in people looking for alternatives as soon as the use case exceeded the capabilities of the open source version. Kubernetes and the ecosystem is eating their lunch for more complex service mesh deployment scenarios where nginx is basically an interchangeable dumb proxy, and doing it with generally new and free open source products, so here, have some more stuff we've kept gated behind an expensive license/subscription so we can stay relevant. I don't say this to be ungrateful about what nginx has provided for free, it's great, thank you. But the post also feels like a cynical take about what the value of open source truly is.

miohtama 4y ago
My web server path has been Apache -> (Varnish) -> Nginx -> Caddy. This outside programming language specific servers like Waitress or Express.js. I love the fact that Caddy is a single binary I can run for simple use cases without configuration file. Plus the built-in Let’s Encrypt support. Nginx is definitely on defence here unless you need “web scale” servers.
- kungfufrog 4y ago
  Also a huge fan of Caddy!!! Such a smart design and incredibly useful piece of software!
  - FooBarWidget 4y ago
    But since we're replying to a comment that's criticial about Nginx's commercialization: Caddy also tried to commercialize, and for some time they got way more criticism for that. Are those concerns no longer applicable?
    - francislavoie 4y ago
      Yes, no longer applicable. https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
- ksbrooksjr 4y ago
  Yeah Caddy's developer experience is unrivaled when it comes to setting up SSL. You don't have to run Certbot or manage certificates manually. If you give it a hostname to proxy to, it just handles certificate management seamlessly in the background. The real killer feature for me is the Cloudflare module. It allows you to use the acme DNS challenge, which means you can test your SSL setup without exposing your server to the public internet.
  - manishsharan 4y ago
    certbot has dns plugin for nearly all DNS providers including Route53 and Cloudflare. I have been using LE certs on the nginx server on my developer environment without any issues ,other can copying over the certs.
    - ksbrooksjr 4y ago
      Certbot is fine, but it’s nice to have that functionality built directly into the reverse proxy as opposed to having to configure and update multiple tools. I would ideally like to see Nginx integrate a subset of Certbot’s feature set into their code base especially given that offloading SSL is one of the primary use cases of Nginx.
- jenia2022 4y ago
  Why do you have so many reverse proxies hooked up to each other? Specially Apache and Nginx? I suppose you're using Caddy for its LetsEncrypt support?
  - kungfufrog 4y ago
    They're talking about a timeline of products that they've used. Not an architecture.
    - jenia2022 4y ago
      Oh. Ok. Thanks
- mholt 4y ago
  To clarify, Caddy absolutely can deal "web scale" as proven by companies like Fathom, Stripe, and many others. (The Go standard library powers many of Google's, Cloudflare's, and Netflix's infrastructure, and Caddy is a relatively thin wrapper over that.)
kungfufrog 4y ago
Also, if you need further evidence of this, look at the MARA diagram. It basically spells it out. There's 2 products in that stack that are branded: nginx and Kubernetes, the rest is noise, with nginx positioned as the only component for traffic ingress. Also if that napkin scribbling constitutes an "architecture"...
0xbadcafebee 4y ago
"Going forward, all NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. [..] We pledge to be more open to contributions, more transparent in our stewardship, and more approachable to the community. We will follow all expected conventions for modern open source work and will be rebuilding our GitHub presence, adding Codes of Conduct to all our projects, and paying close attention to community feedback." "we recognize that many critical features which developers now view as table stakes are on the wrong side of the paywall for NGINX Open Source and NGINX Plus. For example, DNS service discovery is essential for modern apps. Our promise is to make those critical features free by adding them to NGINX Open Source. We haven’t yet decided on all of the features to move and we want your input. Tell us how to optimize your experience as developers. We are listening." "The NGINX Kubernetes Gateway is also something of an olive branch we’re extending to the community. We realize it complicated matters when we created both a commercial and an open source Ingress controller for Kubernetes, both different from the community Ingress solution (also built on NGINX). The range of choices confused the community and put us in a bad position. It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we are changing our approach and will make the NGINX Kubernetes Gateway – which will be offered only as an open source product – the focal point of our Kubernetes networking efforts (in lockstep with the evolving standard). It will both integrate and extend into other NGINX products and optimize the developer experience on Kubernetes." It sounds pretty honest and positive to me. And I'm the first person to call bullshit on corporate doublespeak. Most other companies would just put more money into B2B sales rather than courting OSS devs/free users and admitting when their strategy was stupid (actually their language is evasive, but w/e). Of course hindsight's 20/20; let's see if they make good on these promises.
- mistrial9 4y ago
  > NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. friendly tip - not everything is on Github, not everyone is on Github, everything can be on Github but that's not the only place everything can be
  - 4y ago
colechristensen 4y ago
I would put it in a more positive light. Long ago, nginx was excellent providing way more than Apache or other alternatives. Then they added features which were pretty advanced and uncommon behind a pay wall. Many of those features have gone from fancy to expected, and they transitioned too late to making them open source. The free product went through a slow decline from excellent to artificially crippled, and they’re changing course, which should be applauded. On top of that they didn’t take away features to cripple their product for money, just what is basically necessary these days is so much more than it was years ago.
- kungfufrog 4y ago
  I don't disagree with your take. I just find it disheartening that it took what presumably they must perceive as a threat to their revenue stream to start listening to developers/engineers about the role open source can play in their product offering and what effect that might have on the "community" around nginx.
  - folkrav 4y ago
    To me it sounds rather par for the course as far as open-source projects going partially paid, no?
- bcrosby95 4y ago
  I thought nginx gained popularity because of it's, at the time, superior concurrency model.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

miohtama 4y ago

My web server path has been Apache -> (Varnish) -> Nginx -> Caddy. This outside programming language specific servers like Waitress or Express.js. I love the fact that Caddy is a single binary I can run for simple use cases without configuration file. Plus the built-in Let’s Encrypt support. Nginx is definitely on defence here unless you need “web scale” servers.

kungfufrog 4y ago
Also a huge fan of Caddy!!! Such a smart design and incredibly useful piece of software!
- FooBarWidget 4y ago
  But since we're replying to a comment that's criticial about Nginx's commercialization: Caddy also tried to commercialize, and for some time they got way more criticism for that. Are those concerns no longer applicable?
  - francislavoie 4y ago
    Yes, no longer applicable. https://github.com/caddyserver/caddy/issues/2786 https://github.com/caddyserver/caddy/issues/2786
ksbrooksjr 4y ago
Yeah Caddy's developer experience is unrivaled when it comes to setting up SSL. You don't have to run Certbot or manage certificates manually. If you give it a hostname to proxy to, it just handles certificate management seamlessly in the background. The real killer feature for me is the Cloudflare module. It allows you to use the acme DNS challenge, which means you can test your SSL setup without exposing your server to the public internet.
- manishsharan 4y ago
  certbot has dns plugin for nearly all DNS providers including Route53 and Cloudflare. I have been using LE certs on the nginx server on my developer environment without any issues ,other can copying over the certs.
  - ksbrooksjr 4y ago
    Certbot is fine, but it’s nice to have that functionality built directly into the reverse proxy as opposed to having to configure and update multiple tools. I would ideally like to see Nginx integrate a subset of Certbot’s feature set into their code base especially given that offloading SSL is one of the primary use cases of Nginx.
jenia2022 4y ago
Why do you have so many reverse proxies hooked up to each other? Specially Apache and Nginx? I suppose you're using Caddy for its LetsEncrypt support?
- kungfufrog 4y ago
  They're talking about a timeline of products that they've used. Not an architecture.
  - jenia2022 4y ago
    Oh. Ok. Thanks
mholt 4y ago
To clarify, Caddy absolutely can deal "web scale" as proven by companies like Fathom, Stripe, and many others. (The Go standard library powers many of Google's, Cloudflare's, and Netflix's infrastructure, and Caddy is a relatively thin wrapper over that.)

kungfufrog 4y ago

Also, if you need further evidence of this, look at the MARA diagram. It basically spells it out. There's 2 products in that stack that are branded: nginx and Kubernetes, the rest is noise, with nginx positioned as the only component for traffic ingress. Also if that napkin scribbling constitutes an "architecture"...

0xbadcafebee 4y ago

"Going forward, all NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. [..] We pledge to be more open to contributions, more transparent in our stewardship, and more approachable to the community. We will follow all expected conventions for modern open source work and will be rebuilding our GitHub presence, adding Codes of Conduct to all our projects, and paying close attention to community feedback." "we recognize that many critical features which developers now view as table stakes are on the wrong side of the paywall for NGINX Open Source and NGINX Plus. For example, DNS service discovery is essential for modern apps. Our promise is to make those critical features free by adding them to NGINX Open Source. We haven’t yet decided on all of the features to move and we want your input. Tell us how to optimize your experience as developers. We are listening." "The NGINX Kubernetes Gateway is also something of an olive branch we’re extending to the community. We realize it complicated matters when we created both a commercial and an open source Ingress controller for Kubernetes, both different from the community Ingress solution (also built on NGINX). The range of choices confused the community and put us in a bad position. It’s pretty clear that the Gateway API is going to take the place of the Ingress controller in the Kubernetes architecture. So we are changing our approach and will make the NGINX Kubernetes Gateway – which will be offered only as an open source product – the focal point of our Kubernetes networking efforts (in lockstep with the evolving standard). It will both integrate and extend into other NGINX products and optimize the developer experience on Kubernetes." It sounds pretty honest and positive to me. And I'm the first person to call bullshit on corporate doublespeak. Most other companies would just put more money into B2B sales rather than courting OSS devs/free users and admitting when their strategy was stupid (actually their language is evasive, but w/e). Of course hindsight's 20/20; let's see if they make good on these promises.

mistrial9 4y ago
> NGINX projects will be born and hosted on GitHub because that’s where the developer and open source communities work. friendly tip - not everything is on Github, not everyone is on Github, everything can be on Github but that's not the only place everything can be
- 4y ago

colechristensen 4y ago

I would put it in a more positive light. Long ago, nginx was excellent providing way more than Apache or other alternatives. Then they added features which were pretty advanced and uncommon behind a pay wall. Many of those features have gone from fancy to expected, and they transitioned too late to making them open source. The free product went through a slow decline from excellent to artificially crippled, and they’re changing course, which should be applauded. On top of that they didn’t take away features to cripple their product for money, just what is basically necessary these days is so much more than it was years ago.

kungfufrog 4y ago
I don't disagree with your take. I just find it disheartening that it took what presumably they must perceive as a threat to their revenue stream to start listening to developers/engineers about the role open source can play in their product offering and what effect that might have on the "community" around nginx.
- folkrav 4y ago
  To me it sounds rather par for the course as far as open-source projects going partially paid, no?
bcrosby95 4y ago
I thought nginx gained popularity because of it's, at the time, superior concurrency model.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]