This chapter is named Community 101 in reference to a way of numbering courses at colleges and universities. The "101 course" is the material you first encounter as a learner in a specific field.
There are generally two pursuit areas where it comes to getting involved in open source software from the very beginning. The first pursuit ranges from understanding through to participating in an existing open source community. The second pursuit is deciding to start a new open source software community yourselves.
This chapter is in two sub-sections. The first covers pursuit toward participation. The second covers how you decide if you want to start a new open source community.
If you are considering forming or joining an open source community for the first time, some of the concepts may be new. This section explains the basics of an open source community, and why people and organizations get involved in them.
A community is a group of people united by a common identity and collective purpose who engage in activities together over time. Communities develop unique sets of shared values, principles, and norms that distinguish them from others and provide members with a sense of belonging.
An open source software community is a group of people united by the shared purpose of developing, maintaining, extending, and promoting a specific body of open source software. These communities are often globally distributed—their members occupy different geographic regions and work across numerous industries. What unites them is their common vision for the open source software project—as well as the spirit of camaraderie and collective identity that participating in the community affords them.
The community-driven ecosystem of open source software is vast and difficult to visualize, so many developers tend to describe it metaphorically, preferring the language of waterways and tributaries. Software that forms the foundation of other software is said to exist "upstream" from that software. When "upstream" software undergoes changes, those changes flow "downstream" to the open source projects that rely on them. When programmers working "downstream" create innovations that might benefit others, they can submit those changes "upstream" to their parent projects, so those improvements can ripple outward to everyone utilizing those same upstream projects.
Red Hat Enterprise Linux, for example, exists "downstream" from many open source software projects that comprise it, such as Fedora and CentOS Stream. Those projects, in turn, rely on additional "upstream" projects—like the Linux kernel, the GNOME desktop environment, and hundreds more.
Open source software communities form when people agree to work together to build and improve software. For this to occur, a person or group building software must make that software available to others—by releasing the software’s source code and expressly giving others permission to copy, modify, and redistribute it (typically under the terms of a specific open source license).
Because open source communities are globally distributed, they typically form online through the shared use of electronic mailing lists, forums like Discourse, and code-sharing platforms like GitHub.
Most open source software communities don’t have formal membership applications or approval processes. More commonly, people get involved in projects simply by contributing to them in some way—for example, by fixing bugs in software code, creating new features for an application, writing and editing documentation, creating logos and graphics, promoting adoption of the software, representing the project at a conference and other events, or assisting others who have questions about the software.
In short, people earn membership in open source software communities by virtue of their contributions to those communities and the positive reputations they establish as a result of those contributions.
People join open source software communities for many different reasons.
Many join because working on the software is part of their jobs—either because their organizations hired them to develop it, or because their jobs depend on the software working well. They join communities so they can directly impact the development of software on which they (or their organizations) rely for critical operations.
Other people join because communities offer opportunities for them to sharpen their skills by working alongside and learning from others.
Some join because doing so allows them to collaboratively solve a problem they’re experiencing.
Some join because of their belief in the importance of contributing to a common set of resources beneficial to everyone. And others join for the purpose of socializing, or for a sense of identity and affiliation.
Organizations increasingly rely on open source software applications for various critical operations, as much of the world’s most innovative and effective applications are open source. So they participate in open source software communities because they’re invested in the long-term viability, stability, and security of those applications—and, often, because they want to influence development of those applications' features and functionalities.
Other organizations participate in open source software communities because they’d like the software they’ve developed to become an industry-wide standard—they open their work in the hope that others will more quickly adopt and integrate it.
Many organizations find that participating in open source software communities allows them to access a wider talent pool than they could if they developed their applications entirely in house.
Consider engaging an open source community using the same approach you might take when you move into a new neighborhood. Introduce yourself and work to understand the community’s history, values, and dynamics before proposing big changes.
Make new friends by performing small jobs. Fix bugs in source code. Edit documentation. Build installation scripts. If your organization is able to allocate additional resources to support the community, consider sponsoring that community’s activity at events or hiring community developers so they’re able to spend more time working on the project.
Just note that arriving in a community with more people than it can comfortably welcome at one time may elicit a reaction from the community, which can be counterproductive to an organization’s long-term goals. And choose your organization’s initial participants in a community wisely. Individuals—not organizations—join open source communities, and the trust one participant garners is not automatically transferrable to another person or organization.
Many companies are in this position. These companies have determined that collaborating on mutually beneficial software applications or standards is more valuable than competing to develop different, perhaps incompatible, technologies. Instead, their business models involve building market-differentiating and revenue-generating innovations on top of these shared technological foundations.
Getting involved in an open source software community has important organizational, procedural, and legal implications for an enterprise. Most organizations that are seriously invested in open source software development fund internal open source program offices (OSPO) to advise the organization on matters related to open source community participation. Others partner with open source experts to advise this work.
It is possible and not uncommon to have software that is open source and the maintainers have shown no interest in forming a community beyond themselves. Frankly, not every code base needs its own community. Conversely, any code base may suddenly find itself at the center of a community that arises around it. Being open source doesn’t mean it must have a community. But it does mean that if it has one, it gets certain benefits particular to open source software.
Forming an open source software community has many of the same ethical and organizational considerations of forming any other community of practice. A community of practice is a group of people who share a common interest, who also get together to learn and practice within the common domain.
An example of a community of practice might be hammer dulcimer players who have an annual gathering to share about the art and practice of being a hammer dulcimer player. Or it might be skateboarders, gathering every week at the park to learn and practice new tricks.
For you and your organization to consider forming an open source software community, you must first ask yourselves: are you willing to form and be the caretakers for any other sort of community? Does doing so match your vision? Does it match your style of getting things done?
For example, an organization like a university or a branch of the armed forces would have two very different approaches to getting things done. Their reasons for forming any kind of community may be wildly different, or unexpectedly aligned.
A feature of communities of practice that applies to open source software communities is how they can truly draw together people and organizations from wildly different worlds. Open source software communities, like all communities of practice, can truly draw people together from wildly different worlds. In open source communities, people with common interests (shared practices) band together to learn and grow collaboratively (community).
Some other considerations around forming an open source community:
-
You are interested in the benefits of open collaboration and innovation. You might already have or are planning a new technology, and open source is a way to find like-minded collaborators. Or you may just have a feeling that this is the right approach for your plans.
-
Attracting enthusiasts to your project is a key part of your growth strategy, and you’ve identified that open source contributors of all types are good enthusiasts for you.
-
The scientific method is core to your mission, purpose, and/or practices, and you see the benefit of having your entire software toolchain, infrastructure, et al as something your users should be able to contribute to and become maintainers of.
-
Your organization is one that is open, collaborative, and community-building by nature. You may create right-sized open source projects, where the users and contributors are closely aligned in some way. For example, collaborators at a university. If there is no legal barrier to starting a project, why not start one? You never know who might find it and benefit from it in the future.
Anyone advising open source communities on project goals has likely found themselves asking project leaders the same basic questions. This chapter outlines seven of the most common questions communities can ask themselves as they work to articulate a project’s goal.
This should be a very basic question. But its answers typically aren’t. Too often, open source projects describe themselves in terminology unfamiliar to many potential users, or they focus on how they do what they do, rather than on the problems they can solve. When formulating potential answers to this question, focus them on how the project helps its users. What problem does it solve? How would you describe your project to a potential user of the project in the most succinct terms possible?
For example, let’s imagine we’re asking an Istio developer what Istio is. The most basic answer is "it’s a service mesh." One might argue, however, that most container application developers don’t entirely understand what a "service mesh" is. So the shorthand description—"It’s a service mesh!"—doesn’t help a novice understand if or how to use it. A better explanation might involve describing Istio in terms of an application data plane and control plane (if I am talking to someone from the networking world), or perhaps a concept of traffic cops assigned to components of an application (if I am explaining the project to someone unfamiliar with the concept of a service mesh).
Ask as many follow-up questions as your community needs in order to develop a simple, straightforward understanding of project and what it can do.
Many open source projects do not clearly understand who uses their projects and what those users do with the project’s tools. Consider using the concept of "personas" to characterize archetypal groups of key users, and be sure to think in terms of "jobs to be done."
You might categorize a project’s potential or current users with a number of criteria:
-
Is the project more useful to an individual or to an organization?
-
Is your project particularly useful in a specific industry vertical or business domain?
-
What size organization will find your project most useful? Are you targeting sysadmins in large enterprises, or the small and medium business space?
-
What are the job titles of the people who will be downloading, installing and using your project? Are they the same people? Or are the users different from the project administrators?
-
What is the relationship between the people who download and install open source projects and the people who evaluate and purchase commercial products?
Answers to these questions will influence the priorities your community sets for structuring the project, promoting it, and even the degree of engineering effort you’ll invest into certain features. For example, if your project runs in a datacenter or on a cluster of servers, your audience will typically be a business audience—people running IT professionally (or as a volunteer in a university). For a mobile application or a web development framework, the majority of your audience will be running your project on their personal computer, workstation, or cellphone. Each of these groups has different resource prerequisites, and the problems motivating their use of the project and its tools are different.
Moreover, anyone interested in developing an open source product strategy should think additionally about the critical relationship between project users and product buyers. A company’s path to adopting open source doesn’t usually follow a straight line from use of an upstream open source project to conversion to an enterprise open source product. Open source adoption tends to be "grassroots," bottom-up; enterprise open source products are often evaluated and purchased top-down. Those adopting an open source project inside a company can be valuable influencers when consulting on purchasing decisions—if they’re connected to the purchasing process, or if the person responsible for purchasing is aware that the company is already using the product.
Once people are turning up to your project, engagement is key to growing the project’s user base and community. You can engage with users in multiple ways, each requiring different degrees of effort and resulting in differing outcomes.
Figuring out where you should focus your efforts can be difficult. So it’s useful to take stock of all of the ways you’re currently engaging with project users in order to identify blind spots and opportunities for improvement. Consider characterizing engagement techniques as "low-," "medium-," and "high-touch" (terminology borrowed from sales). Low-touch methods represent very little interaction between potential users and your community, while high-touch methods represent one-to-one or one-to-few efforts.
Here are some examples of the types of things you can categorize this way:
-
Low touch: Website, documentation, online training, newsletters, podcasts, blogs
-
Medium touch: Mailing list, bug tracker, community forum, conference presentation, webinars, user groups
-
High touch: Phone calls, one-on-one or one-to-few training, conversations at conferences, community meetings
Ideally, your project will have a healthy mix of each of these. Working on your website, documentation, and promotional materials allows new users to act autonomously and without much help from a senior community member. Your bug tracker, mailing list, and forum provide opportunities for community members to engage with your community, ask questions, and provide feedback. This kind of activity provides an opportunity to learn more about how people are using your project. Finally, high-effort activities like training, conference booth attendance and follow-up, and in-person conversations can be extremely valuable on a one-on-one basis—but those techniques do not scale well.
The "sales funnel" model may be useful to communities thinking about engagement activities and project goals.
Low-touch activities are good for raising awareness of your project and getting people to look at it for the first time. Ensuring your web site and other materials clearly communicate what the project does, how it can help users, and how contributors can try it out and get started quickly is paramount. Medium-touch activities are great for creating a "center of gravity" around your project—not only making communication with users possible but also enabling those users to help each other (hopefully generating a network effect). And high-touch activities are great for building relationships with key community users, gathering community case studies, and helping larger groups be productive with and become advocates for your project.
A key consideration for groups crafting potential engagement pathways is how someone unfamiliar with the project might start using it and, over time, gain seniority in the project to the point of becoming a core contributor.
You can tell a lot about a project by assessing who that project competes with, or what other projects people use to accomplish the same (or similar) tasks. Consider asking:
-
If your project doesn’t have any competition, why is that the case?
-
Is it in an area of emerging technology?
-
Are people using similar projects to do work they could accomplish with your project—just in a different way?
-
If other projects do the same job, but have no clear leader, how are they approaching the problem differently than you are?
-
If your project has open source competitors, is joining them (rather than trying to compete with them)an option? If not, why not?
-
If a competitor is an incumbent in the market, what can you tell about them and their customers?
-
Who are your competitor’s customers? What do they have in common?
-
What are people’s motivations for using a competing project?
Analyzing your competition can help you begin answering a number of key questions early in a project’s goal-setting process, and answering these questions will help when your community begins prioritizing features and deciding how to contact potential users. Perhaps, for example, you can piggy-back on existing gatherings between people already interested in a competitor’s technology and spread your message there. Or if you’re an upstart disruptor, your goals and messaging may be anchored to your competition: "cheaper than," "an open source alternative to," "simpler and faster than." If you’re in a new market and your project is involved in a "land grab," you’ll need to focus on spreading your message fast—which means a higher marketing budget or more aggressive community plan, and more focus on defining the problems you solve for potential users.
If your software is frequently consumed with or is particularly useful to users of another project, then you may see opportunities for growing awareness of your project in its early stages and better understanding your users' needs. For example, Ceph can manage storage for OpenStack or Kubernetes; for Ceph, then, OpenStack and Kubernetes are adjacent communities. Catering to adjacent projects to find an audience may affect your technology roadmap, the events you target, the effort you put into specific integration projects, and so on. An adjacent project provides you with a potentially friendly audience who have the same problems your technology solves, so you can engage in some joint market research or UX testing, or coordinate joint events to meet and engage with potential users. This is also connected to understanding your competition; the communities important to them will also be important to you.
The existential question for every open source project is: "Why does this project exist?" Specifically, for a project released by or driven by a vendor, that question becomes: "What do we want to achieve by investing in this project?"
Surprisingly, many projects have difficulty answering this question.
As a vendor, ask: Why did you open source this piece of software in the first place? Are you trying to grow a market, promote a standard, disrupt a competitor, or increase demand for another product in your portfolio? Each of these requires a different message and different set of investments.
Understanding the reasons for open sourcing your project will help you clarify the investment required to achieve your goal remain aligned across engineering, product, and sales teams down the road. In the absence of a strong common vision for the project’s goals, you may find yourself under-funding the open source project, in part because of perceptions that it competes with products you build on top of it. A good open source product strategy provides clarity on which markets you are targeting, the market segmentation between product and project, and the role that the project plays in your entire business strategy and product portfolio. Clarifying these things will pay dividends in future discussions concerning the technical roadmap, or the relative prioritization of community promotion versus sales lead generation.
A small number of people who will care deeply about your project, and can represent a group of people or interests which affect the project. These people are your stakeholders.
In the case of vendor-sponsored projects, this group typically includes an engineering lead, product management, product marketing, and a representative of the field (field engineer, sales). You may also want to include in this group someone from your content services or support organizations and someone from product security. This is the group of people you will brief to prepare a stakeholder review, and you should gather them once every six to 12 months to check in on the state of the project and ensure alignment on the goals and the required investments to achieve those goals.
Answers to these seven questions can furnish a single-page document that forms a baseline, a frame of reference, for any project planning conversations. After running this exercise, your team or community should share some understanding of the problems your project solves, and for whom. You will be able to communicate the value of your project in language that makes sense in your potential users' frame of reference. You will understand how your project fits into a market, and what you want to achieve with it there. Finally, you will have identified the key group inside your organization who should be aligned on your current status and future strategy.
Combining the answers to these seven questions, next steps for your project should become obvious to all involved—and your community will be ready to help your project succeed in achieving its goals.