
Chef extends open-source licensing to all its software - doppp
https://blog.chef.io/2019/04/02/chef-software-announces-the-enterprise-automation-stack/
======
geofft
It sounds like all Chef code will be open source (I'm curious what _isn 't_
open source today), but there is no release engineering work in public, and so
if you want a supported / stable release, you need to either pay them, make a
release internally yourself, or hope that someone like a Linux distro builds a
release for you. It's intentionally patterned on the Red Hat model, and very
much unlike the MongoDB / Redis Labs / Elastic approaches.

I'm of the opinion that depending on someone else's release of OSS is an
antipattern anyway because if you're not going through your own release
process, you're not confident that a one-line bug-fix is actually only
changing that one line. (The exception is when you know their release is
through some decently hermetic build environment like distro packaging or
Travis or Docker, such that you expect to be able to replicate that build
environment for yourself when the time comes.) But I think a lot of companies
use vendor binaries even when the vendor source is open source, so this seems
likely to make Chef pick up a few support contracts.

~~~
btmspox
Chef Automate was not previously open source but will be.

------
geofft
Chef co-founder and board member Adam Jacob has a blog post about it:
[https://medium.com/@adamhjk/goodbye-open-core-good-
riddance-...](https://medium.com/@adamhjk/goodbye-open-core-good-riddance-to-
bad-rubbish-ae3355316494)

> _This morning, Chef Software announced that it will be releasing 100% of its
> software as Open Source, under the Apache License. Going forward, all of its
> product development will be done in the open, with the community, and
> released as Open Source Software. Chef is done with being Open Core, and is
> now a Free Software Product company. Good riddance to bad rubbish._

~~~
holoway
Happy to answer questions about it, if anyone has any. :)

~~~
justicezyx
What about a fellow hner's comment above:

"""

jandeboevrie 23 minutes ago [-]

Too little, too late. Surpassed by Ansible (and AWX) a long time ago. Chef was
nice in 2014 to get rid of puppet... """

~~~
holoway
Every person can decide for themselves what story they want to tell. Chef has
been declared dead/dumb/irrelevant from the beginning. It’s doing great as a
business, and as software. You play your game - y’all can think it’s
irrelevant, and it’ll just keep on focusing on solving people’s problems.
Turns out it works.

------
kawsper
I really want to like Chef, but their ecosystem around their Infra-suite is
just such a mess of different offerings, all with different limitations and
features, I hope maybe this will consolidate things.

Chef-solo, Chef-zero, Chef-server, little-chef and tooling like knife and
knife-solo.

~~~
vikramg
Chef Workstation is your answer - try it out Vikram Ghosh, VP Biz Dev Chef
Software

------
bovermyer
I love that the new "Download Chef" page _requires_ you to fill out a contact
form in order to download it.

~~~
bgoldy
Today we have two easy methods for getting Chef's bits. 1) www.chef.io/get-
chef/ \- which is intended for newer users where we collect contact
information so we can help with customer success. 2) downloads.chef.io which
provides all of our downloads, ungated, for advanced users.

hope this helps clarify.

Best, Brian Goldfarb CMO, Chef

~~~
craftyguy
> so we can help with customer success.

Lol. Your privacy policy says you do much more with user info than 'customer
success'.

~~~
yjftsjthsd-h
Point of view:) A "success" is a customer from which more money can be
extracted;)

------
jandeboevrie
Too little, too late. Surpassed by Ansible (and AWX) a long time ago. Chef was
nice in 2014 to get rid of puppet...

~~~
mcdermott
Chef (and configuration management in general) is an anti-pattern for a cloud
native approach.

The soup of the Chef ecosystem has always seemed hard to understand (and teach
new team members): Chef, Chef-solo/zero, rubocup, test kitchen, food critic,
berkshelf automate, delivery druck, inspec, infa, etc...

With containers and immutable infrastructure there just isn't the need
anymore. They obviously realized this and created Habitat as a response, but
after trying it a few times, I don't see why I'd use it over plain old Docker
+ K8s.

If you still need configuration management, Ansible is more flexible, is
easier to learn/teach (no need to learn Ruby), agentless, no need to run a
sever and can also do some orchestration.

~~~
yellowapple
> no need to learn Ruby

Instead we'll just learn yet another ad-hoc language clumsily built atop YAML,
and put up with Norway always being false when abbreviated. :)

~~~
tracker1

        "no"
    

Doesn't address the issue? Of course, I'd rather if boolean evaluation was in
the markup only true and false specifically be translated

~~~
int_19h
It does, but only if you know about it in advance.

------
jamesbjackson
@bgoldy

We use manage chef server in multiple production environments and long
standing customer and install the binaries automatically when building new
servers and AMI's etc. Can someone explain how this will change in the future
and impact us licensing wise? As up to now we pay for number of nodes managed
by chef cloud servers (manage.chef.io) which makes it very clear what we
paying for.. With these news it now not clear at all what we need to have
liencing for :(

Also what happens to chef-zero etc? I looked at the pricing page
[https://www.chef.io/pricing/](https://www.chef.io/pricing/) which has been
updated. Is this per month, year or perpetuity? and what counts as a chef
infra target and inspec targets actually mean? as we use these for test-
kitchen local development and testing as well we use chef-zero for Packer
Images (AMI's) and AutoScaling vms.

I read the FAQ section ([https://www.chef.io/bmc-
faq/](https://www.chef.io/bmc-faq/)) and none of it is very clear as Chef does
not need to be used with just a central server but can work standalone. So can
someone explain how the pricing will work for these non connected workflows in
the future? Chef-Zero for AutoScaling VMs, Packer Builds, and InSpec Profiles
for Local Testing etc..

As looking at these changes it will be huge nightmare to keep track of every
chef-client and inspec target installed everywhere when we got autoscaling and
build systems running Chef as we prefer to use the official binaries but with
this change that seems we may have to fork the Open Source Repos, even if we
paying for some of infrastructure to be central managed by chef directly so we
are 100% confident we not breaching any terms of service.

Will the build release process be also made open source so we can have
confidence we will be creating compatible builds? As we much prefer to use
vendor releases but under this new licensing terms that does not seems
possible :(

~~~
bgoldy
James -

For the $$ questions I strongly advise you talk to your sales rep. We will
make it simple for you and your scenario. It's great to see real world
concepts and we are working to align how you work with how we price. I'm
confident we can work something out - no need to try to solve it on your own.

As for the build release process, no - we are not releasing the release
engineering pipeline work. But since I'm confident we can get to constructive,
affordable commercial relationship with you this shouldn't matter.

------
antoncohen
Reading this makes me worry that they will no longer be providing easily
installable downloads that are free for commercial use.

I suppose that is a good tradeoff, like Red Hat providing RHEL source but not
installation media. But it will make harder to get started with Chef, and I
don't know if there is enough community motivation to create a CentOS
equivalent for Chef. I hope AWS's Open Distro project takes on more software
projects ([https://opendistro.github.io/for-
elasticsearch/](https://opendistro.github.io/for-elasticsearch/)).

~~~
bgoldy
@antoncohen - We will provide easily installable downloads for non-commercial,
experimentation, and individual use which should make getting started with
Chef just as easy today as it was yesterday.

~~~
geofft
What prevents companies from using those downloads for commercial use? Is it
"just" a copyright violation (i.e., the same thing that prevents them from
paying for one copy of Windows and running a thousand), or is there something
in the code (limits on scaling, time bombs, etc.) to make them unsuitable for
production use?

~~~
holoway
Historically the answer is nothing, or very little. The commercial products
have a licensing mechanism that nags you, or at least it did. I don't know
what their plan is on that - but I know they'll do it in public now. :)

Since everything Chef makes is used for production infrastructure, they have
historically avoided doing anything that would break functionality for license
compliance.

------
sansnomme
You will get a lot more customers if you drop the enterprise-style website and
the contact form requirements for downloads. Switch to a Stripe-like landing
page.

------
fdsak
Any reason to use Chef instead of Ansible ?

~~~
dsr_
If you already have a complete config management setup, you're already getting
85% of the benefit.

If you're choosing one, Chef and Puppet work by having an agent on each client
contact a server and pull down whatever's designated for that client. Then
they try to make the local client conform to that state. Ansible is a push
system where your server goes out to each client and tells it what to do over
SSH.

In the event of a server issue, a chef-controlled system will continue trying
to be in the last state it downloaded. That is, if you make a manual changeto
something that chef controls, expect it to be reverted shortly. An ansible-
controlled system will diverge with every manual change, up until contact with
the server is regained.

The major difference between Chef and Puppet is that Chef recipes are Ruby
programs with supplementary libraries, while Puppet uses a DSL written in
Ruby. If you already have some Ruby experience or coworkers who write in Ruby,
Chef is probably a better choice for that alone.

If you don't know any Ruby at all, ansible configuration may be faster for you
to pick up.

~~~
dcosson
FWIW, we've had a lot of success with a super simple pull version of ansible.
You can configure ansible to run against a local host instead of via ssh push,
so we have a cron on all servers that pulls the latest configs from S3, runs
ansible, and reports any failures to cloudwatch metrics. This is a good fit in
particular for configuring stable host OSes that don't change all that often,
for something like deploying application code where you want to be able to run
it right away instead of in ~30 minutes the next time the cron runs. If we
really needed to push out a critical patch or something, we could also
parallel ssh to the necessary servers and trigger a run immediately.

I believe Ansible Tower is their enterprise tool to do a similar pull-based
model. I haven't used it but I've used a Puppetmaster setup in the past, and
I'm really not a fan of how much of walled garden, standalone solution these
things all are. They introduce coordination that you might not really need and
have their own protocols for dealing with it, they have their own patterns for
bootstrapping new servers, authentication to servers, encrypting secrets,
tracking which servers are up or down, etc. and a lot of that is redundant
with other tools you might be using (e.g., secret management or monitoring)
and other primitives that the cloud provider likely has built in (like IAM
profiles to solve the bootstrapping problem).

~~~
quicksilver03
What you've described is essentially Puppet in masterless mode.

One of the reasons why I prefer Puppet to Ansible is the speed: Ansible in
push mode is incredibly slow, even after applying all of the recommended
tuning options and configuring Mitogen. I haven't yet used Ansible in pull
mode on a large scale infrastructure, but I'd love to know if it's faster.

------
danielvf
TLDR:

\- “Chef will move all of our product software development to an open source
model with 100% of our product code available and licensed under Apache 2.0”

\- “Chef will produce a new distribution (release), Chef Enterprise Automation
Stack, built for commercial users with new terms and conditions of use.”

~~~
mkesper
From the FAQ ([https://www.chef.io/bmc-faq/](https://www.chef.io/bmc-faq/)):

Q: What do I have to differently today than I had to do yesterday?

For our existing commercial customers there is no action required.

For existing customers using Chef for non-commercial purposes,
experimentation, or individual use there is no change.

For contributors to Chef OSS projects, non-profits, and other special groups
we are still working on how we will partner with those communities around
licensing Chef products. Stay tuned for more info.

Everyone else can continue using our current releases in perpetuity – although
they will be end-of-support in 12 months and no further bug fixes or security
updates will be available for those versions without a commercial arrangement.
Customers who choose to use our new software versions will be subject to the
new license terms and will have an opportunity to create a commercial
relationship with Chef, with all of the accompanying benefits that provides.

Q: How will this impact existing customers?

For existing customers this change will not impact their usage or contracts.
Companies that already pay us for Chef Infra (formerly Chef), Chef Inspec,
Chef Habitat and/or Chef Automate will continue to do so and we will continue
to increase the value of their relationship with Chef.

Users who do not pay Chef today (use our free open source binaries), and net
new users, will have three options going forward:

    
    
        License our commercial software distribution.
        Take our open source code and create a software development org to build and manage their own distro (create their own downstream fork) or leverage a public free distribution (which may or may not exist).
        Stay on an older free distribution in perpetuity. For example, they could use Chef 14.7.17 forever but they would not receive security updates , bug fixes or support from Chef starting 1 year after Chef 15 is released.
    

We will make licensing accommodations for individuals and significant
community contributors to continue to use Chef Infra, Chef Inspec and Chef
Habitat in the same way that they have been. In addition, we want to make it
equally easy to experiment and self-learn with our various products.

Finally, we will have a low cost “Essentials” suite of our commercial
distributions that should satisfy the needs of smaller businesses.

~~~
sytse
So on one hand all the software will be open source and on the other hand
there will be no free as in beer distribution anymore. Sounds similar to the
RedHat model. I wonder if the community is active enough to produce a CentOS
like alternative distribution for Chef.

The Essentials distribution is interesting, I wonder what is in it. I assume
it will not have things like Role Based Access Control (RBAC).

~~~
holoway
Original author of Chef here (although no longer with the company day-to-day).
I would not assume that - 100% of the software Chef produces is open source,
so no reason to ever differentiate on features in licensing. So I doubt they
would remove anything.

~~~
bgoldy
Correct - Essentials is just a low cost suite of Chef products. We offer two
suites,. Effortless Infrastructure, focused on core config mgmt and
security/compliance use cases and Enterprise Automation Stack which includes
all of that plus a wide range of app automation capabilities including
dependency mgmt, lifecycle mgmt, etc.

see pricing for the suites at
[https://www.chef.io/pricing/](https://www.chef.io/pricing/)

~~~
sytse
Cool! Thanks for following up.

------
raincom
Too late, as people are moving away from bloated Chef and Puppet.

~~~
Bombthecat
To where?

~~~
raincom
Containers, orchestration of containers. Lots of ad hoc tasks can be done with
ansible.

------
Data_Junkie
Disgusted by the spin. They are making it so more people will pay them by
saying "we are more open and free". Dishonest.

~~~
dhuramas
"we are more open and free" \- There is nothing dishonest about that. What we
are seeing is companies trying out different business models and seeing what
works. I can respect that.

As an end user, if you care about free software- this is good news. Instead of
having different "Enterprise" and artificially handicapped "open-source"
edition, we get to see everything out in the open. The secret sauce is now
limited to the release process. They say openly that if you need to, fork them
and create your own releases - yeah go for the "knockoffs" if you can trust
them - or else try the branded (Chef) product.

MongoDB got a lot of flak for misappropriating the name "open source". What
Chef is doing is IMHO more clear and honest. They need to make money too.

