https://velog.io/@skynet/오픈소스-기여-입문
오픈소스 기여는 단순한 자기계발을 넘어 일종의 스펙이 되고 있다. 기업들이 오픈소스 활용/기여 경험이 있는 개발자를 선호한다는 사실이 알려지면서 이력서에 한 줄이라도 새겨넣고 싶어하는 취준생이나 신입 개발자들이 많아졌다.
마음 같아서는 리눅스 커널이라도 뚝딱 만들어내고 싶지만 처음부터 큰 일을 해낼 순 없다. 오늘은 오픈소스 기여에 입문할 수 있는 쉬운 방법을 소개한다.
참고로 나는 다음의 프로젝트에 기여를 한 바 있다.
취준생 시절에는 아무 오픈소스에나 기여를 하려고 눈을 부릅뜨고 찾아다녔다. 운 좋게 기여를 몇 번 하긴 했지만 비효율적이고 무의미한 방식이었다. 오픈소스의 주된 기여 방식은 사용자가 직접 불편한 점을 개선하는 것이다. 해당 프로젝트를 사용하지도 않으면서 기여할 거리를 찾는 것은 아주 어렵다.
기여에 욕심낼만한 유명한 프로젝트일수록 이런 방식은 더욱 어렵다. 이미 개발된 분량이 방대해서 이해하기가 어렵기 때문이다. 기여 자체를 목적으로 하는 방식은 특수한 경우가 아니라면 자제하는 것이 좋다. 특수한 경우에 대해서는 후술하겠다.
사용자로서 불편함을 느꼈거나 문제점을 발견했을 때 이슈를 등록하는 것도 굉장히 중요한 기여 방식이다. 특히 버그를 발견하였다면 웬만한 코드 기여보다 더 큰일을 해낸 것이다. 발견한 문제점이 꼭 거창할 필요는 없다. 사소한 불편함의 예로 내가 대학생 시절에 khaii 프로젝트에 게시했던 이슈를 보여주겠다.
해당 프로젝트의 빌드 문서에는 리눅스나 맥에서만 정상 작동한다는 언급이 없었다. 당시 사용하던 데스크탑에 Cmake, gcc 등이 있었으므로 빌드를 시도하였으나 자꾸 실패하였다. 이슈를 검색해보니 나처럼 빌드를 실패했던 사람이 또 있었다. 문서를 수정하는 것이 어떻겠냐고 이슈를 올렸고 곧 반영되었다. (지금 생각해보면 직접 수정해서 PR했어도 됐을 것 같다.)
서문에 쓴 쿠버네티스에 기여 내역을 보고 놀란 독자가 있을 것이다. 예상하는대로 구글이 개발하는 대규모 프로젝트에 기여하는 것은 쉽지 않은 일이었다. 다음은 내가 한 PR의 캡처이다.
