8 ms·
Chef extends open-source licensing to all its software
- danielvf 8y agoTLDR: - “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 8y agoFrom 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 8y agoSo 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).
- geofft 8y agoThey call out RHEL specifically as inspiration: > Beginning on April 2, we will be making all of our products open source under the Apache 2 license and we will begin to attach commercial license terms to our software distribution (binaries) with the next major release. This is very similar to the “open source product” model most effectively run by Red Hat®, where they develop software in the open while attaching enterprise license terms to the distribution of RHEL (Red Hat® Enterprise Linux®).
- sytse 8y agoI missed that, thanks for posting.
- holoway 8y agoOriginal 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 8y agoCorrect - 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/
- bovermyer 8y agoI love that the new "Download Chef" page requires you to fill out a contact form in order to download it.
- bgoldy 8y agoToday 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 8y ago> so we can help with customer success. Lol. Your privacy policy says you do much more with user info than 'customer success'.
- yjftsjthsd-h 8y agoPoint of view:) A "success" is a customer from which more money can be extracted;)
- kawsper 8y agoI 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 8y agoChef Workstation is your answer - try it out Vikram Ghosh, VP Biz Dev Chef Software
- geofft 8y agoIt 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 8y agoChef Automate was not previously open source but will be.
- fdsak 8y agoAny reason to use Chef instead of Ansible ?
- dsr_ 8y agoIf 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.
- 33degrees 8y agoI'll add that while using Ruby makes certain things easier in Chef, overall Ansible is simpler and that's I've ended up preferring it despite my familiarity with Ruby.
- dcosson 8y agoFWIW, 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).
- antoncohen 8y agoReading 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 8y ago@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 8y agoWhat 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 8y agoHistorically 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.
- bgoldy 8y agofrom our FAQ at http://www.chef.io/bmc-faq/ http://www.chef.io/bmc-faq/ "All Chef’s software is mission critical and runs in a variety of different use cases and environments. As a result, we have not implemented hard enforcement and we don’t have any plans to change that. What we do have are commercial terms that we expect users of the software to honor. Users will have to accept the terms of the Chef End User License when they first run our software. Once the license acceptance has been acknowledged, acceptance can be automated to avoid the need for user input for further deployments. "
- geofft 8y agoChef co-founder and board member Adam Jacob has a blog post about it: https://medium.com/@adamhjk/goodbye-open-core-good-riddance-to-bad-rubbish-ae3355316494 https://medium.com/@adamhjk/goodbye-open-core-good-riddance-... > 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 8y agoHappy to answer questions about it, if anyone has any. :)
- dwiguy 8y agoIs pricing going to remain similar? We'd rather be running automate now; cost has been the primary reason we aren't.
- holoway 8y agoI'm not involved in the day to day of the business anymore, so I don't know. I suspect now is a good time to talk to a sales rep and see what they can do.
- justicezyx 8y agoWhat 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... """
- awill 8y agoI'd agree with this. If they'd done this in 2012 when they were the up and coming, they might be in the lead today. I think ultimately this wasn't 'experimenting', this was Chef thinking they'd be in the lead _without_ open sourcing. When they realized otherwise, they open sourced as a defensive measure.
- Data_Junkie 8y agoDisgusted by the spin. They are making it so more people will pay them by saying "we are more open and free". Dishonest.
- dhuramas 8y ago"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.
- jamesbjackson 8y ago@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 8y agoJames - 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.
- jandeboevrie 8y agoToo little, too late. Surpassed by Ansible (and AWX) a long time ago. Chef was nice in 2014 to get rid of puppet...
- empath75 8y agoIf you think people moved to ansible, that’s the wrong direction. They’re moving towards containers.
- mixedCase 8y agoThey're certainly not mutually exclusive. You probably mean fully managed container orchestrators; and they certainly don't serve nowhere near the majority of businesses.
- rad_gruchalski 8y agoOh, ansible, I like ansible. I even maintain this: https://github.com/radekg/terraform-provisioner-ansible https://github.com/radekg/terraform-provisioner-ansible. But chef is a completely different beast. For those who can digest ruby (as I do), chef is still a fantastic choice. I have fond memories of chef. Written countless cookbooks, recipes and bootstrapped thousands of machines with it. Having full power of ruby at one’s disposal can’t be underestimated. But one has to appreciate ruby first ;)
- h1d 8y ago> Having full power of ruby at one’s disposal That's when your config becomes unmaintainably large and complicated with personal taste.
- rad_gruchalski 8y agoWhich it often does. Our platform had 70 VMs and many operational dependencies bewteen them. Not everybody handles 5 containers per project.
- wmf 8y ago
- raincom 8y agoToo late, as people are moving away from bloated Chef and Puppet.
- Bombthecat 8y agoTo where?
- raincom 8y agoContainers, orchestration of containers. Lots of ad hoc tasks can be done with ansible.
- sansnomme 8y agoYou 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.