The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really. The complete rewrite for Caddy v2 was necessary to make Caddy flexible enough to solve like half or more of the open issues the Caddy repo had at that point. Flexibility and simplicity are often at odds. But Caddy tries to keep smart defaults in general.
Also, any time someone brings up the malicious fork "wedge", it saddens me. That was done at literally the most stressful moment in the project's history, and it only made things worse for everyone. I really hope people learn to chill out and give maintainers a bit of time to breathe and respond instead of taking such hostile measures like that. (You can probably pretty easily dig up the Github issue with the discussion if you really care to see what went down. Sigh.)
> The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really.
You know, as someone who used Caddy v1 pretty extensively (still probably have it running on some of my homelab boxes), i never really ran into those supposed problems. Maybe they'd manifest in more complex configurations, but as a reverse proxy, file host, web server that's integrated with PHP or even something to allow setting up basicauth, i never found it to be lacking.
That's not to say that Caddy v2 is bad, just that someone for whom v1 worked perfectly might find it a bit cumbersome to move to the newer version, as the old one is no longer supported. Of course, you can say the same about JDK 8 vs JDK 11+ etc.
> Also, any time someone brings up the malicious fork "wedge", it saddens me.
If i recall correctly, it just took the project and rebranded it, which isn't necessarily malicious (for example, aggregating and selling users' data would). That's the nature of open source - anyone who wants to do that, can.
Of course, i think that the fork is also irrelevant because they couldn't actually be bothered to maintain the fork and nobody cared for it, much like how other projects, like Materialize.css, ended up.
Also, any time someone brings up the malicious fork "wedge", it saddens me. That was done at literally the most stressful moment in the project's history, and it only made things worse for everyone. I really hope people learn to chill out and give maintainers a bit of time to breathe and respond instead of taking such hostile measures like that. (You can probably pretty easily dig up the Github issue with the discussion if you really care to see what went down. Sigh.)