Open source isn’t just about opening up your code—it’s also about building a supporting infrastructure that invites people to contribute. In order to create a vibrant, growing, and exciting project, the community needs to be able to participate in the governance, the documentation, the code, and the actual structures that keep the project alive. If the overall “hive” is doing well, it attracts more individuals with diverse skills to the project.

Although many projects strive for “open everything,” infrastructure is often closed to contribution. Usually, only a few people run the infrastructure and keep the lights on. They’re sometimes unable to recruit help because, well, you can’t really give the keys to the kingdom to everyone. A certain level of trust is needed before granting a contributor access to project infrastructure.

Over the last few years, infrastructure tools like Ansible, Chef, and Puppet have become widely adopted. It’s now possible to open source project infrastructure as code, with the same levels of access as any other contributor. This makes the process visible to contributors and enables the community to scale. You’re no longer tied to the problem of only a limited amount of high-level contributors who have access.

In keeping with this, here are a few things that we’ve learned while working on Gluster:

• Make decisions in the open: Use public mailing lists for infrastructure-related discussion and planning. Involve the community in every part of the decision-making process. Specifically, avoid announcing decisions made in private.
• Define infrastructure as code: Use Ansible, Puppet, or any other configuration management tool that enables contributors to drive infrastructure development. Use Jenkins Job Builder to define Jenkins jobs. Developers and the wider community can define new jobs with little overhead.
• Define ownership of infrastructure: Define clear ownership of infrastructure with public post-mortems for failures. This transparency will help your community trust you to do your jobs.
• Clear a path to contribution: Define a clear path for infrastructure contributions. As my friend Elizabeth Krumbach Joseph says, “If you need root access to do your job, it is a bug.”

When you try to open up your infrastructure, you will run into problems. Here are some of the problems we came across and how to solve them.

• You will change the status quo: As you change infrastructure processes, you will change how things work. There may be some resentment within your team about the changes. Make sure you announce your plans well in advance. Make changes in chunks so you can discover any “brokenness” soon. Get your team on your side by fixing things that affect its productivity.
• You will want to fix too many things: There will be plenty of things in your infrastructure that need fixing. Be wary of turning it into a yak shave, which is something that seems to be made of a thousand pointless different steps, all happening at once. Imagine trying to shave a yak! If you are trying to perform a task and discover other things that need fixing, record them for later instead of trying to fix them immediately. Your progress will be slow, but make sure it’s steady. The important thing is to not get overwhelmed by the work ahead of you.
• You will break things: When you make massive changes to process and infrastructure, you will break things. Make sure you do a public post-mortem of your failures. Create a plan to avoid this particular pattern of mistakes in the future.
• It feels like work will never end: We’ll let you in on a secret: It will never be finished. Infrastructure changes with the needs of the project. There’s no such thing as “done.” You will always have something else to fix.

The most important thing we’ll leave you with is that it’s not just important to open the infrastructure, but also the documentation and process around it so everyone can contribute.