What distributed teams can learn from open-source projects

Every week, I read about another company that issued an RTO (Return-to-Office) policy. In many cases, it’s fair to assume that this is a thinly veiled tactic to reduce expensive headcount. In other cases, I’m sure it’s the effect of a leadership that had to jump into the deep end of remote work, and never learned how to run distributed teams properly. The latter is a tragedy, because there are plenty of success stories from which these leaders could have learned a lot. And some of the greatest examples grew out of open source projects.

What comes to mind first are the poster children of remote work such as Automattic, Buffer and GitLab. But we can draw from many more examples. For every successful distributed business, there are probably a hundred open source projects that function just as successfully.

That’s not a coincidence. Well-known remote-first or remote-only companies such as Automattic, GitLab and Elastic were initially open-source projects that later formalized into businesses. When a company has its origins in a decentralized community, it makes sense that they would also bring its tools and principles to building a distributed company. And they’ve succeeded as distributed companies in large part because of these tools and principles.

Tools

Successful open source teams use tools that are easy to set up and use, but most importantly lower the barrier to contribution. Their collaboration platforms, e.g. GitHub and GitLab, support asynchronous communication, which also includes making notifications opt-in. This gives participants autonomy where and when they switch their focus from individual work to interaction with the team. Asynchronous communication means writing, and for the resulting documents, open formats like Markdown are the default. They enable each contributor to choose the writing tool that meets their individual needs best. Open formats also allow cross-application data exchange. By connecting the APIs (Application Programming Interfaces) of their platforms and tools, maintainers and contributors build systems that makes their day-to-day work on the project efficient and, in the best case, fun, too.

Processes designed for remote work

But if it was just down to tools, companies wouldn’t fail at distributed teamwork despite all their expensive Jira and Slack instances. Tools and services have to be embedded in well-designed processes to be effective. Looking at open source projects, we can identify a whole bunch of practices that benefit any distributed team. The starting point is to define a common goal. The more clarity there is about the destination, the easier it is for the team to get there. That’s a management job, just like it is to foster good working relationships among collaborators.

Another practice that businesses doing remote work can learn from the OSS community is to foster a positive team culture. Well-run open source projects have a Code of Conduct that they enforce. Great leaders have a clear vision for the culture of their business, and communicate it regularly. By making sure that every team member’s behaviour is aligned with this vision, they create psychological safety and an environment that is fun to work in.

Sharing resources within the team is another core practice, and there is a wide variety of resources: expertise, equipment, materials, data, code, and work hours, just to name a few. A responsibility that all team members share is communicating regularly about process and progress. It’s an essential practice to ensure that everyone is on the same page at any time. (I heard that this can benefit even teams collaborating in-person!) And a bonus practice that we can find in well-rounded open-source projects, but wouldn’t mind in company teams as well, is to give clear and fair credit to all contributions.

Learn from the best

If you want to gain detailed insight into the processes and tools of one of the biggest remote companies in the world, check out the GitLab Handbook. It’s an amazing resource shared in true open source spirit.

In summary, what distributed teams can learn from open source projects is to put in place processes that enable teams to communicate and collaborate effectively towards clearly defined goals, and to provide them with an environment and tools that make executing these processes safe, efficient and fun.