Suddenly Remote: What the Open Source Community Can Teach Us

By now we’re all familiar with the, uh, “challenges” (that’s the printable word) of uprooting millions of workers from their offices so they can work more safely from home. Remote work -- all of a sudden with no time to plan for it -- is disruptive. It’s unfamiliar. It’s stressful. It’s distracting, especially for those with school-aged children who are now themselves remote learners.

That doesn’t mean office work teams will crash and burn, though. There is a template available for overcoming that challenge. The open source software sector has been doing projects remotely since --well, since open source became a “thing.”

In many cases, open source contributors have never met. They don’t know each other. They are likely in other parts of the country, or parts of other countries, many on the other side of the world. Frequently, they don’t even speak the same language.

Yet they work together, in many cases with astonishing efficiency, and they produce products of superb quality. The Linux operating system, one of the more popular in the world, started and remains open source. Open source software is part of virtually every application, network and device in operation today. It usually represents the majority (sometimes more than 90%) of the components in an application -- even in commercial software.

So yes, remote teamwork -- productive remote teamwork -- is possible.

Not that it is an exact parallel to the corporate world. Open source is a “community,” not a company. Those who participate are essentially volunteers, not paid employees. There is a hierarchy, but it’s generally more along the lines of “community leader” than boss.

Based on my experience and observations, here are some of the ways open source communities mitigate the absence of physical human contact:

Communication. Of course, working remotely can’t be exactly like the physical office environment, where if someone is working on something that relates to what you are working on, you will know because up will pop a head when you say ‘I really don’t understand why this is doing this.’

But it can come close, if teams aren’t too large -- ideally fewer than 10 people.

For example, you could have everyone join a standing Skype call during work hours. The Skype call then becomes a proxy for an office environment. This is but one way to solve the office dynamic problem. You just need to find the pieces your team is missing.

Resiliency. This flows from communication -- and empowering teams to solve problems by arming them with information.

As is the case with open source projects, resiliency results when there is nobody who is magically special who needs to know extra stuff. That level of egalitarianism really starts to pay dividends with team dynamics and job satisfaction.

But it also means there is no single point of failure, which is a mandatory element of resiliency. If somebody gets sick, goes on vacation, wins the lottery, or gets a different job, it doesn’t hamstring the rest of the team because one person isn’t carrying all the institutional knowledge. Everybody is.

Overcoming tone deafness. With a focus on community, these teams make a conscious attempt to overcome cultural and linguistic differences all to boost engagement, and by extension, productivity. This also flows from good communication and can be much trickier since emails and texts usually lack “tone.” 

When you remove the nuances of facial expression and other physical cues, opinionated feedback can become harsh or even accusatory -- a dynamic that is only enhanced when working in a second language or using Google Translate to understand messages. For example, if you have ever been in a situation where somebody has complained about the tone of your writing, that is exactly the type of scenario that successful open source teams figure out how to overcome.

As teams are so widely distributed, it’s critical to invest in communication dynamics rather than assuming you can be bold now and smooth things over later. In the open source world, once feathers are ruffled, that contributor could very well leave forever and take their expertise with them. There’s no unifying employer to enforce team cohesion.

No sacred cows. Every team and every project require a process to govern how things get done. But the whole point of the process is to help things get done. As Jono Bacon puts it in his book, The Art of Community, processes are “only useful when they are a means to an end.”

Process then boils down to making certain that everyone knows what it is, why it is and to a certain extent knows that they can raise their hand and say, ‘But you do realize you’re not doing this, right?’ So, if the shift from the office to remote means certain things can’t get done, then the process needs a revision.

Of course, change will take some getting used to. There will likely be some bumps in the road. But if the open source community have been doing it for over 25 years, businesses can, too.

Tim Mackey is a principal security strategist within the SynopsysCybersecurity Research Center (CyRC). He joined Synopsys with the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms. As a security strategist, he applies his skills in distributed systems engineering, mission-critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He also delivers talks globally at events such as RSA, Black Hat, Open Source Summit, KubeCon, DevOpsCon, and Red Hat Summit.