It is challenging to build successful open-source teams inside traditional and large organizations. This challenge stems from major differences between organizational processes, business goals, and the personal career goals of the people involved. In this case, your task as an engineering leader would be to harmonize these different forces and build a thriving team.

Getting started on this journey may seem an intimidating task. Tolstoy famously wrote, “All happy families are alike; each unhappy family is unhappy in its own way.” This quote applies well to the software teams as well. Focusing on three key areas will help you build a solid foundation for your project, these are:

• People: talented folks sharing a common vision towards building a great product.
• Technology: a modern infrastructure enabling people to rapidly deliver a high-quality product
• Product: an impactful product that solves customer’s problems, and delivers business value.

In practice, you might face issues with hiring and motivating people to work on this niche open-source corner you are creating in your organization, building a technical foundation with a mixture of open-source tools without relying on the infrastructure you are used to, or creating a product that deliver business value while maintaining open-source ideals. Finding ways to overcome these challenges ensures a successfully-led open-source initiative.  

Building out a strong open-source team and culture 

Your goal as an engineering leader is to attract talented people to your team and support them throughout their journey. This still holds true for an open-source project. However, there are some key differences. 

The team for an open-source project has both internal and external engineers contributing to it. Open-source projects differ from internal ones as there isn’t a unified managerial hierarchy i.e., engineer, tech lead, engineering manager, senior engineering manager, you can rely on. Often, this means that those internal peers default to thinking of themselves as the “core team”, meaning that those who fall outside of the org aren’t.

Establishing and defining the team

To combat an “us” and “them” mentality, set out to accurately define each team member’s role and responsibilities. You can achieve this by increasing the collaboration and transparency between all the developers working on this project. This might require some cultural changes and nudges. For example:

• You want important tools and infrastructure to be accessible to all contributors. You could remind everyone to use openly available tools such as publicly accessible code repositories, review tools, and issue trackers. 
• Avoid a throw-it-over-the-wall culture where important decisions are made by a group of people and shared with the rest of the team after the fact. You can ask for all decisions, documents, and discussions to be shared in their initial stages openly.

Bringing on new talent 

Bringing on new talent is one of the most important aspects of building an impactful team. You will need to build strategies for attracting external contributors to the project at large and internal company-members. 

Critical skills to look for in potential team members, aside from technical skills, would be clearly written technical communications and an interest in performing their work in the open. Luckily, many folks are passionate about open-source, and you can use that to your advantage to grow your open-source team. Consider the following key points when looking to build out your team:

• Explain your business goals publicly and clearly. Your company, your team, and you are investing your time in this project for a reason. Transparency is highly valued among open-source participants. And that information would help candidates understand your goals, expectations, and the project’s direction.
• Explain how a candidate’s career trajectory may develop as part of the team and how you would support them. This will especially help with internal hires who only have experience on company-wide projects. You need to have concrete answers about how being on this team will propel them in the direction they want.
• Do not oversell. Any open-source project in a large company will require doing some non-open-source work. Make sure that people understand this before joining. This will filter out some folks, but it will prevent future frustrations.
• Let your team’s open-source work speak for itself. Since your team is working in the open already, you can point to those artifacts in your blog posts, conference presentations, and other public-facing materials. By doing this, you can show the inner workings and the culture of your team to potential candidates and future members of your team.

Supporting and motivating the people on the team 

In order to build a sustainable team and ensure the long-term success of your project you need to effectively encourage and support your reports. As an engineering leader, you will already have these skills; however, you will need to think about how you can apply them to the new definition of your team. For example, onboarding, offboarding, and mentoring are typical processes for healthy projects – but you will need to “think bigger” about the broader project when establishing these usual processes. Find ways to make resources public and easily accessible to the larger community rather than building processes that only cater to internal members.

Ensuring high-quality and efficient performance 

Performance management is a critical process you need to address as well. Open-source communities will hardly ever offer performance processes you can utilize. 

On the other hand, large organizations will have established processes and metrics that are unlikely to take open-source projects into account. 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. By doing this, your reports will be able to continue to advance their careers, and your team will speak for itself as an attractive place to work for internal talent looking for new opportunities.

Ensuring high-quality technology on open-source projects

Large organizations provide a plethora of resources to boost productivity and job satisfaction. These will come in the form of frustration-free infrastructure, testing framework, design guidelines, etc. Unfortunately, most of these will be tuned for internal usage and will not apply to your project well. 

The open-source ecosystem will offer plenty of options to fill in that gap in the form of openly available tools and frameworks. However, you will also find out that creating a coherent and easy-to-use technical environment that will support both your external contributors and internal developers will be quite hard to build.

The good news is that you can start from the foundational principles and pragmatically use internal and open-source components in a harmonious way to build a solid technical bedrock for your project.

A baseline of engineering practices 

The first step towards building excellent technologies is establishing consensus on engineering practices. This is the most important step because it will guide the next set of actions and also determine the team’s long-term productivity levels. 

For these practices to be effective, it is critical for the whole community to agree on them. Keeping these “ground rules” simple and small would allow you to build consensus faster, evolve them over time as needed with ease, and be flexible in implementing them. For example, you could include things like doing code reviews (not always a standard in open-source), writing design documents for larger features, having a functioning testing infrastructure, and having service and release health practices.

Make internal and external team relations streamlined

Reduce the friction between internal and external environments by investing in automation as much as possible, as early as possible. Inevitably, your internal team will have to integrate with some internal-only technologies as well. It will be necessary to perform manual work to keep both environments in sync, and cruft will accumulate as engineers strive to support both. This is a tax that open-source projects in large organizations need to pay, and you can significantly reduce its impact by an upfront investment to:

• Eliminate the differences between two environments by reducing the number of tools you are using or by using the same tools on both sides.
• Automating the remainder of the work to minimize manual work involved.
• Prepare for the unexpected. There will be processes that cannot be automated (e.g., a security vulnerability). Incentivize your team to perform this work by allocating enough time in your plans and recognizing the team for doing that essential work.

Continuous improvement 

Monitoring and continuously improving technical infrastructure and processes should be a stable part of your project. You can achieve this over time by setting up metrics in advance when you are establishing the infrastructure and leading blameless post-mortems after failures. You can also invest time into making those improvements by using a standard post-mortem template, a meeting with a regular cadence to review recent failures, and tracking the progress of previously identified improvements. A good set of initial metrics would cover product health (e.g., release frequency, production issues), technical health (e.g., percentage of test flakes, test coverage, time to run tests), and community health (e.g., average time for code reviews, levels of information sharing).

Building an excellent product

Building an impactful product, helping users solve their problems, and delivering business value, are the core reasons a large organization invests in any project. Having a product vision, a feasible product roadmap, and showcasing your product’s value to users while supporting them are all equally important for an open-source project. 

You might face two obstacles when working in the intersection of open source and a large organization: a product without a clear focus, and roadblocks preventing non-code contributors from supporting your product. The right approach will help lessen or mitigate these hurdles. 

Building the product infrastructure 

Open-source projects mostly consist of code contributors. With so many individuals working on things, undoubtedly with different perspectives, there might be a gap in thinking about the product infrastructure. Even for projects that started with a great strategy, without dedicated attention, entropy will take its toll, and eventually, they will end up with an obsolete and cluttered roadmap. Additionally, folks might be hesitant to lean into the area of defining the product and clarifying its focus as they might perceive a contribution to the product roadmap as an example of top-down decision-making, as opposed to the bottom-up feature-driven structure expected in an open community. 

You can overcome this potential obstacle by setting an example and defining the product yourself, then inviting the rest of the folks to join the effort. Leading by example will demonstrate the value and convince others to help you as well. You can achieve this by opening the floor for the team to participate in early versions of roadmaps, or by starting a new user support channel. You can also build processes to gradually improve the product infrastructure over time through, for example, annual roadmap updates that steer the direction of your product. You can also introduce a rewards system for engineers who participate in support channels to increase customer satisfaction.

Get all the help you need to grow your product 

In a large organization, it’s only natural that your path will cross with other individuals in other departments such as sales, marketing, support, and user research. Those people would not necessarily know how to contribute to an open-source project or may even think that code contributors are the only ones necessary in such projects. It is your chance to explain to them:

• They could add lots of value to your project, and trailblaze in this new and less crowded space.
• They will be recognized and rewarded for their work internally and externally.
• They will get a chance to show their creativity, by experimenting with you in a non-corporate, off-brand, and open-source domain. You can collaborate on fun projects like building a new blog, and starting a new conference for your open-source project.

Iterate on the product strategy over time 

Identify a small set of business metrics that will be important to your organization, such as revenue, usage, or customer count, and identify the best proxy metrics you can track without compromising user privacy (e.g, download counts or number of questions on support channels). Tracking this information will allow you to show the impact of your project to the stakeholders and also help you shift your strategy incrementally to find the right product market fit.

Final thoughts 

The principles for successfully leading an open-source project inside a large organization are similar to any other project. However, there will be major differences stemming from organizational and cultural norms between the two environments. You will need to think about strategies for creating a harmonious environment. Implement those strategies using both the open-source and corporate resources available to you. Then, you will reach the goal of a unified team of talented people, with the support of a solid technical foundation, delivering an excellent product.

Opinions expressed are solely my own and do not express the views or opinions of my employer.