055.3 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
055 Project Management |
Objective: |
055.3 Community Management |
Lesson: |
1 of 1 |
Introduction
A key reason to create an open source project is to draw contributions from many different people. Open source makes it easier to respond to the different needs and interests of the project’s users and to benefit from their varied skills. Therefore, a diverse community is central to the success of the project. The community is where creative forces come together to make your project succeed.
This lesson explains the basic elements of free software and open source communities and how people in them work together. Of course, because communities are made up of different people, and because projects have different goals and requirements, each community is unique.
Roles in Open Source Projects
The main output from most open source projects is software, so at the very least, such projects require programmers, software designers or architects, testers, release managers, and other experts in code development. Documentation is usually a part of such projects too, so the community also needs authors, editors, and reviewers.
Other projects might not produce code, but other “deliverables” such as a book, an art or music project, or a policy report. Wikipedia is a well-known example of collaboration on an open source project that focuses on text documents and media. These projects need experts in the design, production, and delivery of the deliverable.
Communities also benefit from many other general skills, such as marketing and evangelism, administration, legal advice, artistic talent to produce logos or diagrams in documentation, and skills at maintaining the project’s web site and other communication tools. Open source projects might organize physical get-togethers and even conferences, in which case they need organizers to bring those events to life.
The proceeding paragraphs give you an idea of the types of skills a community looks for. These general roles can be further subdivided into various focused tasks. One simple example of such a task is for some writers to edit the work of other writers.
Among programmers, a range of experience exists. A healthy project always wants some veteran programmers (or senior programmers) who know its code and coding standards well, along with newbies who provide new ideas and simple help such as bug fixes. Some newbies will hopefully evolve into the next generation of veterans.
Code quality requires careful control over what gets into the central repository shared with users. Therefore, some veterans get committer status. They are responsible for checking contributions for quality, usefulness, and conformance to coding standards. They have the priviliges to accept the proposed code into the trusted repository. Other contributors submit code to the committers for review.
Many committers and other veterans also mentor new contributors to teach them the standards and practices needed to get their code accepted.
Some committers fail to appreciate the gift that a contributor is offering. If the contribution falls short of quality or coding standards, the committer might simply reject it. But the rejection discourages the would-be contributor and eliminates a valuable educational opportunity. Remember that good committers are also mentors. So they give the contributor hints about how to bring the code up to standards and work with the contributor over time. If the contribution is truly unusable, the contributor should at least be thanked and encouraged to work on something else for the project. It’s important to help people discover and refine their skills.
When a company starts an open source project, it sometimes appoints committers from its own staff to ensure that it can control the direction and quality of the project. But often, companies allow non-employees who show skill and dedication to become committers.
Project leads make critical decisions such as what new features to support. These project leads often have non-coding decisions to make as well, such as how to promote the project, resolve major disagreements, and get funding. Project leads and committers work closely with release managers to decide when a code base is stable and ready to share with the users.
Some projects have a single project lead, often referred to as benevolent dictator. This is often a person who started the project (Linus Torvalds being a well-known example in the case of Linux) and who has great authority and even charisma. However, most projects prefer to set up a small committee of project leads instead of a single benevolent dictator. Even the Linux project has moved to a committee approach.
Projects might also ask particular contributors to provide user support on the project’s forums. But healthy projects should have many knowledgeable users who support each other.
We’ll finish this section with a very important role: the community manager. This is someone responsible for maintaining open and constructive communication and making sure the community progresses toward its goal. The community manager knows how to onboard and motivate contributors, resolve arguments, protect community members against abuse, and perform other tasks to maintain the community’s health.
Common Tasks in Open Source Projects
In many ways, open source projects involve the same tasks as traditional projects carried out within a single organization. For instance, all code requires testing. But in some ways, open source projects differ from proprietary ones, where only a limited set of people are allowed to change the code and where the source code is often hidden from the public.
For instance, corporations usually assign trained quality assurance (QA) staff to test code. But many open source projects just ask their users to test each release. (Proprietary projects involve their users in testing too, in addition to QA.)
Another example of differences: A proprietary project usually assigns paid developers to specific tasks and tells them how much of their time each week to spend on the tasks. Some open source projects benefit from contributors who are paid by their employers, or sometime even employed by the project itself, and who are assigned tasks in the same way as proprietary developers. But in most healthy projects, a lot of contributions come from volunteers who just do the tasks as time permits. Because the project doesn’t rely on all volunteers to complete their projects on schedule, an open source release might be delayed until the developers feel that the features are ready, or might be released at fixed times with whatever features are ready.
Communications are critical to both proprietary and open source projects, but are often conducted differently. Proprietary projects often gather a team in one office and hold regularly scheduled stand-up meetings under a development methodology such as SCRUM. Because open source projects are geographically distributed, such methodologies are rare. Instead, communication takes place online and asynchronously.
In short, free software and open source projects often achieve the same goals as proprietary projects, but in different ways.
Bug reporting is a critical part of software development that gives rise to its own set of roles. Someone has to monitor the bug database and assign priorities. If a bug is critical (and particularly if it can weaken the software’s security), it should be assigned to a competent maintainer to fix.
Project leads and community managers should look over participation in the project and see where there are gaps. Are too few people willing to test code? Is documentation missing? Are too many veterans or senior project members leaving without being replaced? Project leads and community managers can focus on recruiting people to fill needed roles.
Project leads and community managers on large projects often gather metrics as well, to learn important things such as whether important bugs are getting fixed in a timely manner.
Kinds of Open Source Contributions
As explained in an earlier section, people who put code, documentation, or other items in the central repository are called contributors. Project members who approve contributions and accept them into the repository are called committers. Some members take on other common roles for software development.
Although the term contributor is usually reserved for someone who develops code or another part of the project’s official offering, anyone who participates to the project’s success is contributing in some way and should be thanked for doing so. These more informal contributions include reporting a bug, answering a question on a forum, donating or raising funds, and promoting the project to outsiders.
Open source projects, like proprietary ones, ask users what they want in terms of features, performance improvements, or other changes to the project. These users are making important contributions by voicing their opinions.
Kinds of Open Source Contributors
Many communities draw contributions not only from individuals, but from corporations who pay their staff to contribute to a project that the corporation thinks is important to its business.
Sometimes, having paid contributors right next to volunteers can create tensions. Volunteers might feel that their work is being exploited, or might be afraid that paid contributors are trying to bend the direction of the project to favor their employers' interests. A community manager and the project leads must guarantee that all accepted contributions provide benefits to the whole project and its users. Volunteers must also receive motivation to contribute for their own personal reasons, whether out of loyalty to the community or to meet their needs.
Some people contribute to a project regularly and take on long-term responsibilites; these are called core team members. Healthy communities also have occasional contributors who report bugs or post advice on forums, but are not expected to assume responsibility for the project.
Similarly, some contributors will be professionals in their field — whether or not a company pays them to work on the project — whereas others are amateurs, often called enthusiasts. But you don’t have to be a professional to take on an important role. You might even become a core team member or project lead.
The Role of Organizations in Open Source Projects
Although many open source projects are created by zealous individuals or small groups of volunteers, they usually seek organizational support when the projects get large. Organizational support can take many forms. In general, organizations make these contributions because an open source project can meet their business needs more cheaply and more reliably than reinventing the same features in proprietary code. The guarantees provided by a free or open source license are valued by many organizations.
Some idealists distrust corporations or other large organizations and would prefer to keep open source projects entirely free from their influence. Over the years, this rather simplistic attitude has become less common. Most open source advocates believe that corporations and other organizations can provide crucial underpinnings to open source projects.
Many open source projects start within an organization, and might even be based on proprietary code that the company decides to open up. To make money, the company may decide to keep firm control over the project and to break it into open and proprietary parts: This is called the open core model. Many project founders start as open source but form a company around it, which might or might not use the open core model.
Other projects try to ensure that no single company controls their direction. Maintaining independence usually requires signing up several organizational supporters, so that no one is strong enough to make a dictatorial decision.
How do organizations support open source? As mentioned earlier, many put paid staff onto projects. Additionally, they might hire highly productive individuals who have contributed to the project as volunteers and have developed expertise in the project. This path to employment is a valuable way for students and other volunteer contributors to advance their careers.
Companies desiring extensions that don’t interest other users should not pressure the open source project to add the extra features, but should pay their staff to write the features without contributing them back to the project.
An interesting example of the possible tension created by corporate needs is shown by the famous Android operating system, based on Linux and developed by Google to drive its mobile devices. Some changes to Linux made by Google are contributed back to the Linux community, whereas other changes appear only in Android. The Linux developers sometimes reject changes submitted to them by Google, just as all projects choose what contributions to incorporate.
There are many reasons for a company, or a group of developers, to make a separate version of your code. Ideally, they can meet their needs by adding an optional library or sequence of code that can be excluded during compilation. But sometimes a group feels a major need that is incompatible with the direction chosen by project leaders. When a separate version is made, it’s called a fork.
Forks used to be considered failures of collaboration, but nowadays forks are much more accepted. Usually, people who make a fork set up a new repository and start a new project. Some people work both on the original project and the fork.
(Note that GitHub uses the word “fork” for a very different phenomenon: making a clone or copy of project code to work in separately.)
In addition to code, many companies contribute financially. They may fund efforts such as marketing and conferences. They can join the board and offer expert advice on the project’s direction and strategy.
An example of the importance of such “soft support” comes from the historic Apache web server. The project took a big leap forward early in its existence when IBM showed interest. IBM lawyers showed the project how to create legal safeguards, and a meeting paid for by IBM helped the Apache leadership create a robust organization.
To maintain independence, many open source projects form a nonprofit foundation or join an existing foundation. Famous examples of foundations that guide open source projects include the Linux Foundation, the Apache Foundation, and the Eclipse Foundation.
A foundation’s support is valuable because it can provide the logistics that most software developers don’t want to deal with: legal support such as trademarking, indemnification, and licensing; help with raising money; infrastructure such as bug databases and web sites; and so on.
Transfer of Rights
Just as with books, music, and other creative efforts, software involves a complicated relationship between the developers, the organizations that distribute their contributions, and the general public. Essentially, contributors must take steps to formalize the right of an open source project to use and distribute their code.
Thus, many open source organizations ask contributors to sign a contributor license agreement (CLA). Sometimes, the contributor just gives the code to the project. The project owns the code and all rights to it, just as a proprietary company owns the code that it paid its staff to develop.
Other CLAs leave some rights in the hands of the individual contributors. Contributors might like this flexibility because they can go on to contribute the same code to another project or build their own business around it.
To harmonize the different contributions from different people, the license assigned to the code is crucial. The Linux kernel is one of the projects that leaves ownership in the hands of the contributors, so that by now many thousands of people own rights to the Linux code. But all contributors to the core code put it under the GNU General Public License (version 2). Thus, Linux is free for all to use, alter, and redistribute.
Using a single license for all code in a project is the simplest way to guarantee that no encumbrances hinder the code from being distributed and used. But sometimes a project allows different parts of code to be contributed under different licenses, usually because the project wants to take advantage of some pre-existing code that’s already released under a different license. Licensing experts should make sure that the licenses are compatible.
Rules and Policies
Many online communities have a reputation for unrestricted speech (a cavalier idea that “anything goes”) leading to verbal abuse and bickering. Nowadays, most open source communities are battling that tendency, which takes hold of people all too easily. In contrast, modern communities want people to be constructive, civil, respectful, and inclusive of everyone: all genders, ethnic groups, personality types, and so forth.
Expectations of group members are usually specified explicitly in a code of conduct that explains how to engage with other people on the project, both online and in person. To be effective, this code of conduct has to be enforced by the community manager and project leaders.
Sometimes, a person who flagrantly mocks or denigrates a fellow community member is expelled permanently or temporarily. At other times, the community manager or a colleague simply announces publicly that the behavior violates the code of conduct and might talk to the offender outside the forum. Often, the offender previously felt frustration, lack of attention, or burn-out, and community members can help the offender find better ways to express themselves.
In addition to social behavior, communities establish quality standards. The most formal consist of coding guidelines, which try to ensure that all code looks similar. The guidelines may remind developers of good practices such as using brackets around blocks of code, or may specify details such as how to name variables and what kinds of indentation to use.
Open source communities also have rules around releases of code or other deliverables. Some projects establish fixed times for releases; for instance, Ubuntu promises a new long term support (LTS) version every two years along with interim releases on a more frequent basis. Other projects maintain a list of new features and bug fixes they want in the upcoming release and approve the release when everything is checked off the list. But unlike most businesses, open source communities don’t usually establish deadlines for participants, because one cannot ask too much of volunteers.
Attribution and Transparency
In addition to the contributor license agreement mentioned earlier, some projects ask contributors to sign a developer certificate of origin (DCO). In the DCO, the contributor promises that they have the legal right to donate the code.
Why is the DCO important? Imagine this scenario: If a programmer takes code from a proprietary product produced by their employer and contributes it to an open source project, the programmer violates the employer’s license and puts the open source project at legal risk.
The DCO is supposed to ensure that the contributor actually wrote the code, or obtained it legally. The open source project depends on the honesty of the contributor who fills out the certificate.
Diversity, Equity, Inclusivity, and Non-Discrimination
Social scientists claim that projects and companies benefit by having many people with different genders, races, economic backgrounds, nationalities, and abilities. All organizations have a natural human tendency to bond with other people like their current members, so a community that values diversity and equity has to consciously train its members to be more open to people who aren’t like them. The movement to carry out this ideal is called diversity, equity, and inclusion (DEI).
The code of conduct is the starting point for DEI. It should explicitly welcome people of different genders, races, etc. Every violation of the code of conduct must be handled promptly with unambiguous disapproval. This is because some minorities have suffered from exclusion and negative comments their whole lives, and a single bad interaction in your forum could make them decide they have no reason to participate anymore. A speedy response to aggressions can reassure them that the community backs them.
But DEI goes much further. The community should reach out to groups who need more representation. For instance, if you are developing a job search app, you should make sure it shows jobs for low-income people as well as upper-class and middle-class people. You should also advertise the app among low-income communities and recruit members from those communities to test it.
Your community might benefit from finding organizations that train people from marginalized communities, and from which you can recruit new members of your team. Many such organizations are established in local areas, and aren’t well-known nationally or internationally.
Understanding the needs of marginalized communities is key. Is your web site accessible to the sight-impaired? Do you translate your documentation into languages with which the target community is familiar? Perhaps you should create specific forums in other languages.
Most communication in open source communities is asynchronous and online. But if you have meetings or synchronous chat sessions, think about where people are geographically and find ways to include everybody. For instance, when people from many countries and regions are communicating in English, try to keep the vocabulary and grammar simple.
Finally, if you have members of some minority on your team, make sure to listen to them. One well-known symptom of exclusion is discounting what minorities say or just underappreciating its importance.
On the other hand, don’t burden minority members with the need to explain their communities' needs — everybody should be tasked with that research. The minority members might do valuable outreach for you, but don’t pressure them to do so. Each person should have the equal opportunity to participate the way they want, without having to be a token minority.
Guided Exercises
-
Why don’t all contributors give their code to the project and relinquish all rights to the code?
-
If someone wants to help the project but can’t program, what are some ways they can help?
-
Why do many open source projects join a foundation?
Explorational Exercises
-
You are a committer on your project. Someone submits code that was taken from another project (but the contributor has the rights to it). The code is formatted completely differently from the rest of your code. What do you do?
-
You created a proprietary software product and want to contribute parts of it to an open source project. Under what circumstances can you continue to offer your proprietary product?
-
Two people on your mailing list start to argue over a feature in your code. The argument gradually gets more heated until one person calls the other an idiot. How can you handle the situation?
Summary
In this lesson, you learned what it’s like to be part of a community and how communities remain productive. You learned different types of contributions, contributors, and roles. You learned how communities control the right to use contributions. You learned about rules in a community and how they protect everyone, including people of different races and genders, from verbal abuse.
Answers to Guided Exercises
-
Why don’t all contributors give their code to the project and relinquish all rights to the code?
The contributor might want to contribute the same code to a different project or release a product based on the code, and therefore wants to keep some rights.
-
If someone wants to help the project but can’t program, what are some ways they can help?
There are many roles for contributors besides coding. A few such roles include documentation, testing and bug reporting, community management, participating in forms, promoting the project, and doing artwork.
-
Why do many open source projects join a foundation?
A foundation handles many legal, financial, and other tasks that the project’s community might have difficulty doing.
Answers to Explorational Exercises
-
You are a committer on your project. Someone submits code that was taken from another project (but the contributor has the rights to it). The code is formatted completely differently from the rest of your code. What do you do?
Your project’s coding standards should clearly explain how to format the code. Thank the contributor, point them to the standards, and ask them to reformat the code. Sometimes, automated tools exist to reformat code as you want it. If the contributor doesn’t have time to do the reformatting, look for a junior member of your team who can do that job.
-
You created a proprietary software product and want to contribute parts of it to an open source project. Under what circumstances can you continue to offer your proprietary product?
The answer depends on the contributor license agreement. If the CLA requires you to hand the code over to the project, granting them all rights, you might not be able to continue offering your proprietary product. However, if they let you keep your rights to the code, you can release it under any license you like in your proprietary product.
-
Two people on your mailing list start to argue over a feature in your code. The argument gradually gets more heated until one person calls the other an idiot. How can you handle the situation?
Anyone who notices the escalation and the abusive comment should react as quickly as they can. The community manager is ultimately responsible for repairing the damage. The person who intervenes should post a comment to the whole list saying that the behavior violates the project’s code of conduct (which hopefully rules out such behavior.) The person intervening can also reach out to the people on each side separately to make sure they are satisfied by the resolution of the argument and understand how to discuss disagreements constructively.