News for hackers. Stuff that matters.
Re:Put a Fork in Caddy; It's Done by pmlnr on Monday April 30, 2018 @10:44AM (#16958918)
Being able to fork in case of disagreements is a feature of open source, not a bug.

Some of these forks get re-merged a few years later (see ffmpeg), others don't, but this is not bad at all.

The ideal solution would be to build Caddy with flags that disable telemetry, just like Firefox is built for Debian.

Re:Put a Fork in Caddy; It's Done by detaro on Monday April 30, 2018 @10:50AM (#16958978)
There's a difference between announcing a fork with "we disagree with the following upstream decisions and thus are making this fork that will remove them" and broadcasting widely something along the lines of "I hate this, it's totally unacceptable, it's done, could someone fork it for us?" though, smearing all kind of barely related things into it.
Re:Put a Fork in Caddy; It's Done by conradk on Monday April 30, 2018 @10:49AM (#16958961)
Totally! Forks can be great.

Saying "Caddy was supposed to be great" or "This is no longer just a conversation on privacy; this is a hostage situation" is not right. Caddy is great, but Neflabs doesn't agree with the direction it's taking. The solution is not describing the free software's developer as a hostage taker.

The solution, as you said, is forking.

Re:Put a Fork in Caddy; It's Done by astrodust on Monday April 30, 2018 @11:06AM (#16959156)
Apache httpd is itself a (patchy) fork of NCSA httpd.