2

What Makes a Good Open Source Project?

We talked in Chapter 1, The Whats and Whys of Open Source, about the whats and whys of open source and looked a bit at the how in the context of existing open source projects. In this chapter, we will look at what makes a good open source project. We will look at some of the key characteristics of what a good open source project looks like, some of the pitfalls I’ve seen when open source projects aren’t created with the idea of building community, and, finally, some patterns and anti-patterns for open source projects.

The concept of a good open source project is by no means a trivial one. I get asked this question routinely, usually in a conversation that goes something like this:

Person: “So, how does my project compare to other projects you work with?”

Me: “Well, that’s a hard comparison to make.”

Person: “Why is that?”

Me: “Each project is different; different work being done, different participants, different velocity of development, and so on.”

Person: “So, how do I know whether it’s a good project?”

I’ll pause this dialog to not tip my hand too much on how to answer the what makes a good open source project? question, but I do want to highlight that it’s not a cut-and-dry answer.

We’ll cover the following topics in this chapter:

• The core characteristics of an open source project
• Open sourcing code versus creating an open source project
• Patterns and anti-patterns for successful open source projects

Before we dig into what that good open source project looks like, let’s back things up and correctly characterize what an open source project is.

Core characteristics of an open source project.

Early on in the free software movement, the characteristics of a project being open were simply tied to the licensing aspect of the code – is it under a license where one could see, modify, and distribute the code or not? At that time, that was novel in and of itself; recall from Chapter 1, The Whats and Whys of Open Source, the main challenge was proprietary software growth being antithetical to a hacker and maker culture.

I reread The Cathedral and the Bazaar [1] as I was writing this chapter, and when I did, I could sense the aha moment that Eric Raymond had as he looked at the early development of Linux. A given piece of software, in general, up to that point, was developed by a single developer or a small circle of developers, carefully built and aligned with what you would think of today as obsessive-compulsive tendencies; carefully constructed code, nothing other than perfected code released, and while feedback was appreciated, code contributions were under a lot of scrutiny.

Before you look at this with ire, consider the time and place. Much of software development was still heavily academically rooted. The tools were still out of reach for many due to the hardware being quite expensive (in 1990, the average cost was nearly USD 4,000, adjusted for inflation [2]). Picking up programming wasn’t something you could do in a six-week boot camp; it was years of post-secondary schooling. You can’t blame the early project maintainers for the approach that they took; it was largely pragmatic, and many of those projects are the cornerstones of free and open source software today.

However, Raymond saw something novel in how Linus Torvalds approached Linux, namely the following:

• It wasn’t all code he wrote from the ground up; instead, there was a fair amount of code borrowed from Minix (along with concepts and ideas)
• The first version of Linux released was effectively beta-quality code
• He openly encouraged others to give feedback and participate in the work

If you look at Torvald’s post announcing Linux on 25 August 1991, you can see his humility in approaching the community. If you look at some of the most popular open source projects today, they model the approach Linus took intentionally with Linux; Linux is looked at as one of the best examples of what an open source project is. What are those characteristics? We’ll look at them in the following sections.

Users are part of the development process

This is something we’ll dive deeper into in later chapters when we talk about roles in open source, but one thing that is evident with open source is the intention for users to have a path to be part of the development process.

Recall the anecdote I shared in the previous chapter about the car’s sealed-shut hood, making it nearly impossible to see or modify its internals. Without that constriction, the user can now learn more about the car, how it works, where some of the weak points of the design are, and areas where an upgrade might be easy to do versus others where it will be more complicated.

This is something you see quite often in car enthusiast groups; one I have an interest in is the enthusiasts around the Buick Grand National. The peak years for this vehicle were 1986 and 1987 (and the drivetrain was used in the 1989 Pontiac Trans Am Pace Car). In the years since, we saw the enthusiast community take the vehicle much farther than General Motors intended. They saw the air intake as limiting, so they added larger air intake systems. They saw the possibility of larger turbos, injectors, and exhaust systems and built them to fit. Now, they are making the car modifiable to the new fuel types, with many converting the car from using 93 octane fuel to E85. All of this was driven by real-world requirements, whether that be performance, adaption to modern needs, or just general technological improvements, and those were made involving those who owned the cars, as well as the vendors and mechanics.

There’s a saying in open source that says, a rising tide lifts all boats, which is evident in the user’s involvement in the development process. While it seems obvious from where we are sitting, the idea that there would be new ideas beyond the core developers was a bit novel at the time, but encapsulates exactly how Torvalds approached Linux and what we continue to see decades later.

Release early, release often

Getting users involved in the development process requires a way for users to be able to get involved. Generally, in open source projects, individuals start as observers (or what some might call lurkers, but let’s keep things positive). These individuals are often thinking less about being a contributor and more about whether the project will be useful to them, asking questions such as, does it solve my problem? How does it compare to other solutions? How would I get started? Over time, they progress to being a user, then someone interacting on mailing lists and forums. However, as discussed previously, in an open source project, the intention is not to keep the user far away from the development process but instead to see how they could integrate into the process.

In the work I currently do with open source projects, I often help set up their code repositories. One invaluable tool for me has been repolinter (https://github.com/todogroup/repolinter), which is a tool that checks your code repository for common issues, such as finding missing license files, ensuring there is a contributing guide, and alerting you if there were any build artifacts (such as binary files, test files, or build logs) that were accidentally checked in.

When using the tool, I found a bug with how it detected pull requests and issue templates. The tool did great if you used a single file, ISSUE_TEMPLATE or PULL_REQUEST_TEMPLATE, but GitHub also had support for adding multiple templates if you named the directory ISSUE_TEMPLATE or PULL_REQUEST_TEMPLATE, and the repolinter tool didn’t recognize that. This being an open source project, I was easily empowered by the project to not only submit a bug report but also a guide on how to fix it:

Figure 2.1 – Pull request against repolinter (https://github.com/todogroup/repolinter/pull/186)

Quickly, a project maintainer looked at the pull request and approved it coming in, and that fix made it into the 0.10.0 release [3].

This is the exact model and rationale behind “release early, release often.” The project, having version numbers starting with 0., was still in active development, and features needed to be added. Regular releases in that timeframe that rolled up the fixes coming in got into the hands of users quickly for them to try out. Additionally, a user could pull a version right out of the code repository at the given point in the main branch (at that time, named master, although it is now named main) to start trying it right away (which is exactly what I did). This enabled the feedback loop to move faster, as users could test these features before a release and potentially catch edge cases and other hard-to-reproduce issues that come out of extensive testing; fortunately, my contribution was quite simple, so there weren’t any.

We will dig into users becoming contributors in later chapters as we talk about making a project feel welcoming and contributors becoming maintainers, but know that the cornerstone for this is a development model that empowers and encourages users to take part.

Transparent and dynamic decision-making

One unintentional trend I often see in groups outside of open source that I work with is it’s hard to understand how the group works and where you can take part. I say unintentional because when I talk to those leading or taking part in those groups, they will often lament that others don’t want to join or help the group or that the questions they get about the group from outsiders are often basic ones that they answer with, “well, everyone knows that!”

As I write this book, I’m volunteering to lead our local school district’s school levy campaign, where the goal is to renew an income tax levy, which is a major revenue source for the school district’s operating budget. One of the frustrations that school administrators and those volunteering in the levy campaign have is the vast amount of disinformation out there; one particular piece of disinformation relates to the funding of the turf installed on the football field. Questions arose about why this was funded over other projects, which is a fair one to ask. With a void of what I call intentional transparency, many rumors have started that spread false information, such as “this town only likes football and nothing else” or “the school board doesn’t know how to spend money.”

The truth was that the old field was in really bad shape, borderline unsafe to play any sports on, and when weighing up the options of repairing and maintaining the field versus going with turf, they saw turf as the better solution going forward. Additionally, going with turf made it possible to host more events on the field during the times of the year when the ground would be wetter, thus a greater revenue opportunity. It was also not just funded by the school district but also by private sources and fundraising done by the athletic boosters. Not to mention when a new school was constructed a few years prior, part of that new building included a state-of-the-art performing arts center, which to this day hasn’t hosted an athletic competition.

The school board felt they had been transparent because all of this kind of decision-making happens in public meetings and the finances are made public, but there was a lack of intentionality in sharing the background on why the choices were made.

Open source projects thrive on both intentional transparency but also the ability to quickly and dynamically make decisions, which typically results in a higher development velocity and vibrancy around the project in general. Good open source projects focus on these aspects, typically with a strong written culture in writing down all the processes in the project, such as how releases happen, what is required to make a code contribution, and how decisions are generally made.

Good open source projects also make all of the past discussions available and make current discussions transparent so that others can see how decisions are being made; for them, it lets them have a sense of the culture and dynamics of the group and impacts whether they might want to get more involved in the project in the future. We will dig more into these concepts in Chapter 5, Chapter 6, and Chapter 7.

While open source projects can be a mechanism for driving collaboration and innovation, we’ve also seen them as a way to push out code without an intention to build community. Let’s look more at the expectations you should have when releasing code as open source.

Open sourcing code versus creating an open source project

The release of the NetSuite Communicator source code was the validation of the bazaar model that Raymond described. While that started the tidal wave of open source, as with any new trend, you see those pushing the edges of the trend to see what works and what doesn’t.

One particular trend is companies seeing open sourcing code as a method for making source code available, but not necessarily wanting to build an open source project around it, as described in the previous section. This is an important distinction, and while in general, it isn’t a great open source strategy, there are some cases where it is worth discussing. Let’s look at them now.

Intelligent code dumps

You might have heard of the term code dump, which refers to when code that might have previously been a commercial product or otherwise not open is made available under an open source license, but the group contributing the code has no intention of maintaining it, let alone building a project or community around it. I’ve seen companies using this strategy over the years that have the thought “if we release the code, people will come and build a project around it,” which has rarely been the case.

That being said, there are some edge cases where it’s not such a bad thing, such as when Microsoft open sourced the source code from MS-DOS v1.25 and MS-DOS v2.0 [4]; the rationale was more to enable research into operating systems and enable various retro-computing communities to support running older software on newer hardware and operating systems better. This is what is called an “intelligent code dump,” as is quite useful if it is done for these reasons, in addition to any of these:

• Enabling companies who use older versions of the software that you no longer support to continue to support themselves
• Allowing others to build converters or connectors using obsolete file formats
• Showing goodwill by making software that is obsolete available for hobbyists and enthusiasts in the community

One thing important for an “intelligent code dump” is to be super clear about the intentions in the README file for the project. This has been done quite well by Microsoft in the release of the MS-DOS source code, as illustrated in Figure 2.2:

Figure 2.2 – README.md for the MS-DOS source code release (https://github.com/microsoft/ms-dos)

Sometimes, releasing open source code but not creating an open source project doesn’t just apply to obsolete software but also to current software that hopes to gain a larger user base. Let’s look at that use case now.

Open Core

One early business model of open source was called Open Core, meaning that a company releases a basic, stripped-down, yet functional version of the product as open source and then a more full-featured version as a commercial product under a proprietary license. This was an extension of the shareware model that started in the 1990s (also known as nagware because of the annoying popups that urged users to pay for a commercial version). You can see parallels with the code dump approach in that the code going out into open source is not where development is happening; instead, releases are dumped to the community for consumption. Often, you can contribute to these Open Core projects, but it typically is quite difficult, as the patches have to be incorporated into internal development.

Open Core as a model hit its high-water mark in the late 2000s. One particular software company that chose this approach was SugarCRM; they owned Sugar Community Edition, which in itself was a full-featured open source CRM (something new and exciting on the market at that time), and then Sugar Professional and Sugar Enterprise, which were commercially licensed versions, although the source code was made available to customers. For SugarCRM and companies such as this, the idea was growing a market share – that is, getting as many users as possible, with the strategy that as the use of the software grew in an organization, they would look at one of the commercial versions.

Many in open source viewed the concept of Open Core as a bit of a black eye in history, and frankly, there are valid arguments for why you would view Open Core that way. I’ve always looked at the trends in both technology and life, and seen that they often follow the pattern of a pendulum; swinging from one side to another and eventually coming to rest somewhere in the middle after lessons have been learned and experiences gained. Open Core came about as open source business models were still being developed, and you see some later open source companies who have led projects in open source, often within a vendor-neutral foundation, regarding the concept of downstream ecosystem building as an evolved way to help solve the monetization question.

Expectations when releasing code as open source

One thing that came to light as Open Core went through its life cycle is that open source has an ethical responsibility to downstream users and developers. The TODO Group, which is a project hosted at the Linux Foundation that provides a forum for collaboration around Open Source Program Offices (OSPOs), offers a great resource. This resource is their OSPO guides [5], which walk through the various aspects of being effective in participating in open source as an organization.

One guide in particular focuses on starting open source projects as an organization [6], which speaks not only to the responsibilities and due diligence an organization needs to bear in mind to release an open source project (much of which we will cover in Chapter 4, Aligning the Business Value of Open Source for Your Employer) but also, toward the end, to the post-release responsibility. Some key considerations include the following:

• Get other outside organizations and people with an interest in contributing or participating involved as early as possible. You’ll want them to feel like part of the process and letting them contribute to governance, development standards, and marketing/outreach activities starts to build the comradery that sets the cultural tone in the community early.
• Get the collaboration infrastructure set up and out in the open. Things such as mailing lists, chat channels, code repositories, and issue trackers out in the open give people a sense of the activity of the project and the culture around it. Beyond that, having social media accounts engages a broader audience of more casual individuals that might track things from a distance and will inspire them to get involved in the future.
• Hold community meetings at a regular cadence, and also look for natural opportunities to meet, such as a part of an event or through local meetups. I really, really, emphasize the regular cadence part – this not only sets expectations for your community but also for you as a maintainer to keep these things at the forefront of your mind.

Again, much of this we will cover in later chapters, but the key thing to think about here is that putting out an open source project means you need to be intentional in supporting its success. This investment upfront will very likely be high, even higher than it was as an internal, non-open source project, but done right, that investment pays off and you will reap the rewards of lower investment and amazing technology that you can leverage (and others can too!).

Patterns and anti-patterns for successful open source projects

I started this chapter by ruminating on the challenge of defining what a good open source project is. The challenge with that definition is what works for one project may not work for the next one, as each project has its own people, culture, industry dynamics, and velocity. Because of this, I like to think in terms of patterns instead, and there are several patterns (and anti-patterns) I’ve seen that are good guideposts and ways to think about open source projects and how to approach and work with such a community.

Open communication (and over-communication)

The biggest challenge I see with open source projects, and often in other domains in life, is communication. As I described in my earlier story on my work in my local school district’s levy campaign, communication gaps lead to confusion, misunderstanding, and in the worst case, things being taken the wrong way. I often hear the saying that “if you don’t define yourself on the market, the market will gladly do that for you.” Open source projects are no different and require the same intentionality.

One challenge I often see with communication comes from those in a project being frustrated that someone who is not in the project doesn’t know something that they think should be obvious. For example, they might ask, “Hey! Do you support doing CSV export?” As a maintainer, you might respond with, “Did you read the documentation?” In my experience, this is a surefire way to turn someone off from ever contributing anything else or asking another question (we will cover other surefire turn-offs in Chapter 3, Open Source Licensing and IP Management).

This is not to say it’s entirely the maintainer’s fault either; I’m a firm believer that a breakdown in communication faults both the communicator as well as the recipient. This is why I recommend over-communicating, meaning communicating multiple times, in multiple ways, and in multiple different places, such as via a mailing list, discussion forum, and chat channel. As a maintainer, you might take this as some sort of millennial placating exercise, but instead, I’d recommend thinking about the contributor or user. Each of them is likely super busy, has tons of priorities, and, with the constant rate of technological change, is probably overwhelmed (which doesn’t even account for factors in their personal life). As a maintainer, you can likely relate; the list of to-dos is endless, the demands are constant, and users often give you grief. Having a bit of mercy for these folks goes a long way, but more importantly, gives you clues on the best way to engage your contributors and users.

So yes, over-communicating is much more work on the front end, but it saves you the time of answering questions later and potentially helps you reach users you might never have connected to. Keeping communication open adds transparency and insight for users and potential contributors. Often, you can gain interest from the so-called drive-by audience. We will dig into this more in Chapter 6 and Chapter 7.

Benevolent dictatorship versus leading by committee

Linux has famously been led by Linus Torvalds for over 30 years at the time of writing, and he has been the poster child for the benevolent dictator style of leadership. This style mirrors similar national governments of the same style, such as Singapore from the 1960s through the 1990s. Benevolent dictatorship puts a heavy burden on the individual, both from a project management standpoint and from a cultural, ethical, and growth standpoint, meaning the person has to be able to move the project forward while bringing contributors and users along, enabling them and empowering them for the growth of the technology.

Beyond Linux, we’ve seen other projects adopt this in their early years as well; examples include Rasmus Lerdorf for PHP, Guido van Rossum for Python, and Ton Roosendaal with Blender. Linux is a bit unique in that it’s largely maintained this model throughout its life, but like the other projects I just mentioned, it’s slowly transitioning away from it, as maintainers are looking at ways to bring in new maintainers to carry Linux into the decades to come.

Benevolent dictatorship as a pattern generally falls into the narrow category of “generally doesn’t work well, but in some cases, with the right benevolent dictator and the right community, it works.” Often, it’s a good choice in the early days of the project, where there are several opinionated choices to be made that set the course for the future. However, the challenge is having the right individual to lead; as described earlier, they need to be visionary, organized, thoughtful, and able to bring people together to make it work. With this being quite a demand, it can be stressful and consuming, which is often why you see the model akin to a start-up, which then transitions to the next stage as a critical mass forms.

Leading by committee solves the problems of the benevolent dictator model by spreading the decision-making and responsibilities across multiple people, which enables a project to drive efficiency and get diverse contributors and contributions over time. It also forces a project to involve better communication; a benevolent dictator can ruminate on key decisions in their head, while a committee approach forces each person to externalize their thoughts to get a consensus.

That’s not to say leading by committee is perfect; it can often slow down development and project velocity because of the work needed to get alignment. That can be a good thing in one sense, as it makes decision-making more thoughtful, but at the same time, it can lead to overthinking and the dreaded bikeshedding [7] that stagnates a project.

Thinking about both approaches with a pattern mindset, most often, an early-days project benefits more from a benevolent dictator whereas a more mature project benefits more from a committee approach. We will explore this more in a later chapter when we dig into governance.

Forks

Forks are one of the inherent rights one has in open source and are at the heart of every open source license out there. They give the user the freedom to take a code base any way they want, customize it to their specific needs, and use it to solve their unique problems. The downside of forks is the cost to that user, namely in continued maintenance and the upkeep of a fork, as it can become long-lived (meaning a fork that is intended to persist for several project releases, or even indefinitely), including bringing changes from the project code base back into the fork as it changes over time.

That overhead is often a headache, and why generally long-lived forks are an anti-pattern. The better approach is known as working upstream, which means that as you make changes to the code base, you contribute them back into the project rather than maintaining them separately. In open source communities, working upstream generally is the best approach; it gives you the benefit of your changes being tested more broadly, saves you time in not having to merge them into later versions, and showcases you as a steward of the code base. There are cases where that isn’t always possible due to technical or licensing issues; for example, what you might be modifying breaks other use cases, so it can’t be upstreamed. Another example is changes that include code licensed in a way that is incompatible with the upstream project.

Other times you will see forks are when there are differences of opinion on the direction of a project or a project may have slowed down in its development, and certain individuals want to break away from that and increase its velocity. Another case is when cultural or personal clashes happen. These are often problematic forks, and in open source, almost always end up with one of two outcomes:

• One fork ends up getting all the momentum, and the other fork dies off
• The forks merge back together into one project

Conflict in communities is healthy, as it gives people a voice and ensures there can be cohesion and space for different opinions. At the same time, if that conflict gets to the point where a fork happens, then you see long-term scars that are hard to repair. In a later chapter, we will dig into dealing with conflict so that your community doesn’t face this dilemma.

Over-governance

Someone once told me that if you run into a law or rule that seems a bit crazy, then there is an even crazier story behind its origin. That is not to say there isn’t validity in the law or rule, but often the context is missed or the problem it was meant to solve is no longer relevant.

Governance is something I’ve tended to see open source projects over-engineer. This isn’t done maliciously, but details that can be hard to predict may be over-indexed. One that I recently ran into is a project wanting to define exactly how long a vote via email should be open. The group forming the project had the right intentions; they had a concern that a vote taking too long to complete would slow things down or be a sign of disengagement with the group. However, the downside was that being prescriptive got in the way of several possible scenarios:

• What if a person was out on leave or vacation and didn’t have access to email? That would be a clear barrier.
• What if there needed to be some more thought or internal company alignment on the item being voted on? Putting the vote out there forces the vote to happen, regardless of alignment within the project.
• What if the person had more sensitive concerns that were hard to address in the context and timeline of a vote?

The thought when building governance and looking at adding a given policy or rule should be, what is the goal the project is aiming to achieve? And then, what is the most lightweight way to accomplish that? If we look at the previous example, the goal is to conduct a vote efficiently. If not everyone has submitted a vote in a given amount of time, the factors in the preceding raised bullet points may come into play, as does how often we can expect this to happen. Generally, during the early days of a project, people are more engaged, so we would likely never run into this constraint.

Later on, that might change. Projects should always know their governance isn’t written in stone or tattooed on the maintainers. Rather, it’s a living document that can change easily over time to accommodate the concerns in that project stage. An example that I see come up in open source communities is, don’t make rules to handle hypothetical situations, but rather ones for known concerns and revisit them over time. We will discuss this topic in Chapter 5, Governance and Hosting Models.

Competitors welcome!

One of the unique aspects of open source is that because the collaboration is open to all, anyone can participate – even if they are competitors. This probably seems like a scary proposition, but in reality, the right ground rules in place can make a very vibrant and high-velocity open source project.

Kubernetes, a project hosted by the Cloud Native Computing Foundation (CNCF), is the poster child for this in my view. Check out the chart from the following Kubernetes project journey report [8] that speaks to organizational diversity within the contributors to the project in its first 5 years:

Figure 2.3 – Percentage breakdown of contributions by company since the Kubernetes project launch

You can see that while at the project launch, Google dominated contributions to Kubernetes, with well over 80% of contributions, that changed dramatically over the following 5 years, with Google making up just under 25% of contributions. We may infer that Google has stepped back from the project during that time, but rather it’s been just the opposite:

Figure 2.4 – Cumulative volume of contributions by the company since the Kubernetes project launch

This speaks to the value of competitors coming together in a project to collaborate; not only has this project seen huge overall growth from code contributions and contributor standpoints in its first 5 years but also by bringing together all the top cloud providers, Kubernetes has become a ubiquitous technology. This has resulted in a vibrant and growing vendor ecosystem that has driven huge economic value. I’ll dig more into this in Chapter 10, Commercialization of Open Source.

Write everything down

This pairs with open communication well, in that a great way to achieve open communication is through a written culture. It also makes it much easier to repeat processes consistently, as well as identify opportunities to be more efficient as a project and gaps that might need to be addressed.

I have a large family and organizing all the activities from school to sports, work, and other groups we are involved with is an undertaking. Adding to that, my amazing wife and I aren’t getting any younger, so juggling it all in our heads is a bit more challenging than it was in our youth. Like many of you, we established a family calendar using one of the major software and hardware vendors’ family calendar solution, where we were keen to add all our kids' sports practices and games, any work events or travel, volunteer group meetings, activities, and other events we might be taking part in.

We also keenly decided to make it so that when an event was added or changed on the calendar, it sent notifications to everyone in the family and alerted them a day in advance, as we often add to the calendar when away from each other, which ensures that everyone else knows about these events. Of course, we aren’t perfect at this and have run into the occasional double-booking of events due to someone not adding something to the calendar, but it’s worked well overall.

What this written culture has given, in addition to coordination, is a sense of whether someone is overloaded or has the capacity to do more. For example, my oldest daughter has taken on the responsibility of cleaning our house once a week, which is something she balances, as I write this book, with taking a full load of college classes as a high school junior, year-round volleyball, and trying to have a social life as a teenager. The family calendar has become a great tool for her to look ahead on when she could do that cleaning and plan it into her schedule, which has helped her balance things and better communicate with us on when she can clean the house (or helped us as parents point out to her when she does have free time and should do the house cleaning ).

This same concept works well in open source projects; writing things down helps make it easier to not only communicate externally but also coordinate and prioritize activities. For example, if a project aims to release once a month, writing down the release process ensures the project isn’t scrambling to pull together code and run through all the building and other processes to get a release out of the door, while at the same time being able to prepare contributors and maintainers to submit their code by a certain point for it to be included in the release.

Writing things down, while sometimes seeming like an annoyance, helps make a project more efficient and organized. As a bonus, it helps your community scale and enables new people to come in over time to take over these responsibilities and consistently manage those tasks. We will talk more about this in Chapter 9, Handling Growth.

Embrace your community

The primary driver I see in creating an open source project is to get a diverse set of individuals to come in and offer feedback, contribute code, and help maintain the project. I’ve often seen that software engineers can be somewhat introverted or have social anxiety, which can make this daunting. Perhaps there is a degree of imposter syndrome, and the maintainer might be leery of engaging with community members or intimidated by them. While I can appreciate all of that, especially as somebody who has had to work through that in my career and still struggles with it from time to time, embracing your community is key if you want success in your project.

I won’t dig too much deeper into this topic as later on in Chapter 6, Making Your Project Feel Welcoming, I’ll discuss this more, along with strategies to help.

Focus on your strengths and use tools and other resources for your weaknesses

One of the hardest things we have to do as humans is accept our shortcomings and what we aren’t good at. It becomes worse oddly enough as we become more successful in other aspects of our career, as we think success in one area translates across everything.

In the United States, we see this culturally in American football, where from time to time, coaches move from being highly successful college coaches to trying to replicate that in the National Football League (NFL). More often than not, it isn’t very successful [9]. Various factors are at play, such as the age and maturity of the players, the environment of college students versus paid athletes, and the greater demands on managing the various aspects of a longer season and often more talented athletes. Similar patterns exist in coaches transitioning from college basketball coaching to the National Basketball Association (NBA) [10]. What is interesting is that often these same coaches go back to the college ranks and become successful, which leads us to infer that it’s not a question of somebody losing their touch as a coach but rather whether skills translate well in one environment more than another.

I often see open source projects try to run their events, do their marketing, or manage other operational tasks themselves. To be fair, I have seen projects do this well (and sometimes, this teaches me a few things). However, more often than not, these aren’t skill sets that a software developer has, and frankly, that’s okay, as that person has skills that an event manager, marketing person, or lawyer doesn’t have. Technical documentation is a great example here; most software engineers feel they aren’t great at it or have little affinity for technical writing, but there are people out there who excel at this and can partner with a project to produce stellar documentation.

On top of people, tools are another way to work smarter, not harder. Taking the technical documentation example, multiple tools can take code comments and build API reference guides or take plain Markdown files and build out beautiful-looking documentation that can be consumed in multiple formats. Scanning files by hand for the right license headers is a lot of work, but tools such as FOSSology [11] can do that for you and build out reports and the Software Bill of Materials (SBOM) at the same time. There are multiple tools for tracking contributor growth and project health, and collaborative work in projects such as the CHAOSS Project [12] that provide guidelines on metrics to measure based on the collective experience of millions of open source projects over the past few decades.

Summary

This chapter built upon the what and why of open source into the how – namely open source projects in which the work of open source is done. Additionally, I dug into the ethical expectations of releasing open source code and some of the patterns and anti-patterns I’ve seen in various open source projects.

One thing I want to stress is that there is no one way to run an open source project or one way a community should work; there are so many factors that come into play across cultures, industry verticals and horizontals, the pace and velocity of development, the maturity of a project, and the people involved themselves. Using a fruit analogy, apples and oranges are both fruit and will share some characteristics, and direct comparisons are equivalent to comparing apples and oranges.

This chapter also ends the so-called 101 level of education, as future chapters will delve into specific areas more. I’ve called out several of those chapters in this chapter and the previous one, and encourage you to jump ahead if one of those topics is specifically of interest – feel free. For those just starting this journey, simply continue on to the next chapter, where we will dig into one of the most debated and nuanced topics in open source – licensing.

Further reading

1. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
2. https://www.usatoday.com/story/tech/2018/06/22/cost-of-a-computer-the-year-you-were-born/36156373/
3. https://github.com/todogroup/repolinter/releases/tag/v0.10.0
4. https://github.com/Microsoft/MS-DOS
5. https://todogroup.org/guides/#ospo-guides
6. https://todogroup.org/guides/starting/
7. https://en.wiktionary.org/wiki/bikeshedding
8. https://www.cncf.io/reports/kubernetes-project-journey-report/
9. https://athlonsports.com/nfl/college-coaches-who-went-nfl-good-bad-ugly
10. https://www.espn.com/mens-college-basketball/story/_/id/26738229/how-college-coaches-fared-nba
11. https://fossology.github.io/
12. https://chaoss.community/