What the open source community can teach the suddenly remote workforce – Security Boulevard

Productive remote teamwork is possible. Just ask the open source community, who has been doing it for years. Here are some top tips for working remotely.

By now we are all familiar with the, uh, challenges (thats the printable word) of uprooting millions of workers from their offices so they can work more safely from home.

Remote workall of a sudden with no time to plan for itis disruptive. Its unfamiliar. Its stressful. Its 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. Im 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 doesnt mean development has to crash and burn, 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.

In most cases, participants have never met. They dont 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 dont 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 majoritysometimes more than 90%of the code in a codebase.

So yes, productive remote teamwork is possible.

Thats 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 itone of the most popular is The Art of Community by Jono Bacon, former community manager for Ubuntu.

Tim Mackey, principal strategist at the Synopsys 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 doesnt 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:

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 cant 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 dont understand why this is doing this.

But it can come close, as long as teams arent too largeideally 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 doesnt 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 flows from communicationwhat 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 doesnt hamstring the rest of the team, because one person isnt carrying all the institutional knowledge. Everybody is.

You dont 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 dont like the cold, some people love the cold.

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.

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 youre not doing this, right?

And if the shift from the office to working remotely means certain things cant 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 doesnt work when nobody is at the office. Process needs to be a living entity. You cant 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 Ive created a situation where, in trying to do the work Ive been assigned, I have now circumvented every process in place because it wasnt designed for the reality of everybody working from home? he asked.

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.

Like what youre reading? Subscribe to the blog!

See more here:
What the open source community can teach the suddenly remote workforce - Security Boulevard