Ohai profiles a machine into a JSON blob, and Chef is its reason to exist

The output is one JSON blob of everything known about the system

Ohai detects data about your operating system, and the README is precise about what that produces. Ohai will print out a JSON data blob for all the known data about your system. The word known is doing work there, since the set of collectors is what the project defines, and the JSON shape is the contract other tools consume. The second sentence explains the delivery. When used with Chef, that data is reported back via node attributes, which means the same detection that produces a standalone document also becomes the inventory a Chef run reasons about. That dual purpose explains the project shape. A tool that only fed Chef would be a component inside a larger system, whereas a tool that also prints its output is something you can run on a machine, diff between two machines, or feed into your own scripts, and the same collectors serve both.

This README is for developers, the plugin docs are for everyone else

The repository makes a distinction that tells you where the project sits in the Chef ecosystem. Chef distributes Ohai as a RubyGem, and the README states plainly that it is for developers who want to modify the Ohai source code. Users who want to write plugins are pointed elsewhere, to the general documentation at docs.chef.io/ohai/ and the writing plugins documentation at docs.chef.io/ohai_custom/. So the two audiences are separated on purpose. Changing the collectors means working in this repository, with its RSpec suite, its Cookstyle configuration and its Rake tasks. Extending what Ohai detects for your own environment means writing a plugin, and that path is documented outside the repository, which is where the interesting growth happens for most users. The site linked in the homepage field points at the same general documentation page.

The development loop is bundler, RSpec and Cookstyle

The contributor workflow is short and conventional for a Ruby gem. Development dependencies are installed with bundler, by running bundle install in the root of the repository. The test suite is RSpec, and the full suite runs with:

bundle exec rake spec

Individual test files are run through the rspec executable directly:

bundle exec rspec spec/unit/FILE.rb

Style is enforced with Cookstyle, which the README describes as a code linter, and the check runs as:

bundle exec rake style

with an automatic correction pass alongside it:

bundle exec rake style:auto_correct

The repository root backs this up with the usual configuration files, a .rspec file, a .rubocop.yml, an .editorconfig, a .linelint.yml and a cspell.json for spell checking. There is also a sonar-project.properties file, which is a small sign that the project runs static analysis in its continuous integration. The result is a project where the path from a change to a merged pull request is one bundle install, one rake spec and one rake style away.

The Rake tasks are the project's own interface

Ohai has a set of Rake tasks for doing various things, and the README lists them, which makes the whole publishing surface visible in one place:

bundle exec rake -T
rake build               # Build ohai-$VERSION.gem into the pkg directory
rake clean               # Remove any temporary products
rake clobber             # Remove any generated files
rake install             # Build and install ohai-$VERSION.gem into system gems
rake install:local       # Build and install ohai-$VERSION.gem into system gems without network access
rake release[remote]     # Create tag $VERSION and build and push ohai-$VERSION.gem to rubygems.org
rake spec                # Run RSpec code examples
rake style               # Run Chefstyle tests
rake style:auto_correct  # Auto-correct RuboCop offenses

Two details are worth pulling out. The release task takes a remote argument and does the tagging and the push to rubygems.org, so the published gem and the git tag are produced by the same command, and the install:local variant exists for machines without network access. The version itself comes from the GemSpec in the Rakefile, and there is a VERSION file at the repository root, so the number is not scattered across the tree.

The tree carries two homes, a gem and a Habitat plan

The top level of the repository shows a project that has grown a second life. The gem itself is in lib/, with spec/ for the tests, bin/ for executables, tasks/ for the Rake task definitions, and the ohai.gemspec plus Gemfile at the root. Alongside that sits a habitat/ directory, which is a Chef Habitat plan, meaning the same software is packaged for Habitat as well as distributed as a gem. Then there is the release and continuous integration machinery: .buildkite/ with a .bldr.toml configuration, .expeditor/ for release automation, CHANGELOG.md, RELEASE_NOTES.md, an OHAI_MVPS.md file, VERSION, NOTICE, SECURITY.md and a COPYRIGHT.md. Two small scripts stand out as practical details, a binstub_patch.rb and a post-bundle-install.rb, both of which exist to make a Ruby install behave the way the project needs, and a cookbook of small annoyances that any gem with binstubs accumulates.

Contributing means a signed off commit and a green Buildkite

The contributing section points at the Chef contributing guide and then lists the mechanics. Fork it, create a feature branch, commit the change with a signoff, run the tests with bundle exec rake spec, run the style tests with bundle exec rake style, push and open a pull request. The auto-merge rules are spelled out in their own section, and they are strict in a specific way. GitHub auto-merge is enabled, but all checks must be green before it can complete, with a workflow named allchecks verifying that every configured workflow has passed. Buildkite must be green, and a required Buildkite check blocks merging if it is not successful. DCO is required, so commits must be signed off. In practice this means a contributor is not merging into a quiet repository but into one where the test suite and the style gate are both enforced by the platform rather than by reviewer diligence.

The published versions and the working tree have drifted apart

The release history in the repository is old. The tags are v8.10.0 from 2016-02-03, v8.9.0 from 2016-01-28 and 8.8.1 from 2015-12-09, all in the 8.x line. The repository itself is not archived and the last push was on 2026-10-12, so the code has kept moving for a decade after the last listed release. That gap is the single most important fact for anyone considering the gem, because it decides which version you install. The tree carries VERSION and RELEASE_NOTES.md, which is where you look to find out what the current source thinks it is, while the gem index shows what was actually published. The licence is Apache License, Version 2.0, with the author listed as Adam Jacob, and the copyright details are in a separate COPYRIGHT.md file, so a fork or an embedded use is covered by the usual permissive terms.

Editorial conclusion

Adopt ohai if you run Chef and want a defined, versioned answer to what a node looks like, or if you want the same collectors as a standalone JSON tool for your own automation. Do not adopt it if you only need a few facts about one machine, since a short script is less machinery than a gem with a plugin framework, and do not expect the published gem versions to reflect current work, because the releases listed are from 2015 and 2016 while the repository keeps changing. Before you pin a version, read VERSION and RELEASE_NOTES.md in the tree, and check the documentation on writing plugins if you intend to extend the collectors rather than only consume them.

Frequently asked questions

Official sources

1. chef/ohai on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases