Leading Open-Source Teams in Large Organizations - Part I: People

Update - I published a more complete version of this article at LeadDev: Leading open-source teams in large organizations (Archive)

Disclaimer: Opinions are my own and not the views of my employer

I have been a member of an open-source team for Apache Beam since its inception at my current employer. Over the years I took on different responsibilities and eventually led the team. During this time, I wore many hats and performed duties in many different domains with the goal of making the project and the people working on the project successful.

You might ask what is the challenge? Most of the complexities of this role stem from an open-source project being different enough from a traditional company-internal project. The differences are not just limited to the code base being in the open. Indeed, that is not even a major difference. Various mismatches between goals, intentions, processes, and incentives of the people would be the source of more complex differences.

I wrote this guide to touch on many different areas you would have to touch on while working on an open-source project in a large organization. This is the guide I wish I had had years ago. I hope this will serve you well to build an amazing project with excellent people, community, technology, and a product.

People Excellence

Having amazing and talented people, being motivated about the goals, and sharing a common vision is the most important part of having a successful project whether it is open source or not. This will be more complex to achieve in our setup. You might be a people manager (or have access to a people manager) for a group of people working at your company. However, that will not be the whole group of open-source contributors. Your goal will still be the same, having those amazing people work on this project independent of their company affiliations. You can and will raise the bar and be a helpful resource for everyone.

Defining “the team”

This might be a bit counterintuitive. The people at your company might define “the team” as the people at your company. You will be most successful if you can get that “internal” team to see all contributors as peers. By doing this you will increase the collaboration and transparency between all the developers working on this project. This might require some cultural changes and nudges. For example:

• You would want all important decisions, communications, and tools (e.g., testing infrastructure) to be accessible to everyone. You could ask and remind people to use mailing lists, issue trackers, code review tools, etc. available openly.
• You would want to avoid a throw-it-over-the-wall culture. You can: ask for all decisions, and documents to be shared in their initial stages openly; ask code development and reviews to happen openly.

There will be exceptions of course where some information could be shared in a public way. Your role would be to minimize those exceptions (e.g., by increasing alignment between two of your worlds), and where you cannot share things by maintaining some level of visibility (e.g., communicating your intentions openly, clearly communicating that there are private bits that are aligned with your intentions despite you would not be able to share specifics).

Hiring

Working on open source is cool! You will hopefully have plenty of interested people internally and externally interested in working on your team! Use that to your advantage and find those folks who are passionate about open source and your project, they will push the project forward. There are a few key points that would be worth paying attention to:

• Explain your business goals. Your company is investing in this project, and likewise, you and your team are investing your time in this project for a reason. Explain those in clear terms. It would help you and the candidates a lot to understand goals, expectations, and how they will be evaluated.
• Explain the career trajectory and how you would support them. People will have questions about working on your project, especially if it looks sufficiently different from what the rest of the company does. You need to have concrete answers about how being on this team will not hold them back.
• Do not oversell. Any open-source project in a large company will require doing some non-open-source work. More on this later, but ultimately there will be parts of the project that are not open source like integrations, value-added features, etc. Make sure that people understand this before joining.
• Let your team’s open-source work speak for itself. Since your team is working in the open, you can point to public emails, design documents, code reviews, etc. to show how a member of your team works and interacts typically.
• Critical skills to look for during hiring (in addition to usual technical skills) would be clear written technical communications and an interest in working in the open.

Onboarding

Onboarding is important for any project, and it is true for open-source projects too. You can offer a better onboarding experience for your open-source project by doing:

• Prepare a short doc with getting started resources for your project. This will help you with any project.
• Ideally, some of this would be based on public resources. That way you can share this list with people joining the open-source community (but not with your team) as well!
• A secondary benefit would be that you could share it with candidates (who ask for it) before their official start date.
• Keep a list of shovel-ready starter projects. A wonderful way of onboarding a new person would be to get started with some portion of the project with a well-defined, well-scoped, and not urgent project.
• A secondary benefit of this would be to have projects ready limited time/part-time contributors (e.g., interns)
• If you are onboarding an internal hire, remember that they would not necessarily onboard much faster because they will have to learn a separate set of tools and processes. They might even need to unlearn some of those.

Offboarding

Offboarding could be done like any other project:

• Chat with the person, understand why they are leaving, and make any necessary improvements to the project and the plan.
• Identify a continuity plan, and help the person transition their work to their peers.
• Organize a farewell for people to connect and share messages with their offboarding peers.

However, there will be some extra steps:

• Remember that the team is an open-source community. Make sure that the community also knows about this change so that people who are not on your direct team could also make changes and bid farewell as well.
• Note that the offboarding person might be leaving your direct team, but they are still part of that open-source community, and they are still welcome members of that community. And hopefully, they are going somewhere else, to still work on this project, and expand the project even more.

Performance Management

A large organization will have established processes and metrics for measuring the performance of people. And chances are that those would not have much about contributions to an open-source project or the impact of an open-source project. Even more, your peers who are leading other projects would also not fully understand the nuances enough to measure the performance of your team.

It will be up to you to explain how open-source contributions could be measured against an existing rubric and how to measure the business impact. Ideally, you could do this by writing a short document, updating it regularly, and sharing it with your peers. This document will contain both high-level things (e.g., what is this project, why are we doing it), explain its impact (e.g., how are we helping our organization by working on this project), explain types of contributions (e.g., a list of tools used for contributing code & designs, reviewing those, interacting with users, etc.)

By doing this you will both help your team continue to advance their careers and keep your team an attractive team to work at for internal talent.

What will we cover in the future parts?

So far, we have covered one aspect (people excellence) of leading an open-source project in a large organization. In future posts, we will cover building an excellent community (growing the community, knowledge sharing, funding), excellent technology (e.g., engineering best practices, a frictionless infrastructure, release health), and excellent product (e.g., marketing, event planning, building a product roadmap).

I would love to hear your feedback, thoughts, and comments on this.

I hope you found this information useful! I would love to hear your feedback, thoughts, and comments on this. Please reach out if you have any suggestions for specific areas that could to be covered. Please share if you think this would be useful to others.