Language Selection

English French German Italian Portuguese Spanish

Chef Liberated

Chef Goes All-In on Open Source

  • DevOps Chat: Chef Goes All-In on Open Source

    In front of next month’s ChefConf in Seattle, Chef has announced a major refinement to its business model. Affirming and clarifying its commitment to open source business models, Chef will now and in the future release all of its software as open source.

LWN and original from Chef

  • Chef becomes 100% free software

    Chef, the purveyor of a popular configuration-management system, has announced a move away from the open-core business model and the open-sourcing of all of its software.

  • Introducing the New Chef: 100% Open, Always

    Today, Chef is announcing meaningful changes to the way that we build and distribute our software. Chef has always believed in the power of open source. This philosophy is core to the way that we think about software innovation. There is no better way to build software than in the open in partnership with individuals and companies who use our stack in the real world. And for enterprises and other organizations facing complex challenges, Chef backs up our software by building and supporting distributions for our projects with the resources necessary for these organizations to succeed.

    Going forward, we are doubling down on our commitment to OSS development as we extend our support for the needs of enterprise-class transformation. Starting today, we will expand the scope of our open source licensing to include 100% of our software under the Apache 2.0 license (consistent with our existing Chef Infra, Chef InSpec, and Chef Habitat license terms) without any restrictions on the use, distribution or monetization of our source code as long as our trademark policy is respected. We welcome anyone to use and extend our software for any purpose in alignment with the four essential freedoms of Free Software.

Chef-paid 'analysi' comments

  • Chef’s Different Recipe

    Over the course of the past three plus years, the market has seen a growing number of commercial open source organizations – with encouragement from some investors – drifting away from traditional open source licensing and norms. While there have been significant differences in the precise mechanics of their respective approaches, the common thread between the likes of Confluent, Elastic, MongoDB, Redis Labs and TimeScale has been their willingness to violate open source norms long considered sacrosanct.

    Contrary to internet opinions, however, little if any of this was done with malicious intent, or absent due consideration for the grave implications of the various moves. In the majority of cases, the difficult decisions were made reluctantly, under duress. Whether that duress was real or more theoretical in nature is a matter of some debate, but there can be no doubt that the companies involved embarked on these courses because they felt they had to, not because they particularly wanted to.

    There have been many contributing factors to this drift away from open source, including the intrinsic problems of compelling payment for assets otherwise available for free, but by far the biggest driver has been the once cold war that recently escalated into a full scale hot war between cloud vendors and commercial open source providers. The relationships between these archetypes is fraught, and has evolved from relatively benign indifference on the part of open source providers to existential, unmanageable dread.

By Sean Michael Kerner

  • Chef Opens Up DevOps Platform With Enterprise Automation Stack

    Chef has been at the forefront of the DevOps movement with its namesake open-source Chef project. Not all of Chef's platforms, however, have been open-source, with some available under commercial proprietary licenses.

    On April 2, Chef announced a major shift in its company alignment, making all of its products available under the Apache 2.0 open-source license and revealing a new supported platform called the Enterprise Automation Stack. The move to being 100 percent open-source is an effort to provide more transparency and encourage broader collaboration. Rather than moving the projects to an independent, third-party open-source foundation and governance model, however, Chef will continue to lead and operate the projects.

    "When looking at foundations and the shape of open-source, a big issue is deciding who controls and builds the upstream asset. As soon as you put software into a foundation, the foundation controls the asset," Adam Jacob, co-founder and CTO of Chef, told eWEEK. "One of the things that we're doing is aligning our own commercial interests with our interest in being the upstream that provides the project."

Goodbye Open Core — Good Riddance to Bad Rubbish

  • Goodbye Open Core — Good Riddance to Bad Rubbish

    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.
    As a Co-Founder of Chef, a board member, and a community member, I couldn’t be more thrilled. For me, it eliminates the longest-running source of friction and frustration from my time at Chef. On the one hand, we have a community that cares about the software, and about each other, where we develop the software in concert with our users and customers. On the other, we produced a proprietary software stack, which we use to make money. Deciding what’s in, and what’s out, or where to focus, was the hardest part of the job at Chef. I’m stoked nobody has to do it anymore. I’m stoked we can have the entire company participating in the open source community, rather than burning out a few dedicated heroes. I’m stoked we no longer have to justify the value of what we do in terms of what we hold back from collaborating with people on.
    As an insider, I got to witness first-hand the boldness and deep thought put in to this transition by the team at Chef. Our incredible CEO, Barry Crist; Corey Scobie, the SVP of Product and Technology; Brian Goldfarb, CMO; Katie Long, our VP of Legal; and so many others. Thank you.

Yet more coverage

Chef Goes All Open Source

  • Chef Goes All Open Source

    The Chef automation tool, a popular solution for DevOps IT management scenarios, has announced that it will be become a 100% open source platform. In the past, the basic Chef application was available in open source form, but the company also provided several enhancements and add-on tools with proprietary licenses. Rather than building proprietary tools around an open source core, Chef will now open source all of its software under an Apache 2.0 license.

    According to Chef CEO Barry Crist, “Over the years we have experimented with and learned from a variety of different open source, community, and commercial models, in search of the right balance. We believe that this change, and the way we have made it, best aligns the objectives of our communities with our own business objectives. Now we can focus all of our investment and energy on building the best possible products in the best possible way for our community without having to choose between what is “proprietary” and what is “in the commons.”

Configuration Management Tool Chef Announces to go 100% OSS

  • Configuration Management Tool Chef Announces to go 100% Open Source

    You are here: Home / News / Configuration Management Tool Chef Announces to go 100% Open Source
    Configuration Management Tool Chef Announces to go 100% Open Source
    Last updated April 5, 2019 By Ankush Das 2 Comments
    In case you did not know, among the most popular automation software services, Chef is one of the best out there.

    Recently, it announced some new changes to its business model and the software. While we know that everyone here believes in the power of open source – and Chef supports that idea too. So, now they have decided to go 100% open source.

    It will included all of their software under the Apache 2.0 license. You can use, modify, distribute and monetize their source code as long as you respect the trademark policy.

    In addition to this, they’ve also introduced a new service for enterprises, we’ll take a look at that as you read on.

"Chef Plates All Software as Open Source"

  • Chef Plates All Software as Open Source

    The IT automation and dev ops software vendors is embracing the open source model to clarify its product line and enhance its value proposition.

  • Chef says it’s going 100% open source, forks optional…

    Chef has lifted a page from Red Hat’s recipe book, and is making all of its software 100 per cent open source, under the Apache 2 license.

    But if you’re planning to use the automation and configuration specialist’s software in production, you’re still going to be expected to cough up for a subscription.

    Chef CEO Barry Crist said in a blog post today that the company “has always believed in the power of open source”.

  • Leading DevOps program Chef goes all in with open source [Ed: CBS repeats Microsoft talking points: "Some companies are wriggling out of open-source to maximize their profits." And proprietary software companies never do?]

    Some companies are wriggling out of open-source to maximize their profits.

  • “Chef” DevOps leading program goes all-in on open source

    Chef, one of the leading DevOps companies announced from here on out it would be developing all of its software as open source under the Apache 2.0 license and revealing a new supported platform called the Enterprise Automation Stack.

Some belated coverage

  • Chef open sources 100% under Apache 2.0 license

    “Chef Enterprise Automation Stack lets teams establish and maintain a consistent path to production for any application, in order to increase velocity and improve efficiency, so deployment and updates of mission-critical software become easier, move faster and work flawlessly.”

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

First Release Candidate of Linux 5.3

  • Linux 5.3-rc1
    It's been two weeks, and the merge window is over, and Linux 5.3-rc1
    is tagged and pushed out.
    
    This is a pretty big release, judging by the commit count. Not the
    biggest ever (that honor still goes to 4.9-rc1, which was
    exceptionally big), and we've had a couple of comparable ones (4.12,
    4.15 and 4.19 were also big merge windows), but it's definitely up
    there.
    
    The merge window also started out pretty painfully, with me hitting a
    couple of bugs in the first couple of days. That's never a good sign,
    since I don't tend to do anything particularly odd, and if I hit bugs
    it means code wasn't tested well enough. In one case it was due to me
    using a simplified configuration that hadn't been tested, and caused
    an odd issue to show up - it happens. But in the other case, it really
    was code that was too recent and too rough and hadn't baked enough.
    The first got fixed, the second just got reverted.
    
    Anyway, despite the rocky start, and the big size, things mostly
    smoothed out towards the end of the merge window. And there's a lot to
    like in 5.3. Too much to do the shortlog with individual commits, of
    course, so appended is the usual "mergelog" of people I merged from
    and a one-liner very high-level "what got merged". For more detail,
    you should go check the git tree.
    
    As always: the people credited below are just the people I pull from,
    there's about 1600 individual developers (for 12500+ non-merge
    commits) in this merge window.
    
    Go test,
    
                Linus
    
  • Linux 5.3-rc1 Debuts As "A Pretty Big Release"

    Just as expected, Linus Torvalds this afternoon issued the first release candidate of the forthcoming Linux 5.3 kernel. It's just not us that have been quite eager for Linux 5.3 and its changes. Torvalds acknowledged in the 5.3-rc1 announcement that this kernel is indeed a big one: "This is a pretty big release, judging by the commit count. Not the biggest ever (that honor still goes to 4.9-rc1, which was exceptionally big), and we've had a couple of comparable ones (4.12, 4.15 and 4.19 were also big merge windows), but it's definitely up there."

  • The New Features & Improvements Of The Linux 5.3 Kernel

    The Linux 5.3 kernel merge window is expected to close today so here is our usual recap of all the changes that made it into the mainline tree over the past two weeks. There is a lot of changes to be excited about from Radeon RX 5700 Navi support to various CPU improvements and ongoing performance work to supporting newer Apple MacBook laptops and Intel Speed Select Technology enablement.

today's howtos and programming bits

  • How to fix Ubuntu live USB not booting
  • How to Create a User Account Without useradd Command in Linux?
  • Container use cases explained in depth
  • Containerization and orchestration concepts explained
  • Set_env.py

    A good practice when writing complicated software is to put in lots of debugging code. This might be extra logging, or special modes that tweak the behavior to be more understandable, or switches to turn off some aspect of your test suite so you can focus on the part you care about at the moment. But how do you control that debugging code? Where are the on/off switches? You don’t want to clutter your real UI with controls. A convenient option is environment variables: you can access them simply in the code, your shell has ways to turn them on and off at a variety of scopes, and they are invisible to your users. Though if they are invisible to your users, they are also invisible to you! How do you remember what exotic options you’ve coded into your program, and how do you easily see what is set, and change what is set?

  • RPushbullet 0.3.2

    A new release 0.3.2 of the RPushbullet package is now on CRAN. RPushbullet is interfacing the neat Pushbullet service for inter-device messaging, communication, and more. It lets you easily send alerts like the one to the left to your browser, phone, tablet, … – or all at once. This is the first new release in almost 2 1/2 years, and it once again benefits greatly from contributed pull requests by Colin (twice !) and Chan-Yub – see below for details.

  • A Makefile for your Go project (2019)

    My most loathed feature of Go was the mandatory use of GOPATH: I do not want to put my own code next to its dependencies. I was not alone and people devised tools or crafted their own Makefile to avoid organizing their code around GOPATH.

  • Writing sustainable Python scripts

    Python is a great language to write a standalone script. Getting to the result can be a matter of a dozen to a few hundred lines of code and, moments later, you can forget about it and focus on your next task. Six months later, a co-worker asks you why the script fails and you don’t have a clue: no documentation, hard-coded parameters, nothing logged during the execution and no sensible tests to figure out what may go wrong. Turning a “quick-and-dirty” Python script into a sustainable version, which will be easy to use, understand and support by your co-workers and your future self, only takes some moderate effort. 

  • Notes to self when using genRSS.py

The Status of Fractional Scaling (HiDPI) Between Windows & Linux

There’s a special type of displays commonly called “HiDPI“, which means that the number of pixels in the screen is doubled (vertically and horizontally), making everything drawn on the screen look sharper and better. One of the most common examples of HiDPI are Apple’s Retina displays, which do come with their desktops and laptops. However, one issue with HiDPI is that the default screen resolutions are too small to be displayed on them, so we need what’s called as “scaling”; Which is simply also doubling the drawn pixels from the OS side so that they can match that of the display. Otherwise, displaying a 400×400 program window on a 3840×2160 display will give a very horrible user experience, so the OS will need to scale that window (and everything) by a factor of 2x, to make it 800×800, which would make it better. Fractional scaling is the process of doing the previous work, but by using fractional scaling numbers (E.g 1.25, 1.4, 1.75.. etc), so that they can be customized better according to the user’s setup and needs. Now where’s the issue, you may ask? Windows operating system has been supporting such kind of displays natively for a very long time, but Linux distributions do lack a lot of things in this field. There are many drawbacks, issues and other things to consider. This article will take you in a tour about that. Read more Also: Vulkan 1.1.116 Published With Subgroup Size Control Extension

Android Leftovers