Openness plays a significant role in propelling DevOps and organizational processes forward. This is not to imply that everything must be open, but the default should be openness unless a valid reason indicates otherwise.

Andrew Zigler, developer advocate at Mattermost, and Matty from Arrested DevOps recently shared insights on this subject. They discussed creating impactful developer advocates, managing community writing programs, and dealing with the challenges of open source communities.

The Importance of Open Source in Communities

Andrew emphasizes that the loudest and most contributory voices in open source projects are usually the paid internal staff. However, he champions setting up pathways in the community to validate the experience of all contributors and reward them with anything from thought leadership, platforms, or even swag. The key is to influence individuals at all levels of engagement and ensure that they feel they own part of what they are contributing.

One of the challenges he identified is over-influencing which often stems from the fact that the paid staff are the ones driving the open source project vehicle. This imbalance usually drowns out the voices of other contributors, particularly those who may not have the luxury of dedicating as much time and energy to the project as the paid staff.

Andrew suggests a solution: the company creating more developer advocates through the multiplier effect. This means ensuring that everyone across the board understands the importance of the open-source community and empowers them to contribute. The more developers contribute, the larger and more diversified the community becomes, leading to better outcomes and solutions.

The Critical Role of Leadership in Open Source Communities

Matty highlights how vital leadership is in these initiatives. By allocating resources, prioritizing open source community engagement, and maintaining a strategic focus, leaders can do much to foster a healthy open-source community. Successful leaders understand that engagement levels differ, so they create opportunities for different levels of contributors to partake and contribute to the community.

To ensure the project remains harmonious and aligned with company goals, the leadership should give equal weight to both staff and contributors’ voices. In the end, everyone involved in the project is part of the community.

Engineering Blogs: The Balance of Output

The conversation took an interesting turn when they started discussing engineering blogs, a tricky subject for many organizations. Matty points out that these blogs have the tendency to publish sporadically, often dominated by lengthy droughts of content or a sudden overflow of posts.

Such inconsistency happens when the contributors, mostly engineers, write when they can spare the time. Balancing this dynamic is crucial, and one suggested solution is to involve people whose primary job is creating content. They can collaborate with subject matter experts to create consistent, relevant content.

Conclusion

Operating under a default open environment for your projects does not mean that everything has to be open. Nevertheless, transparency and openness should be the norm unless necessary otherwise. By dealing with the occasional echo chamber and understanding that contributions will always ebb and flow, the community will thrive and keep moving forward.

In line with the open source spirit, scaling advocacy is crucial in DevOps. It involves not only the individuals whose title is developer advocate but everyone within the company. By creating more advocates and amplifying community efforts, the DevOps movement continues seamlessly.

Links

Matty’s blog post about SharePoint (including broken images!)
Community Pulse podcast

BURKHARD BENECKEN (Strafverteidiger)