왜 다들 마음 한편에 오픈 소스를 하려는 마음을 가질까?
선한 마음? 모두가 그런건 아닐것이다. 좋은 코드를 남겨서 코드를 남기면 은퇴후에도 기억 남을만하다. 라고 말한 사람도 있다.
기업에서 오픈소스를 하는 이유
비용적이익, 혁신에 대한 접근성이 올라감, 우수 인력 채용
개인 입장에서
어떤 점이 나를 성장시켰나.
오픈소스 활동에 대한 키워드, 프로그래밍, ui, ux, 접근성 디자인 테스트, 문서편집 커뮤니티 번역 마케팅 등을 다 해야 했기에 여러 방면으로 성장할 수 있었다.
서비스를 발전 시킬 수 있다는건 큰 장점이다. 코드, 테스트작성 보안 등에 대해 참여하며 실력 향상할 수 있었다. 그 외에도 디자인과 ui, ux 등에도 참여. 티셔츠 만들어서 홍보를 해보기도 했다.
디자이너와 사용성에 대한 소통도 했다.
사용자 분들이 쉽게 적용할 수 있게 하기 위해 번역을 하거나, 여러 군데에 글을 작성해봄
더 많은 사람들이 사용하게 하기 위해 홍보 및 커뮤니티를 하며 여러 경험과 실력이 향상될 수 있었다.
또한, 범용적인 기능에 대해 많은 고민을 할 수 있다. 오픈 소스는 시간적인 측면에 쫓겨 하는 것보다. 범용적으로 쓰일 수 있는 기능인가에 대해 고민을 많이한다.
어떤 기능이 범용적일까? 가장 일반적인 사용성, 아무 프로젝트에 쉽게 적용할 수 있음. 쉽게 커스터마이징 되는. 부족하지도 과하지도 않은 기능. 많은 사람들이 쉽게 사용가능한 것.
다른 유명한 오픈소스를 참고하며 분석하고 공부할 수 있었다.
커뮤니케이션 연습
소프트 스킬: 개인 가진 커뮤니케이션, 팀워크 같은 스킬.
최근 들어 비대면이나 글로 소통하는 경우가 많았다.
오픈 소스 메인테이너들은 당신에게 빚지지 않았다. 좀 더 공손하게, 확실하게 이슈를 남기자.
오픈소스 메인테이너들은 나의 코드를 한번 써볼래? 일 수도 있다 평가해줘가 아닐 수 있다는 것이다. 너무 당연하게 생각하지 말자.
그럼 어떻게 질문하는게 좋을까
정중하고 감사를 표하며 질문하자.
명료하고 구체적인 사례를 함께, 템플릿이 있다면 최대한 충실하게 작성하자.
독촉하지 않으면서(비동기로 이뤄지는 대화에 익숙해지자)
오픈소스는 성과가 외부로 드러난다.
내 코드를 보는 사람들이 생긴다. 공유에 익숙해진다. 큰 노력 없이 포트폴리오가 만들어진다.
좀 더 명료하고 읽기 쉬운 코드를 만들기 위해 노력.
누가 프로젝트에서 어떤 일을 했나요 라고 물으면 커밋내역을 주면 된다.
개발 뿐만 아니라 다양한 경험을 하며 많은 것을 배울 수 있는, 많은 개발자들의 코드를 살펴보며 범용적인 코드를 작성하는 연습을 할 수 있는, 적절한 의사소통의 자세에 대해 연습할 수 있는, 추가적인 노력없이 내 성과를 온전히 드러낼 수 있는 오픈 소스 활동을 통해 성장했다.
그럼 어떻게 시작할까?
이미 만들어져있는 프로젝트에 참여 or 새로운 프로젝트
이미 만들어진 프로젝트
장점: 내 소유가 아니다→ 책임이 덜하다. 여러 관심 있는 프로젝트에 동시에 참여가능.
커뮤니티 활발한 곳에 참여가능.
단점: 내 소유가 아니다. 커뮤니티 적응에 시간이 걸린다. 커뮤니티가 활발하다면 그 문제를 해결할 사람도 많다. PR을 노리는 수많은 사람들이 존재.
적절한 프로젝트 선정이 중요. 개인적으로는 이미 잘 알고 있는 ,, 사용해 본적이 있는 분야부터 시작하는 것을 추천. 기여 가능 여부는 개인의 자유가 아니다. 오픈 소스라고 무조건 기여 가능한 것은 아니다.
리드미, 라이센스 등을 확인 컨트리뷰팅 읽어보고 없으면 기여 못 하는 프로젝트일 가능성이 높음. 모든 프로젝트가 기여에 호의적이지는 않다.
커뮤니티의 분위기를 파악하라.
merge가 된 PR, 활발하게 토론되고 있는 issue를 살펴보자.
이슈를 올리거나 PR을 올린다면 같은 이슈, 기능 요청 이슈나 진행되고 있는 스레드가 있는지 찾기
존재한다면 관심을 표현하기, 닫혔다면 댓글을 남기거나 reopen 하지 말고 새로운 이슈 열기
최대한 구체적으로 정중하게 작성하기
템플릿에 충실하게
버그라면 재현에 대한 정보를 구체적으로, 스크린샷, 발생환경, 가능하다면 온라인 ide로
기능 제안은 해당 기능이 왜 필요한지, 현재 동작과 기대되는 동작.
기대되는 동작이 나의 고정관념에서 나온 동작은 아닌지 리서치 해보기.
기여 하기 전 메인테이너에게 의견 물어보기
내가 이 이슈에 대한 개발을 해도 될까요? 물어보기, 익숙하지 않은 프로젝트라면 메인테이너와 충분히 의견을 나누고 시작하기.
코드 리뷰 전 필요한 작업 모두 마무리 했는지 확인 하기
코드 스타일, 문서작성, 테스트, 다른 동작에 영향이 있는지 등등 확인
내 용건이 끝나도 맘대로 issue 열고 닫지 않기, 소통 장소 찾기, 깃허브, 슬랙, 디스코드, 등등등
내가 프로젝트를 시작해도 괜찮다. 간단한 것부터 모듈화 해서 공개하는 것이 좋다고 생각. 회사에서 개발한 프로젝트를 공개해도 좋다. 작은 프로젝트, 모듈부터 시작하자. 새로운 무언가를 만들려는 것보다 기존의 것을 개선해서 시작. 공유가 자연스러운 조직 문화가 만들어진다.
오픈 소스가 되려면 오픈 된 Source, LICENSE 파일, CONTRIBUTING 파일, README, COC, 가이드 문서, 커뮤니티
사용자를 모으기 위해 페북, 트위터 레딧, 해커뉴스 등에 기술적인 내용 발전사항 등을 정리해서 홍보하는게 좋음.
단순한 홍보는 개발자들에게 외면을 받기 쉬움.
이슈나 PR에 답변할 때는 최대한 빠르게 어려움에 공감하면서, 구체적인 리뷰와 명확한 기준을 제시하면서 프로젝트를 이해할 수 있도록 하자. 비방이나 구체적이지 않은 질문에는 많은 노력을 들이지 말자. 스트레스를 받지 말자.
