Back during that mess, I settled on haproxy+certbot+nginx in containers to setup my personal sites, but something like Caddy can greatly simplify that kind of stack.

This is pretty cool news and I hope this project continues to develop. How have they solved their funding problems? Does this have to do with the comment about Ardan Labs? For other people with FOSS projects who want to be able to work on this kind of stuff full time and not care about motorization, what options are there (other than Patreon/crowd/community type funding?)

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

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.

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/

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.

Non-linear editing systems?

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

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?

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?

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.

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

Nope.

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

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

This is simple not true.

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.

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.

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

And? Supermarkets don't take pull requests.

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

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

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.

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.

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

Imagine the amount of innovation we'd get if this happened with hardware too.

But then I opened the article and was brought back to earth. soon

Then I realized this could be extended to anything where there is a platform for rating the content creation, from books (Goodreads) to arts (deviant art) to deeds (Facebook and Twitter). Then my friend told me I had reinvented Whuffie, as presented in the book Down and Out in the Magic Kingdom...

The main problem with this idea is that the money for paying creators would probably have to come from the government, since who else would pitch in to support this? But hey, people talk about universal basic income, this is like a weighted version...

I went from “I’m going to use this everywhere” to “I’ll switch back to nginx the next time I have time to transition back” Because it was too expensive to host little sites on. I’m relieved that I procrastinated. Now i can continue to use it in many places since Caddy is awesome.

Prior to the partnership I believe the real issue was that Matt & co didn't have a sustainable way to maintain the project and they were trying to figure that out. I don't know the details of the partnership with Ardan Labs, but my guess is it is structured in a way that allows Caddy to focus solely on building out a great product without worrying about monetizing it so they dropped all the proprietary licensing.

[1] - https://www.ardanlabs.com/news/2019/05/ardan-labs-partners-w... [2] - https://twitter.com/mholt6/status/1179957356005707776 [3] - https://twitter.com/goinggodotnet/status/1178949305421438976

> Caddy-Sponsors: This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph

https://github.com/caddyserver/caddy/pull/1866

Donations, books, patreon, pull requests.

So these devs crib on little amount of money to OSS devs but big time supporters must not put any ad at all.

Of course we need to be paid top dollar. We donate our (finite) time and mental resources at the cost of family life, etc. to integrate and master 9 Javascript libraries, 8 messaging formats, 7 architectural patterns, 6 programming languages, 5 package managers, 4 cloud platforms, 3 operating systems, 2 caching tools, and 1 HTTP server to power it all.

Along the way, the creators of quality OSS benefit from the popularity of having thousands of adherents donating their collective millions of hours and trillions of neurons learning their software packages and providing fixes, ideas, and polishing to their product. And once the users have all 45 of those tools successfully integrated over years of effort and lessons learned, along comes an OSS creator who writes the newest 9 Javascript libraries...

Do I correctly understand that Light Code Labs, the company steward of the Caddy project, is shifting to an entirely professional services-based business model, which is Ardan Labs' business model, by partnering with them?

Since Ardan Labs is already in the support business, this would allow them to expand their business while Light Code could focus on coding.

Curious, who/when would you use caddy? If I were to be building and deploying microservices with the likes of Gin, Mux, etc.. would I have a use for this library? Or is this primarily for those wanting to serve static html pages? Still trying to get a foot hold on what my tool kit is going to consist of to build my software product.

But caddy is also pretty cool to use as a development web server as well.

https://caddyserver.com/docs/automatic-https#on-demand

Obviously not what it’s limited to, but that’s it’s selling feature for me

You can look at the features list to see more: https://caddyserver.com/features

I do not use Caddy (the code) as a library.