By now we are 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 not at school. As one frazzled parent put it, “I now have two more full-time jobs. I’m a principal and a teacher.”
And in the tech sector, software developers who have been working together, collaborating in open office environments, are suddenly isolated. Sure, there are virtual connections, but they are not the same as being in the same room.
That doesn’t mean development has to fail, though. There is a template available for overcoming that challenge. The open source software sector has been working remotely since … well, since open source became a “thing.”
Open source vs. conventional development teams
In most cases, participants have never met. They don’t know each other. They might never see or speak with one another. They are likely in different parts of the country, or different countries, many on different sides 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, for example, started as an open source project and remains open source to this day. Open source software is part of virtually every application, network, and system in operation today. It often represents the majority—sometimes more than 90%—of the code in a codebase.
So yes, productive remote teamwork is possible.
That’s not to say that open source development 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 the supervisor is generally more along the lines of “community leader” than boss.
But conventional development teams and their managers in need of new ideas for working remotely can still learn plenty of things from the remote operation of the open source world. There are even books about it—one of the most popular is The Art of Community by Jono Bacon, former community manager for Ubuntu.
Tips for working remotely from an open source leader
Tim Mackey, principal strategist at the Black Duck Cybersecurity Research Center (CyRC), knows about the remote operation of open source communities as well. While he works for a company, he has been a community leader, and still is a community member, for open source projects. He has worked remotely and managed remote teams for the bulk of his career.
So he knows from experience that “remote” doesn’t have to mean “disconnected.” It just takes some awareness, effort, and cooperation. He described some of the ways open source communities mitigate the absence of physical human contact:
Communication, communication, communication
It sounds like the tech version of the real estate mantra “Location, location, location,” which describes the most important factor in buying a house.
But that is because communication is the foundation for everything else. Of course, working remotely can’t be exactly like the physical office environment, where, as Mackey puts it, “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, as long as teams aren’t too large—ideally fewer than 10 people.
“You could actually have everyone put their phone on a Skype call. The phone is just sitting in the corner, and it doesn’t have any other purpose than to serve as the proxy for the office,” he said. “There are many ways to solve the problem. You just need to find the pieces that are missing.”
Resiliency
Resiliency flows from communication—what Mackey says is “completely and transparently communicating all of the issues” regarding a project.
As is the case with open source projects, resiliency is the result when “there is nobody who is magically special who needs to know extra stuff,” he said. “Anyone at any point in time can know everything. That level of egalitarianism really starts to increase the engagement.”
It also means there is “no single point of failure,” which is a mandatory element of resiliency. If somebody gets sick, goes on vacation, 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.
“You don’t have to worry about one person having all the magic knowledge and then you are massively disrupted when that one person has to deal with some personal issue or, for that matter, wins a Powerball ticket,” Mackey said.
“It gives you flexibility. Everybody is going to have some aspect of their life that is going to be variable. Some people want to ski, some people want to surf, some people don’t like the cold, some people love the cold.”
Emotionally intelligent feedback
Emotionally intelligent feedback, which also flows from good communication, can be much trickier among a team working remotely, since emails and texts usually lack “tone.” Facial expressions, speech volume, and other physical cues present in face-to-face communication can bring a lot of helpful nuance to comments that might seem harsh or even accusatory in writing.
Not to mention that cultural and language barriers can be easier to overcome face-to-face than in writing. If a recipient from another country who speaks another language gets a note and puts it into something like Google Translate, the results can be unpredictable.
“If you know multiple languages and have tried that, then you know Google Translate is sometimes really good and sometimes it is absolutely atrocious,” Mackey said. He noted that in the open source world or any remote situation, he makes a point of using very precise language when he writes comments.
“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 pretty early how to overcome,” he said. “In some countries, tone is such a key component of their written language that they might miss what you meant more often than you would prefer.”
A breakdown in the emotional element of feedback can be “a huge kick in morale,” Mackey said.
No sacred cows
Every team and every project needs a process to govern how things get done. But remember that the whole point of the process is to help things get done. As Bacon says in his book, processes are “only useful when they are a means to an end.”
Or as Mackey puts it, “It really 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?’”
And if the shift from the office to working remotely means certain things can’t get done, then the process needs a revision.
A perfect example, Mackey said, is a scenario where IT and legal have imposed a security policy that says, “To protect our source code, you can only commit code on this special network that will never be accessible outside of the company.”
While that might have made perfect sense before, it doesn’t work when nobody is at the office. “Process needs to be a living entity. You can’t just fall back on, ‘But this is the way we have always done it,’” he said.
One reason is that someone on the team might come up with a workaround just to get their job done, but such a workaround amounts to “shadow IT,” since it is outside security policy.
“Does that mean I’ve created a situation where, in trying to do the work I’ve been assigned, I have now circumvented every process in place because it wasn’t designed for the reality of everybody working from home?” he asked.
Again: Communication is the key to working remotely
It is clearly much better to figure out a way to maintain the security of source code without making it impossible for a remote development team to do its work.
All of which, once again, comes down to “communication, communication, communication.”
Of course, it will take some getting used to. There will likely be some bumps in the road. But if the open source community can do it, organizations can too.
Continue Reading
A new identity for the Synopsys Software Integrity Group
Aug 12, 2024 / 2 min read
CyRC Vulnerability Advisory: CVE-2024-5184s prompt injection in EmailGPT service
Jun 04, 2024 / 1 min read
CyRC Vulnerability Advisory: CVE-2024-5185 Data Poisoning Vulnerability in EmbedAI Application
May 27, 2024 / 1 min read