As businesses and their employees come to terms with remote working, there are lessons that can be learned from the open source world, says Brian Proffitt, Manager, Red Hat.
The world in 2020 looks very different from a year ago. Where previously cities were bustling and offices were busy, now they are all but deserted as many organisations ask their employees to stay home. Many organisations, including Red Hat, made the decision to close all offices as early as was practical. Working as a distributed community is something many open source projects have done for a long time. As businesses and their employees come to terms with remote working, there are lessons that can be learned from the open source world and how distributed communities can work together from afar to build products and collaborate on ideas.
Open source communities are semi-organised collections of contributors to a project, typically software. These communities bring people with shared interests together to collaboratively build something, which can be shared with anyone inside or outside of the community. And, almost always, open source projects are the results of distributed communities.
Working in open source communities
One of the biggest mistakes we see organisations make when they try to work in open source communities is when they take their code and give it to the open source community and expect people to jump right in to work on it. It happens a lot and it almost never works in favour of the company or the project. Organisations need to show they are willing to be involved and be an equal participant in the development of the code.
On the other end of the spectrum, some contributors try to join open source communities and bring with them their corporate approach to software development, which includes rules and guidelines of how their developers work.There is a strong streak of libertarianism in open source, as contributors are independently driven they tend to be mistrustful of larger organisations trying to get involved in their communities. This approach can fail because organisations bring their own rules that simply don’t mesh with the freedom many expect in open source. You won’t attract contributors to a community if you have too many rules.
There is a fine balance between simply giving code to a community and expecting people to work on that code unguided, and having too many rules or too much structure.
The lesson here can be applied across an enterprise organisation with an entirely distributed workforce. Employees need to see the organisation helping and getting involved in supporting its workforce, but without being restricted or constrained by too many rules that stifle creativity and innovation, or that enforce a working regime that proves difficult and stressful for those that aren’t used to working in this home environment.
Supporting and enabling your remote community
When you are trying to support your remote workers, it’s important to let go of all the old rules. In open source communities, developers don’t focus on how much time they’ve worked on a project – it doesn’t matter what time they start or finish. The focus is, and should be, on results.
In a remote working environment, take away the manual that describes how someone should do their job, keeping the important pieces of what needs to be done, and let people use their freedom and creativity to get things done in a way that works best for them
The role of an open source community manager isn’t just about making sure features are crossed off, it’s about making sure people are happy, enjoy what they’re doing, and they have the tools to do it. Give your employees the tools to get the job done and then let them figure out how to do it themselves. At the same time, be there to support that person. An open source community manager loosely watches and steps in when needed.
Be welcoming
Alongside maintaining a healthy open source community, it remains vital to ensure you also attract new contributors. From the outset, providing information on where the code is, how to download the software, and technical documentation is vital. Burying a download link three pages deep in a web page sends a signal: if it’s this much work to get into the community, or you don’t know who to talk to or where to start, you’re not going to attract new contributors.
As employees work remotely, their usual ‘go to’ lines of communication may be changed, so making sure they know where to go for help, and who to ask is more important than ever. It’s hard to over-communicate when you’re working with an entirely distributed workforce, so take the time to set regular update calls on topics that matter across the business. Then give employees the option to attend these.
Embracing the change
As we all learn how to work as distributed teams, it’s important not to try to replicate the culture they had in an office. The space isn’t there, the serendipitous ‘watercooler’ moments no longer happen as easily. The drastic change from in office to remote work is no doubt a struggle for some employees, the culture from the office doesn’t translate into a remote workforce.
Culture must grow organically. It’ll happen. One day, someone will do something silly and everybody will laugh about it for a week, and then it becomes an in-joke. Cultures and communities get their rituals and jokes with time and it’s these that grow a community. This is how open source contributors come to join communities and remain active and dedicated to them, often for many years.
