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:
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:
Let’s get started with the first task in being able to handle growth, which is being able to measure it.
“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:
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.
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:
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.
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:
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:
If a project is more focused on mature adopters, these goals might be a better focus:
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.
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:
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.
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.
Projects will often set a metric around the number of commits or committers in a project, which takes various forms, such as the following:
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:
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.
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:
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 tends to be one of the more challenging areas to grow in a project, for two reasons:
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:
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.
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:
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.
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:
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:
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:
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:
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.
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:
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.
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,
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:
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.
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.
3.94.202.151