A few months back we collectively began a concerted effort to improve our operation as a Salt community. Salt had grown and, as a result, the project’s original structure and processes were unable to cope with the increasing demands of this passionately admired project.
It wasn’t easy, but we all took it upon ourselves to tackle the issues. The same themes repeatedly echoed in our community:
- An unpredictable release cadence meant no one could plan and build on the platform.
- Quality issues grew as use cases expanded.
- As team members worked diligently to keep up with increasing demands, they became overburdened and less responsive.
- Inadequate communications on project direction or decisions left some in the dark.
Rumors fueled speculative root causes including the suggestion that SaltStack is not investing in open source anymore. Frustration surfaced every so often, creating a less-than-productive climate.
So we decided to take charge and address the situation. We spent time talking to community members and our partners. We researched best practices from other open source projects. We were diligent in exposing root cause. We identified some key actions:
- Reduce the burden and overhead of our branching and release approach, freeing our expert contributors from maintenance, allowing them to focus on the most important issues that needed support and to innovate again.
- Grow the team. We have more engineering resources focused on Salt than ever before.
- Institute common-sense quality standards (e.g. require passing tests before merge).
- Invest in automation and continue investing every release cycle.
- Innovate to ease platform extensibility with projects like POP and Idem.
- Empower more folks in the community through work groups that drive segments of the project.
- Elevate Salt community management role to a full-time effort.
We knew that these actions would lead to many improvements, but we also knew things would be different. Implementing a predictable release cadence meant rules had to be put in place for what would and would not make it into the codebase at a specific point in time. It meant every contributor needed to be responsible for the full lifecycle. Submitting raw code and letting someone else take care of the rest would no longer work for us as a community. Quality would no longer be the responsibility of a hidden backend process, but rather a joint responsibility shared by all of us.
Additional community responsibility also means additional rights: the right for every community member to give input, to be heard, and to engage productively. We expanded Salt project communication channels with weekly open hours. We increased SEP review times and engaged with community members ahead of changes. All of these changes are meant to ensure a collective voice. If we are going to evolve the Salt project to a better place, we must do it together.
Now that we are a few months in, what are the results? We have made progress but there is still plenty of room to grow. We released very close to our scheduled timetable. We improved our tests and will do more. We automated a lot, yet still have a long way to go. We introduced a wave of innovation projects (e.g. POP, Heist, Idem, Umbra, and more) that will extend the value of the platform to meet community needs. You can read an independent view by The New Stack on the potential impact of Plugin Oriented Programming (POP) here.
So are we done? Far from it. We are just starting. Sometimes you get it right. Sometimes you learn. For example, we can communicate better by sharing recordings and written summaries of our discussion and decision meetings. And we can support each other at times of transition, e.g by running clinics on how to write tests.
And we can improve our culture. A community is as strong as the positive engagement amongst its members. The Salt community has always been notably friendly and welcoming, and we won’t tolerate intimidating language, hostile interactions, finger pointing and tribal notions of us versus them. The team genuinely strives every day to be helpful and address the needs of the community.
Are we experts on everything? Absolutely not. Can we get it wrong? Sure. But this is where the notion of a community becomes essential. Help folks understand your needs. Ask before you assume. Engage constructively to understand why something was done and ask how you can help. While opinions, preferences, and armchair diagnoses do provide insight, they are not always the best contribution. What we really need are solutions that triangulate needs and help us fulfill as many of the requirements from the community as possible.
I have personally been involved with my fair share of open source projects including early Java, Openstack Nova, Openwhisk, Kafka and more. Yes, there are differences, but the fundamentals are the same. If you want to receive, you need to be willing to give – and give constructively. We are heartened by the many folks who have sent positive messages and engaged constructively to help us improve.
Change is hard. We can only work through it by working together. We will work our hardest every day to improve. We will work equally hard to ensure our community is a positive, collaborative, welcoming forum for all those who love Salt and are passionately making it the great platform it is and can be.
We extend a sincere thank you to all who are constructively engaged and positively impacting the direction of Salt.