Next Steps for the Caddy Project Maintainership (opens in new tab)

*Matt btw

Oh wow. I just wrote a test that needed to parse CSV, and PapaParse was the perfect library for it.

Sponsoring right away.

Yeah, I donate from time to time to various projects. But voluntary contributions will never solve this issue.

I had in mind somehow requiring or rewarding everyone to pay a small amount. Like, anyone who uses software from a platform such as GitHub should pay a subscription fee for maintenance depending on usage. It could be small so that it doesn’t interfere with usage. Considering huge number of users, that could pay for maintainers.

As a core contributor, Matt has expressed on many occasions he would like to be able to pay us for all the time we've spent on the project, but I've always told him we're doing it as volunteers and not for money (my day job pays me sufficiently) and I think he needs it more since he doesn't have other sources of income. And if he did get enough from sponsorships to pay a second salary, I think he should hire someone not already a volunteer to broaden the skillset of the team. One of our biggest problems at this stage is that the members of the core team don't have expertise in a few specific areas that Caddy is lacking in (e.g. metrics/prometheus stuff)

Matt has been generous and rewarded me a few times for my efforts on the project. But just as Francis said, we are willing volunteers.

I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box:

    server {
        server_name example.com;
        root /var/www/wordpress;
        location ~ \.php(/|$) {
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/run/php/php-version-fpm.sock;
        }
        ssl_certificate /etc/ssl/local/service.pem;
        ssl_certificate_key /etc/ssl/local/service-key.pem;
    }

It's very similar to Caddy's, except for the explicit cert.

No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use.

In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking.

I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!

It's also extremely nice as a reverse proxy. You get the certificate for free and defering authentication to a middleware is very easy. The community has some very good option for this like caddy-security.

Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions?

Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions?

Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.

My 1st thought: The comment to which you are replying is why I'm not sure I'd have the patience to maintain an OS project. Though the older I get, the better I get at ignoring certain things.

My 2nd thought: Actually, this is very likely a culture/communication difference whereby both people care (I'm a big fan of Erin Meyer's work here)

My 3rd thought: I wonder what happens if I provide this repo and the chat comments to codex. Outcome: https://github.com/wsimmonds/caddy/pull/1

My 4th though: Perhaps I can make 'enemies' become friends if they both have disdain for AI ;)

Note: I would absolutely not submit this as-is. Caddy's an amazing project though I am not very familiar with its implementation and I'd seek to understand it, conventions etc. and make some obvious improvements to the code which has been generated - but this was a minor bit of fun. I created 4 separate versions and only in one of them did anything with TLS related get amended.

I think it's unfair to say that I post this every time when I've only mentioned it twice before, with the previous time being 2 years ago. I don't have a grudge, I just recognize it as an easy to reproduce bug that disqualifies me from using the software. I'm not itching to get off of nginx as I already have a site that works, so I have no motivation to do extra work to fix bugs in other projects.

You responded to a specific technical observation stated briefly and without emotion with a nasty personal attack.

Oh and now I see you work on the project. Hard pass on Caddy if this is how you respond to mild criticism.

That form of domain name is very common in DNS configuration. All it means is the name is complete already and should not have any local search domains appended. It's unusual to see it in URLs, but its presence should be harmless; that it's not harmless in Caddy is definitely an error - but I can't begin to understand why it would be seen as a particularly significant one.

The correct way to write a fully qualified domain name is with a period at the end otherwise it’s subject to the resolver search path.

I've never used caddy but "better config than nginx" is a pretty low bar.

I still think for Kubernetes ingress controller, traefik is more optimized for this use-case than Caddy. However, sitting in front of containers or a standalone reverse proxy I exclusively use Caddy.

Well then.

Hopefully some Mikes have been involved in the project as well and picked up some stray well wishes.

Haha, hi Mike!

(He and I were coworkers for a time.)