Cloudsplaining and Policy Sentry are fairly new project, so let’s first discuss what these projects do. Policy Sentry is an AWS IAM Least Privilege Policy Generator, auditor, and analysis database. It can be used by organizations to limit the blast radius in the event of a breach and scale creation of secure IAM policies. Cloudsplaining identifies violations of least privilege in AWS IAM and generates a risk-prioritized HTML report with a triage worksheet.
What are the different types of governance you have experience with? What are your thoughts on those experiences?
I don’t know all the “correct” governance terms, but I know how various governance models run based on experience. I’ve seen projects that rely heavily on how many GitHub users have smashed the “Like” button on a GitHub issue. I didn’t want to use this method as a way to collect feedback and prioritize new features.
I’ve noticed that some governance models have a large barrier to entry. For example, it should be easy for a less-technical person to contribute to the technical documentation. That’s part of why I use Markdown instead of reStructuredText (reST) — it’s more straightforward for a large population of contributors. I’ve also seen a governance model called “ask this person.” I didn’t want this to happen to my projects. If the project becomes too reliant on one person, that one maintainer can get burned out. If it becomes mission-critical to its users, the maintainer can use that as motivation to keep contributing — but if the community does not grow, that one maintainer can get burned out. Their passion becomes a chore.
How do you choose which type of governance is best for your project?
I wanted things to be as accessible and as easy for people as I could make them. I focused on three areas: documentation, collaborating by meeting users where they are, and bringing a positive attitude to every conversation.
I try to record as much information as I can, as long as I structure it in an informative and straightforward way. The documentation should allow the reader to get the information that they need without reading a dissertation. I don’t want to assume that people know how to get started or have the same background and context. If I assume that, it can unintentionally create a barrier to entry.
Regarding collaboration: I want to meet people where they are already having these conversations. I didn’t want to require them to join Gitter or have a GitHub account. I joined Slack channels that already have users of Cloudsplaining and Policy Sentry. I opened up my Twitter DMs (Direct Messages) so people can reach out for help.
If you think of open source as a business, it is similar to a start-up. I didn’t want the governance model to become “Ask Kinnaird.” I want to create a community with many core contributors who are empowered to help. If one of the contributors reached out over Slack to make a feature request, I will open the issue and tag the person, rather than dismissing their request directly and telling them to open a ticket. I want people to get credit for it and become the person that others turn to when they have questions about that issue.
How do you think you will make the change from “Ask Kinnaird” to a more Contributor-driven model?
I have a few things in mind that will help make the transition:
- Document everything — documentation is so important.
- Log everything and tag people who make the request or change.
- Engage directly with contributors so they feel more empowered to answer questions.
- Automate where you can.
- Set up strong testing so that when people are submitting a PR they can see whether it will break anything.
- Keep the code clean. If it’s a healthy project, it should be easy to make changes or updates without knowing how the other parts work.
It is also important for me as a maintainer to admit that I don’t know everything. I am more of a back-end person and I know I need help with UI. I need to rely on and accept other people’s expertise.
Have you documented your governance? If yes, where is it located?
All of my documentation is on Read the Docs. I use Material for MkDocs by Martin Donath because it is beautifully formatted and uses Markdown, which is easier for contributors. I pride myself a lot on the documentation for the user guide and the contributing section. I don’t want my documentation to be, “Go do this simple thing.” I realize that some people don’t know how to set up a virtual environment. I also added specific commands, one-liners, cheat sheets, and examples. I don’t want people to have to remember those. If someone asks me a question about the tool, I have to assume that 10 other people have asked that same question — so I reflect my answers in the documentation.
How do you think that your choice of governance affects areas like onboarding, succession, and technical decision making?
Contribution guides are essential. From a technical standpoint, it helps to start with a high-level description and then include lots of copy and paste commands. The copy and paste commands reduce that barrier to entry. I maintain a “Beginner Friendly Philosophy” and make it clear that you don’t need to be an expert on the topic or the technology to contribute. How many times has a GitHub issue comment saved you? It’s saved me plenty of times, and I try to make it clear that opening up a GitHub issue is also a contribution. I want as many people to contribute as possible and “get dangerous” quickly — so I try to put myself in their shoes.
For succession planning, I have to ask myself: “If I got hit by a bus (which would be quite sad), would the project survive?”
Out of my two projects, I believe Policy Sentry would be fine without me, but Cloudsplaining needs some more work before we get to that point. I need to make it easier for people to contribute.
For my open-source projects to be successful without me, I make sure that I’ve onboarded internal and external stakeholders, that all stakeholders have meaningful input on the project, and that there are clear communication channels. I made sure that the stakeholders aren’t just on my immediate team at work — that other groups within the company depend on the project and that their team planning includes the project. When companies and teams are dependent on your project, they need it to survive and will do things that need to get done.
I had to make sure to get my manager on board. I show the business value by demonstrating what teams and projects are dependent on these projects. I knew it fit a unique need and fixed a common pain point among public cloud customers. I knew that if I shared it with the world, it would help others in the open source community, and then they will want to help us. One of my mentors says that “a rising tide lifts all ships” — and that is why it is so important to contribute to open source.
If there are any significant technical decisions to make, I try to ask five contributors for their thoughts and feedback. I lay out the upside, the downside, what is working, and what needs improvement. I’ve found that people really appreciate it when you engage them directly and they get to influence the direction of your software. Some of the core features in Cloudsplaining would not be in place if it were not for certain contributors who suggested new features I didn’t even consider! And even if they don’t contribute any code, I make sure to give them credit if it was their idea.
What advice do you have for someone who is new to open source community leadership?
- Recognize that everyone has imposter syndrome. Don’t be afraid to admit you aren’t an expert in an area. Rely on other people’s expertise.
- Ask other people and maintainers about their experiences and thoughts.
- Look into different ways to communicate with your users — Gitter, Discord, Slack, or even in Twitter DMs.
- Don’t be afraid to address weaknesses and acknowledge the shortcomings of your tools. No one expects things to be perfect from the start.
- Engage with your users. If one person voices a question, assume that at least 10 other people had the same question.
- Look at metrics. See how many people viewed your project or downloaded your tool, and keep track of your “big moments.” You’ll see the impact and get inspiration from that to continue your efforts.
- Build your network and ask them for advice.
Any books, podcasts, conference talks, or blog posts you would recommend for maintainers around governance?
I relied on my network to help but I would love to see what other people suggest here.
Now for a non-Governance question. You mentioned that up until you started Policy Sentry and Cloudsplaining, you had some experience in Terraform and no experience in Python. Have you open sourced anything previously and what motivated you to learn all this at one time?
I learned Terraform in 2018 for a consulting gig. It was the first language that I felt comfortable with and helped me realize that I didn’t need to know binary search trees and leetcoding to do incredibly impactful things with code.
Within 9 months, I had built out a production-grade HashiCorp Vault infrastructure with Terraform. I still doubted my ability to program, since Terraform uses a configuration language and is not a full-fledged programming language. But my experience with Terraform gave me the boost of confidence to try new languages and write more code.
I was motivated to learn Python when I saw how dire the problem is with managing AWS IAM at scale and how people weren’t able to solve it. I knew that we were going to end up becoming an AWS IAM policy writing shop if we didn’t come up with a solution. I visualized a path to completion and how I could automate our way out of the problem. I just needed to become comfortable with Python first. I told my manager that we would become an AWS IAM Policy writing shop if we didn’t do this and that I needed to write this thing and learn Python — but it would take 50% of my time for three months. He told me to go for it!
Read the other posts in our Accidental Maintainers series:
