In April, I attended the Linux Foundation’s Open Source Summit, which included tracks for leadership and Open Source Program Offices. Many open source project contributors have been doing globally distributed collaboration long before the pandemic made remote knowledge work widespread. One of the most famous open source projects, Linux, has been around for over 30 years! There are a lot of established open source software projects which are regarded as higher quality and more reliable than proprietary alternatives, thanks to the transparency of their work and practices.
Given this long track record of collaboration with high quality results, there are quite a few concepts and practices that remote projects in general can learn from open source development… so many that I’m planning 2 blog posts! This month will focus on the written aspects and next month on the people aspects.
Let’s dive in!
Create a clear project objective/mission statement
Having the team work together to spell out a clear and concise project objective/mission statement will help maintain focus, alignment, and motivation among team members. A well-defined project objective/mission statement serves as a rallying point for team members, fostering a shared sense of purpose and accountability towards realizing the project's vision.
As a project evolves, it’s very easy for people to forget or get confused about what exactly the team is trying to accomplish, and being geographically distributed makes it difficult to detect when that is happening because you don’t have as many spontaneous or free-form live discussions. When you have someplace the team can always go back to, to remind themselves of the project objective/mission, remote teams are better able to act with more autonomy to prioritize their tasks and make aligned decisions.
Here is an example of the OpenAMP open source project’s mission, crafted by the steering committee, at the top of the project's “About” page.
Have guidelines for email communication
Open source projects often have guidelines or conventions around email communication to ensure clarity, efficiency, and professionalism in discussions. Adopting guidelines can benefit remote projects by streamlining communication and reducing misunderstandings. For example, establishing protocols for subject lines, formatting, and response times can enhance the overall effectiveness of email correspondence within remote teams.
Some contributors to the Linux kernel have written guides to help their fellow contributors participate according to the protocol: [Mailing list etiquette] [Basic guide to Linux mailing lists]
Adopt a chat tool
Asynchronous chat tools like IRC, Slack, or Discord can support less formal, lighter-weight collaboration and community. These provide a space for quick exchanges, informal discussions, and brainstorming sessions without the need for immediate responses. Conversations are organized into topic-specific channels, which help to focus discussion. History is also available for people to catch up during their time zone’s working day. These tools are also handy to catch someone for one-on-one live interactions and small group discussions, or ping someone when they’re late for a call or not responding to your emails.
Have a central archive of important team email discussions
Maintaining archives of discussions and decisions can prevent the need to rehash the same topics repeatedly. This saves time, is a great way for new people to the discussion or project to get caught up, and promotes transparency and accountability within the project.
Here is an example of an archive for the Linux kernel mailing lists. It is a bit spartan, but is aligned with the project philosophy. There are other tools that enable prettier display of the emails & some statistics - here is an example using Mailman3. Within a company, your IT department could be enlisted to create an internal email archive for team discussions.
Have solid project documentation + Invest in keeping it up-to-date
Solid documentation enables new contributors to a project to onboard smoothly and empowers existing members to work efficiently. By documenting project goals, workflows, standards, guidelines, best practices, and important references, remote projects can accelerate the learning curve for newcomers, boost their morale by allowing them to be productive quickly, and alleviate the burden on experienced team members when they have to otherwise spend time conveying tribal knowledge whenever a new person joins.
I like to put the newest person in charge of updating onboarding documentation, because they are the first to discover a problem with it. Might as well fix it right away! They are also able to get to know other folks in the team as they work with the subject matter experts to make the corrections.
Conclusion
The principles and practices of open source development offer valuable insights and strategies for remote projects seeking to improve their collaboration and productivity. From establishing clear project objectives to implementing guidelines for effective email communication, adopting asynchronous communication tools, archiving discussions, and maintaining comprehensive documentation, there are many lessons to be learned from the open source community. By embracing these practices, remote teams can enhance transparency, streamline communication, foster autonomy, and accelerate the onboarding process for new project team members. In Part 2 of this series, I’ll get into the people aspects of open source development that can benefit remote projects in general. Stay tuned!
댓글