I'm definitely not target market for this, but even trying to think open mindedly, I still I don't see people paying for this. I just don't get it. It's not specific to Caddy either, I just don't see people paying to install any web server software. The hurdle of coordinating an install that requires any kind licensing vs. something that's baked into the core package repos for my OS makes it a non-starter.
Then there's the instance counting. From the FAQ:
>> What is an "instance"?
> The commercial license grants the right to use Caddy in a commercial context based on how many instances you run or how many employees will be using Caddy ("users") at any given time. An instance is an OS process of Caddy. For example, if you have 2 instances of Caddy in production and 3 web developers using Caddy locally to build your website, that's 5 instances. (A single developer who starts multiple instances of Caddy temporarily in local dev can still just count as 1.) If you also spin up a maximum of 3 containers at a time with Caddy binaries inside it, that's a total of 8 instances. If you distribute Caddy to others, contact us for distributor pricing
I'd suggest getting rid of the local developer license. If anything, you want more people using it locally so that they end up using it in production. I know that the vast majority of people will not try things out if they think they're going to be paying $25/mo per developer. Heck, I'd get rid of non-prod pricing entirely.
Best of luck on this but I just don't see the commercial angle working out for it. And it's not something like a PaaS or DBaaS where you can offer it as a SaaS.
There really is no good way to monetize the existing open source product outside of support contracts. Developers will know that building from source is an option.
The approach that nginx and other projects use involves an open source core that solves one problem well and a series of proprietary extensions that solve related problems. It's not clear if the caddy extensions are worth paying for, and it's definitely not clear if those solutions are better than nginx offerings
Caddy is a solid piece of software, the let's encrypt integration alone is amazing. The majority of comments here on HN seem to be negative about the pricing and commercial structure, which to me is a bit absurd. This is after all a forum for entrepreneurs right? More power to the Caddy team for trying to monetize. When you work hard, create a great product, you have every right to monetize.
Quite honestly I am growing weary of the entitled, everything should be free, universal income, frugal, mentality on HN.
My negativity isn’t about the the commercial pursuit itself, it’s about their prospects. The market that they’re going after simply doesn’t pay for web servers so it’s a very uphill battle. That and they’re pricing model, in particular charging for local dev, would inhibit things even more.
I’m about as capitalistic as they come. I don’t think everything should be free. I’m perfectly fine with people charging for their goods and services. And in particular I have no qualms with charging for software, hell I do it myself!
I’m simply saying the business, at least the way they’re approaching it right now, is not viable regardless of the technical advantages of the Caddy over the competition.
There are literally dozens of packages that will register and renew certs with LE using the ACME protocol, and last time I checked none of them will cause your web server to refuse to start, with a valid certificate, because LE is down.
I find the whole concept to be quite conflicting. Their potential market is a Venn diagram of organisations who: want to use LetsEncrypt but can't install certbot; can justify spending $25 a month per instance for a web server licence; can't compile a go binary.
> There are literally dozens of packages that will register and renew certs with LE using the ACME protocol, and last time I checked none of them will cause your web server to refuse to start, with a valid certificate, because LE is down.
The work Caddy has put in though beyond the tech; business, pricing, support, is what differentiates a cool "project" from a business, that effort should be applauded in my opinion. Launching a project is tough... Adding pricing, support, and creating a business is in another league of difficulty.
You can applaud their 'effort' all you want, but "they're trying hard" isn't a very compelling argument for using commercial software when the competition is much more mature, and open source to boot.
As for your specific points of 'effort':
> business
Well, they clearly don't have a working business model yet so strike point 1.
> pricing
The whole point of this discussion is "why would people pay for this?", and their pricing is quite flip-floppy at the moment, so strike point 2.
> support
Their "basic" commercial support says:
> We usually respond within 1-2 business days
Wat. Paid support that includes the term "usually" is a giant red flag, even before you get to the idea that you could have zero response for 2 days.
The main problem with that is it can be hard to distinguish local development from internal service that is constantly being developed. The line between production and Dev can be complicated or blurry. So to keep things simple it's just straight instance counting. We lowered the price to account for that.
So now the free official binary distribution doesn't allow commercial use but you can build it yourself from the source (which is licensed under Apache 2.0) and use it commercially for free:
"""
Q: Which license do I need?
A: If your company uses official Caddy binaries internally, in production, or distributes Caddy, a commercial license is required. This includes companies that use Caddy for research. The personal license is appropriate for academic research, personal projects, websites that aren't for profit, and development at home.
Q: Is Caddy open source?
A: Yes, it is. Caddy's source code is licensed under Apache 2.0, which requires attribution and stating changes made to the code when forking it, using it in your own projects, or distributing it. This website distributes official, compiled Caddy binaries, which are licensed differently.
https://caddyserver.com/download not once mentions the fact that the server is open source or could be compiled from source for free. The entire page is structured to give the impression that commercial uses require a paid license. Other servers like nginx have separate websites for the open source and paid versions (http://nginx.org/ open source, https://www.nginx.com/ plus)
Github != open source. There are plenty of proprietary software products like HighCharts that distribute with GitHub and have a clear commercial license (https://github.com/highcharts/highcharts/) -- merely saying GitHub is not enough to communicate the license terms.
We communicate the license terms by using the license (and the website, and the FAQ, and the Terms of Service, etc), not the link to GitHub. :)
I just realized the GitHub link goes away on mobile (for lack of horizontal space) but, there are many other places on the website where it mentions that the project is open source.
AIUI, Debian can put Caddy in the main section because it is Apache 2.0. Patches to upstream can happen.
The big question: will any Debian maintainer want to invest time in this, when at any moment LightCode Labs can say "next version will not have an open license"?
Probably it's enough. That's the situation that nginx is in, anyway.
Assuming that one day there will reproducible builds, how will they ever tell apart the legal use from the illegal use of the (bit-for-bit identical) binary?
Ouch! Then we have the choice between a community-provided binary that is cross-validated by multiple build servers of multiple distros, and a vendor-provided binary which is deliberately different and has legal restrictions. Which one would we consider to be more trustworthy?
Code signing involves attaching a certificate from the author which nobody else can reproduce unless a CA is compromised. Think SSL certs to some degree. This only proves identity of person signing it. This would differentiate the binary enough I would think.
So, launching a product or service 101: speak to your potential customers first to gauge their response and limits.
This is a good change. I'm glad they listened to feedback on pricing and removed the header. Had the commercial licence lunched like this, would there still have been unhappy people? Probably, yes, people like to complain and don't like to pay, but I don't think it would have even been on the same scale. Instead, I think the majority of people would have understood that developers need to live.
The pricing change seems great - the startup plan looks good (you can pay monthly!), and the price per instance for other commercial use looks much more reasonable.
This is the real meta-lesson, and particularly that "speak to your potential customers first" doesn't mean just asking sponsors[1], it means asking the entire community that the company hopes to serve.
Before making a significant change in business models, best case, publish a blog post explaining the changes (or a few possible scenarios and their perceived pros and cons) and ask for comments. Not being confident enough to do that is probably a sign that the change is higher-risk than is being acknowledged. And even in that case, pick, say, 100 random users and email them for their opinions.
[1]: Caddy stated that they asked sponsors, but that they incorrectly interpreted silence as support or at least neutrality.
We asked our sponsors about the header, not the pricing. And we did ask people for information about how they used Caddy but virtually none of the commercial use cases came up. For some reason people were reluctant to talk about it, even in private. I'm glad that at least some of them came out of the woodwork this last month. We look forward to more established business relationships in the future.
To be fair they had no idea about their potential customers and assumed most of which were hobbyists. I think it's good they're trying to monetize though, it allows them to keep the lights on a focus on their project full-time without having to hand it off to another major org like Apache or anybody else.
Just want to say: Just because you hand your project over to a foundation doesn't mean it automatically allows full time development.
We've moved our open source bits to the eclipse foundation recently..and surprise! We're still the primary developers.
Granted, this was recently, but apache projects can also go to the apache attic where they go to "retire".
Generally, you still need some sort of revenue stream in there to sustain/subsidize a "community".
A lot of apache projects have a company behind them driving development.
> To be fair they had no idea about their potential customers and assumed most of which were hobbyists.
That's kind of the point though - a quick survey at download time, or a post on a blog describing proposed pricing and the caddy-sponsors header would have given them a lot of the information they needed to make an informed choice. Instead they made assumptions and got it very wrong.
Unlike most commercial launches, they already had a large userbase to gather information from, they just chose not to use it.
Those "quick surveys" that we all either skip (if possible) or just enter random bullshit into so that we can just download the damn file and get on with our work?
Those blog posts that 95%+ of customers never read or, if they do, won't bother commenting on?
> Those "quick surveys" that we all either skip (if possible) or just enter random bullshit into so that we can just download the damn file and get on with our work?
They've already got something built into the download page to configure plugins. All it would have taken was an additional question and a few radio options:
I plan on using Caddy for:
[ ] my personal website [ ] my startup [ ] other commercial
> Those blog posts that 95%+ of customers never read or, if they do, won't bother commenting on?
People already follow their social accounts etc. to be notified of updates. Plenty of people will read a post "We're thinking of charging for Caddy", and even a 5% response rate would be in the hundreds or thousands.
Plenty of people have done it in much more difficult markets with fewer resources. It's never easy, but Caddy had some good options they never used.
Welcome to the world of market research. It's how you avoid launching a bad product at the wrong price. The alternative is getting it very publicly wrong and having to backtrack.
> For example, if you have 2 instances of Caddy in production and 3 web developers using Caddy locally to build your website, that's 5 instances. (A single developer who starts multiple instances of Caddy temporarily in local dev can still just count as 1.) If you also spin up a maximum of 3 containers at a time with Caddy binaries inside it, that's a total of 8 instances.
This reminds me of Microsoft’s CAL licensing scheme(s). Those were ALWAYS confusing, and [in my experience] rarely followed correctly.
I'd wager this won't generate any meaningful revenue, but may open doors for legal action of people in violation. Hopefully that's not the goal.
At this point after the entire debacle that is the PR mess that this company has made for themselves it's obvious to me and my company that we will be going with NGINX for future projects. This whole situation has left a bad taste in my mouth about Caddy. Spending any more time on this is a waste of time.
Can someone explain why this is worth paying for over Envoy or Nginx for commercial use? For personal projects Go and even node Express/Koa seems good enough.
If you're already writing a Go application, you probably don't need an instance of your own server in front (I word that carefully because services like Cloudflare can still be valuable).
As for why use Caddy over NGINX or similar, I have some thoughts on this that I might turn into a blog post someday, but a few highlights:
- Memory safety. No Optionsbleed, Heartbleed, or similar bugs and security vulnerabilities. (Thanks to Go)
- The most mature HTTP/2 stack. Caddy uses Go's HTTP/2 implementation which has been around at least a year longer than that of other servers and has been widely deployed in many, many environments.
- Some of Caddy's individual features are more mature than that of other servers. For example, Caddy's automatic HTTPS has been around longer than any similar module in other servers. Caddy's TLS stack is also advanced, and rotates STEKs on a regular basis. Caddy has the most mature, robust OCSP implementation. Caddy's QUIC implementation is second only to Google's library. Its markdown rendering and Turing-complete templating features are second-to-none.
- Caddy's plugin ecosystem is one-of-a-kind. With plugins, Caddy can do things that other web servers can't do (without writing your own custom modules in C or whatever).
- Several of Caddy's features that are freely available are only available in paid versions of other web servers (such as h2 server push and proxy health checking).
But, I understand if these are not of value to your business; like any software, it's not for everyone. And like every software, it's not perfect. But it's pretty good.
As much as I dislike this licensing kerfuffle (it was kind of the nail in the coffin for me, after Caddy's long-time lack of deb/rpm support), all these points are true.
Especially the automatic TLS functionality is very valuable and works well.
I really dislike the new download page, instead of just being able to download the piece of software I want I now have to jump through at least three hoops just to get the link. Meh, it's quicker to download Nginx.
Then there's the instance counting. From the FAQ:
>> What is an "instance"?
> The commercial license grants the right to use Caddy in a commercial context based on how many instances you run or how many employees will be using Caddy ("users") at any given time. An instance is an OS process of Caddy. For example, if you have 2 instances of Caddy in production and 3 web developers using Caddy locally to build your website, that's 5 instances. (A single developer who starts multiple instances of Caddy temporarily in local dev can still just count as 1.) If you also spin up a maximum of 3 containers at a time with Caddy binaries inside it, that's a total of 8 instances. If you distribute Caddy to others, contact us for distributor pricing
I'd suggest getting rid of the local developer license. If anything, you want more people using it locally so that they end up using it in production. I know that the vast majority of people will not try things out if they think they're going to be paying $25/mo per developer. Heck, I'd get rid of non-prod pricing entirely.
Best of luck on this but I just don't see the commercial angle working out for it. And it's not something like a PaaS or DBaaS where you can offer it as a SaaS.