GitHub לקוד פתוח — קהילה ותרומה

10.1 למה קוד פתוח חשוב — ומה זה נותן לך

קוד פתוח (Open Source Software / OSS) הוא לא רק פילוסופיה — זו תשתית של תעשיית התוכנה כולה. כמעט כל אפליקציה שאתם משתמשים בה מורכבת מעשרות עד אלפי packages של קוד פתוח. React, Node.js, Linux, Kubernetes, VS Code, Git עצמו — כל אלה קוד פתוח.

אבל למה אתם צריכים להתעניין בזה? שלוש סיבות מעשיות:

1. קריירה. פרופיל GitHub עם תרומות לפרויקטים מוכרים שווה יותר מעשרה שורות ב-CV. מנהלי גיוס מסתכלים על contribution graph, על PRs שהתקבלו, על פרויקטים שבניתם. זה proof of work שאי אפשר לזייף.
2. מיומנות. לתרום לפרויקט אמיתי — עם code review, CI pipeline, coding standards — מלמד אתכם יותר מעשרה צוותים פנימיים. אתם נחשפים לארכיטקטורות שונות, סגנונות קוד שונים, ותהליכי עבודה מקצועיים.
3. השפעה. תיקון באג ב-library שמשרתת מיליון מפתחים? זו השפעה אמיתית. בניית כלי שפותר בעיה שלכם? סביר שעוד אלפים צריכים אותו.

ועוד נקודה שרבים מפספסים: GitHub נותן יתרונות משמעותיים לפרויקטי קוד פתוח. ריפוזיטורים ציבוריים מקבלים Actions minutes ללא הגבלה, Packages storage בחינם, ו-GitHub Advanced Security (GHAS) — כולל CodeQL — ללא עלות. פרויקט פתוח ב-GitHub הוא סביבת פיתוח מלאה, בחינם.

הנוף של קוד פתוח ב-GitHub

כמה מספרים שמראים את הסקאלה:

• מעל 420 מיליון ריפוזיטורים ב-GitHub (כולל פרטיים)
• מעל 100 מיליון מפתחים רשומים
• מעל 4 מיליארד תרומות (contributions) בשנה
• פרויקטים כמו torvalds/linux, facebook/react, microsoft/vscode — כולם חיים ב-GitHub

הרעיון הוא פשוט: אתם כבר חלק מהאקוסיסטם הזה בכל פעם שאתם עושים npm install או pip install. הפרק הזה ילמד אתכם להיות חלק פעיל — לא רק צרכנים, אלא גם תורמים ויוצרים.

מה GitHub נותן בחינם לפרויקטי קוד פתוח

GitHub מתייחס לפרויקטי קוד פתוח כאזרחים ממדרגה ראשונה. הנה מה שריפוזיטורי ציבורי מקבל בחינם:

כלומר, פרויקט קוד פתוח מקבל בחינם דברים שעולים כסף לריפוזיטורים פרטיים. זו סיבה נוספת לשקול להפוך חלק מהפרויקטים שלכם לציבוריים — לא רק בגלל הקהילה, אלא בגלל הכלים.

דוגמאות מייצגות: מפתחים שבנו קריירה מקוד פתוח

קוד פתוח יכול להיות מנוע קריירה חזק. הנה כמה דפוסים נפוצים:

• מפתח שמתקן באגים בספריות שהוא משתמש בהן — כל fix ב-package שמוריד מיליון פעמים בשבוע = נראות גבוהה. Maintainers שמים לב לתורמים עקביים.
• מפתחת שבונה כלי CLI פתוח — פותרת בעיה שלה, משחררת כ-OSS, הכלי צובר stars, היא מזוהה כמומחית בתחום.
• צוות סטארטאפ שמשחרר ספרייה פנימית כ-OSS — הספרייה מקבלת תרומות מהקהילה, הסטארטאפ מקבל branding ו-recruiting advantage.

בישראל הדפוס הזה חזק במיוחד — חברות כמו Wix, Monday.com ו-Snyk משחררות כלים פנימיים כקוד פתוח, ומפתחים ישראלים מובילים פרויקטים בינלאומיים רבים.

10.2 לתרום לפרויקט קוד פתוח — מאפס לתורם מוכר

הרבה מפתחים רוצים לתרום לקוד פתוח אבל לא יודעים מאיפה להתחיל. התהליך נראה מפחיד — פרויקטים גדולים, קוד לא מוכר, code review מ-strangers. אבל בפועל, התהליך מובנה ומוגדר היטב. בואו נפרק אותו לשלבים.

שלב 1: מצאו פרויקט מתאים

לא כל פרויקט מתאים לתרומה ראשונה. חפשו את הסימנים האלה:

• קובץ CONTRIBUTING.md קיים — סימן שהפרויקט מקבל תרומות ויש תהליך מוגדר
• Issues עם label good first issue — בעיות שה-maintainers סימנו כמתאימות למתחילים
• פעילות אחרונה — PRs שמתמזגים, issues שנסגרים, commits אחרונים
• Code of Conduct — סימן שהקהילה מקפידה על סביבה מכבדת
• CI ירוק — סימן שהפרויקט מתוחזק ויש בדיקות אוטומטיות

מקומות לחפש:

• github.com/explore — דף Trending של GitHub
• goodfirstissue.dev — מנוע חיפוש ל-good first issues
• up-for-grabs.net — פרויקטים שמחפשים תורמים חדשים
• חפשו ב-GitHub: is:issue is:open label:"good first issue" language:javascript

שלב 2: Fork ו-Clone

לא עובדים ישירות על הריפוזיטורי המקורי. עושים fork — עותק אישי שלכם — ועובדים עליו:

# Fork דרך gh cli (המהיר ביותר)
gh repo fork owner/project --clone

# או ידנית:
# 1. לחצו Fork בדף הריפוזיטורי
# 2. Clone של ה-fork שלכם:
git clone https://github.com/YOUR-USERNAME/project.git
cd project

# הגדירו את ה-upstream (הריפו המקורי)
git remote add upstream https://github.com/owner/project.git
git fetch upstream

שלב 3: צרו branch עם שם ברור

# תמיד עבדו מ-branch חדש, לא מ-main
git checkout -b fix/typo-in-readme
# או
git checkout -b feat/add-hebrew-translation
# או
git checkout -b docs/update-installation-guide

מוסכמה נפוצה: type/short-description — כש-type הוא fix, feat, docs, refactor, test.

שלב 4: עבדו, commit, push

# עשו את השינויים שלכם
# ודאו שאתם עוקבים אחרי ה-CONTRIBUTING.md של הפרויקט

# Commit עם הודעה ברורה
git add .
git commit -m "fix: correct typo in installation section of README"

# Push ל-fork שלכם
git push origin fix/typo-in-readme

שלב 5: פתחו Pull Request

# דרך gh cli
gh pr create --title "fix: correct typo in installation section" \
  --body "Fixes a small typo in the README installation instructions.

## Changes
- Fixed 'instll' → 'install' in line 42

## Testing
- Verified the README renders correctly on GitHub"

# או דרך GitHub UI — GitHub יציע אוטומטית ליצור PR אחרי ה-push

כמה כללים ל-PR טוב:

• כותרת ברורה — מה השינוי עושה, בקצרה
• תיאור מפורט — למה, מה השתנה, איך לבדוק
• PR קטן ומוגדר — שינוי אחד = PR אחד. לא שני פיצ'רים ב-PR אחד
• עקבו אחרי הסגנון — אם CONTRIBUTING.md אומר Conventional Commits, תעקבו
• היו סבלניים — code review לוקח זמן. Maintainers הם בדרך כלל volunteers

שלב 6: Code Review והתאמות

אחרי שפתחתם PR, ה-maintainers יעשו code review. מה לצפות:

• שאלות — "למה בחרת בגישה הזו?" — ענו בנימוס ובבהירות
• בקשות שינוי — "אנא שנה X ל-Y" — עשו את השינויים ודחפו שוב לאותו branch
• CI failures — אם הבדיקות נכשלות, תקנו לפני שמבקשים review נוסף
• דחייה — קורה. לא אישי. למדו מהמשוב והמשיכו לפרויקט הבא

סוגי תרומות — זה לא רק קוד

הרבה מפתחים חושבים שתרומה = כתיבת קוד. אבל פרויקטי קוד פתוח צריכים הרבה יותר:

הנקודה החשובה: תרומות תיעוד ו-triage הן לעתים קרובות מבוקשות יותר מקוד. Maintainers תמיד מחפשים עזרה בדברים ש"אף אחד לא רוצה לעשות". אם אתם מתחילים — תיעוד וניהול issues הם הדרך הטובה ביותר להיכנס לפרויקט.

סנכרון Fork עם Upstream — שלב שרבים מפספסים

אחרי שעשיתם fork, הריפוזיטורי המקורי (upstream) ממשיך להתקדם. אם לא תסנכרנו, תיתקלו ב-merge conflicts. הנה איך לשמור על ה-fork מעודכן:

# סנכרון ה-fork עם ה-upstream
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

# או דרך gh cli (פשוט יותר):
gh repo sync

# או דרך GitHub UI:
# בדף ה-fork שלכם, לחצו "Sync fork" ← "Update branch"

מתי לסנכרן: לפני שמתחילים עבודה על branch חדש. תמיד. אם ה-fork שלכם 50 commits מאחור ב-upstream, כל PR שתפתחו יהיה בעייתי.

10.3 רישיונות — MIT, Apache, GPL ומה שביניהם

רישיון (LICENSE) הוא המסמך המשפטי שקובע מה מותר לעשות עם הקוד שלכם. בלי רישיון, הקוד שלכם הוא all rights reserved כברירת מחדל — אף אחד לא יכול להשתמש בו, לשנות אותו, או להפיץ אותו, גם אם הריפוזיטורי ציבורי.

זה אחד הדברים שמפתחים רבים מפספסים: ציבורי (public) לא אומר חופשי (free to use). ריפוזיטורי ציבורי בלי LICENSE = אפשר לקרוא את הקוד, אבל אסור לעשות איתו שום דבר אחר.

שלושת הרישיונות הנפוצים

עוד רישיונות שתפגשו

• BSD 2-Clause / 3-Clause — דומה ל-MIT, קצת יותר מפורט. פופולרי בעולם ה-BSD/Unix.
• ISC — גרסה מינימלית של MIT/BSD. npm משתמש ברישיון הזה.
• LGPL — GPL "רך" — מאפשר link ללא copyleft. נפוץ בספריות C.
• AGPL — GPL + חובה לשתף קוד גם ב-SaaS. שימושי אם אתם רוצים למנוע "SaaS loophole".
• Unlicense / CC0 — ויתור מלא על זכויות — public domain. הכי חופשי שאפשר.

איך מוסיפים רישיון

# הדרך הקלה ביותר — דרך GitHub UI:
# 1. Repository ← Add file ← Create new file
# 2. כתבו "LICENSE" בשם הקובץ
# 3. GitHub יציע לכם לבחור רישיון מתוך template
# 4. בחרו, מלאו פרטים, commit

# דרך gh cli (אם הריפו כבר קיים):
# הוסיפו LICENSE מתוך template
gh repo edit --default-branch main
# ואז ב-GitHub UI: Settings ← "Add a LICENSE"

# או פשוט צרו קובץ LICENSE בשורש הריפו
# והדביקו את הטקסט מ-https://choosealicense.com/

GitHub מזהה את הרישיון אוטומטית ומציג badge בראש הריפוזיטורי. אם הקובץ לא מוכר, בדקו שהשם הוא LICENSE (בלי סיומת) והתוכן מתאים לתבנית הסטנדרטית.

תאימות בין רישיונות — מתי יש בעיה

אם הפרויקט שלכם משתמש בספריות עם רישיונות שונים, אתם צריכים להבין תאימות:

• MIT + MIT = בסדר — שני רישיונות permissive, בלי בעיה
• MIT + Apache 2.0 = בסדר — שניהם permissive, תאימות מלאה
• MIT + GPL = זהירות — הקוד הסופי שלכם חייב להיות GPL (copyleft "מדביק")
• Apache 2.0 + GPL 2.0 = בעיה — לא תואמים. GPL 3.0 כן תואם ל-Apache 2.0
• GPL + proprietary = אסור — לא ניתן לשלב קוד GPL בתוכנה קניינית סגורה

כלל אצבע: אם אתם לא בטוחים, השתמשו ב-license-checker (npm) או pip-licenses (Python) לסרוק את התלויות שלכם ולבדוק תאימות:

# Node.js — בדיקת רישיונות של כל התלויות
npx license-checker --summary

# Python
pip install pip-licenses
pip-licenses --format=table

רישיון לתוכן (לא קוד)

אם הפרויקט שלכם כולל תיעוד, תמונות, או תוכן לא-קודי — שקלו רישיון Creative Commons. CC BY 4.0 הוא הנפוץ ביותר: מאפשר כל שימוש בתנאי ייחוס. הפרדה נפוצה: MIT לקוד, CC BY 4.0 לתיעוד.

10.4 README Profile — הפרופיל האישי שלך

GitHub מאפשר ליצור README שמופיע ישירות בעמוד הפרופיל שלכם. הטריק: צרו ריפוזיטורי עם בדיוק אותו שם כמו ה-username שלכם. GitHub מזהה את זה כ-"profile repository" ומציג את ה-README.md שלו בראש הפרופיל.

איך מתחילים

# צרו ריפוזיטורי חדש עם השם של ה-username שלכם
# אם ה-username שלכם הוא "dana-dev":
gh repo create dana-dev --public --description "My GitHub profile" --clone
cd dana-dev

# צרו README.md
touch README.md

GitHub יציג הודעה מיוחדת: "dana-dev/dana-dev is a special repository. Its README.md will appear on your public profile."

מבנה מומלץ ל-README profile

אין מבנה חובה, אבל הנה template שעובד היטב:

# Hi, I'm Dana 👋

## About Me
- 🔭 Currently working on [project-name](link)
- 🌱 Learning TypeScript and Kubernetes
- 💬 Ask me about React, Node.js, CI/CD
- 📫 Reach me: dana@example.com

## Tech Stack
![TypeScript](https://img.shields.io/badge/-TypeScript-3178C6?logo=typescript&logoColor=white)
![React](https://img.shields.io/badge/-React-61DAFB?logo=react&logoColor=black)
![Node.js](https://img.shields.io/badge/-Node.js-339933?logo=node.js&logoColor=white)
![GitHub Actions](https://img.shields.io/badge/-GitHub_Actions-2088FF?logo=github-actions&logoColor=white)

## GitHub Stats
![GitHub Stats](https://github-readme-stats.vercel.app/api?username=dana-dev&show_icons=true&theme=tokyonight)

## Recent Projects
- [awesome-tool](link) - CLI tool for X
- [cool-lib](link) - Library that does Y

שירותים שימושיים ל-profile:

• Shields.io — badges מותאמים לכל טכנולוגיה. shields.io
• GitHub Readme Stats — כרטיסי סטטיסטיקות אוטומטיים. github-readme-stats
• GitHub Profile Trophy — "פרסים" על הפעילות שלכם. github-profile-trophy
• GitHub Streak Stats — כמה ימים רצופים של contributions. streak-stats

Pinned Repositories — מה שאנשים רואים ראשון

בנוסף ל-README, תוכלו לנעוץ (pin) עד 6 ריפוזיטורים שמופיעים בולט בפרופיל. לכו ל-Profile ← "Customize your pins". בחרו את הפרויקטים שהכי מייצגים את היכולות שלכם — לא בהכרח הגדולים ביותר, אלא אלו שמראים את הטוב ביותר שלכם.

10.5 README מקצועי לפרויקט — הדלת הראשית

ה-README של פרויקט הוא הדבר הראשון שכל מבקר רואה. README טוב הוא ההבדל בין "מעניין, בוא נבדוק" ל-"מה זה? הלאה". זה לא רק תיעוד — זה שיווק.

README מקצועי חייב לענות על 5 שאלות בתוך 30 שניות:

1. מה זה? — תיאור קצר וברור
2. למה שאשתמש בזה? — מה הבעיה שזה פותר
3. איך מתקינים? — הוראות התקנה מדויקות
4. איך משתמשים? — דוגמת קוד מינימלית
5. האם זה maintained? — badges, activity, license

מבנה מומלץ

# Project Name

[![CI](https://github.com/user/repo/actions/workflows/ci.yml/badge.svg)](link)
[![npm version](https://img.shields.io/npm/v/package)](link)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](link)

> One-line description of what this does.

## Features
- ✅ Feature one
- ✅ Feature two
- ✅ Feature three

## Quick Start

```bash
npm install my-package
```

```javascript
const myPackage = require('my-package');
myPackage.doSomething();
```

## Installation
Detailed installation instructions...

## Usage
Detailed usage examples...

## API Reference
If applicable...

## Contributing
See [CONTRIBUTING.md](CONTRIBUTING.md)

## License
[MIT](LICENSE)

טיפים:

• Screenshots / GIFs — תמונה שווה אלף מילים. הוסיפו screenshot של ה-output או GIF של השימוש
• Badges — CI status, npm version, license, coverage. shields.io ליצירת badges מותאמים
• Table of Contents — אם ה-README ארוך מ-100 שורות, הוסיפו TOC
• דוגמאות קוד שעובדות — כל דוגמה ב-README חייבת להיות copy-paste-ready

Badges — אותות ויזואליים

Badges (תגיות) בראש ה-README משדרים מידע בהצצה אחת. הנפוצים ביותר:

[![CI](https://github.com/USER/REPO/actions/workflows/ci.yml/badge.svg)](https://github.com/USER/REPO/actions)
[![npm](https://img.shields.io/npm/v/PACKAGE)](https://www.npmjs.com/package/PACKAGE)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
[![Downloads](https://img.shields.io/npm/dm/PACKAGE)](https://www.npmjs.com/package/PACKAGE)
[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/USER/REPO/badge)](https://securityscorecards.dev/viewer/?uri=github.com/USER/REPO)

כלל אצבע: אל תוסיפו יותר מ-6-7 badges. יותר מזה נראה עמוס ומפחית את ההשפעה. הציגו רק badges שנותנים ערך — CI status, version, license. אל תוסיפו badges שרק "נראים יפה" בלי מידע אמיתי.

10.6 קבצי קהילה — CONTRIBUTING, Code of Conduct ו-Templates

פרויקט קוד פתוח שרוצה לקבל תרומות צריך תשתית קהילתית. בלעדיה, תורמים פוטנציאליים לא יודעים מה הציפיות, איך לתרום, ומה הנורמות. GitHub מגדיר סט של Community Health Files — קבצים שאפשר לשים בתיקיית .github/ בשורש הריפו (או בריפו מרכזי .github ברמת הארגון).

CONTRIBUTING.md — חוקת התורם

קובץ שמסביר בדיוק איך לתרום. מה צריך לכלול:

# Contributing to Project Name

## How to Contribute

1. Fork the repository
2. Create a feature branch (`git checkout -b feat/amazing-feature`)
3. Commit your changes (`git commit -m 'feat: add amazing feature'`)
4. Push to the branch (`git push origin feat/amazing-feature`)
5. Open a Pull Request

## Development Setup

```bash
git clone https://github.com/your-fork/project.git
cd project
npm install
npm test  # Make sure everything works
```

## Commit Convention

We use [Conventional Commits](https://conventionalcommits.org/):
- `feat:` — new feature
- `fix:` — bug fix
- `docs:` — documentation change
- `refactor:` — code change that neither fixes a bug nor adds a feature
- `test:` — adding or updating tests

## Code Style
- ESLint + Prettier (run `npm run lint` before committing)
- All functions must have JSDoc comments
- Tests are required for new features

## Pull Request Guidelines
- Keep PRs small and focused
- Include tests for new functionality
- Update documentation if needed
- Reference the issue number in the PR description

CODE_OF_CONDUCT.md — כללי התנהגות

מגדיר את הנורמות החברתיות בקהילה. הסטנדרט הנפוץ ביותר הוא Contributor Covenant, שמאומץ על ידי אלפי פרויקטים כולל Kubernetes, Rails, ו-Swift.

דרך GitHub UI אפשר להוסיף Code of Conduct ב-click אחד: Repository → Insights → Community Standards → "Add" ליד Code of Conduct.

למה זה חשוב? קהילה בלי כללי התנהגות ברורים מרתיעה תורמים, במיוחד אנשים מקבוצות שנמצאות underrepresented ב-tech. Code of Conduct שולח מסר: "פה יש סביבה מכבדת".

Issue Templates — טפסים מובנים

בלי templates, אתם מקבלים issues בסגנון "It doesn't work" בלי שום מידע שימושי. עם templates, כל issue מגיע עם מבנה:

# .github/ISSUE_TEMPLATE/bug_report.yml
name: Bug Report
description: Report a bug to help us improve
title: "[Bug]: "
labels: ["bug", "triage"]
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to report a bug!

  - type: textarea
    id: description
    attributes:
      label: Describe the bug
      description: A clear description of what the bug is
    validations:
      required: true

  - type: textarea
    id: reproduction
    attributes:
      label: Steps to reproduce
      description: Steps to reproduce the behavior
      value: |
        1. Go to '...'
        2. Click on '...'
        3. See error
    validations:
      required: true

  - type: textarea
    id: expected
    attributes:
      label: Expected behavior
      description: What you expected to happen

  - type: dropdown
    id: os
    attributes:
      label: Operating System
      options:
        - macOS
        - Windows
        - Linux
    validations:
      required: true

  - type: textarea
    id: version
    attributes:
      label: Version
      description: What version are you using?
    validations:
      required: true

וגם template ל-Feature Request:

# .github/ISSUE_TEMPLATE/feature_request.yml
name: Feature Request
description: Suggest an idea for this project
title: "[Feature]: "
labels: ["enhancement"]
body:
  - type: textarea
    id: problem
    attributes:
      label: Is your feature request related to a problem?
      description: A clear description of the problem
    validations:
      required: true

  - type: textarea
    id: solution
    attributes:
      label: Describe the solution you'd like
    validations:
      required: true

  - type: textarea
    id: alternatives
    attributes:
      label: Describe alternatives you've considered

PR Template

קובץ .github/PULL_REQUEST_TEMPLATE.md שמוסיף תבנית אוטומטית לכל PR חדש:

## Description


## Related Issue


## Changes Made
- [ ] Change 1
- [ ] Change 2

## How to Test

1.
2.

## Checklist
- [ ] Tests pass locally
- [ ] Code follows project style
- [ ] Documentation updated (if needed)
- [ ] Changelog updated (if needed)

config.yml — הגדרת "issue chooser"

בנוסף ל-templates עצמם, אפשר ליצור .github/ISSUE_TEMPLATE/config.yml שמגדיר את דף הבחירה כשמישהו פותח issue חדש:

# .github/ISSUE_TEMPLATE/config.yml
blank_issues_enabled: false  # חוסם issues ללא template
contact_links:
  - name: Question / Help
    url: https://github.com/USER/REPO/discussions/categories/q-a
    about: For questions, please use Discussions instead of Issues
  - name: Security vulnerability
    url: https://github.com/USER/REPO/security/advisories/new
    about: Report security vulnerabilities privately

blank_issues_enabled: false — מונע מאנשים לפתוח issue ריק (בלי template). זה מבטיח שכל issue יגיע עם המידע שאתם צריכים. contact_links — מפנה אנשים למקומות אחרים (Discussions לשאלות, Security Advisories לפגיעויות).

Community Health Files ברמת ארגון

אם יש לכם ארגון GitHub עם כמה ריפוזיטורים, אפשר להגדיר ברירת מחדל לכל הריפוזיטורים מריפו מרכזי בשם .github:

• צרו ריפוזיטורי בשם .github בארגון
• שימו בו CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, FUNDING.yml
• כל ריפו בארגון שאין לו קובץ משלו יירש את הקובץ מ-.github

זה חוסך כפילות ומבטיח עקביות. אם ריפו ספציפי צריך שינוי — הוא יכול לדרוס עם קובץ משלו.

SECURITY.md — מדיניות אבטחה

קובץ שמסביר איך לדווח על פגיעויות אבטחה באופן פרטי (לא דרך issue ציבורי). GitHub תומך ב-Private Vulnerability Reporting — אפשר להפעיל ב-Settings → Security → "Enable private vulnerability reporting".

# Security Policy

## Reporting a Vulnerability

Please **DO NOT** open a public issue for security vulnerabilities.

Instead, use GitHub's private vulnerability reporting:
1. Go to the Security tab
2. Click "Report a vulnerability"
3. Describe the issue in detail

We will respond within 48 hours.

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| 2.x     | ✅ Yes             |
| 1.x     | ❌ No (end of life)|

10.7 Discussions ו-Sponsors — בניית קהילה ומימון

GitHub Discussions — פורום מובנה בריפוזיטורי

Discussions הוא פורום שחי בתוך הריפוזיטורי. ההבדל מ-Issues: Issues הם לבאגים ופיצ'רים (דברים שצריכים טיפול), Discussions הם לשאלות, רעיונות, הכרזות ודיונים (דברים שצריכים שיחה).

איך מפעילים: Repository → Settings → Features → Discussions → Enable.

קטגוריות שמגיעות כברירת מחדל:

• Announcements — הכרזות מ-maintainers (רק admins כותבים)
• General — דיונים כלליים
• Ideas — רעיונות ובקשות מהקהילה
• Polls — סקרים
• Q&A — שאלות ותשובות (עם אפשרות לסמן "תשובה מקובלת")
• Show and Tell — הקהילה מציגה מה בנתה עם הפרויקט

אפשר ליצור קטגוריות מותאמות. למשל, פרויקטים רבים מוסיפים "RFC" (Request for Comments) לדיון על שינויים גדולים לפני implementation.

טיפ: Issues vs Discussions — מתי מה?

טיפ חשוב: אפשר להמיר Discussion ל-Issue (ולהפך). אם מישהו פותח שאלה ומתברר שזה באג — המירו ל-Issue בלחיצה.

ניהול Discussions בפועל

Discussions הם כלי חזק, אבל בלי ניהול הם הופכים ל-"מזבלה" של שאלות ללא תשובה. כמה טיפים:

• ענו על כל שאלה — גם אם התשובה היא "I don't know, but try X". שאלה ללא תשובה משדרת "לאף אחד לא אכפת".
• סמנו "תשובה מקובלת" בקטגוריית Q&A — זה מסדר את ה-Discussions ועוזר לאנשים עם שאלות דומות.
• נעלו discussions ישנים (מעל 30 יום ללא פעילות) — gh api repos/OWNER/REPO/discussions/ID/comments --method POST
• Pinned discussions — ניתן לנעוץ עד 4 discussions. השתמשו ב-: FAQ, Getting Started guide, Roadmap, Changelog.
• הפנו מ-Issues ל-Discussions — כשמישהו פותח issue שהוא בעצם שאלה, המירו ל-Discussion עם הסבר מנומס.

GitHub Sponsors — מימון מהקהילה

GitHub Sponsors מאפשר לאנשים לתמוך כספית ב-maintainers ובפרויקטים. אם אתם מתחזקים פרויקט קוד פתוח שאנשים משתמשים בו — זו דרך לגיטימית להרוויח ממנו.

איך מתחילים:

1. לכו ל-github.com/sponsors ולחצו "Get sponsored"
2. מלאו פרטי תשלום (Stripe — חשבון בנק או PayPal)
3. הגדירו tiers — רמות תמיכה עם הטבות:
   • $5/חודש — "שם ב-README"
   • $25/חודש — "שם + logo ב-README"
   • $100/חודש — "priority issue handling"
4. צרו קובץ .github/FUNDING.yml שמציג כפתור "Sponsor" בריפוזיטורי:

# .github/FUNDING.yml
github: [your-username]
# אפשר גם:
# open_collective: project-name
# patreon: your-patreon
# ko_fi: your-kofi
# custom: ["https://your-website.com/donate"]

שתי עובדות חשובות:

• GitHub לא גובה עמלה — 100% מהתשלום מגיע אליכם (Stripe גובה עמלת עיבוד רגילה)
• GitHub Sponsors מציע Sponsors Matching — בחלק מהמקרים GitHub מכפיל תרומות עד $1,000 לשנה הראשונה

אלטרנטיבות ומשלימים ל-Sponsors

Sponsors הוא לא הדרך היחידה למימון קוד פתוח. הנה אופציות נוספות שאפשר לשלב:

• Open Collective — פלטפורמה למימון שקוף. הכספים מנוהלים בפומבי — כל הוצאה גלויה. פופולרי מאוד בפרויקטים גדולים כמו Webpack ו-Babel.
• Patreon / Ko-fi — פלטפורמות מימון כלליות. טובות אם יש לכם קהילה מעבר ל-GitHub (YouTube, blog).
• Dual licensing — הקוד פתוח (GPL) בחינם, אבל חברות שרוצות רישיון מסחרי משלמות. דפוס נפוץ ב-MySQL, Qt, ועוד.
• Paid support / consulting — הקוד חינמי, תמיכה פרימיום בתשלום. תורמים גדולים מקבלים priority support.
• GitHub Sponsors for Organizations — לא רק ליחידים. ארגונים יכולים לקבל sponsorships ולחלק אותם בין maintainers.

10.8 בריאות הקהילה — OSSF Scorecard, Dependencies ו-Social Proof

פרויקט קוד פתוח מצליח זה לא רק קוד טוב — זה אותות אמון שגורמים לאנשים לסמוך עליו, להשתמש בו ולתרום לו.

Community Standards Dashboard

GitHub מספק dashboard שמראה כמה "בריא" הפרויקט שלכם מבחינה קהילתית. מצאו אותו ב: Repository → Insights → Community Standards.

הוא בודק האם יש לכם:

• Description (תיאור) — קיים / חסר
• README — קיים / חסר
• Code of Conduct — קיים / חסר
• Contributing guidelines — קיים / חסר
• LICENSE — קיים / חסר
• Issue templates — קיים / חסר
• Pull Request template — קיים / חסר
• SECURITY policy — קיים / חסר

המטרה: ירוק בכל שורה. אם חסר משהו, GitHub נותן לינק ישיר ליצירה.

OSSF Scorecard — ציון אבטחה לפרויקט

ה-OpenSSF Scorecard (Open Source Security Foundation) הוא כלי אוטומטי שמדרג את האבטחה ואת הפרקטיקות של פרויקט קוד פתוח בסקאלה של 0-10. הוא בודק 18+ בדיקות (checks) כמו:

איך להריץ Scorecard:

# דרך GitHub Actions — הדרך המומלצת
# הוסיפו workflow שמריץ scorecard אוטומטית:
# .github/workflows/scorecard.yml
name: Scorecard
on:
  schedule:
    - cron: '0 6 * * 1'  # כל יום שני ב-6 בבוקר
  push:
    branches: [main]

permissions: read-all

jobs:
  analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ossf/scorecard-action@v2
        with:
          results_file: results.sarif
          results_format: sarif
      - uses: actions/upload-artifact@v4
        with:
          name: scorecard-results
          path: results.sarif

בדיקה מהירה דרך CLI:

# התקנה
brew install scorecard  # macOS
# או
go install github.com/ossf/scorecard/v5/cmd/scorecard@latest

# הרצה
scorecard --repo=github.com/YOUR-USERNAME/YOUR-REPO

Dependency Management — ניהול תלויות

פרויקט קוד פתוח עם תלויות לא מעודכנות הוא סיכון אבטחה וגם סימן שהפרויקט לא מתוחזק. הכלים שלמדתם בפרק 7 (Security) קריטיים כאן:

• Dependabot alerts — התראות על תלויות פגיעות (חינמי לריפוזיטורים ציבוריים)
• Dependabot version updates — PRs אוטומטיים לעדכון תלויות
• Dependency graph — Settings → Code security → Dependency graph

# .github/dependabot.yml — הגדרה מומלצת לפרויקט OSS
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    labels:
      - "dependencies"
    commit-message:
      prefix: "deps:"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "ci"
    commit-message:
      prefix: "ci:"

Social Proof — אותות אמון

Stars, forks, contributors — כל אלה אותות שמשפיעים על ההחלטה של אנשים להשתמש בפרויקט. הנה איך לבנות אותם לאורך זמן:

Stars — המטבע של קוד פתוח:

• בקשו מאנשים ל-star את הפרויקט — לא spam, פשוט הוסיפו "If this was helpful, give us a star!" ב-README
• שתפו את הפרויקט ב-Reddit (r/programming, r/webdev), Hacker News, Twitter, ו-LinkedIn
• כתבו blog post שמסביר את הבעיה שהפרויקט פותר — עם לינק לריפו
• הגישו את הפרויקט ל-GitHub Topics — סמנו topics רלוונטיים ב-Settings

Good First Issues — דלת כניסה לתורמים:

• סמנו issues פשוטים עם label good first issue. GitHub מקדם אותם ב-Explore
• כתבו כל good first issue עם הוראות מפורטות — איפה בקוד, מה לשנות, איך לבדוק
• תמיד שמרו 3-5 issues פתוחים עם התווית — כשאחד נסגר, הוסיפו חדש

עוד אותות חשובים:

• Releases — פרסמו releases עם changelogs. זה מראה שהפרויקט חי ומתפתח
• "Used by" section — אם פרויקטים אחרים משתמשים בכם, זה מופיע ב-"Used by" בדף הריפו
• Contributors badge — הוסיפו רשימת תורמים ב-README. all-contributors עושה את זה אוטומטית
• Activity graph — commits עקביים לאורך זמן עדיפים על burst של 100 commits ואז שקט. Consistency builds trust.
• Response time — תגובה מהירה ל-issues ו-PRs (גם "thank you, looking into this") משדרת שהפרויקט מתוחזק

10.9 לבנות פרויקט קוד פתוח משלך — מדריך מלא

עכשיו בואו נחבר הכל. יש לכם כלי, ספרייה, או פרויקט שאתם רוצים לשחרר כקוד פתוח? הנה רשימת כל מה שצריך לעשות, לפי סדר:

Releases — ניהול גרסאות

כשפרויקט מוכן לשימוש, פרסמו release ראשון. Releases ב-GitHub מבוססים על Git tags:

# יצירת tag וגרסה
git tag -a v0.1.0 -m "First public release"
git push origin v0.1.0

# או דרך gh cli — יוצר גם tag וגם release
gh release create v0.1.0 --title "v0.1.0 - First Public Release" \
  --notes "## What's New
- Initial public release
- Core functionality: X, Y, Z
- Full documentation and examples

## Installation
\`\`\`
npm install my-package
\`\`\`"

Semantic Versioning (SemVer) — הסטנדרט לניהול גרסאות שכמעט כל פרויקט OSS עוקב אחריו:

• MAJOR.MINOR.PATCH — למשל 2.1.3
• MAJOR — שינוי שובר (breaking change). מ-1.x ל-2.0. המשתמשים צריכים לשנות קוד.
• MINOR — תכונה חדשה שלא שוברת backwards compatibility. מ-2.1 ל-2.2. בטוח לעדכן.
• PATCH — תיקון באג בלבד. מ-2.1.3 ל-2.1.4. בטוח לעדכן תמיד.
• Pre-release — 2.0.0-beta.1, 2.0.0-rc.1 — גרסאות בדיקה לפני release סופי.

חשוב: כל עוד הגרסה היא 0.x.y (לפני 1.0.0), אין התחייבות ליציבות — שינויים שוברים יכולים לקרות בכל עדכון MINOR. זו הסיבה שפרויקטים רבים נשארים ב-0.x לזמן ארוך — זה מאפשר גמישות. ברגע שעוברים ל-1.0.0, אתם מתחייבים ל-backwards compatibility.

אפשר גם להגדיר Actions workflow שיוצר release אוטומטית על כל tag push:

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ['v*']

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: softprops/action-gh-release@v2
        with:
          generate_release_notes: true

generate_release_notes: true — GitHub מייצר changelogs אוטומטית מ-PR titles שבין ה-release הקודם לנוכחי. זה עובד מצוין אם ה-PR titles שלכם ברורים ומבוססים על Conventional Commits.

שימו לב: אפשר להגדיר .github/release.yml כדי לקסטם את ה-generated notes — לקבץ PRs לפי labels, להסתיר שינויי CI, ולהדגיש breaking changes:

# .github/release.yml
changelog:
  exclude:
    labels:
      - "ci"
      - "chore"
  categories:
    - title: "Breaking Changes"
      labels:
        - "breaking"
    - title: "New Features"
      labels:
        - "enhancement"
    - title: "Bug Fixes"
      labels:
        - "bug"
    - title: "Documentation"
      labels:
        - "documentation"

Changelog — מה השתנה בכל גרסה

כל release צריך changelog — תיעוד של מה השתנה. שני דפוסים נפוצים:

דפוס 1: Auto-generated release notes — GitHub מייצר חזרה אוטומטית מ-PR titles (מה שראינו עם generate_release_notes: true). זה עובד טוב אם ה-PR titles שלכם ברורים ומובנים (Conventional Commits).

דפוס 2: CHANGELOG.md ידני — קובץ שנוהל ידנית (או עם כלי כמו standard-version או release-please). פורמט סטנדרטי:

# Changelog

## [2.1.0] - 2026-03-15
### Added
- Hebrew translation for error messages (#123)
- Support for custom themes (#125)

### Fixed
- Memory leak in connection pool (#130)
- Typo in installation docs (#128)

### Changed
- Minimum Node.js version is now 20 (was 18)

## [2.0.0] - 2026-02-01
### Breaking Changes
- Removed deprecated `init()` method — use `create()` instead
- Config format changed from YAML to JSON

כלי אוטומציה: release-please (GitHub Action) מייצר CHANGELOG אוטומטית מ-Conventional Commits ופותח PR עם release draft. זה אולי הכלי הטוב ביותר לניהול releases אוטומטי בפרויקטי OSS.

# .github/workflows/release-please.yml
name: Release Please
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: node

release-please מזהה commits מסוג feat: ו-fix:, מעדכן את ה-CHANGELOG, מעלה את הגרסה ב-package.json, ופותח PR שכשהוא מתמזג — יוצר release אוטומטית. פשוט עובד.

"Good First Issue" — איך למשוך תורמים חדשים

אחד הדברים שהכי משפיעים על בניית קהילת תורמים: תווית good first issue. GitHub מקדם issues עם התווית הזו ב-Explore ובחיפוש.

מה עושה good first issue טוב:

• ברור — מתאר בדיוק מה צריך לעשות
• מוגבל — שינוי ב-1-2 קבצים, לא refactoring גדול
• בדיק — ברור איך לאמת שהשינוי עובד
• מתועד — מראה איפה בקוד צריך לעשות שינוי

למה maintainers צריכים להשקיע ב-good first issues? כי זו הדרך העיקרית שפרויקטים מגדלים את מאגר התורמים. תורם שמתחיל מ-good first issue ומקבל חוויה חיובית — merge מהיר, feedback בונה, תודה — הופך לתורם חוזר. תורם חוזר הופך ל-maintainer. זו מערכת שנותנת בטווח הארוך הרבה יותר ממה שהיא עולה בטווח הקצר.

דוגמה טובה:

Title: Add Hebrew translation for error messages
Labels: good first issue, documentation, hacktoberfest

## Description
Our error messages are currently English-only. We want to add
Hebrew translations.

## What needs to happen
1. Open `src/messages/en.json`
2. Copy it to `src/messages/he.json`
3. Translate each message to Hebrew
4. Add Hebrew to the supported languages in `src/config.ts` (line 12)

## How to test
Run `npm test` — the new language should pass validation.

## Helpful context
- See the [translation guide](link) for style guidelines
- If unsure about a translation, leave a comment and we'll help

10.10 סיכום ומבט קדימה

מבט קדימה

בפרק הבא והאחרון: נמפה את כל מה שחינמי ומה שבתשלום ב-GitHub. תלמדו לחשב עלויות של Actions, Codespaces, Packages ו-LFS, להשוות בין Pro, Team ו-Enterprise, ולבנות אסטרטגיית שימוש שממקסמת את ה-free tier. כל מה שלמדתם ב-10 פרקים — תדעו בדיוק כמה זה עולה ומה שווה לשדרג.

הנה מה שכבר יש לכם:

• Actions (פרק 1) — CI/CD, minutes, billing
• CLI (פרק 2) — ניהול מהטרמינל
• Pages (פרק 3) — אתרים חינמיים
• Codespaces (פרק 4) — סביבות ענן, core-hours
• Projects (פרק 5) — ניהול פרויקטים
• Packages (פרק 6) — storage, bandwidth
• Security (פרק 7) — GHAS, Dependabot, CodeQL
• API (פרק 8) — REST, GraphQL, Apps
• Orgs (פרק 9) — צוותות, rulesets, roles
• OSS (פרק 10 — כאן) — קהילה, רישיונות, תרומות

בפרק 11 נחבר את כל החלקים למפה אחת שלמה. →