9

Handling Growth

I was recently looking back at the recordings that the Kubernetes project has done of its community meetings since early 2016 (https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ). It’s an interesting exercise to see how a community grows and progresses over time; some things change, but some don’t. We spoke about open source being driven by “scratching one’s own itch,” and the way a community operates reflects exactly that. For Kubernetes, I look at the community meetings as driven by bringing together the large ecosystem for a few key purposes:

• Release, development, and special interest group (SIG) updates
• Demos of projects and work related to Kubernetes
• Shoutouts to specific community members who have made a noticeable impact

Such a simple structure – one that not only reflects the community as being development oriented but also highly appreciative of the work community members do to drive the project forward. It’s also one that is highly scalable because of its simplicity; there is always development and updates going on that are interesting to the larger community, and recognizing great contributors shows the goodwill that brings in more contributors over time.

Open source projects typically start small with a single or maybe a few contributors. If a project is successful, you will quickly see interest from both users and contributors, which can be overwhelming. This chapter will dive into strategies for recognizing and managing that growth, as well as seeing when growth isn’t happening and how to remedy that as well. Specific topics will include the following:

• Measuring growth
• Assessing and remedying low areas of growth
• Growing and scaling project leadership

Let’s get started with the first task in being able to handle growth, which is being able to measure it.

Measuring growth

“You can’t manage what you can’t measure” is a quote you see thrown around quite a bit, and typically attributed to Peter Drucker, the Austrian-born American management consultant, educator, and author. Drucker’s statement holds true, as when you say “I want to improve X,” you need a baseline to build your measurements and then a target to go toward. Let’s say a project wants to get 1,000 commits a year; if that rate is 10 commits a month, there is a ton of work to do. But if it’s 50 commits a month, it’s a much more realistic growth.

On the flip side, Homer Simpson, the father in the long-running sitcom, The Simpsons, stated flippantly in an episode in which he was being interviewed, “Oh Kent, you can use statistics to prove anything; 45% of all people know that!” Simpson calls out a fair point, where you could find the numbers to make any assertion seem plausible. I see this from time to time in projects where they are on the hunt for the right numbers to measure. In open source, there are a ton of numbers to measure:

• Number of commits
• Number of committers
• Lines of code added/changed/removed
• Commits per week/month
• Commits by organization affiliation
• Project downloads
• Number of issues/pull requests created
• and the list goes on...

The CHAOSS project (https://chaoss.community/) is a community that focuses on open source metrics, with the intention of better understanding open source project health. They go quite deep into looking at metrics, focusing on topics such as diversity, equity, and inclusion (DEI) in open source, the impact of events and meetings on community growth, code base evolution over time, the social value of open source projects, and much more. Needless to say, there are numerous ways to measure the health and success of an open source community.

It’s also important to note that not all metrics are created equal. For example, “lines of code added/changed/removed” often isn’t very useful as a metric if you apply code styling rules to a code base or have a large code donation, both of which create a skewed result that might indicate “high code velocity” versus the reality of a one-time touching of a lot of lines of code. “Project downloads” is also a metric I’ve seen skewed, as I’ve heard of cloud providers and sysadmins that, as part of a provisioning script, will pull the code right from the project to ensure its integrity. A project might boast “We’ve had 1,000 downloads a week,” but if 800 of those are from a single client using automated tooling, it’s not the same story as 1,000 downloads from 1,000 different people.

Further, knowing the right metrics you can affect is important. An example project is OpenCore Legacy Patcher (https://github.com/dortania/OpenCore-Legacy-Patcher), which is a tool that enables you to install more recent versions of macOS on Macs that no longer receive OS updates. This project setting a metric around organizational diversity is likely something that they won’t be able to affect; there likely isn’t a vendor willing to support an unsupported macOS installation.

It’s hard to focus on too many metrics at once, as it becomes hard to optimize for metrics that might be too different depending on how you get there. The Rule of 3 is a great construct for goal setting for me, as it intentionally keeps the number of things to measure and manage low, but also helps me prioritize and focus on what is important at a given time. Open source projects adopting the same construct help them focus in the same way. But how do you pick which three metrics to focus on? Here are some suggestions depending on what your priorities are.

Growing awareness of the project

At the awareness stage, the goal is to get as many eyes on the project and see some sort of action being taken based on someone seeing the project for the first time. Here, you want to have a combination of both metrics that show someone coming in contact with the project, and also metrics that look at the next step they would take.

The challenge with this metric goes back to the “Rule of 3” constraint, as you can quickly find a bunch of metrics to go after. While challenging, this can help you focus on the initial journey a user goes through in your project. Let’s look at a basic one that focuses on discovering a project and the steps where you might use it.

Figure 9.1: User flow from code repository to documentation

Here is a pretty basic flow that captures the steps a user would go through in downloading and using a piece of software. It makes the presumption that the validation of the step for the user is them going to the next step; namely, if a user views the code repository and likes what they see, they will download the code. If the user downloads the code and starts using it, they likely will start reading the documentation to understand how to best use it.

In this case, a project could set metrics like this:

1. 1,000 code repository unique visitors in a month
2. 100 code downloads in a month
3. 100 documentation unique visitors in a month.

I’ll note that, often, this progression isn’t completely linear as if there is some complexity to the software, the user might read more about it before actually downloading the code. In this case, the progression would be more like Figure 9.2.

Figure 9.2: User flow to download code or read documentation

Awareness metrics are great starting metrics, but the ultimate goal is to have the project used actively. Let’s look at some example project adoption metrics.

Project adoption

Once someone starts to use a project, the next step is looking at the adoption of the project in some way. In commercial projects, there often will be some sort of telemetry in use that is able to report the number of active users, but for open source projects, that invasiveness is often looked down on. Because of that, a project needs to look more at the actions a user would take once they’ve adopted the software itself. These might include the following:

• Reporting issues
• Asking questions on a mailing list/forum
• Blog posts or conference presentations on the use of the project
• Code contributions back to the project
• Testimonials or case studies about the project being used by someone
• Organization logos or names listed on the project website or in an ADOPTERS file in the code repository

Important note

Note that each of these actions reflects different levels of maturity by the user in their usage of the project. For example, someone using the project early on will likely be reporting issues and asking questions a fair amount. Once they have been using the project for a long period of time, they will be more inclined to be public about it, writing blog posts and testimonials, and indicating they are a user in public forums.

Looking at goal recommendations, if the project is focused on early-stage adopters, these goals might be appropriate:

1. 50 new mailing lists or forums topics per month
2. 20 new issues per month
3. 5 code contributions from new contributors per month

If a project is more focused on mature adopters, these goals might be a better focus:

1. Two blog posts a month from community members about the project’s usage
2. Five testimonials a year made publicly about the project being used by them
3. Two organizations a year publicly saying they are using the project

The last two goals might seem too low, but in my experience, getting someone to identify as a user and advocate publicly for others to use it is a high bar to hit.

Some of the most important metrics to focus on are related to diversity; let’s look at those now.

Project diversity

A diverse project is a sustainable one, as you have individuals from different areas who can help support the project and aren’t reliant on one group of people, one organization, or one region to support your efforts. Diversity is something to think of at the onset of a project, as diversity is shaped by the culture of a project.

When you think about diversity, it has many angles. It could be around aspects of gender, race, age, economic status, or cognitive ability. It can also be more affiliation related, such as employer or nationality. Back to the “Rule of 3,” a project needs to prioritize what is important for growth. Generally, for projects, I tend to recommend the following, as it relates to project diversity. When I use the term “maintainer” in this context, it refers to someone who has permission to allow code to be contributed to a given project:

• No more than 40% of commits from any single organization
• No more than 40% of maintainers from any single organization
• 30% of maintainers from an under-represented group

You’ll note that for the first two organizational diversity metrics, intentionally, the metric is lower than 50%. This means that no single organization has dominance over a project. We saw in Chapter 2, What Makes a Good Open Source Project?, that there is value for multiple organizations – including competitors coming together – in driving an open source project. But just because an organization is invested in an open source project today doesn’t mean they will be forever; I’ve seen organizations change direction, drop products, get acquired, and/or see the market conditions change, only to have them de-invest in the project. If a project can ensure that a company leaving doesn’t mean the majority of people in the project leave as well, it avoids a catastrophic vacuum. That doesn’t mean there won’t be a noticeable impact on the project, but it does mean that the project can continue to function.

For the under-represented group metric, this is important to ensure your project is welcoming to all, as we talked about in Chapter 6, Making Your Project Feel Welcoming. People from under-represented groups will often feel intimidated in engaging in an open source project if they don’t see people like themselves in the project, so having the project intentionally look to have diversity across race, gender, sexual orientation, cognitive ability, age, and more, makes those individuals from under-represented groups more comfortable in taking part in the project.

The metrics highlighted tend to capture the key areas where projects can measure growth: awareness, adoption, and diversity. These key areas are dimensions of how projects measure themselves, though often we see it as a progression – meaning early-stage projects focus on awareness, then projects with awareness begin to look at adoption, and then more established projects look at diversity as it looks to build a diverse and sustainable community. What does a project do when there are areas of growth that are low? Let’s look at this in more depth.

Assessing and remedying low areas of growth

Before we dig into this more, I want to tell all maintainers that it’s perfectly normal to have areas where growth doesn’t hit the targets you are aiming for. Every open source project is a bit different, with different people, priorities, target audiences, industries, and paces of development, and it will tend to be discouraging if you look at your open source project in the same light as something like Node.js or Ruby. Setting goals and metrics is an iterative process, and it is important to re-assess as time progresses to ensure you have the right goals and/or metrics.

Fixing growth issues is quite unique to each specific growth metric. Let’s look at a few metrics that I’ve commonly seen as ones that projects might struggle with and look at some strategies to fix them.

Commits/committers

Projects will often set a metric around the number of commits or committers in a project, which takes various forms, such as the following:

• Number of unique committers
• Number of new contributors in a time period
• Number of commits
• Lines of code added/changed

When these metrics are challenging to achieve, the strategies outlined in Chapter 6, Making Your Project Feel Welcoming, and Chapter 7, Growing Contributors to Maintainers, are typically ones to focus on improving, as the challenge is often related to contributor onboarding and management. Particular areas to focus on include the following:

• Review the contributor guide, ensuring that it’s clear on the expectations and it’s not too overbearing on the contributor where it might discourage simple contributions
• Ensure any contributions are regularly reviewed and responded to, and work with contributors to help bring their contributions in
• Recognize new contributors in release announcements to make them feel welcome and appreciated

Another challenge could be attrition happening among contributors. If a project looks at its contributor list and sees contributors “drifting away,” meaning formerly active ones have stopped contributing, this could be a sign of burnout (a topic we will dig more into in the Avoiding burnout section later in this chapter) or perhaps contributors have changed roles in their organization and the project is no longer relevant to them. Project maintainers should try to reach out to contributors who have drifted away to see what the situation is. Natural attrition happens in open source projects where people ebb and flow as the relevance of the project to them changes over time.

Project usage

Usage metrics can be tricky to measure in open source, as using telemetry is typically discouraged. That all being said, there are metrics that are either leading or lagging indicators of project usage and can be used to help give a sense of project usage, such as the following:

• Downloads or repository clones/forks
• Posts or issues filed regarding using the project
• Blog posts or other social media using the project

Chapter 6, Making Your Project Feel Welcoming, has a number of great recommendations for improving project usage metrics by getting users started and successful quickly with the project. Additionally, a project might consider doing regular surveys of its user base to understand usage patterns and concerns a community might have. One important thing in surveys is to ensure data is collected anonymously, which will help the project get more candid feedback from users. Also, know that with surveys, the most likely people to respond are those with something of concern rather than someone who is perfectly happy with the project. Nonetheless, surveys are a great tool to identify troublesome areas of your project, along with areas where the project is making its users happy.

Diversity

Diversity tends to be one of the more challenging areas to grow in a project, for two reasons:

• It tends to push project maintainers to bring in people not like them
• People that aren’t like the project maintainers will often find participating in the project intimidating

Growing diversity in a project doesn’t typically happen by happenstance but is by intentional work of the project maintainers. Here are a few strategies to look at in improving diversity:

• Finding individuals already in your project community that come from under-represented backgrounds, and supporting and encouraging them. This can be as simple as sending them a note to thank them for their contributions, or perhaps bringing them to an event or meetup to speak about them using the project. Seeing you as an ally will help them feel confident, and then they will be able to bring others in based on their positive experience.
• Ensure your project has a Code of Conduct in place, as we discussed in Chapter 8, Dealing with Conflict. This is a great outward sign that the project cares about having an inclusive community.
• Look to grow diverse contributors into maintainers using the strategies outlined in Chapter 7, Growing Contributors to Maintainers. When people see project leadership as diverse, they will quickly tell that the project is diverse at its core and will be more likely to want to participate.

Tip

I encourage you to check out both the All In initiative (https://allinopensource.org/) as well as the Software Developer Diversity Initiative (https://sddiproject.org) for deeper insights and strategies to improve project diversity.

To be able to grow, the project itself needs to scale but project leadership also needs to have a plan for growth and succession. Scaling leadership is an important factor in growing a project and being able to support it long-term. Let’s dig more into this topic.

Growing and scaling project leadership

Being a maintainer and a project leader is most often very rewarding, giving the person a chance to showcase their talents and skills while being able to make an impact on others globally. But at the same time, it can be quite stressful, as we saw in Chapter 8, Dealing with Conflict. I did a cursory search and came up with several stories about the stress a maintainer takes on:

• Being ridiculed for your open source project (https://harthur.wordpress.com/2013/01/24/771/)
• Maintainers hitting their breaking point and quitting or even sabotaging their own projects (https://www.businessinsider.com/open-source-developers-burnout-low-pay-internet-2022-3)
• Stress on how to say no to a feature request (https://news.ycombinator.com/item?id=32366248)

There is a similar pattern I’ve seen in early-stage start-ups, where you see founders taking on a number of roles from sales to marketing to product development, and roles such as “growth hacker,” which, at scale, are completely unsustainable. Most often, this is unintentional, as the level of excitement and dedication grows to such a point where those founders are blind to the number of hours they are putting into their growing company and the impact it is having on them. Open source projects, as they are most often the “scratch-your-own-itch” for the maintainer, fall into the same trap.

We talked a fair amount about identifying potential maintainers and growing them into that role in Chapter 7, Growing Contributors to Maintainers, so I won’t repeat much of what was discussed there. Instead, let’s look at how to take an existing group of maintainers and how to scale them across a project.

From project generalists to project specialists

In the early days of a project, it can be a bit of “all hands on deck” as everyone tends to do a lot of everything. And in those early days, it tends to work out OK; many open source project maintainers tend to have skills that are more than just being a pure software developer. Many open source projects target software developers, which are the same persona as the maintainers, so it’s easy for them to relate to their users. And having that tight connection between the maintainers and users helps push a tighter feedback loop from how users are using the project to the direction maintainers should guide the project toward. Thus, having a maintainer leading activities such as outreach, events, and support tends to make a fair amount of sense.

That being said, the project will often get to the point where you see the following situations occurring:

1. The demands of the project become so high that maintainers lack the time to properly devote themselves to a specific area
2. The skills needed to level up areas of the project aren’t primary skills for the maintainers, and thus, while they are getting done, they aren’t done well

It’s a hard thing for a maintainer to recognize and acknowledge the preceding situations happening, especially the second one, where a maintainer needs to see the areas in which they aren’t as strong. But even recognizing the demands can be challenging, and most of the time, it’s in the area where a maintainer doesn’t realize how much time they are spending on a task or duty that someone else could do better or more efficiently.

This came up in a project I’ve worked on (I’ll leave the name of the project out). The maintainers were solid, taking the role seriously, and were doing a great job in managing the various processes, including the release cadence. But the problem they kept having was the barrier to entry to contribute to the project was quite high, and they were struggling to convert contributors to maintainers.

One part of the challenge was related to the missing mentorship and contributor development strategies we talked about in Chapter 7, Growing Contributors to Maintainers. But a larger issue was that the maintainers were so overwhelmed that they couldn’t see how to make the time to develop contributors into maintainers. They saw the barrier to entry for being a contributor and realized they would have to spend too much time developing contributors, so much so that the other areas of the project, which were more important in their view, would suffer.

As I sat down with the project and broke down their challenges and opportunities, a few things emerged:

• There weren’t great ways for new users and developers to “self-enable” themselves for the project, meaning there weren’t great documentation or training materials. When materials like this were needed, they were largely re-created each time and not recorded or repurposed.
• Maintainers tended to hold similar leadership roles in related projects, which was leading to burnout for them.
• The maintainers would pragmatically tend to manage any participation at industry events, including running meetups, preparing presentations, doing social outreach, and coordinating with event managers. The number of events kept growing for the project, which again was taking away from the time the maintainers could spend in the code base.
• Maintainers were manually managing contributor license agreements (CLAs), sending out paperwork to each maintainer, and then having to manually cross-reference on the CLA signee list for each new contribution.

You could sum up this as the classic “focusing on the short-term pains versus long-term opportunities,” meaning the maintainers saw the needs of today and focused on knocking them out, while not looking at larger ways to improve efficiencies and bring in new resources to help.

There were a few things we did quickly with the project that started to help out:

1. First, we implemented a tool similar to CLA Assistant (https://cla-assistant.io/) to handle CLA management. This was a quick win and even helped catch a few areas where there were contributions being made and the CLA wasn’t in place correctly.
2. Then, we built out a list of the various events for the project, and what participation should look like for each (just a presentation, organizing a meetup, or actually sponsoring the event).
3. Next, I worked with each of the maintainers to understand their responsibilities outside of the project, both to other projects and their employers.

There were some immediate results, but the pain wasn’t fully eliminated by a long shot. The next level was to bring in new resources to help in areas where the maintainers could use support but didn’t need a maintainer’s expertise to accomplish. Here’s where we focused:

• We worked to find a technical documentation writer leveraging the Write the Docs community (https://www.writethedocs.org/). One of the maintainer’s employers stepped up to fund this resource.
• One of the maintainers had a friend who was looking for some experience doing social media and blogging outreach for a university class requirement and got them connected to help do outreach for the project. They stepped in to maintain the event list we created, and then put together a simple plan on how to do promotion before and recaps after the event, leading much of the writing.
• We took one of the recent presentations on the project, cleaned it up some to make it more generic, and then recorded someone presenting the materials to make it an introductory training.

The results took a bit of time, as it required the maintainers to pause some of the project development to get these new resources involved, but after about 6 months, maintainers were already seeing how much less stress they had and the value these specialists brought to the project. It was also great for the technical writer and the intern on outreach, as both got jobs with the employers of one of the maintainers (and that employer ensured they had time to still contribute to the project). This is a great part about getting involved in open source, which can help get your work in front of potential employers; we will chat more about this in Chapter 11, Open Source and the Talent Ecosystem.

One of the things found in this story was a solution to help maintainers balance their time across other priorities. Let’s dig more into that as we focus on maximizing time and managing expectations.

Managing time and expectations

Time management is also expectation management, meaning being able to set expectations of what can be done, by when, and what is needed to complete a task. This is where the phrase “bite off more than you can chew” comes into focus, because often, what seems simple becomes more complex as you dig into it. This could be a simple bug fix that highlights larger architectural problems in the code base or maybe responding to support requests and issues that become more time-consuming. For a maintainer, this could manifest itself as too many meetings, too many requests to present or speak about the project at events, or too many pull requests or code contributions to review.

Scaling is not just adding more resources but also working more effectively. Many in the software development field will reference Fred Brook’s book The Mythical Man-Month: Essays on Software Engineering, in which the central tenet is the idea that adding manpower to a software project that is behind schedule delays it even longer. I’ve seen with projects that the problem isn’t not having enough people involved but more with streamlining work and setting expectations.

Strategies for scaling and setting expectations include the following:

• Set boundaries for how much time you will dedicate to a task. For example, state that you will only dedicate an hour a day to triaging pull requests and issues.
• When the amount of time dedicated to a task appears to be not enough, assess why. It could be for several reasons:
  • What is needed is too tedious. For the example of the pull request and issue triaging, maybe the system being used isn’t well set up and could be improved.
  • Are there better ways to accomplish the task? For issues requests, maybe if you are seeing the same issue over and over, there should be documentation added and the user directed towards that first. Or maybe common issues should be linked together. If the task is around preparing for a meetup, perhaps making a standard template for everything needing to be done would help streamline things.
  • Do you just need more resources or a dedicated resource? Perhaps instead of a maintainer doing issue triaging, there should be a dedicated person doing the triaging who can bring in a maintainer when they have questions.
• Communicate the expected timeframe for when a task should be done. For issue triaging, this might be saying that all issues will be reviewed within 5 days.

Communication is key with open source projects – being as transparent and honest as possible can often build stronger bonds and trust between maintainers, contributors, and users. Looking at the aforementioned OpenCore Legacy Patcher project (https://github.com/dortania/OpenCore-Legacy-Patcher), the primary maintainer had a family based in Ukraine. This maintainer knew he couldn’t support users for the time being as he needed to tend to his family due to the outbreak of war, so he opened an issue to explain the situation.

Figure 9.3: OpenCore Legacy Patcher maintainer indicating new issues will be temporarily closed (https://github.com/dortania/OpenCore-Legacy-Patcher/issues/985)

This maintainer did a great job of explaining his situation and setting expectations well. And as it turned out, the pause was fairly temporary as the project cadence continued a few months later once his family situation was settled.

The risk of not managing time well is burnout; let’s look more at what burnout is and ways for a maintainer to avoid it.

Avoiding burnout

The articles I linked to at the beginning of this section point to a theme that, at the time of this writing, is one of the hot topics in open source: burnout. Burnout is often what we see, but in reality, it’s the last step in a larger continuum of stress that isn’t well managed by a project maintainer.

Figure 9.4: Burnout continuum

If you look at the continuum outlined in Figure 9.4, you can probably resonate with some of the stages/symptoms outlined. We’ve all been tired after a long stretch of work. Sometimes, the work we do becomes so much that we never think it’s enough. Forcing yourself to sit down and concentrate can be a challenge when you have multiple other priorities to balance with both other work roles and also family and personal priorities.

There’s a story from the great Pat Riley, who was a longtime NBA head coach and general manager, where he talks about a whitewater rafting trip he once went on. As part of the safety instructions they gave the group prior to getting in the raft, the instructor said,

“If you fall into the water, you can’t just sit there in the water and hope someone comes to rescue you; you need to let the others know you fell out of the boat and try to swim back. You need to be an active participant in your own rescue.”

That last statement rings true, as it’s hard for other maintainers to often see the stress a maintainer is under and find ways to help.

So, what can a maintainer do to help themselves avoid burnout? Here are some suggestions:

• Use a task management system for capturing all the things you need to do. I’d suggest having one specific to the project itself, but also one for other areas of work and also for your personal/family to-dos. As we get older, it’s hard to keep it all in our heads, but writing things down can also help us visualize what needs to be done.
• With a task management system, use some sort of system to help prioritize or schedule items. I like to put in dates for tasks to do, as this gives me a way to pace my work and know what needs to be focused on at a given time.
• Schedule downtime throughout the day, and stick to it. I try to block out 5:00 p.m. to 9:00 p.m. each day for family activities, limiting any work emails or meetings. Similarly, taking a midday break is important.
• Use weekends as much as possible for recouping, and not work. I try to keep work on projects to just a few hours in the morning before the rest of my family gets going for the day, and then step away from things for the day.
• Schedule holidays and vacations, and then actually use them for rest and recouping as well and not for working on that one project feature you’ve wanted to fix.
• Ensure you are eating well and getting proper sleep and exercise. Fatigue, illness, and anxiety, are all symptoms of not taking care of your health.
• Find activities outside of the project that brings enjoyment. This might be a sport (I ski, kayak, and bike), volunteering or other work (for me, this is volleyball officiating), spending time with friends and family, or hobbies. It’s important that it’s different from what you do daily, so taking on a new open source project isn’t a really good hobby; doing something entirely different such as woodworking or cooking is.
• Get regular health checkups. For those of us in areas of the world with great healthcare systems available to us, we are often the worst about actually using them. Schedule at least a yearly physical checkup.
• When you hit a mental roadblock, walk away for a while and do something different. Maybe read a book, play a game, or go for a walk. Or even chat with someone about it. Changing mental perspectives helps get past mental roadblocks.

You’ll probably note that most of this advice isn’t specific to open source but to life in general. It’s easy for any part of your life to be consuming, and when it becomes consuming, that is when the symptoms in the burnout continuum in Figure 9.4 start to present themselves.

Summary

This chapter focused on how to handle growth in an open source project, both in the realm of setting good metrics to measure growth and also ensuring the project leadership can scale alongside this growth. Too often, projects that could become great projects are crushed under their own weight, and staying ahead of that ensures a project can become sustainable for the long term.

When a project is viewed as sustainable, organizations look to invest and adopt it for their own internal use as well as build it into their own products. Commercialization might be viewed as an anti-pattern to open source, but in reality, it’s a validation that the project has value. In the next chapter, we will look at how projects can best manage commercialization.