Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Caddy Commercial Licenses

caddyserver.com

Post reply on HN
Print view View original

61–70 of 295 posts

Re: Announcing Caddy Commercial Licenses

#61

Post by jimangel »

mholt wrote: post #46
jimangel wrote: post #21

I completely understand this direction, and really appreciate the work mholt and team has put into Caddy, but I'm disappointed at the same time. I looked forward to spinning up my dumb ideas tied with commerce using Caddy (on a 0 budget). I've been a Caddy evangelist ever since discovering the powers (auto HTTPS, git webhooks, simple config, etc.), I had plans to write blogs about simple sites for simple ideas that c…

Thanks for your feedback. Really appreciate it. > Does anyone know if there's significant pain in maintaining a docker image that compiles source code like Caddy on rebuild? Yes, Cory specifically is looking into the ability to get custom distro packages and containers through our website for our customers. Totally understand about bootstrapping a business and the costs there. Feel free to contact us: sales@lightcode…

Thanks! While I appreciate the offer to work with sales, it really abstracts the simplicity of Caddy (ex: grab this binary, add these couple lines, and BAM you have a site).

I want to shout from the rooftops about Caddy and how awesome it is to effectively roll out side projects. If I had to create a blog post saying "contact sales if you're just starting out" at the end, it would leave a bad taste in my mouth.

An amazing part of the open source tech community is the ability to read a blog post, put the concepts together, and see the light (or not). I've grown so much as a professional by reading blogs, forums, etc and I'd love to give back. Before today, Caddy stripped away the complexities of maintaining a webserver and allowed entrepreneurs to focus on what matters. This move appears to add the complexity back in for those who want to still use it as open source.

Once again, love the work you've done on the project and understand the desire to make money. IMHO a model similar to nginx or an "honor system" (companies generating more than X revenue need to purchase a license) would be better.

Re: Announcing Caddy Commercial Licenses

#62

Post by stavros »

mholt wrote: post #33
stavros wrote: post #19

I've been trying to get Caddy more widely deployed at work, and this move is going to alienate commercial customers (at least us) even more than Caddy already does. Not only do they not have repositories, essentially doubling the effort to keep machines up to date (we have to have one process to upgrade everything else , and one process to upgrade just Caddy ), but now we can't even download precompiled binaries to d…

> Not only do they not have repositories, essentially doubling the effort to keep machines up to date (we have to have one process to upgrade everything else, and one process to upgrade just Caddy) Cory's working on this, actually. If we can get it working, we should be able to offer official Caddy packages to all our customers, customized just how they need it to be, so your 'apt upgrade' could upgrade Caddy as well…

> it's not "apt install" but it's pretty close

It's not close, though, it's very far. With apt, I know things are going to go in their proper place, and are going to get cleaned up afterwards (not to mention the biggest benefit, automatic updates).

With a shell script, I don't know what sort of stuff it puts where on my filesystem, and I can't automate the installation easily. My preferred order of installation procedures is: "apt", "manual", and "random shell script" is a distant last, to the point where I sometimes won't try software if the installation procedure isn't sane.

Re: Announcing Caddy Commercial Licenses

#63

Post by bauerd »

stavros wrote: post #59
bauerd wrote: post #42

Earlier quoted context omitted.

To give commercial users an incentive to pay for the open source software they use. Can you name an open source project that does not offer extended features for commercial versions and that sells? Because I can't

Ad headers isn't an extended feature, it's a nag screen.

Removal of ad headers surely counts as a feature then?

Re: Announcing Caddy Commercial Licenses

#64

Post by lol768 »

JamesMcMinn wrote: post #53

Well, I guess I'm moving switching from Caddy to NGINX then. I like Caddy, it's been great, but I have no interest in paying for support, and I'm certainly not going to pay to remove a HTTP header. Yes, I could spend time setting everything up to build custom versions of Caddy without the header, but it'll be quicker and easier to switch to NGINX. Whilst I really appreciate all the work that has gone into Caddy, I am…

Yeah, I'm in the same position now. As you mention, NGINX is reasonably straightforward to set up if you're remotely technical or hell, if you can follow a tutorial.

It's a huge shame, because I used to recommend Caddy for how easy it was to get TLS to work.

Re: Announcing Caddy Commercial Licenses

#65

Post by stavros »

mholt wrote: post #54
nevi-me wrote: post #43

Earlier quoted context omitted.

I pay $149 a month for a server, I was using Nginx + nghttp2 (for gRPC), until last month when I switched to Caddy (LE benefits). I'm not familiar with Go, so I can't modify source to get the plugins I like. I read the announcement page, and can't find what the cost is, but it doesn't matter. My work doesn't count as non-x, because I want to someday make an extra income from it. I've found Caddy to be a cool and inte…

The Caddy source code is Apache licensed, so if you build from source, you're good to go. That's the point: we know there are many projects that are just a little side income here and there, so you should be able to build your own Caddy binary from source and use it. The pricing is on our pricing page: https://caddyserver.com/pricing If your commercial venture isn't profitable yet, we will try to help you bootstrap.…

> if you build from source, you're good to go.

That's a pretty big if. The one time I had to compile the server from source (to help you test a bugfix), I had the Go toolchain installed (which not everyone does) and I still couldn't figure out how to compile with some of the plugins I wanted. I gave up after 30 minutes of not getting anywhere, IIRC.

I think this move has lost you a lot of goodwill from people.

Re: Announcing Caddy Commercial Licenses

#66

Post by mholt »

donatj wrote: post #45

Caddy is OK, easy to setup on a personal machine, but nginx's performance trumped it completely in our testing. Particularly when requesting large numbers of files concurrently. I genuinely don't know why a business would use Caddy over nginx, especially given the new commercial licensing scheme. nginx really isn't that hard to setup.

The business use case isn't just about performance; businesses also get private plugin hosting, basic email support, and in the future, other amenities as well.

We'll be optimizing Caddy more over time. You can also use the http.cache plugin to help with performance: https://caddyserver.com/docs/http.cache

Re: Announcing Caddy Commercial Licenses

#67

Post by djsumdog »

JosephLark wrote: post #57
lol768 wrote: post #38

Earlier quoted context omitted.

> Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?) I dislike this for a few reasons. Firstly, it honestly comes across as petty. I'm using the server for personal reasons, it's for a non-commercial site which I don't make money off. I don't display ads, and suddenly I'm now being forced to serve ads to my visitors. The medium of delivery is utterly irreleva…

> No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues. This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So…

I have pretty much the same reaction. I was considering moving some stuff to Caddy, but looking at this, I'd need to create my own build pipeline to keep rubbish like this out. No thanks. I'll use tools that give me the options of turning things like this on/off without having to compile my own copy.

Re: Announcing Caddy Commercial Licenses

#68

Post by mholt »

overcast wrote: post #26
st3fan wrote: post #18

This is all great, I hope this turns into a viable business. But I am just not sure about the approach here. Maybe this is a good moment for someone to finally fork Caddy, remove the Sponsors header, and distribute proper RPMs and DEBs. Then those of us who want to use a truly open source project with no strings attached (special conditions re binaries, EULA, etc.) have nothing to worry about.

I've been praying for proper distribution channels for installs. For a project that is all about simplicity in setup, the installation is such a hassle. Manually creating startup entries, directories, process users, horrible.

One of the things we're hoping to offer soon are official distro packages that can be customized with the plugins you want/need.

Re: Announcing Caddy Commercial Licenses

#69

Post by nopzor »

andkenneth wrote: post #37
StavrosK wrote: post #30

Earlier quoted context omitted.

> And even among your technical visitors, how many of them actually inspect the response headers? I find that a bit disingenuous. You can't both include annoying headers and argue that they aren't annoying anyone because nobody will see them. If nobody will see them, why add them in the first place?

I think the headers are there so they can see if commercial sites are using the personal version and get them to pony up.

Wouldn't they already know who their customers are?

Re: Announcing Caddy Commercial Licenses

#70

Post by mholt »

JamesMcMinn wrote: post #53

Well, I guess I'm moving switching from Caddy to NGINX then. I like Caddy, it's been great, but I have no interest in paying for support, and I'm certainly not going to pay to remove a HTTP header. Yes, I could spend time setting everything up to build custom versions of Caddy without the header, but it'll be quicker and easier to switch to NGINX. Whilst I really appreciate all the work that has gone into Caddy, I am…

Caddy is still open source, Apache licensed. You can certainly build from source as long as you give attribution and state your changes.
Post reply on HN