Remote Software Dev: What Can Be Learned From Open Source World

As working remotely becomes the new normal, proprietary software developer teams – which for decades have been working in on-premises office environments – have been adapting to working in relative isolation from home without any in-person interaction with co-workers. This is contrasted with open source developers, who have been working from home with teams spread across the globe since open source software's beginnings in the 1990s.

The common knowledge seems to be that working remotely is here to stay and that most of these newly remote software dev teams won't be returning to centralized offices in nearly the same numbers after the pandemic ends, making it imperative for them to optimize their remote operations for the long haul.

We wondered what these freshmen remote software developers can learn from their more seasoned counterparts on the open source side and contacted some people with long involvements in remote open source projects to ask what advice they would have to offer. We learned that it basically boils down to communication or, more specifically, learning how to function in an asynchronous environment where no response will be immediate.

"I think that a critical piece of the puzzle here really ends up being time zones," said Joe Beda, one of the three original developers of Kubernetes, who is now a principal engineer at VMware.

"Being able to work remote, where folks are in the same time zone, or one or two time zones away, is very different than working with teams that are spread across the globe," he said. "Once you have to deal with time zones, that forces you to go from synchronous to asynchronous in a whole bunch of ways, whether that's email, writing documents or using tools like whiteboarding. That ends up being a big part of the phase shift in terms of going from synchronous to asynchronous."

Michael Hall, who spent over six years working remotely as a Ubuntu employee, said that when he first started he was worried that without the ability to go to nearby cubicles to ask colleagues questions, he would communicate with his team less. The reality, he said, was that he communicated more, and, due to the lack of immediate back-and-forth, the communication was more likely to stay focused on the work at hand.

He added that this also taught him to pose his questions differently.

"Now whenever I reach out to somebody, I try to anticipate any questions they might have so I can get all of that in there, instead of waiting for them to see it, read it, respond to it hours later, and then have to provide that information," he said. "It saves time. Instead of me and the person I'm talking to both using up 10 minutes of our time, I use up 10 minutes of my time crafting a well-thought-out message that they can read quickly and easily.

"A lot of times I don't even have to send it," he added. "Just the process of writing the question and explaining the question answers it for me."

The problem of remote software dev teams being spread across time zones was also mentioned by Scott Hanselman, an open source program manager at Microsoft, who has been working remotely during most of his nearly 14-year tenure with the company.

He said this is something Microsoft has been increasingly dealing with as newly remote workers, no longer tied to a geographical location, leave the Redmond, Wash., area to live in less expensive areas or to be closer to their families.

"We're noticing that team members who were in our time zone are no longer reliably in our time zone, so the asynchrony of it has been important," he said. "Email, we have found, tends to be where ideas go to die, so we are adopting a writing-things-down culture.

"I do write some things in SharePoint and proprietary stuff, but a lot of our folks are on Macs or Linux, and we have folks who manage Linux build servers, so Markdown becomes the lowest common denominator," he added. "Because we are an engineering team building C# and .NET, putting design documents and conversations in Markdown in Git and GitHub allows us to track those things really effectively. Plain text is the great equalizer."

Hanselman said that one of the advantages of posting communications in a text language like Markdown on GitHub instead of relying entirely on Teams, Slack, Zoom and email is that it enables remote software dev team members who may have unreliable internet connections to work offline when needed. This is especially important during the pandemic, when school-aged children in the home might be taking up all of the available bandwidth with online classes.

Another thing that remote software dev teams need to consider is how new members are brought onboard. Hall said that one of the things he learned at Ubuntu was the importance of putting remote workers who are new to the team through some sort of orientation.

"My first week was loaded with call schedules with different people in the company to talk to managers, such as in adjacent teams, so I could find out what their teams do, who on their team is working on what and how that might impact me," he said. "Then there are things like who to ask if I need to get a computer or computer repair, or who's in charge of Google accounts if I have an access issue."

Hall said that the need for some sort of orientation for remote software developers is something that some companies where he's been employed have failed to address.

"A lot of companies just throw you in and expect your manager to be your point of contact for all of that, because in an office that works; you can just go to your boss's office and ask him a question," he said. "When you're remote and everything's asynchronous, the time it takes to go to your boss and get your response back to find out who you need to talk to takes a whole lot longer, and you don't want to delay people by hours or days when you don't have to."

Along the same lines, Beda said that with the influx of new members joining remote teams, it might be time for companies to develop guidelines for videoconferences, to help new team members understand how to contribute to the conversation and not be left out.

"Things like, when you're on a videoconference, how do you indicate that you want to talk, because when you're co-located, the loudest person wins," he said. "I think there's room in this new world for us to create new patterns that I think are more equitable in terms of giving folks a chance to be heard and to be more fair about how we actually cede the floor in meetings and interactions."