Nginx does have paid-only features, so I don't really think your "purity move" hit the target...

The harsh truth is that even Free Software costs money to write, and developers should be paid.

As a developer, I like to get paid, but the issue of monetising something you already gave away for free is more complicated than that and the idea that somebody can build an effective business on something like caddy is probably a tad unrealstic.

There's a long list of free shit that we're building on top of. It's a bit like somebody sticking a cherry ontop of a free cake then trying to charge for it.

This is why a lot of people just go down the consultancy route. I imagine Matt Holt will be better off simply from being the author of a famous project.

Don't get me wrong though, if the project can monetise Caddy, all power to them.

Kevin Kelly of Wired magazine fame once wrote a piece called Better than Free which I think kind of distills key points against competing with anything that can be had for free on/from the internet [0], which are:

1. Immediacy (pioneer?)

2. Personalization (bespoke?)

3. Interpretation (consultancy?)

4. Authenticity (brand?)

5. Accessibility (SaaS?)

6. Embodiment (concierge/luxury?)

7. Findability (marketing?)

I'm not sure if anyone else has written abt this, but I'd like to read more.

[0] https://kk.org/thetechnium/better-than-fre/

Yes, basically this translates to that if you write a FOSS program and give it for free, you can start a side business for it with 10x the effort (marketing, polish, etc) needed than if you were selling it proprietarily, for 1/10 the profits...

> Kevin Kelly of Wired magazine fame once wrote a piece called Better than Free which I think kind of distills key points against competing with anything that can be had for free on/from the internet [0], which are:

Or maybe, you know, just have a better product. Case in point: NLEs. There are a whole bunch of free and sometimes open source NLEs, most of which just aren't particularly good.

> NLEs

Non-linear editing systems?

nginx has an ad-free truly FOSS offering under BSD-2-Clause (not AGPL or SSPL) that isn't intentionally hamstrung. Their paid features are for larger and more advanced deployments. They don't try to claim a different non-commercial license for the binaries. It's definitely a massive step up compared to how Caddy operated in the past.

If you start an nginx reverse proxy and it cannot reach upstream, nginx won't start at all. Only way to fix this is to pay.

Some friends got hit by this: they forgot some upstream from a domain that got removed, at the next nginx restart the whole server didn't come up.

Basically you have to pay for basic error handling. It's not "more advanced deployments" at all.

I have been using nginx pretty heavily in a wide variety of use cases for coming up on 10 years and I have never encountered this issue. I have also always used the free version of nginx.

I of course don't dispute that this limitation exists, but I'm just pointing out that the need for this type of error handling is, in my experience, quite rare.

There may be some very specific use cases where this is a deal breaker, but I would say the claim that the free version of nginx does not include "basic error handling" is a pretty grotesque exaggeration.

The scenario described only occurs if they’re using host names for their upstreams, and that hostname is no longer resolvable. It results in an error during config parsing, preventing reloads and fresh starts. Moral of the story: don’t use DNS names in upstreams unless you’re sure they’ll always resolve I guess.

That's tough: we do docker compose, so upstream = named container, and so init can be wonky (ex: dev). We have started strangling Nginx out for caddy bc this + LE (no pay gate on ssl autorenewal). These are increasingly basic things for modern apps.

>> If you start an nginx reverse proxy and it cannot reach upstream, nginx won't start at all. Only way to fix this is to pay.

I don't understand - if my upstream is down my nginx returns the usual "503 Service Unavailable". Are there any particulars to the configuration you are describing?

The problem isn't when the host is down, it is when nginx can't lookup the address for the host. If your DNS records are OK and your resolvers are working this isn't a problem, but if nginx (re)starts while you are having connectivity issues or if a DNS record that your config relies upon has been dropped it won't start any service until that one is edited.

Workarounds include using addresses not names (not practical at scale), running a local resolver that will hand out the last known address if it can't see the resolvers it normally forwards requests to or gets an NXDOMAIN response (extra hassle and technically breaks DNS so make sure other things don't use that resolver), or just ignoring the problem because it very rarely happens (though for some setups it is more likely than in others).

In my (current) uses of nginx it isn't a problem at all, though a concern springs to mind that might affect me later: if it only fails on startup, does that imply it isn't ever refreshing name->address mappings at all in normal operation so that if a server it is proxying for moves address that proxy config will start to fail until nginx is restarted? Any nginx experts want to comment so I can be lazy and not test or otherwise research this myself?

Huh. I don't think I've ever encountered this because I've only used nginx to server content or applications. I've always had it behind haproxy, which does have an option to allow haproxy to startup even if a backend host name doesn't resolve.

You describe an environment that is quite scaled up. I would assume that if there is scale, there is money. And a license to the commercial version is what, 2 salaried hours a year? It is easy to save time and money. I am sorry, but I cannot see this as a big problem.

We'd strayed off topic and were discussing an issue in nginx. Basic per-instance subscriptions for that are $2,500/yr each for small numbers of instances which is somewhat more than a couple of salaried hours.

Still not a large amount for a company with a profit making product, of course, but companies with profit making products are fewer and farther between than companies would like, and for a one-man-band or other small business trying to boot-strap something bigger, there isn't the same drop/ocean ratio.

Also, the implied problem (this still needs confirming/contradicting, so I might be barking up the wrong end of the stick) that it may not be updating name->address resolution regularly during normal operation (otherwise why does this only cause failure on start-up?) might not by fixed by the extra modules enabled by the paid licence.

It only happens when nginx is starting and the hostname of the upstream doesn't resolve, doesn't have to be reachable.

I believe just specifying a resolver should fix it, but another common workaround is to use a variable for the hostname

> Only way to fix this is to pay.

Nope.

  resolver 1.1.1.1;
  set $resolved_upstream whatever-it-is.lan;
  proxy_pass http://$resolved_upstream;

I am for sale, FWIW. ;) The first one's on me.

This is particularly annoying when using nginx to sit in front of a bunch of uwsgi (python) docker containers. if one of the containers doesn't start for some reason, nginx will abort.

Presumably you could write some basic error handling and distribute under the same or even stricter oss terms? It would be fairly simple to 'uncripple' it in other words, either with contributed code, or to wrap the upstream in haproxy itself to ensure availability.

You could but this is not in question here.

>> Their paid features are for larger and more advanced deployments.

This is simple not true.

I avoid this by running configtest before the reload - it checks it can get the upstream ips.

Software takes effort. Whether you want to get paid for that effort is a decision each developer can make, and many choose to contribute freely without payment. It's their prerogative. There is no "should" about it.

They said that they will focus on supporting enterprise clients, so that’s probably where the money will come from. This is similar to what Nginx is doing I believe.

Ah the rescue board of FOSS projects, because some devs can't be bothered to pay for their tooling.

That's the point of the licensing. It's free to use. Don't do it if you don't want to give it away for free.

Well, $25/per instance/per month is quite steep if you’re a small developer, especially not based in the US.

Short answer: Yep. And even for developers in western countries there is still the hassle of pushing it through purchasing.

Long answer, hopefully really thoughtful and careful as I've had time to think this through:

I think I remember sponsoring Caddy when it was still an open source project. Not much, maybe USD25 or 35 or something (dinner level or something I think it said).

Also I think they got a grant or sponsorship from Mozilla.

I never used it though, I only donated because I was enthusiastic about him creating a nice open source project that I would likely use in the future.

Next I know it is a commercial project, more or less (it took a while before I realized he had left a way around it and it seemed entirely intentional that it wasn't obvious.)

So now I have helped someone start a business, which is nice but not what I thought I did when I donated to a permissively licensed open source project. (I thought I was helping create a new Apache server.)

Still no big problems so far in my case, I'm lucky that USD25 is not much in my case and he probably deserved it even if it left a small sour taste right there and then.

The bigger problem is I never started using Caddy because when I came back to use Caddy I had to consider if my use case would be OK, if I would have to pay a license (which is fine with me but an extra hassle as it has to got through my boss) and suddenly it was very easy to fall back to Apache.

Suddenly instead of helping kickstart an open source project around a product I loved I've helped start a business with a product that I can't use.

One of the things with using commercially-licensed components like this in your stack is that is greatly increases complexity.

You have to worry about counting instances vs licenses. This might sound trivial, but months down the road, are you still remembering to go through and check which licenses are affected anytime you make a change to the number of instances you're running? Can you spin up another instance or two to handle a load burst, or does that violate your license terms and/or require a purchase order go through finance first? What about dev/staging/testing stacks? Can you spin up a replacement for your production in a blue-green deployment and flip, or do you require 2x licenses?

If the license is enforced technically (eg, a license file) then you have to also have that as part of your deployment, but also make sure you secure it. In the worst case if the license is unique per instance, that pretty much precludes use in modern "cloud" environments.

What guarantee is there the cost won't go up 10x come renewal time next year? If it does, what does it take to replace the component? As others have pointed out, you also have to go through purchasing and maybe convince someone(s) that this purchase is necessary, etc.

This is all extra cost (time) and pain that really doesn't exist with using OSS -- and brings it far above whatever the list price is (even if it's "only" $25/node).

Also, from a developer perspective, none of these problems are fun or interesting to spend time on. Even if it has some feature that's missing in the OSS equivalent, I'd way rather spend my time building out a missing feature than doing licensing paperwork.

They have had startup pricing of $20 per month for unlimited instances, which is what I've been paying. Though mostly I've just installed the free version with the HTTP ad header.

There are plenty of countries where small developers can afford it, US is not the only one.

When I was a student I did managed to buy several software packages, with student discounts, at prices that would be around 100 to 300 euros nowadays.

Let alone when one is actually having a business instead of a student side job.

Yeah, but it's still a lot for a small project which might easily run on a $5/month VPS. If your project is bigger than this then you don't gain much benefit from caddy: you might as well take half a day to setup certbot with nginx.

>> When I was a student I did managed to buy several software packages, with student discounts, at prices that would be around 100 to 300 euros nowadays.

Did you buy all of those packages yearly and for every one of your clients?

No, one time purchases, without distribution royalties.

And? Supermarkets don't take pull requests.

Good for you, but you can't expect that everybody is in the same situation as you.

Indeed, there are also plenty of stuff I cannot afford and have to contend with cheaper alternatives.

Just like you cannot expect people that you don't support their work, keep doing it for free ad eternum.

>Just like you cannot expect people that you don't support their work, keep doing it for free ad eternum

Sure you can.

And then upstream developers go work for a corporation and everyone downstream comes with their pitchforks to HN, bad luck.

$25 / instance / month. So if you have 5 side projects that make you no money and you want play around with some load balancing, etc you will probably have 3 sites with 1 instance an 2 with 2 each, so 7. Then you will want to play with some docker swarm clustering or whatever and you spread around your instances a bit and you end up with 10 instances. That is $250 / month. Not $250 one-off, but every month. Now you are paying $3000 per year for you side projects.

$2000-3000 per year is not something that I am willing to spend on my side projects.

Then search for other cheaper side projects, just like people on other professions happen to do, as they have to pay for their toys.

Software costs nothing to replicate. It's more advantageous to give hobbyists your software for free since they will not pay for any software and you can at least use them to make your software more popular.

Popularity doesn't pay bills.

You can not make money selling software to people who have $0 budget to buy it. Sell software to enterprises and give it away for free for OSS side projects.

Apparently before the FOSS wave they had money.

Because enterprises take it for free. The way you can prevent this is to use AGPL licensing and charge money to use it under a comersial license.

The problem is now no one uses your software because there are endless amounts of more permissive open source software available that work just as well.

>There are plenty of countries where small developers can afford it, US is not the only one.

In most of the world it's a lot though, even for developers. Being able to afford it is another thing than being able to comfortably afford it.

Sell something: https://piero.dev/2019/04/how-to-make-money-with-open-source...

From Github

> Congratulations! Interesting new approach to funding open source: get acquired and let them figure it out!