Ceph is an open source project; built through the efforts of its dedicated, passionate community. If you find Ceph useful, the best way to say thanks is to contribute back. Here are a few things you can do to pitch in:

Join the Mailing Lists and IRC Channels

Becoming an active member of the community’s discussions is the best way to get to know people, and you can reinforce your understanding of Ceph by asking questions and helping others learn. Join the mailing list and hang out in the IRC channels – that’s where it all happens!

Visit the Mailing Lists & IRC page for more info.

Build Ceph from Source

Using pre-built packages, the ceph-deploy tool, or orchestration frameworks (like chef, puppet, juju, etc) may be the quickest way to get Ceph up and running, but building from source can help you become familiar with how everything is put together.

To get started building Ceph you should clone our repository and then follow the guide for building Ceph. As you work through the build process, feel free to update the documentation or submit issues along the way.

Learn the Source Tree

Once you have walked through installing Ceph it would be a good idea to learn your way around the source code. During the Firefly Ceph Developer Summit Sage gave a great overview of how best to contribute to Ceph, including where everything lives in to the source tree.

Source Tree Highlights

  • auth — authentication infrastructure
  • common / include — random bits and pieces shared by everything (atomics, link lists, library headers, etc)
  • crush — crush algorithm for data placement
  • gtest — google’s unit test framework used for ceph unit tests
  • java — java bindings for libcephfs (used for hadoop binding)
  • osdc — client side code for object storage daemon
  • os — object store (internal abstraction used for storing data on the local node)
  • msg / messages — used for messaging across the wire
  • mon — code for the monitor daemon
  • mds — code for the metadata server daemon
  • rgw — code for the rados gateway daemon
  • osd — server side code for object storage daemon
  • osdc — client side code for object storage daemon

Attend Ceph Developer Summits (CDS)

For every major release (dumpling, emperor, firefly, etc) the Ceph developer community gets together for a virtual Ceph Developer Summit. These summits, held quarterly, serve to discuss proposed work and ensure that all tasks have a blueprint, and an owner so that the features can be delivered in time for release.

Keep an eye on the Ceph blog and mailing lists for the call for blueprints and submit work that you would either like to see, or are willing to do yourself. Each blueprint will get a session at CDS so Sage and other developers can weigh in on how best to implement the suggested work.

Submit Issues

Are you having problems building or running Ceph in your environment? Every user has a unique storage architecture and workload, so it’s possible you’ve found a bug that nobody else is experiencing.

You can search through our issue list to make sure you’ve found something new. If it is, share it with the community by creating a new issue and including as much detail as you can.

Fix Issues!

While you’re searching through the issue list, you might come across something that you’d like to fix! Don’t let us stop you.

Once you’ve fixed it, the best way to submit your work to the team is through a GitHub pull request. Posting patch files on the mailing list is, of course, always welcome.

Help With Documentation

Not a coder? If you’d rather write prose than code, we can use your help in making the Ceph documentation more thorough. Our documentation is always growing and changing, and there are lots of spots that need additional detail. Heck, there may even still be entire sections that need to be written!

The documentation lives inside the /doc directory of the main Ceph repository. It’s written in reStructuredText, an easy-to-write text format.

For more information, read the documentation pages on Prerequisites for Building Ceph Documentation and Building Ceph Documentation.

Share Your Experiences

The Ceph community is always interested in seeing how people are using Ceph. Whether this is a simple blog entry about what you’ve been doing or a more formalized Use Case, we would love to feature it on

If you already have a place where you are recording your experiences we would love to include it on our Ceph Planet page for aggregation. All we need is an RSS feed for a Ceph-specific tag.

Drop us a line to get started.

Dedicate Engineering Resources

Do you work for a company that’s deploying Ceph? Dedicating engineering resources to Ceph is the best way to ensure the ongoing evolution of Ceph. Drop a note to the mailing list and tell us what you’d like to accomplish; we’d be glad to hear from you.

Join Engineering Stand Ups

Every week each of the component teams within the Ceph platform (CephFS, RGW, RBD, RADOS, etc) has a stand up meeting to discuss progress, status, and new development tasks. Once you have proven yourself as an active contributor to one (or more) of these components you can ask to join the weekly stand up and become more of a core contributor. In order to take this step you should have done the following:

  1. Had a pull request approved
  2. Served as a Blueprint owner during a CDS cycle.
  3. Spoken with a Component Technical Lead (CTL) about becoming more involved in the development process
    • RBD – Josh Durgin
    • RGW – Yehuda Sadeh
    • CephFS – Greg Farnum
    • RADOS – Sam Just
    • Teuthology – Zack Cerza
    • ceph-deploy – Alfredo Deza
© 2016, Red Hat, Inc. All rights reserved.