Caddy 0.10.10 Released Along with New Pricing Structure
caddyserver.com
caddyserver.com
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.
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
Quite honestly I am growing weary of the entitled, everything should be free, universal income, frugal, mentality on HN.
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.
Really? How so?
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.
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.
"""
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.
"""
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.
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.
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.
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 blog posts that 95%+ of customers never read or, if they do, won't bother commenting on?
Good luck.
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
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.
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.
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.
You're not talking to enough people.
- Everyone who comes to my restaurant loves my food! They all told me that!
- So why is no one here?
- I don't know. It must be the decor!
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.
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.
Especially the automatic TLS functionality is very valuable and works well.