Open Source Collaboration

Preface

Want to contribute to open source but don't know where to start? Open source is more than "using other people's code for free" — it's a way of collaborating and a career accelerator. One high-quality open source contribution can be more convincing than ten personal projects on your resume.

This chapter walks you through the complete open source collaboration process, from finding projects to submitting PRs, and helps you take your first step in open source contribution.

What will you learn in this article?

Chapter	Content	Core Concepts
Chapter 1	Open source contribution process	The complete chain from Fork to PR
Chapter 2	Open source licenses	Differences between licenses
Chapter 3	Collaboration etiquette	How to be a welcomed contributor
Chapter 4	Contributing from scratch	Finding beginner-friendly projects

After reading this chapter, you will master the complete process and etiquette of open source collaboration, and have the confidence to submit contributions to any open source project.

---

0. The Big Picture: The Value of Open Source

Open source is more than code sharing — it's a global collaboration model. Linux, React, Vue, Node.js — these world-changing projects are all open source.

Benefits of Participating in Open Source

• Technical Growth: Read excellent code, receive expert reviews
• Career Development: Open source contributions are the best technical calling card
• Community Belonging: Become a member of the global developer community
• Giving Back: The tools you use every day need people to maintain them

---

1. Open Source Contribution Process

Use the interactive component below to step through the complete process from Fork to Merge:

Open-source contribution workflow - click a step for details

1Fork

2Clone

3Branch

4Commit

5Push

6PR

7Review

8Merge

🍴 Fork

Fork the target repository on GitHub into your own account to get a full copy.

Command

# Click the Fork button on GitHub

1.1 Process Overview

Fork → Clone → Branch → Commit → Push → PR → Review → Merge

1.2 Key Steps in Detail

Create a feature branch: Never develop directly on main.

git checkout -b fix/typo-in-readme

Write clear commit messages: Follow the project's commit conventions.

git commit -m "fix: correct typo in README install command"

Create a Pull Request: The PR description should include:

• What changed and why
• Related issue number (e.g., Fixes #123)
• How to test your changes

---

2. Open Source Licenses

Use the interactive component below to compare common open source licenses:

Open-source license comparison tool

My needs:

License	Commercial use	Modify	Distribute	Patent grant	Private use	Open derivatives	Liability waiver
MITVery permissive, almost no restrictions	✓	✓	✓	✗	✓	✗	✓
Apache 2.0Permissive plus patent protection	✓	✓	✓	✓	✓	✗	✓
GPL 3.0Strong copyleft, derivatives must be open source	✓	✓	✓	✓	✓	✓	✓
BSD 2-ClauseSimilar to MIT, minimal and permissive	✓	✓	✓	✗	✓	✗	✓
MPL 2.0File-level copyleft, a middle ground	✓	✓	✓	✓	✓	⚠	✓

✓ Allowed✗ Not allowed / limited⚠ Conditional

2.1 Common Licenses

License	Characteristics	Notable Projects
MIT	Most permissive, almost no restrictions	React, Vue, jQuery
Apache 2.0	Must retain copyright notice, includes patent grant	Android, Kubernetes
GPL	Derivative works must also be open source	Linux, WordPress
BSD	Similar to MIT, with slight differences	FreeBSD, Flask

2.2 How to Choose?

• Want more people to use it: Choose MIT
• Want to protect patents: Choose Apache 2.0
• Want to ensure derivatives stay open source: Choose GPL

---

3. Collaboration Etiquette

3.1 Etiquette for Filing Issues

<!-- Bad -->
Title: It doesn't work
Content: Your stuff has bugs

<!-- Good -->
Title: v2.1.0 login page shows white screen on Safari 17
Content:
- Environment: macOS 14.2, Safari 17.2
- Steps to reproduce: 1. Open login page 2. Enter credentials 3. Click login
- Expected behavior: Redirect to home page
- Actual behavior: White screen, console error TypeError: xxx
- Screenshot: [attached]

3.2 Etiquette for Submitting PRs

• Read CONTRIBUTING.md first to understand the project's contribution guidelines
• One PR should do one thing only — don't mix multiple changes
• Keep PRs small and focused for easier review
• Be patient waiting for review and respond to feedback politely

3.3 Reviewing Others' Code

• Acknowledge what's done well first, then suggest improvements
• Ask rather than command: "Have you considered using approach X here?"
• Give reasons and alternatives, not just "not good"

---

4. Contributing from Scratch

4.1 Beginner-Friendly Contribution Types

Type	Difficulty	Description
Fix documentation errors	Low	Typos, outdated links, unclear instructions
Translation	Low	Translate documentation into other languages
Add tests	Medium	Write tests for uncovered code
Fix bugs tagged good first issue	Medium	Beginner-friendly issues marked by project maintainers
New features	High	Discuss the approach in an Issue first, get approval before starting

4.2 Finding the Right Project

• Start with tools you use daily
• Search for good first issue labels on GitHub
• Check project activity (are there recent maintainers?)

---

5. AI-Powered: Using LLMs to Accelerate Open Source Contributions

LLMs can help you quickly understand unfamiliar codebases, write high-quality PR descriptions, and even assist with code reviews.

5.1 Quickly Understanding Unfamiliar Codebases

Prompt:

I just cloned an open source project. Please analyze the following
directory structure, explain the responsibility of each directory/file,
and describe the overall architecture and data flow.
I want to fix a login-related bug — where should I start looking?

[Paste tree command output or directory structure]

5.2 Writing PR Descriptions

Prompt:

Based on the following git diff, write a Pull Request description including:
- Title (concise, stating what changed)
- Change description (why and what changed)
- Testing method (how to verify the change is correct)
- Related issue (if any)
Write in English with a professional and friendly tone.

[Paste git diff output]

5.3 Assisting with Document Translation

Prompt:

Translate the following Chinese technical document into English, with these requirements:
1. Use industry-standard English expressions for technical terms
2. Do not translate code comments and variable names
3. Keep Markdown formatting unchanged
4. Natural and fluent tone, not machine-translated

[Paste Chinese document]

AI Usage Advice

When using AI to write PR descriptions, make sure you understand every line of change. Reviewers may ask why you made a certain change — if you can't answer, it means you haven't truly understood it yet.

---

6. Summary

1. Process: Fork → Branch → Commit → PR → Review → Merge
2. Licenses: MIT is most permissive, GPL is most strict — choose based on your needs
3. Etiquette: Clear issues, focused PRs, polite communication
4. Getting Started: Start with documentation fixes and good first issue labels

Final Thought

The essence of open source is collaboration. Technical skills are important, but communication skills and collaboration awareness are equally crucial. A friendly, well-described PR is more welcome than a perfectly coded but rudely communicated one. Your first PR doesn't need to be perfect — it just needs to be your first step.

---

Further Reading

• Getting Started Guide: GitHub's Open Source Guide is the best resource for open source beginners.
• Practical Advice: Find a project you like, star it first, then read the code, and eventually find an opportunity to contribute.
• Community Participation: Join open source events like Hacktoberfest for community support.
• Maintainer's Perspective: Understand the workload and pressure of maintainers — be a considerate contributor.