Contributing to Open Source

• 1: Benefits of Open Source Contribution
• 2: SK Telecom Open Source Contribution Rules
• 3: SK Telecom Open Source Contribution Process
• 3.1: Detailed Contribution Submission Process
• 4: Background on Open Source Contribution
• 4.1: Types of Open Source Contribution
• 4.2: Open Source Project Membership
• 4.3: Key Documents in an Open Source Project
• 4.4: How to Become a Good Contributor
• 4.5: How to Identify a Good Project to Contribute To
• 4.6: How to Communicate

1 - Benefits of Open Source Contribution

Today, any company that develops software naturally uses open source. And many companies do not stop at using open source; they also contribute back to the open source community. Why do they choose to contribute back to open source? Companies that encourage contribution to open source projects do so because they expect the following effects.

Why Should a Company Contribute to Open Source?

What are the purposes and benefits for a company contributing to open source? Why should a company encourage its members to contribute to open source? From a business perspective as well, the reasons a company should contribute to open source are as follows.

1. It Can Reduce Maintenance Costs.

A company uses open source to build products, fixing bugs and adding new features along the way. But what happens if it does not contribute these back to the open source project?

The open source project will keep releasing new versions, including important security patches. Each time, before applying a new version, the company must reapply its own modifications to the new version and then test every time whether the features work without problems and whether there is any impact on performance. If this effort is repeated, the management cost, including the personnel and time required, increases significantly. If the modifications had been contributed to the open source project, they would already be included when a new version is released, so there would be no need for additional maintenance.

Therefore, companies that use open source must educate their developers on the importance of contribution. Of course, contributing to an open source project can take considerable effort and time. Because of tight development schedules, developers may want to apply a patch only to the product right away and not contribute it to the open source project. However, it must be repeatedly emphasized that if the patch is not contributed, the developer will have to reapply their own patch every time a new version is released. The more this work is repeated, the more it becomes a vicious cycle of pouring in more time and effort.

2. It Can Influence the Direction of the Open Source Project.

Do you want an open source project that is important to your product development to add a feature that your company needs? If so, we recommend being active: propose the desired feature to that open source project and, in some cases, directly develop and contribute part of it. After the company contributes in this way, the participation of many people stabilizes and advances the feature, and as a result the project grows in the direction the company wants.

3. It Can Help Recruit Excellent Developers.

The best place to find excellent open source developers is the open source community itself. A company that actively contributes to open source builds a good reputation in the open source community. Excellent developers in the open source community know which companies actively contribute to open source, and they want to work at such companies. It is not easy for a company that does no open source contribution at all to recruit excellent open source developers.

Why Should a Developer Contribute to Open Source?

1. You Can Contribute to the Public Good

When you directly fix a bug or add a new feature to open source you are using, the software is improved and, moreover, everyone who uses the software benefits. With a small contribution, you contribute to the global community.

2. You Can Build Your Skills

Through contributing to open source, you can learn new technologies. Beyond that, you can improve your capabilities through repeated practice and training. Version control, unit testing, integration testing, CI/CD, and the like were born out of open source project development and are now used in almost all software development. You can learn these in open source projects. Furthermore, unlike company work, open source projects are relatively tolerant of beginners’ mistakes, so as long as your will is firm, they are the best space to build your technical capabilities. In open source projects, you can learn not only coding but also practical skills such as UI, graphic design, and writing documentation.

3. You Can Understand Open Source at a Deeper Level and Acquire the Technology

When you go beyond simply using open source and, for the sake of contribution, understand issues and solve problems, you acquire open source technology at a deeper level. Such activity makes it easy to identify and flexibly respond to future changes in the open source, and it can also help you expand your use of open source.

4. You Can Learn Collaboration

The open source community is a space where people from various regions and different time zones around the world come together. Under such constraints, a high level of collaboration ability is needed to carry out a common task. In open source projects, true collaboration that takes into account division of labor and risk management takes place. In addition, you can become familiar with the various tools that support collaboration. Issue trackers, version control systems, and mailing lists are representative examples.

5. You Can Meet New People

Open source has community. People with common interests participate and meet, and through this they can build relationships. Whom you meet can have a major impact on the direction of your career. Once you have a trusting relationship, you can lead each other to new work or jobs. This is possible because in the open source community you always collaborate professionally and can deeply understand each other’s work styles and personalities. The relationships formed while contributing to open source projects are one clear answer to why you should contribute.

6. You Can Build Your Reputation and Career

Open source work is open to everyone. Work done in open source can be shown to anyone, anywhere, which greatly helps raise an individual’s reputation.

7. You Can Learn Leadership

In open source, you can learn leadership and management skills such as team building, conflict resolution, and priority adjustment. To collaborate on an open source project, you have to explain to someone how to do a task, and there are times when you have to ask others for help. Through this process of learning and teaching, you experience leadership and taste a sense of achievement.

2 - SK Telecom Open Source Contribution Rules

SK Telecom respects the value of collaborating with the open source community and, to that end, encourages its members to contribute to external open source projects. However, there are several rules that must be followed to protect SK Telecom’s intellectual property and to prevent unintentional copyright infringement.

Obtain Approval

From a copyright perspective, open source contribution grants the open source project the right to modify, use, and distribute the author’s work. In some cases, you may even have to assign your copyright to the open source project. Generally, however, the copyright of works created during employment is owned by the employer. That is, works created by SK Telecom members are owned by SK Telecom. A member contributing a work to open source at their own discretion can create unnecessary copyright infringement issues.

Therefore, if there is an open source project you want to contribute to, follow the review request and approval process before your first contribution, in accordance with SK Telecom’s open source contribution policy.

• Open Source Contribution Process

Contribute Only Code You Have the Right to Contribute

Contribute only code you have the right to contribute. That is, contribute code you wrote yourself. You must not contribute third-party code at your own discretion.

Be Careful About Disclosing Intellectual Property

Do not contribute code or documents where there is a concern about disclosing the company’s intellectual property, such as sensitive information or patents.

If the code you want to contribute contains a company patent, confirm whether it is permissible to contribute this patent to the project under an open source license. If anything is unclear, contact the OSPO.

Do Not Contribute Substandard Code

Do not contribute substandard code. This can affect the company’s reputation.

Be Careful When Signing a CLA

Some open source projects require all contributors to sign a CLA (Contributor License Agreement). This is an agreement that seeks contributors’ consent in order to reduce copyright disputes that may arise as the project manages works from many contributors. Projects led by large companies typically require signing a CLA.

CLAs differ from project to project, but they mainly contain agreement to the following.

- I (or my company) have the right to contribute the contribution I am about to contribute to the project. (That is, I am the author of this contribution.)
- I (or my company) grant the project the authority to modify, distribute, and manage my contribution.
- I (or my company) will not revoke the authority I have granted.
- I (or my company) grant the project the authority to change the license in the future as needed.

In addition, although it is rare, some CLAs require agreement to the following condition.

- I (or my company), upon contributing my contribution, assign my copyright to the project or the project's managing organization.

To protect its intellectual property, SK Telecom does not permit contributions to open source projects that require copyright assignment. To make this determination, if an open source project you want to contribute to requires signing a CLA, you must request an OSPO review before signing: Open Source Contribution Process.

Most CLAs are not problematic to sign, so the approval process does not take long.

Indicate Copyright

The intellectual property of works created by a member during their employment is, by default, owned by the company. Therefore, when contributing code to an external open source project, members must indicate SK Telecom’s copyright.

When contributing one or more files, indicate the copyright and license at the top of the file as follows.

Copyright 2021 SK TELECOM CO., LTD.
SPDX-License-Identifier: {$SPDX_license_name}

• Here, $SPDX_license_name is written according to the license policy of the relevant open source project.
• However, if you are merely modifying existing code for purposes such as bug fixes, there is no need to indicate copyright for that code modification.
• For detailed copyright and license notation rules, refer to the following page: Copyright and License Notice Within Files

Use Your Company Email

When contributing to open source projects, do not use your personal email; use your SK Telecom email. Through this, (1) members gain a sense of responsibility that they are communicating with the community on behalf of the company, and (2) SK Telecom can improve its recognition as a company that actively contributes to the open source community.

• For how to set up your email on GitHub, refer to the following Link.

3 - SK Telecom Open Source Contribution Process

In accordance with SK Telecom’s open source contribution rules, members follow the contribution process below when contributing to external open source projects.

1. Internal Approval Within Your Organization

Before starting to contribute to an open source project, obtain approval from the responsible executive or leader of your organization.

2. Request an OSPO Review

After obtaining approval within your organization, request a review from the OSPO_{Open Source Program Office}: Support (opensource@sktelecom.com)

• When requesting a review, include the following: [Template]
  • Open source project name
  • Repository
  • License
  • Purpose of contribution
  • Details of contribution
• The OSPO reviews the open source project’s License / CLA and approves it if there are no issues.
• The OSPO compiles the status of open source projects to which SK Telecom members are contributing. The compiled data is used as an expert pool for each open source project.

3. Review the Project’s Contribution Documents

The required process differs slightly from one open source project to another.

• Each project has various guidelines on coding style, language, formatting, bug/ticket management, release timing, and so on.
• Some projects require signing a CLA, while others require a DCO Signed-off-by.
• As for how patches are accepted, most projects now use GitHub Pull Requests, but some still use a mailing list.

For this reason, to properly understand the process of the project you want to contribute to, you must first carefully review the documents the project provides. Most projects provide these documents as a CONTRIBUTING or README file. For example, Kubernetes provides a detailed guide for contributors. (contributing.md: a guide for contributing to Kubernetes) The better you comply with the requirements in the documents, the more likely your contribution is to be accepted.

4. Comply with the Open Source Contribution Rules

Review the SK Telecom Open Source Contribution Rules and improve the code you will contribute accordingly.

5. Submit Your Contribution

Now submit your contribution according to the process required by the project’s documentation. For how to contribute to a typical open source project, refer to the following pages.

• Detailed Contribution Submission Process
• How to Communicate

3.1 - Detailed Contribution Submission Process

Now let’s look at how to submit a contribution. The methods and steps for submitting a contribution to a typical open source project are as follows.

1. Check Prior History

Check whether the contribution you are about to submit has been addressed before. Look through the project’s README, issues, and mailing list. You don’t need to check every document; searching for a few keywords makes it easy to verify.

If you cannot find related content in prior materials, it is time to open an issue or start communicating through a Pull Request. GitHub provides Issues and Pull Request features.

• Issues: You can start a conversation or discussion.
• Pull Request: You contribute a solution to a problem.

Before opening an Issue or Pull Request, check the documents the project provides (typically CONTRIBUTING or README) to confirm the contribution process and method. For example, they may require following a specific template or require pre-testing.

Before starting work on a contribution, it is also a good idea to open an Issue first to let community members know what you intend to work on. In some cases, this can help you avoid doing unnecessary work.

2. Create an Issue

Generally, create an Issue in the following situations.

• Reporting an error you cannot resolve on your own
• Proposing a new feature or idea
• Discussing the community vision or policy

3. Create a Pull Request

Once all the files for your contribution are ready, submit your contribution as a Pull Request.

When to Create a Pull Request

Generally, create a Pull Request in the following situations.

• Submitting minor fixes (e.g., typos, broken links, etc.)
• Starting work on something already discussed in an Issue

A Pull Request does not have to be made only after the work is complete. Generally, it is good to open a Pull Request early to get feedback from others. Mark “WIP” (Work in Progress) in the title line to indicate that it is still in progress, and you can add more commits at any time later.

The Pull Request Process on GitHub

If the project is on GitHub, you can refer to the following when submitting a Pull Request.

Step 1. Fork

Fork the upstream repository to your own GitHub account.

Step 2. Clone

Clone the forked repository to your own local working directory.

$ mkdir -p $working_dir
$ cd $working_dir
$ git clone https://github.com/$user/[repository]

Add the upstream repository as a remote.

$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
 
# Confirm that your remotes make sense:
$ git remote -v

Step 3. Create a branch

First, fetch and rebase the main branch to keep it up to date.

$ cd $working_dir/[repository]
$ git fetch upstream
$ git checkout main
$ git rebase upstream/main

Then create a development branch (myfeature).

$ git checkout -b myfeature

Step 4. Keep your branch in sync

Fetch and rebase the branch to keep it up to date.

# While on your myfeature branch
$ git fetch upstream
$ git rebase upstream/main

Then do your code work in that state.

Step 5. Commit

Commit your changes.

$ git commit -a -m '[commit message]'

Step 6. Push

Push the changes on the myfeature branch to your own GitHub repository.

git push -f origin myfeature

Step 7. Create a pull request

When you go to your repository on GitHub, you will see that the Compare & pull request button is enabled. Click it to create a Pull Request.

After that, the maintainer of the upstream repository reviews the requested Pull Request and decides whether to merge it.

4. Receive Feedback

Once you submit your contribution, you will receive feedback from the project. Feedback generally asks for an explanation of how the improvement or change works and why you adopted that approach. This feedback can sometimes be difficult to respond to, but it is best to accept it as a process that raises the level of your contribution.

Feedback usually falls into one of the following four categories.

(1) No Response?

Before contributing, it is good to first check whether the project is active. Even in a fairly active project, you may not receive a response to your contribution.

If you have not received a response for more than a week, it is good to politely ask someone in the same thread to review it. If you know the name of the appropriate person, use the @-mention feature.

Even so, for various reasons, no one may respond. It is not a great feeling, but there is no need to be discouraged. This can happen to anyone. Look for another way to contribute or another project.

(2) A Request for Changes?

It is common to be asked to explain your idea or to revise your code. If someone requests changes like this, respond promptly. They took their own time to review your contribution.

Leaving a PR open without responding is impolite. If you are no longer in a position to solve the problem, let the Maintainer know that you cannot proceed further. Then they can close the PR or someone else can take it over and continue.

(3) Rejected?

Your contribution may ultimately be accepted, or it may not. If you do not clearly understand the reason it was not accepted, it is reasonable to ask the Maintainer for an explanation. However, you must respect that this is their decision. Do not argue or act with hostility. If differences are never reconciled, you can always fork and work on your own project.

(4) Accepted!

Congratulations! You have finally succeeded in contributing to open source.

4 - Background on Open Source Contribution

4.1 - Types of Open Source Contribution

In open source projects, software developers mainly contribute by modifying source code to fix bugs or improve features. However, developers are not the only ones who can contribute to open source projects. Open source projects need various types of contributions, such as documentation and design, as described below.

Writing Documentation / Translation

• Write project documentation and tutorials. (e.g., PyPA’s contributors did)
• Write the project’s newsletter or summarize key points from the mailing list.
• Translate the project’s documentation into your own language.

Testing / Creating Issues

• Test whether the software works correctly.
• Test whether it builds / installs as described in the documentation.
• Check whether the documentation and API are written consistently.

Design

• Improve the layout, menus, and so on of the project’s website. (e.g., Drupal suggest)
• Create a style guide so the project can have a consistent design.
• Contribute to creating a new logo or T-shirt. (e.g., hapi.js’s contributors did)

Writing / Reviewing Code

• Find an open issue you can resolve. (e.g., @dianjin did for Leaflet)
• Add new features.
• Improve tools and testing for automation.
• Review code submitted by others.
• Become a mentor to other contributors. (e.g., @ereichert did for @bronzdoc on Rust)

Marketing

• Promote the project’s purpose and usefulness in various ways, such as on social media and through seminar presentations.

Events

• Plan and host various gatherings such as the project’s conferences, workshops, and meetups. (e.g., fzamperin did for NodeSchool)

4.2 - Open Source Project Membership

How can an open source project continue to develop high-quality software through collaborative work? How can many people who do not know each other write code together and produce stable software? Open source projects achieve this through clearly defined roles.

Leader

Every project has a leader, and the founder usually takes on this role. The leader determines the direction of the project and is responsible for the final decision when a decision is needed. The leader may be an individual, but for large projects, a Steering Committee is organized to perform the leader’s role.

• For example, Linus Torvalds, as the original author of the Linux Kernel, has the final say on every matter of its progress.
• In the case of the Node.js project, the Technical Steering Committee performs the leader’s role.

Maintainer

Maintainers are core contributors who possess the most trusted technical capabilities in the project. They are delegated specific areas by the leader and take on the role of managing them proactively.

Committer

Committers are those who sufficiently understand the code of specific modules in the project and contribute regularly. They have the authority to review and approve contributors’ contributions, and for certain modules they can merge without the maintainer’s approval.

Contributor

Anyone who has contributed, even in a small way, is a contributor. Contributors contribute to open source projects through methods such as simple bug fixes and documentation. Such contributions are reviewed and supplemented by experienced committers and maintainers, and then merged into the repository.

User

Users play the role that determines the success or failure of an open source project. No matter how well prepared a project is, it cannot succeed if no one uses it. By using the project and providing ideas such as bug reports and new feature suggestions, users give the project its reason for existing.

• If a project’s leader and contributors do not carefully listen to users’ requests, it is difficult for the project to grow healthily over the long term.
• A project can only be sustained if it grows in a direction that meets users’ needs.

4.3 - Key Documents in an Open Source Project

To contribute properly, it is important to understand how each open source project works and to act as the project expects. Most open source projects communicate these requirements through documents such as the README and CONTRIBUTING. Open source projects commonly include several such documents, usually located at the top level of the repository. Before contributing, you should use these documents to familiarize yourself with the project’s culture, code of conduct, and contribution methods.

README

The README is the file you see when you first approach a project. It introduces the project, explains why you should use it, how to use it, and more. It is a must-read document for understanding what the project is.

LICENSE (or COPYING)

The LICENSE is the file containing the open source license, which states that anyone may use the project. Every open source project must have an open source license. Without an open source license, it is not open source. In that case, the source code has been disclosed, but the right to use or distribute it has not been granted. Be aware that including such source code in a product or service carries the risk of copyright infringement.

CONTRIBUTING

If the README is a document for people who use the project, CONTRIBUTING is a document for people who contribute to the project. Because it explains what types of contributions are needed and how to contribute, you should examine this document carefully when you want to contribute to open source. Contributors must follow the contribution methods described in this document.

If the project you want to contribute to has no CONTRIBUTING file, ask the community how to contribute. If you do not receive an appropriate response, you may regard it as a project not worth contributing to and look for another project.

CODE OF CONDUCT

The CODE OF CONDUCT, also called a code of conduct or behavioral guidelines, defines the rules of conduct for participants so that the project stays healthy. For example, it emphasizes that there must be no discrimination based on gender, race, religion, age, and so on, that everyone is warmly welcomed, and that participants must act to ensure safe activity. It also explains how to report someone who breaks those rules.

Other Documents

(For large open source projects) documents such as tutorials and governance policies may also be provided.

4.4 - How to Become a Good Contributor

Before getting into how to submit contributions in earnest, let’s briefly look at how to become a good contributor. Of course, since every project operates differently, there is no single right answer. Each time you join a new project, you need to invest time in learning how it operates. Even so, the following points are commonly helpful in becoming a good contributor.

1. Join the Community

Open source projects have a community of users and developers. Each community participates in slightly different ways. Read the documentation the community provides, and join its main communication channels such as the mailing list, forums, IRC, Slack, and bug tracker.

2. Observe for a While

After joining the community, take some time to get familiar with its culture before contributing. Reviewing past communications is a good approach. The more you go through this process, the more likely your first contribution is to be accepted.

3. Understand the Governance

Before contributing, use the project’s management and governance documents to understand how the project is governed. You can learn who makes decisions and how.

4. Start Small

Start with a simple bug fix or documentation change. It is good to learn the process and correct mistakes by making small, low-stakes contributions. Building on this experience, you can contribute more substantially and gradually have an impact on the project.

5. Attend Events

Building lasting relationships with other participants in the open source community is important. The best way to do this is to attend events such as conferences. Nothing builds relationships like meeting in person.

6. Contribute from the Early Stages of the Code

Some people finish developing until the amount of code becomes quite large and then try to contribute it all at once. Such contributions are not easily accepted by open source projects. It is difficult for a project to review a large amount of code at once, and the contributed code may differ from the direction the project wants. Discuss with the community starting from the idea stage, and contribute early in development and often.

4.5 - How to Identify a Good Project to Contribute To

Naturally, you should contribute to open source projects that are related to your work or in an area of technical interest. If there are several such projects, it is also worth considering which one is worth contributing to. Otherwise, your hard-earned contribution may be buried without any response.

The following is a checklist for determining whether an open source project you are interested in is suitable for contribution activity.

1. Is There an Open Source License File?

• Is there a LICENSE file? Typically, there is a file named LICENSE in the root directory of the repository.

A project to which no open source license applies is not open source. Only when the software’s copyright holder grants, through an open source license, the right for anyone to use and distribute it can a company use that software freely. Using software without an open source license at will can create legal risks such as copyright infringement.

2. Is the Project Actively Receiving Contributions?

• When was the most recent commit?
• How many contributors are there?
• How frequent are the commits?

If there are few contributors or there have been no commits for several years, the project can be considered unmaintained.

On GitHub, you can check the commit status under “Commits” at the top of the screen.

3. Check the Project’s Issues

• How many issues are open?
• When an issue is opened, do maintainers respond quickly?
• Is there active discussion on the issues?
• Are the issues recent?
• Are issues being closed?

If issues are not being opened, or if they are opened but not responded to, the project can be considered unmaintained.

On GitHub, you can check the status of closed issues by looking at the “closed” tab on the Issues page.

4. Check the Project’s Pull Requests

• How many Pull Requests are open?
• When a Pull Request is opened, do maintainers respond quickly?
• Is there active discussion on the Pull Requests?
• Are the Pull Requests recent?
• How recently have Pull Requests been merged?

On GitHub, you can see closed Pull Requests by clicking the “closed” tab on the Pull Request page.

5. Does the Project Have a Welcoming Atmosphere for Contributions?

• Do maintainers give helpful answers to questions about issues?
• Are people friendly in issues, forums, and chat (such as Slack)?
• When you submit a Pull Request, does a review take place?
• Do maintainers show appreciation for people’s contributions?

A project that does not have a welcoming atmosphere for contributions is unlikely to develop well over the long term. This can also be a criterion for judging whether a project is worth contributing to.

4.6 - How to Communicate

Every part of the open source contribution process is a continuous series of communications with community members. First, keep the following points in mind for effective communication.

Communicate Your Intent Precisely

If you are reporting an error, explain precisely what task it occurred during and how to reproduce it. If you are proposing a new idea, explain why you think it would be useful to the project.

Do Not Just Ask; First Try What You Can Do Yourself

Before asking for help, look for the answer in the project’s documentation such as the README, in issues, in the mailing list, or through a search. It is good to show this kind of effort.

Keep Conversations as Concise as Possible

Every contribution you submit has to be reviewed by someone. Some projects accumulate so many contributions and requests that they are difficult to review. Therefore, the more concise your request, the more likely it is to be accepted.

Make All Communication Public

Contacting maintainers privately is not a good practice. Keep all conversations public. This allows more people to learn and benefit.

Once You’ve Asked, Be Patient

Even maintainers cannot handle everything perfectly. They also need time to review.

Respect the Community’s Decisions

Your ideas may differ from the project’s priorities or vision. The community may decide not to adopt your idea. You must accept this. If you cannot find a compromise, or can never agree, you should consider forking and starting your own new project.

Above All, Maintain Your Dignity

In open source projects, you collaborate with members from all over the world. Depending on language, culture, region, and time zone, there are differences in communication styles. Also, because you communicate through writing rather than face to face, it can be difficult to convey tone and mood accurately. A good way to overcome these difficulties is to always interpret others’ writing in good faith. When declining someone’s proposal, be polite, and express your own position clearly. Conduct yourself with dignity in the online space that is open source.