📚 Part 5 오픈소스 컨트리뷰터
📌 오픈소스 구성원 역할
- 저작자 : 오픈소스 프로젝트를 만든 사람 또는 조직
- 메인테이너
- 프로젝트의 방향을 알고 있는 / 직접 설정한 프로젝트를 관리하는 컨트리뷰터
- 커미터 : 컨트리뷰터가 컨트리뷰션을 하면 리뷰를 하는 컨트리뷰터.
- 프로젝트에 이 코드를 반영할지 말지 결정 권한도 가지고 있는 컨트리뷰터
- 컨트리뷰터 : 오픈소스 프로젝트에 컨트리뷰션(기여) 활동을 하는 모든 사람
- 사용자 : 오픈소스 프로젝트를 사용하는 사람
메인테이너나 커미터의 경우 없어도 된다. 다만, 그 역할들을 저작자가 대신 해야 됨.
📌 컨트리뷰션 활동 유형
컨트리뷰션은 오픈소스 프로젝트에 기여하는 것이다. 그렇다면 코드 구현과 수정만이 오픈소스에 "기여"하는 활동일까? 기여활동은 소스코드를 수정하는 것만이 아니다.
요구사항에 맞게 결과물이 나오면 우리는 그것을 프로젝트라고 부른다. 결과물을 도출하는 과정에서 우리는 기획, 설계, 분석 등 소스 코드 구현 뿐만 아니라 다양한 작업을 한다. 테스트, 배포, 가이드(문서화) 등 이러한 모든 작업들이 프로젝트에 "기여"하는 활동이다. 즉, 컨트리뷰션이다.
ex. 리액트
위 표를 보면 컨트리뷰션의 30% 이상이 소스코드가 아니라 다른 것들이라는 것을 알 수 있다.
✨제안✨만해도 가능
🔗 코드 외의 컨트리뷰션
- 오타 수정
- ex. rect → react로 바꿔도 컨트리뷰션임
- 코드가 아니라
README.md에서의 오타 수정이더라도 컨트리뷰션임- 직접 오타를 수정하는 것이 아니라 오타 수정을 제안해도 컨트리뷰션임.
- 번역
- 직접 번역하는 것 뿐만 아니라 제안만 해도 컨트리뷰션임
- 문서 설명 덧붙임
- 배너 문구 수정 (제안도 포함)
- UI / UX (제안도 포함)
- ... 등등
🔗 소스코드 관련 컨트리뷰션
- 버그 수정 (Bug Fix)
- 문서 작업
- 기능 추가/수정/삭제
- 리팩토링
- ex. e라는 변수를 expired로 수정하여 의미를 명확하게 하는 등
- 버전 수정 or 외부 모듈 변경 (의존성)
- 에러 메세지 (구체화)
- 리소스
- "테스트 케이스 추가"
위 예시들 모두 직접 행하는 것이 아닌 제안을 하더라도 컨트리뷰션으로 간주한다.
즉, 우리는 아무리 사소한 것이라도 그로 인해 컨트리뷰터가 될 수 있다.
📌 컨트리뷰션을 하는 이유?
🔗 오픈소스 저작자
- 컨트리뷰터들이 저작자가 찾지 못한 버그를 찾아줄 수 있음
- 컨트리뷰터들이 사용하면서 불편했던 점, 개선할 코드 등 혼자서는 찾을 수 없는 사항들을 찾아줄 수 있음 (개선 사항들)
🔗 오픈소스 사용자/컨트리뷰터
- 전 세계 멋진 개발자에게 코드 리뷰를 받을 수 있음
- 이는 실력 성장에 굉장한 도움이 된다
- 사용자가 원하는 기능을 추가할 수 있고, 이를 이용하여 사용자 입장에서 자신의 코드를 짜는데도 편리함
- 또한 다른 사람에게 객관적인 시선으로 나의 코드와 기획 능력을 평가(?)받을 수 있음
- 따라서 성장에 굉장한 도움이 됨.
- 코드 퀄리티를 높일 수 있다. 또한 코드를 보는 시선/관점/시야가 넓어짐
- 오픈소스 코드를 분석하면서, 코드를 분석하는 능력 즉, 코드 문해력이 높아짐
- 협업을 경험할 수 있으며, 성취감을 느낄 수 있음.
cf. 이력서, 포트폴리오
📌 우리나라는 컨트리뷰션에 진심입니다 (feat. OSS)
🔗 오픈소스 소프트웨어 (Open Source Software, OSS)
소스코드는 공개 + 라이선스 ⇒ 소프트웨어
오픈 소스 소프트웨어는 소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈 소스 라이선스를 만족하는 소프트웨어를 말한다. 간략하게 오픈 소스라고 말하기도 함
cf. 우리나라의 공공기관에서는 공개 소프트웨어라고도 부른다.
OSI : OSS 인증 마크 (전세계에서 오픈소스를 담당하는 협회. 즉, 전세계적인 비영리 조직)
OLIS (우리나라의 저작권 협회에서 운영함)
📌 컨트리뷰터/Contribution 주의 사항
= 협업의 주의 사항
"공유"
✔️ 커뮤니케이션 : 태도, 자세, 말투 👉🏻 "겸손"
커뮤니케이션이 가장 중요하다고 할 수 있다.
서로 존중하는 태도 필요함.
✔️ 소스코드 충돌
- Contribute하고 싶은 내용을 이미 구현하고 있진 않은지, 구현하지 않기로 결정한 건 아닌지 확인하는 것이 필수임.
- 너무 오래된 open 이슈 (ex. hubot: translate Korean 2018)
- 디스커션이나 커뮤니티를 통해 문의하기
- ✨ 오래된 이슈, 작업하지 않는 이슈, 정리되지 않은 이슈 정리! 일종의 Contribution ✨
- 시작하기 전에 내가 작업을 시작할 것을 알리는 것이 좋음
- 이슈를 오픈하거나, discussion을 통해서..
✔️ 새롭고, 큰 중요한 기능을 추가하고 싶을 때
- ✨ 이런 기능을 추가해보고 싶은데 어떻게 생각해? ✨
- 무작정 기능을 추가하는 것이 아니라 이슈를 열거나 discussion에 물어보기
- 내부적으로 팀원 모집도 추천
✔️ Pull Request를 던질 때(소스코드 합쳐달라고 요청할 때)
- 템플릿(틀)이나 문서를 확인하면서 준수할 내용 체크
- 테스트 유무, 코드 컨벤션, 유효성 검사 등등
📌 컨트리뷰트 절차
Contributing 문서 / 가이드 참고
- 1. 오픈소스 프로젝트를 Fork
- 깃허브 안에서 레포지토리를 복제해오는 것
- 개인 깃허브 계정으로 원하는 오픈소스 프로젝트를 Fork 한다.
- 2. 내 계정 - 레포지토리 Clone ⇒ 내 로컬
- 내 깃허브 계정에 있는 Fork된 Repository를 내 개발 환경 즉, 로컬로 Clone한다.
- 3. ✔️코드 컨벤션 ✔️커밋 메세지 등 코드 구현전에 체크해야 하는 "규칙"이 있는지 찾아봐야 됨
- Contributing 텍스트 파일 혹은 md 파일, Readme 파일, Discussion, Issue 등 확인
- 다른 개발자들이 커밋을 어떻게 했는지 확인해봐도 됨
- 4. 코드 구현, 수정 👉🏻 커밋
- ✨주석 수정✨
- 주석 수정과 명명법 수정도 모두 컨트리뷰션임
- 5. Clone 했던 내 계정 깃허브 레포지토리로 Push
- 6. 깃허브 > 내 레포지토리 → 오픈소스 레포지토리 Pull Request
- 7. Contributor License Agreement
- Pull Request를 요청하면 컨트리뷰터가 오픈소스 라이선스에 동의하는지 서명을 받음
- 8. 리뷰어, 커미터, 메인테이너, 저작자 등 코드를 검토해주는 사람이 코드 리뷰를 함
- 코드 검토를 생략하고 바로 머지(merge)되는 경우도 있다
- 9. merge 되었다! = Pull Request closed 알림
- 10. Contributior List에 내 계정이 추가될 것임! 🎉
📚 Part 6 라이선스 논란
📌 라이선스가 없는 코드라면?
문서가 있어도 라이선스가 없으면 오픈소스가 아니다. 라이선스가 없으면 그저 Public 프로젝트일 뿐이다. 즉, public이라고 해서 모두 오픈소스는 아니다.
즉, 만약 라이선스가 없다면 오픈소스가 아니라는 뜻
이것은 기여 권한이 없다는 뜻이다.
만약 다른 개발자의 public 프로젝트가 너무 좋아보여서 자유롭게 사용하고 수정하고 배포하고 싶다면 오픈소스로 만들면 된다. 하지만 이것을 우리가 할 수는 없고 저작자에게 "제안"하는 것이다.
✨오픈 소스로 하실 생각 없으신지.. 제안! propose! License 종류까지 제시!✨
오픈소스로 하자고 제안만 하는 것이 아니라 License 종류까지 제시해야 된다. 그리고 이것도 Contribution의 일종이다.
📌 오픈소스 라이선스 제시하기
라이선스를 제안할 때 OSI, OLIS, OSS 등에서 규정을 찾아보고 제안한다기 보다는 이 프로젝트의 목적을 생각해보고 제시하는 것이 좋다. 즉, 사용자 입장에서 프로젝트가 어떻게 쓰였으면 좋겠는지에 대해 고민해야 한다.
깃허브에서 추천하고, 많은 개발자들이 사용하는 라이선스는 Apache License 2.0, GNU General Public License v3.0, MIT License 이 세 가지이며, 이 셋 중 하나를 제안하면 된다.
1. 어떤 프레임워크 위에서 작동하는지, 어떤 모듈이랑 같이 쓰이는지 고려함
ex. node.js
✔️ npm에서 다른 모듈들이 어떤 라이선스를 적용하고 있는지 확인하기
그 중에서 가장 많이 쓰이는 MIT 라이선스를 제시하면 됨
2. 딱히 고려할 것이 없으면
가장 간단하고, 고려할 것이 없으며 이해하기 쉬운 라이선스 사용하면 됨
저작자만 보호할 목적이라면 👉🏻 누구나 사용 가능한 MIT 라이선스
3. 기업이 사용하기를 원하면, 웹 관련 Apache : "특허"
특허가 포함되어 있기 때문에 기업일 경우 사용하면 좋음
4. 오픈소스 커뮤니티/프로젝트 구성원/컨트리뷰터 등등 히스토리가 모드 공개되었으면 좋겠을 때 👉 GNU (L/A/)GPL v3
무조건 다 오픈해야 한다는 규정이 강력함
