Skip to main content

Section 2.1 The Challenges of Global Community

Open Source Software is as much about community as it is about writing software. Consider the two words that make up the phrase open source: obviously, having source code is not a unique quality, since all software has source code, somewhere. The distinguishing feature of open source software is its openness, but being open is moot unless there is a community using and improving the software. The more people using, collaborating on, and contributing to the software, the greater the value of its openness.
Each OSS project builds its own unique community with its own qualities. Some communities are small, others large; some are highly structured, some are much more casual; some readily welcome new contributors, others have high barriers to entry; and some communities are global, while others are very local. One of the first steps in getting involved with an open source community is to scout out the lay of the land and discover the characteristics of the community. To do so, you need to understand the qualities you’re looking for, and you need to understand how to communicate with the community.
It’s important, and a little daunting, to realize that the concept of open applies not only to the source code, but to all of the activity that takes place within a community. Engaging with an open source community means working in the open, succeeding in the open, and failing in the open.
At the end of this chapter, you should:
  • Understand the key qualities of an OSS community;
  • Understand common OSS communication tools;
  • Be able to determine the qualities of a specific OSS community;
  • Start to engage with one or more OSS communities using its communication tools and culture.
Most OSS projects are (or aspire to become) distributed, global communities. This introduces a number of challenges:
  • Language.
    Any global community will of necessity include participants with different native languages. Large projects usually evolve collaborative subgroups that work on documentation and localization for specific languages, but contributors to code and base documentation need a common language in which they can communicate. In many cases, the common language is English, in part because it is one of the most widely spoken languages today. However, the fact that the reserved keywords and base documentation for many programming languages are in English may also be a critical factor. In Eric S. Raymond’s How to Become a Hacker, Linus Torvalds, the original creator of the Linux kernel, is quoted as saying that it never occurred to him to comment the Linux kernel code in any language other than English, despite the fact that English is his third language.
  • Time and distance.
    Photo of a world map with shading to represent day and night across the globe at 8:00 am Eastern Standard Time.
    Figure 2.1.1. Our World Day and Night at 8:00 am Eastern Standard Time
    The fact that our globe spins introduces some interesting challenges: collaborators in India and the USA, for example, will never be able to collaborate in real time during normal business hours – in fact, they’ll hardly be able to collaborate during normal waking hours. Most communities meet face-to-face only once or twice a year, if at all, and the face-to-face meetings usually involve only a small subset of the whole community. These challenges have forced the development of really good asynchronous online communication tools. However, having people in different timezones also has some advantages, making it easier to respond in a variety of threads, follow rapidly-developing security issues, and manage infrastructure 24×7.
  • Ego.
    Standing out in an ocean of nicknames and e-mail addresses, trusting people you have never met, and accepting criticism from strangers is very difficult. Control freaks, glory-grabbers, bullies, and fear-mongers exist in OSS communities and are poisonous to community-building. Creating and maintaining a fork of a major software project is a significant undertaking that is not usually done except as a last resort, because it divides community attention and requires duplication of resources; however, the simple fact that a fork is possible and the community is essential often provides an effective check on runaway egos.
  • Knowledge-level.
    Knowledge-level can be tied up in ego. When you are new to any community, you are a novice on the culture of that community even if you are an expert in some of the tools and languages used by that community. As you endeavor to become a new member of an open source community, it is good to remember that you are a novice to the culture. Some good advice is to read the contribution guide (if the project has one), read the community discussions such as in relevant discussion forums and in bug reports. If you first try to get a sense of how the community operates before you violate any implicit or explicit rules, you are much more likely to be welcomed in. For example, it could be frustrating to try to maintain code quality with volunteer contributors who are happy to contribute but who have not tried to understand the existing standards (such as formatting, documentation, or tests).

Checkpoint 2.1.2.

    Why is it important for contributors to read the contribution guide and community discussions before joining an open-source project?
  • To better understand the existing codebase.
  • While understanding the codebase is crucial, there’s another primary reason for reading the contribution guide and community discussions.
  • To identify potential job opportunities within the project.
  • Although contributing to an open-source project can enhance career prospects, the primary purpose of reading the contribution guide and community discussions is different.
  • To avoid violating implicit or explicit rules.
  • Absolutely! Reading the contribution guide and community discussions helps contributors understand the project’s established rules, best practices, and community norms, preventing unintentional violations and fostering a positive collaboration experience.
  • To find out how to access to early-release project features.
  • The availability of early-release project features is not directly tied to reading the contribution guide or community discussions. The primary focus of these resources is different.
  • Both A and C are correct.
  • Incorrect!
You have attempted of activities on this page.