Forking to Sous Chefs

Where it is not possible to contact the existing owner and transfer ownership to the sous-chefs, we can take over maintenance of a codebase by creating a hard fork.

Adoption Note

If adopting an existing cookbook you must use the current name to carry on support for the existing user base. In this case please see [cookbook transferring]({{< ref "docs/" >}})

Before you begin

A hard fork is not the friendliest approach, so we should make no other options are available. Typically, a hard fork decision will be made only after:

  • sous-chefs receives a request to fork from someone willing to be primary maintainer
  • verify that the cookbook is not adequately maintained
  • notify the original maintainers that we’ve received a request to fork, request that they 1) resume active maintenance or 2) transfer to sous-chefs. Include a deadline to respond (the Friday after 1 week)
  • create a soft fork so people have a place to test and merge PRs immediately
  • if the original maintainers don’t respond by the deadline, vote to fork on the day of the deadline

Sous Chefs should not make a release until we know whether we get a transfer (and keep the name) or have to do a hard fork (and affix sc-)


You should rename using the following naming schema:

Use of provides to maintain resource compatibility

When forking a cookbook you can use Provides to force backwards compatible resource names. As an example this would allow you to fork a cookbook foo with a resource bar and maintain foo_bar even though the cookbook is now named sc_foo. This would be accomplished by adding this code to the bar resource:

provides :foo_bar

See (opens in a new tab) for additional examples.