5 Remote-work Lessons From the Open-source Community

Working from home has always been an option for most software developers, but the COVID-19 pandemic has taken away that idea of choice. Now, not only is remote working the norm—whether you and your employer like it or not—but it’s also looking likely to become the status quo for the future.

So how can developers and software-engineering teams better adapt to working remotely? Well, they can learn a thing or two (or more) from the open-source community.

Open-source software is built by maintainers and contributors from around the world. In their 2013 book, Remote: Office Not Required, Jason Fried and David Heinemeier Hansson write: “If you look, for example, at Ruby on Rails, the web framework we created at 37signals [now Basecamp], we’ve managed to evolve the code base for over a decade and have kept adding features and improving code quality. Close to 3,000 people from dozens of countries and hundreds of cities have contributed to that code base over time—and the vast majority have never met each other.”

The open-source community has always relied on distributed teams of developers—and this can still be seen today. According to the 2019 The State of the Octoverse report, on average, each open-source project on GitHub had contributors from 41 countries and regions.

With years of experience under its belt, the open-source movement has a few things it can share about remote working with the wider software-development community. Here are 5 lessons developers and software-engineering teams should find very useful.

1. Trust rather than track

Open-source teams operate on trust: Everyone is accountable for what they need to deliver. Those involved in the open-source community are mostly volunteers working on projects in their own time, and as such, open-source teams have to trust in each other to get things done instead of dictating what the next task will be.

In the Python ecosystem, for instance, the Python Steering Council guides rather than controls. “You can’t tell people to do things, because they’re volunteers,”says Carol Willing, who is a member of the council and a core developer. “You can encourage, you can show the merits of perhaps doing something. But at the end of the day, we are very reliant on our volunteers, and part of the steering council’s charter is to create an environment for volunteers to be successful and collaborate successfully.”

This trust can be empowering, with team members motivating each other to produce high-quality work. “People become empowered by our trust in them,” shared Corey Hulen, co-founder, and CTO of open-source messaging workspace Mattermost, in a talk he delivered at QCon London 2020. “You don’t have that external peer pressure of a boss hovering over your shoulder, so it creates a high-trust environment where we trust in employees to do the right thing and the employee trusts in the company as well, and [the process] self-selects these highly motivated people.”

For remote software-development teams to thrive, they must also operate on trust, tracking output instead of time. To do this, managers and team leads must allow developers to work flexible hours so they perform at their optimal moments. Setting clear goals also helps, as well as granting them the space to figure out how to solve an issue or implement a certain feature on their own. Giving developers more flexibility on how, when, and where they work could make them more productive and will likely turn them into loyal employees who will stay longer in a company.

But trust works both ways, so developers must be honest and transparent about what they can and can’t deliver. If they can’t accomplish a task by its due date or if they’re having difficulty solving a problem, they should let their manager or team lead know immediately so they can work the issue out together.

2. Use asynchronous communication when relevant

In office settings, communication revolves around a physical location: daily stand-up meetings in the breakout room, Friday team lunches in the pantry, fortnightly sprint demos, and retro meetings in the conference room. With teams working remotely, the lines become blurred, so redefining how you communicate, sharing these methods with the team, and adjusting them as you see fit will make things clearer.

“As we accept that the way things are now is likely to be normal for a while, it’s a good time to start writing down the norms and rituals of the team—and considering whether those norms and rituals serve us right now,”writes Cate Huston, a former engineering manager at Automattic, for Quartz. “Perhaps the 10 AM daily standup was a norm, but now is the time to switch to an asynchronous, text-based standup, as people start their day at more variable times. Perhaps the Friday afternoon show-and-tell was a norm, but it’s time to move to something more flexible, like sharing videos in a thread. Starting a conversation with the team about the way you’re going to work now can help everyone work toward acceptance and support.”

Moreover, working on open-source projects is public by nature. This means that problems are shared among the community and anyone can help out. As Fried and Hansson write in their book, “Much of open source is coordinated on mailing lists and code tracking systems like GitHub. Anyone who’s interested in helping out can because the information is all out in the open.”

These asynchronous forms of communication—which also include Slack messages, Google Docs comment threads, and the upcoming GitHub Discussions—work effectively for distributed open-source teams. Remote software-development teams can adopt this approach, too, replacing face-to-face meetings with video calls or chat messages and using other tech tools for communication.

But these methods of communication pose a challenge in terms of grasping tone and ensuring valuable feedback. Ben Balter, senior product manager at GitHub, offers this advice: “Today’s tech culture is built on a foundation of emoji and animated GIFs […] It’s not simply because animated GIFs of puppies are adorable, but because a 😥 is often the most efficient way to express sadness or 🎉 to celebrate great work. Be human and sincere.”

3. Cultivate a sense of community

Successful open-source projects have a strong community behind them. It’s this that discovers the latest innovative projects, with its members becoming advocates for the next great software. Those passionate enough about a project volunteer their time to contribute in any way they can—identifying and fixing bugs, suggesting improvements, testing upcoming releases, and providing feedback on what is and isn’t working.

The responsibility of fostering this community usually falls on maintainers. Vladimir Agafonkin, creator of the JavaScript library Leaflet, believes that one of the roles of a maintainer “involves nurturing the community and making sure that no one feels excluded, that everybody is heard.”Active open-source maintainer Valérian Saliou’s advice, meanwhile, is to stay open to discussion and recognize contributors—even a gesture as simple as tagging them in a project’s readme file will go a long way. Linda Peng, creator of the open-source project CodeBuddies, rewards contributors by thanking them in release notes, offering a promo code for a course, or raffling off swag donated by sponsors.

Managers and team leads can do the same for their remote development teams. Listening to team members and being open to their suggestions on how to fix a bug or implement a new feature will make them feel heard while acknowledging their efforts and rewarding them for a creative piece of code or on-time releases will make them feel valued.

Building community also goes beyond work. Consider playing team games for a bit of fun or creating virtual spaces or channels where developers can chat about non-work-related topics. You can even conduct end-of-week happy-hour sessions or weekly “getting to know you” video calls, with each team member sharing things others don’t know about them. Running skill-sharing sessions is another way of bringing people together.

4. Provide continuous opportunities to learn and grow

In the open-source community, contributors have the chance to become maintainers. “The key is to be available to talk to them and answer their questions, as well as getting them more involved by making them a moderator, asking them to review some code, involving them in building a release, or asking them to speak at a conference,”says former Node.js core team member Bert Belder.

Peng tries to give contributors more creative ways to add to a project, be it through code walk-throughs for other contributors, content, design, documentation, facilitating discussions about GitHub issues, project management, or pull-request reviews. The same opportunities can be offered to remote developers.

For instance, you can give them time off to attend virtual developer conferences, or shoulder the costs of management webinars or technical workshops, depending on which career path they want to take. You can do remote mentoring sessions in place of in-person mentoring, and you can let them work on a complicated enhancement or allow them to take the lead on a new feature. Working remotely doesn’t have to mean learning and growing stops, and providing developers with opportunities can challenge and motivate them.

5. Have a short-term plan but a long-term vision

When working remotely, it’s easy to get lost in your own task. But at times, problems arise that are just too complex to be handled by one person. This is where having a short-term plan but a long-term vision comes in.

“Sometimes there are important issues that are too big for any individual contributor to solve by themselves. So you need multiple unrelated contributors to work together,” Belder says. “It requires defining a long-term vision for the project. When I was working on Node.js, we didn’t really succeed in making a long-term plan. Even when we had weekly technical steering committee meetings, what was discussed was mostly short-term focused, with individual contributors working on their individual pet peeves.”

To bring multiple remote developers together to tackle a problem, you need to present them with the big picture and long-term vision of what they’re solving, then break it down into smaller tasks that each could do within a shorter time frame. That way, there’s still a sense of collaboration, even though developers are working remotely and individually because they’re all pursuing the same goal.

Conclusion

There’s still much to learn from the open-source movement, but these 5 lessons can get your distributed software-development teams started and set them up for remote work success. As Fried and Hansson write, “If people can manage to build world-class operating systems, databases, programming languages, web frameworks, and many other forms of software while working remotely, you’d probably be wise to look more closely at how it’s done.”

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Illustration by Victoria Roussel

Follow Welcome to the Jungle on Facebook, LinkedIn, and Instagram, and subscribe to our newsletter to get our latest articles every day!