What an awesome community!

Today, I want to say thanks to all the people in the Chaos Toolkit community for being so friendly, open-minded and, of course, for all their contributions.

Contributing to an open-source project is where it all started for me and I know how much it takes to be brave enough to share an idea or, a suggestion or even your own code to a project. However, as a project maintainer, it feels awesome to see those contributions on a project you are caring for.

In the past few weeks we have seen a a growing number of people making suggestions and, when they could, even offer pull-requests. So this post is hopefully a small gesture of thanks to our growing community.

From Discussion to Issue

Simon Johansson suggested a rather neat addition to the toolkit. As of now, once an experiment is executed, it goes all the way or bail (when the steady state hypothesis failed to be reached for instance) but, as it runs, you are not given the opportunity to ping services about each step it is about to start or has completed.

Simon suggested on the toolkit slack that we could perhaps call Slack to make team’s aware of what was going on when experiments are being executed. More generally we agreed it would be useful if the toolkit could call external endpoints as it executed an experiment as well. Accordingly, Simon created an issue to continue the discussion and track the work that will be done on that quite exciting new feature.

So first up, thanks Simon!

A Well-Argued Issue is also Great!

Sometimes features make it into a product even though they are not well polished. We certainly don’t pretend to have all the answers, and so working with the community is much more valuable to the project in general.

An open-source product can be a great way of gathering community feedback as people try it out different features. Not long ago, Tim Wuyts made a strong comment about the way you tell the Chaos Toolkit how to make a decision whether your steady state hypothesis is met. We call it the “tolerance” value of each probe that is declared in the hypothesis block.

Let’s recall that it is an important goal to us that the Chaos Toolkit remains as simple as possible for you to try Chaos Engineering against your system. In that regards, we considered that the tolerance should support simple value comparison (an integer, a boolean…) while allowing for richer comparison. I knew the choices I had made, while implementing that feature, were not optimal but I trusted the community to come back with feedback. That’s how Tim came up with an issue on that very subject.

Pull-Requests are Awesome!

As a maintainer of open-source projects, I know all too well how hard it can be to keep up with the issues being raised. It’s obviously awesome, as we just saw, but requires a lot of your time as well because it’s not just the intent you need to understand but the right way to approach the ideas. Sometimes you are really lucky and a user will however perform part of the job for you and submit a pull-request.

This is what Tim did recently with a PR to improve the capabilities of the toolkit in running probes or actions as local processes.

So another honourable mention, thanks Tim!

How can you get a PR in the fast lane to be merged? Well, it obviously depends on the depth of its intention but, for a common change, here are the basics we follow:

• One Intent per PR - If you mix multiple topics in one PR, this will make it harder to review clearly. Better to have more PRs than a bag of unrelated changes on one.
• Follow the Code Style - If you can mimic the code style of the project, it will make it so much easier for the reviewer to scan your code. The maintainer may indeed write code slightly different from you but the project needs to remain consistent (Top Tip: run the linter on the project)
• Always Provide Tests - Tests will clarify your intention and provide confidence
• Accept Push Back on your PR if it happens - Let’s be clear, as a maintainer you have to make a call as to whether a change serves the community or a single member. Some changes may benefit everyone, but sometimes a change may simply introduce complexity that will cost the project much more down the road. In that case, a PR may be declined and the idea is that we should all learn from it.
• In a similar spirit, Accept Changes may be Slow to be Incorporated - Time is scarce and unfortunately a maintainer cannot spend their entire life on your PR, but we really care and will be working round to it as quick as we can.

Generally speaking PRs can speed up the time for your requirements to be integrated into the product so consider making the time for them if you can. If you don’t know where to start, an issue will always be valued!

A Whole Extension? Sure thing!

Recently, we initiated the AWS extension to the Chaos Toolkit to start performing controlled chaos experiments against AWS. This was triggered from a discussion with Brian Devins who showed interested in running the toolkit against that ecosystem.

We quickly spun up a new extension, using our template project, and off Brian was submitting a PR that was quickly merged.

So a shout out to Brian there!

In Summary: An Awesome Community makes for a Fun Project

Let’s face it, the Chaos Toolkit project is still young and has a small, but growing, community. As long as I have been part of open-source projects I have valued communities that cared for their members. We really do try our best to make it so you find a friendly community around the toolkit. There are never any daft questions, and if a question is asked many times then it’s not only you.. it’s more likely that our documentation sucks and we’d better fix it!

Please do come discuss and, if you can and feel like it, contribute. As engineers, open-source projects are probably the last islands of freedom we enjoy to explore the curiosity we naturally have. We want you to feel happy to join us.

And again, a massive thanks to Brian, Simon, Tim and everyone who has contributed to the project. You are the project!

A project is as good as its community is.

The Chaos Toolkit is an open source project, please follow it and come join our community chat! We look forward seeing you there.