So technically isn't Caddy owned by a commercial company instead of merely sponsored?
I'm quite sceptical about promises about the future from commercial companies. It wouldn't be the first time an open source project suddenly wouldn't be open source any longer and would require a fork by the open source community due to actions from the owning company.
To be honest, the same can be said for nginx being acquired by F5. It has had an effect on the development direction. I think commercial interests are a valid reason to be sceptical, but at the same time, it's not like this is a super recent upstart. Track record counts for something and we should be pragmatic. I'm not going to use Apache httpd because it is more purely open source - it also happens to be like 30 years old and not very good.
Because centralization of open source community community is terrible for the entire web.
In a long term view scape, it might blurs gap between features and standards/RFCs.
It's unhealthy for democracy of community.
no offense, Matt Holt, You're always my most respectful community leader and security researcher.
Very true. I suspect that really starting with the assumption that someone is running a web server is probably too strong, as a lot of people are on shared hosting, or using some sort of containerization, or using some sort of "cloud" service that has TLS from their own CA built in if you can figure out what it's called and how to turn it on. The era of people just spinning up Apache (or nginx or whatever) is rapidly ending, and I think that any sort of "official" recommendation really needs to start with the principle of
It'd be really good if there were a good place to send people like in this recent thread of someone who wants to run hosting, knows that they should be providing HTTPS, but doesn't know where to start. I'm not sure where to tell them to start either.
In that specific case, one might start by suggesting that the proprietary "free reseller hosting" ecosystem they are using is likely going to limit their practical options to zero. I endorse your overall sentiment, however.
Can be. I developed CertSage to work around the limitations of such environments to act as a user-friendly, "bolt-on" solution. That said, I find many reselling "schemes" to be just that and often accompanied by corresponding practices and morals one might expect.
You're talking about two different things. The copyright of the website and trademark mentioned in the footer are not the same thing as "sponsoring Caddy."
Well hello Mr. Lam No offense taken...
Agreed, except when people are in need of a web server.
Yeah I'm not sure either, but I think this is getting close.
It sounds like what Let's Encrypt could do is offer some general advice depending on the user's situation. They are on the Let's Encrypt website because they need TLS. So, do they have a website? Do they have a web host? Are they running a web server? And then direct them back to their software's or host's documentation related to HTTPS.
Dang I'm so sorry that comment hurt you. That was not expected, nor my intention. I really respect your contributions to the community.
So you're saying Stack Holdings GmbH does not own the code? E.g., they can't force you to make the github repo private? Which would be a good think of course
Whatever decision happens, I do think Let's Encrypt should stop recommending Certbot as the highest recommendation.
They've stopped taking new plugin integrations into the main repo, which just makes the experience of using it with random providers harder and harder.
I've personally started mainly using Lego when I need a certbot-like client.
I'm not really an expert on licenses and I was hesitant about the apilayer acquisition, however Caddy appears to be irrevocably Apache 2.0 licensed.
I think it would be pretty hard to switch it to a commercial product, aside from monetizing priority / phone / email support which I believe they and Nginx already do.
Thanks for all the thoughts everyone. I really appreciate it.
I agree that I think the best approach isn't a single recommendation for everyone and instead what people should use depends on their specific circumstances. I personally think that striking the balance between having different recommendations for different scenarios while not getting too into the weeds too early and potentially confusing more novice sysadmins is tricky, but it's definitely doable.
To ask yet another question though for those who don't mind, what do you all think of suggesting that many people consider using something like Caddy/Traefik as a TLS terminating reverse proxy in front of their existing infrastructure (if they cannot switch to something like Caddy entirely)? On the one hand, that does result in a more complex system, but in some ways I think it simplifies the process of setting it up significantly. I think in many ways what HTTP thing they have behind the reverse proxy is then irrelevant for our community. Our task would just be helping them set up Caddy/Traefik and pointing it at their existing thing.
What do people think? Too complex? Caddy/Traefik too new for brownfield projects? Other problems I'm missing entirely?
I agree adoption of ACME is the more important question. This is why I created acmeisuptime.com. There are plenty of cases where organizations are hesitant to adopt ACME out of FUD and I felt like as a community we needed to do a better job telling that story.
No offense taken...
I'm so sorry that comment hurt you. That was not expected, nor my intention. I really respect your contributions to the community.
