인기 있는 오픈소스 프로젝트의 유지 관리자는 모두 쉽지 않습니다. 낯선 사람들이 제때 질문에 답하지 않았다고, 제때 그들이 원하는 답을 검색해 주지 않았다고 욕을 합니다. 오픈소스 프로젝트 유지 관리자들은 종종 심리적 질병을 앓게 됩니다. 오픈소스 프로젝트가 있다면 이미 경험해 보셨을 것입니다.
Nolan Lawson은 Microsoft Edge 브라우저 웹 플랫폼의 PM입니다. 여러 오픈소스 프로젝트에 참여했습니다. 예: PouchDB, optimize-js 등. 오픈소스 프로젝트의 유지 관리자가 되는 것은 어떤 경험인가요? 그의 7년간의 직접적인 경험을 들어보세요.
수백 명의 사람들이 줄을 지어 당신의 집 문밖에서 기다리고 있습니다. 그들은 당신이 질문에 답하고, 그들의 불만을 듣고, Pull Request와 Feature Request에 응답하기를 인내심 있게 기다리고 있습니다.
당신은 그들 모두를 돕고 싶지만, 계속 미루고 있습니다. 어쩌면 하루 종일 열심히 일했거나, 피곤하거나, 아니면 그저 가족 및 친구들과 주말을 즐기고 싶을 수도 있습니다.
하지만 github.com/notifications에 로그인하면, Notification이 몇 명이나 당신을 기다리고 있는지 계속 알려줍니다:
screenshot showing 403 unread GitHub notifications
약간의 여가 시간을 찾으면, 당신은 문을 열고 첫 번째 사람을 맞이합니다(즉, 첫 번째 문제를 처리합니다. 여기에는 한 명 이상의 사람이 포함될 수 있습니다. 이하 동일). 그들은 충분히 친절합니다. 그들은 당신의 프로젝트를 사용하고 싶지만, API에서 약간의 혼란에 빠져 있습니다. 그들은 코드를 GitHub 댓글에 붙여넣었지만, 코드를 포맷하는 방법을 잊었거나 몰라서 코드가 엉망이 되었습니다.
다행히도, 당신은 그들의 댓글을 편집하여 코드 블록을 추가하고, 코드를 포맷했습니다. 하지만 여전히 읽어야 할 코드가 많습니다.
또한, 그들의 문제 설명은 다소 이해하기 어렵습니다. 어쩌면 영어가 그들의 모국어가 아니거나, 서면 표현 능력이 부족할 수 있습니다. 어쨌든, 당신은 그들이 제출한 텍스트 단락을 이해하려고 노력합니다.
당신은 피곤한 눈으로, 줄 뒤에서 기다리는 다른 수백 명을 힐끔 봅니다. 당신은 30분을 들여 첫 번째 사람의 코드를 이해할 수 있고, 아니면 그냥 한 번 훑어보고 그들이 문제를 해결하는 데 도움이 될 수 있는 튜토리얼이나 문서 링크를 제공할 수도 있습니다. 당신은 기꺼이 Stack Overflow나 Slack을 시도해 보라고 제안합니다.
두 번째 사람은 미간을 찌푸리며 얼굴에 불쾌한 표정을 짓습니다. 그들은 당신의 프로젝트가 어떻게 그들의 인생에서 두 시간을 낭비했는지 계속 불평합니다. 왜냐하면 어떤 API가 홍보된 효과가 없었기 때문입니다. 그가 한 말은 매우 불쾌해서, 당신을 불편하게 만듭니다.
당신은 이 사람에게 너무 많은 시간을 낭비하지 않았습니다. 당신은 간단히 말합니다, “이것은 오픈소스 프로젝트이며, 자원봉사자가 유지 관리합니다. 코드에 버그가 있으면, 재현 가능한 테스트 케이스나 PR을 제출하세요.”
세 번째 사람은 매우 일반적인 오류를 겪고 있으며, 해결 방법은 간단합니다. 당신은 이 오류를 몇 번 본 적이 있지만, 해결 방법이 어디에 있는지 일시적으로 기억나지 않습니다. Stack Overflow? 위키? 메일링 리스트? 몇 분간 구글 검색을 한 후, 당신은 링크를 붙여넣고 이 Issue를 닫습니다.
네 번째 사람은 정기 기여자입니다. 당신은 여러 커뮤니티 토론과 형제 프로젝트에서 그들의 이름을 알아봅니다. 그들은 매우 난해한 Issue에 빠져 있고, 이를 해결하기 위해 Pull Request를 제출했습니다. 불행히도 이 Issue는 복잡하므로, 그들의 PR에는 문제를 설명하는 많은 지루한 단락이 포함되어 있습니다.
다시 한 번, 당신은 여전히 줄을 서서 기다리는 수백 명을 힐끔 보고, 이 네 번째 사람이 그들의 솔루션에 많은 노력을 기울였으며, 아마도 이 솔루션이 합리적이라는 것을 알고 있습니다. Travis 테스트가 통과했으므로, 당신은 그냥 “LGTM”이라고 코멘트하고 이 Pull Request를 병합하려고 합니다.
하지만, 당신은 이런 종류의 상황에 이전에 다친 적이 있습니다. 과거에, 당신은 충분한 평가 없이 PR을 병합했고, 결국 예상하지 못한 문제로 인해 새로운 문제가 발생했습니다. 어쩌면 테스트는 통과했지만, 성능이 10% 떨어졌을 수 있습니다. 또는 메모리 누수가 발생했을 수 있습니다. 또는 이 PR이 API를 너무 복잡하게 보이게 하여 새로운 사용자가 프로젝트에 혼란을 느끼게 했을 수 있습니다.
지금 이 PR을 병합하면, 나중에 더 많은 문제가 발생할 수 있습니다. 왜냐하면 당신이 이 사람의 문제를 해결하기 위해 다른 사람의 작업 흐름을 중단했기 때문입니다. 그래서 당신은 그것을 보류하고, 더 많은 시간이 생길 때 처리하기로 합니다.
다섯 번째 사람은 새로운 버그를 발견했지만, 당신은 그것이 실제로 형제 프로젝트의 버그라는 것을 알고 있습니다. 그들은 이것이 그들의 앱 시작을 방해한다고 말합니다. 당신은 이것이 큰 문제라는 것을 알지만, 수많은 문제 중 하나일 뿐이므로, 지금은 수정할 시간이 없습니다.
당신은 이것이 실제 문제처럼 보이지만, 다른 Repo에서 여는 것이 더 적합하다고 응답합니다. 그래서 당신은 그들의 Issue를 닫고, 다른 Repo에 복사한 다음, 코드에서 어디서부터 수정해야 하는지 알리는 코멘트를 추가합니다. 비록 그들이 실제로 이렇게 할 것이라고 의심하지만. 거의 없습니다.
여섯 번째 사람은 “지금 어떤 상황인가요?”라고만 말합니다. 당신은 그들이 무엇에 대해 이야기하는지 모르므로, 문맥을 봅니다. 프로젝트의 오래된 버그에 대해, 그들은 긴 GitHub 스레드에 코멘트를 달았습니다. 많은 사람들이 이 문제의 현재 솔루션에 동의하지 않아, 많은 토론이 발생했습니다.
이 특정 Issue 아래에는 20개 이상의 코멘트가 있으며, 읽고 기억하는 데 오랜 시간이 걸립니다. 그래서 당신은 그냥 응답합니다, “죄송합니다, 이 Issue는 한동안 열려 있었지만, 아직 아무도 해결하지 않았습니다. 우리는 여전히 문제의 범위를 이해하려고 노력하고 있습니다. Pull Request를 여는 것이 가장 좋습니다!”
일곱 번째 사람은 GreenKeeper 웹사이트 로봇입니다. 그들의 문제는 간단하지만, 이 특별한 Repo에는 상당히 파편화된 테스트가 있고, 이 테스트는 거짓으로 보이는 이유로 실패했으므로, 당신은 통과하는지 다시 테스트해야 합니다. 당신은 이 테스트를 다시 시작하고, Travis가 실행될 기회가 있은 후 다시 확인해야 한다는 것을 기억하려고 합니다.
여덟 번째 사람은 Pull Request를 열었지만, 있는 Repo는 상당히 활발하며, 다른 유지 관리자가 이미 피드백을 제공했습니다. 당신은 스레드를 훑어보고, 다른 유지 관리자가 잘 처리할 것이라고 믿으므로, 읽음으로 표시하고 계속 진행합니다.
아홉 번째 사람은 버그처럼 보이는 것을 겪고 있으며, 당신도 이전에 본 적이 없습니다. 하지만 불행히도, 그들은 “이 문제가 실제로 어떻게 발생하는지”에 대해 충분한 세부 정보를 제공하지 않았습니다. 어떤 브라우저에서 발생했나요? 어떤 Node 버전? 어떤 버전의 프로젝트? 그들이 재현하는 데 어떤 코드를 사용했나요? 당신은 그들에게 명확히 해달라고 요청하고, 이 탭을 닫습니다.
문제가 계속 쏟아져 들어옵니다
잠시 후, 당신은 10~20명의 이런 사람들을 맞이했습니다. 여전히 100명 이상이 줄을 서서 기다리고 있습니다. 하지만 이제 당신은 지쳤습니다. 모든 사람이 불평하거나, 질문에 답해야 하거나, 향상 요청이 있습니다.
어느 정도, 이러한 GitHub 알림은 당신의 프로젝트에서 나쁜 면만 계속 쏟아져 나오는 것입니다. 그들이 당신의 작업에 만족하면, 아무도 Issue나 Pull Request를 만들지 않습니다. 그들이 무언가 부족하다고 느낄 때만 그렇게 합니다. 이러한 알림을 읽는 데 약간의 시간만 들여도, 정신적, 감정적으로 소모됩니다.
당신의 아내는 이러한 공무를 마친 후 당신이 항상 짜증을 잘 낸다는 것을 관찰했습니다. 어쩌면 당신은 이유 없이 그녀에게 소리를 지르는 것을 발견할 수 있습니다. 그저 기분이 나쁠 뿐입니다. 그녀가 묻습니다: “오픈소스 작업이 당신을 이렇게 화나게 한다면, 왜 계속 하세요?” 당신은 좋은 답을 찾지 못합니다.
당신은 잠시 멈출 수 있습니다. 사실 현재 당신은 이미 경험했을 수 있습니다. 과거에, 당신은 정신 건강을 위해 GitHub에서 일주일이나 이주일 휴가를 냈습니다. 하지만 결국 수백 명이 인내심 있게 기다리고 있어(당신이 문제를 처리하러), 휴가를 중단해야 했습니다.
과거에 GitHub 알림을 계속 따라잡았다면, 매일 20-30개를 처리했을 것입니다. 대신, 당신은 그것들이 쌓이게 했으므로, 이제 수백 개가 모였습니다. 당신은 죄책감을 느낍니다.
과거에, 이런저런 이유로, 당신은 실제로 이러한 Issue가 쌓이게 했습니다. 어쩌면 몇 달 동안 아무도 응답하지 않은 Issue를 보았을 것입니다. 보통, 당신이 돌아가서 그 Issue를 찾으면, 그 Issue를 제기한 사람은 응답하지 않습니다. 또는 그들은 “우리는 당신의 프로젝트를 포기하고 다른 것을 사용했고, 그래서 내 문제가 해결되었습니다”라고 응답합니다. 이것은 당신을 기분 나쁘게 만들지만, 당신은 그들의 좌절감을 이해합니다.
경험상, 이러한 오래된 Issue에 대해 가장 실용적인 응답은 종종 “나는 이러한 오래된 Issue를 닫겠습니다. 이것이 여전히 문제라면, 또는 더 많은 세부 정보를 제공할 수 있다면, 새 Issue를 여세요”라고 말하는 것입니다. 보통 아무도 응답하지 않습니다. 때때로, 그저 화난 코멘트만 있고, 왜 그렇게 오래 기다리게 했는지 불평합니다.
그래서 지금 당신은 알림 받은 편지함을 더 부지런히 처리하고 싶습니다. 수백 개는 너무 많습니다. 당신은 이 숫자가 100개, 수십 개, 또는 신화적으로 비우는 것으로 줄어들기를 갈망합니다. 그래서 당신은 계속 나아갑니다.
새로운 기여자 유치
충분한 이러한 Issue를 처리한 후, 받은 편지함이 결국 비워지더라도, 결국 많은 버그와 Pull Request가 쌓일 수 있습니다. 레이블이 도움이 될 수 있습니다. 예를 들어, Issue를 “재현 필요” 또는 “테스트 케이스 있음” 또는 “좋은 첫 번째 패치”로 표시할 수 있습니다. “좋은 첫 번째 패치”는 특히 도움이 됩니다. 왜냐하면 그들은 종종 새로운 기여자를 유치할 수 있기 때문입니다.
하지만, 당신이 새로운 기여자를 유치할 수 있는 종류의 Issue는 종종 처리하기 매우 간단한 종류입니다. 이러한 종류의 Issue는 새로운 자원봉사자가 기록하는 것이 당신이 직접 하는 것보다 더 가치 있습니다. 당신은 이러한 종류의 Issue를 몇 개 만들었습니다. 왜냐하면 그것의 가치를 알고 있고, 새로운 사람들이 오픈소스에 참여하게 하고, 이 Pull Request의 작성자가 “이것은 내가 오픈소스 커뮤니티에서 한 첫 번째 기여입니다”라고 말할 때 기분이 좋습니다.
하지만 그들이 돌아올 희망은 희박합니다. 보통 이러한 친구들은 정기 기여자나 유지 관리자가 되지 않습니다. 당신은 어디서 잘못했는지, 어떤 면을 개선해야 새로운 기여자를 유치하여 당신의 부담을 줄일 수 있는지 의심합니다.
당신은 거의 스스로 유지되는 프로젝트가 있습니다. 당신은 수년간 건드리지 않았지만, 유지 관리자 그룹이 모든 Issue와 PR에 응답하므로, 당신이 직접 할 필요가 없습니다. 당신은 이러한 유지 관리자에게 매우 감사합니다. 하지만 당신은 무엇을 했는지 알지 못합니다. 왜那么多 기여자가 이 프로젝트에 투자했는지, 다른 프로젝트는 결국 당신, 그리고 당신만이 책임지는지.
앞을 향해 나아갑시다
당신은 새 프로젝트를 만들고 싶지 않습니다. 왜냐하면 그것이 당신의 유지 관리 부담만 늘릴 것이라는 것을 알기 때문입니다. 사실, 여기에는 반대 효과가 있습니다. 당신이 성공할수록, GitHub 알림에서 더 많은 “벌”을 받습니다.
당신은 여전히 이러한 생성의 쾌감을 기억할 수 있습니다. 처음부터 새 프로젝트를 작성하고 이전에 해결되지 않은 문제를 해결하는 기쁨. 하지만 지금 당신은 이러한 기쁨을 평가하기 시작합니다. 왜냐하면 모든 새 프로젝트는 필연적으로 오래된 프로젝트에서 시간을 빼앗을 것이기 때문입니다. 당신은 오래된 Repo 중 하나를 공식적으로 폐기할 때인지, 또는 Unmaintained로 표시할 때인지 알지 못합니다.
당신은 번아웃이 오기 전에 이러한 상황이 얼마나 오래 지속될지 알지 못합니다. 당신은 오픈소스 작업을 낮 직업으로 고려해 본 적이 있지만, 진정으로 오픈소스를 생업으로 하는 친구들과 대화한 후, 이것이 보통 특정 오픈소스 프로젝트를 낮 직업으로 만드는 것을 의미한다는 것을 알게 되었습니다. 이것은 당신에게 도움이 되지 않습니다. 왜냐하면 당신은 여러 분야에 걸친 수십 개의 프로젝트가 있고, 이 모든 것이 당신의 시간을 두고 경쟁하고 있기 때문입니다.
당신이 가장 원하는 것은 더 많은 프로젝트가 스스로 독립적으로 유지되는 것입니다. 당신은 모든 모범 사례를 따르려고 노력합니다: CONTRIBUTING.md와 행동 지침이 있고, 고품질 PR을 제출하는 사람에게 열정적으로 권한을 넘겨줍니다. 하지만 모든 프로젝트가 이렇게 하는 것도 에너지가 많이 들어, 당신이 기대하는 만큼 부지런하지 않습니다.
당신은 또한 이것에 대해 죄책감을 느낍니다. 왜냐하면 오픈소스가 종종 특권을 가진 백인 남성(당신 자신과 같은)의 전용 클럽으로 여겨진다는 것을 알기 때문입니다. 그래서 당신은 그러한 문제를 해결하기 위해 충분히 하지 않았다고 걱정합니다.
더 중요한 것은, 당신은 죄책감을 느낍니다: 죄책감은 당신이 어떤 사람들의 문제를 해결하는 데 도움이 될 수 있다는 것을 알지만, 그들의 Issue를 몇 달 동안 무시했다는 것에서 옵니다. 또는 누군가가 당신의 Repo에 첫 번째 Pull Request를 열었지만, 당신이 응답할 시간이 없어, 그들이 영원히 오픈소스에 참여하고 싶지 않게 좌절했을 수 있습니다. 당신의 죄책감은 당신이 한 일 때문이기도 하고, 당신이 하지 않은 일 때문이기도 하며, 더 많은 사람들을 모집하여 당신의 불행하고 죄책감 있는 경험을 공유하지 못한 것 때문이기도 합니다.
한곳에 모아서
내가 말한 모든 것은 나 자신의 경험에 기반합니다. 나는 모든 오픈소스 소프트웨어 종사자를 대표한다고 주장할 수 없습니다. 이것은 나 자신의 느낌입니다.
나는 꽤 오랫동안(약 7년) 오픈소스 작업에 종사해 왔습니다. 나는 이러한 불평 중 어떤 것에도 불평하는 것을 꺼려왔습니다. 왜냐하면 더 잘 알아야 할 선배가 여기서 과장되게 불평하는 것으로 해석될까 봐 걱정했기 때문입니다. 결국, 이러한 상황은 내 자신이 만든 것이 아닌가? 나는 언제든지 GitHub를 떠날 수 있다. 나는 누구와도 계약을 맺지 않았다.
또한, 나는 감사해야 하지 않나? 내가 종사한 오픈소스 작업은 커뮤니티에서 나의 지위를 확립하는 데 도움이 되었다. 나는 회의에서 연설하도록 초대를 받았다. Twitter에서 나는 수천 명의 팔로워가 있고, 그들은 내 생각을 듣고 내 의견에 높은 가치를 둔다. 말하자면, 나는 Microsoft의 일자리를 내 오픈소스 경험 때문에 얻었다. 내가 무엇을 불평할 수 있나?
하지만, 나는 나와 같은 위치에 있는 많은 다른 사람들이 이미 번아웃이 되었다는 것을 알고 있다. 친구들도 열정적으로 Pull Request를 병합하고, Issue를 처리하고, 그들의 프로젝트를 보여주는 블로그를 쓰고, 그 후 흔적도 없이 사라졌습니다. 그중 일부 사람들에 대해, 나는 심지어 그들의 Repo에 Issue를 열기를 꺼립니다. 왜냐하면 그들이 응답하지 않을 것이라는 것을 알고 있기 때문입니다. 나는 그들을 반대하지 않지만, 내가 그들과 같아질까 봐 걱정합니다.
나는 이미 많은 자기 보호 조치를 취했습니다. 나는 더 이상 Github 알림 인터페이스를 사용하지 않습니다. 나는 이메일 필터를 사용하여, 프로젝트(Unmaintained 범주는 무시할 수 있음) 또는 알림 범주(언급되거나 내가 코멘트한 스레드는 보통 우선권이 있음)에 따라 알림을 분류합니다. 이메일이기 때문에, 오프라인에서 작업하고 한곳에서 업무를 관리하는 데 도움이 됩니다.
나는 종종 놀랍게도 내가 오랫동안 유지 관리를 중단한 프로젝트에서 지원 요청 이메일을 받습니다(예: 이 프로젝트, 나는 여전히 적어도 매달 한 번 받습니다). 보통 나는 응답하지 않습니다. 나는 또한 내 블로그 게시물 아래의 코멘트를 무시하고, Stack Overflow 답변과 메일링 리스트 질문에 응답하지 않기로 선택했습니다. 나는 또한 다른 사람들이 충분히 잘 유지 관리한다고 생각하는 Repo를 적극적으로 팔로우를 취소했습니다.
이러한 상황이 이토록 좌절스러운 또 다른 이유는, 당신이 점점 더 Issue 처리가 프로젝트 실제 유지 관리에서 너무 많은 시간을 빼앗는다는 것을 발견하기 때문입니다. 다시 말해, 나는 보통 Issue를 읽고 “죄송합니다, 지금은 볼 시간이 없습니다”라고 말할 시간만 있습니다. 단지 응답하는 행위만으로도 내가 오픈소스에 예약한 대부분의 시간을 차지합니다.
Issue templates, GreenKeeper, Travis, travis_retry, Coveralls, Sauce Labs… 오픈소스 유지 관리 문제를 처리할 수 있는 많은 기술 도구가 있습니다. 나는 이러한 도구에 감사합니다. 이러한 자동화 도구가 없었다면, 나는 정신을 차릴 수 없었을 것입니다. 하지만 어느 시점에서, 당신은 많은 Issue를 만나고, 그 안에는 기술적 문제보다 사회적 문제가 더 많이 포함되어 있습니다. 한 사람으로서는 설명하기에 부족합니다. 나는 심지어 상위 100명 npm 유지 관리자 목록에 들어가지도 않았는데, 이미 지쳐서 사랑이 없습니다. 나는 그 100명이 어떤 경험을 하는지 상상할 수 없습니다.
나는 이미 내 아내에게 말했습니다. 우리가 아이를 갖기 시작할 계획이라면, 나는 오픈소스 작업을 포기하는 것이 좋을 것이라고. 나는 가족을 키우고 오픈소스 프로젝트를 유지 관리하는 것을 병행할 능력이 없다고 느낍니다. 나는 오픈소스를 포기하는 것이 내 핵심 문제의 해결책이 될 것이라고 예상합니다. 나는 그것이 긍정적인 형태로 오기를 바랍니다. 마치 내 인생의 새로운 장을 시작하는 것처럼, 부정적인 형태가 아니라. 예를 들어 무례하게 번아웃되는 것이 아니라.
마지막 생각
여기까지 읽으셨다면, 오픈소스 커뮤니티를 괴롭히는 문제와 잠재적 해결책에 관심이 있을 것입니다. Nadia Eghbal의 《Roads and Bridges》를 연구해 보고 싶을 수 있습니다. 이것은 아마도 이 문제에 대한 가장 명확하고 심층적인 분석일 것입니다.
나는 또한 제안을 기꺼이 받아들입니다. 비록 나는 오픈소스 프로젝트에서 돈과 노동을 섞는 것을 꺼린다는 것을 마음에 새기고 있습니다(아마도 순진한 이상주의 때문일 것입니다). 하지만 나는 다른 프로젝트에서 그것이 효과가 있는 것을 보았습니다.
위의 글이 오픈소스의 부정적인 면을 표현했지만, 나는 여전히 그것이 내 삶에서 가치 있는 추가라고 느끼며, 어떤 후회도 없습니다. 하지만 나는 이 글이 여러분에게 도움이 되어, 자신의 성공의 희생자가 되는 것이 어떤 느낌인지, 그리고 완료되지 않은 일로 인해 무거움을 느끼는 것이 어떤 것인지 보여주기를 바랍니다.
나는 오픈소스 참여 경험에서 배운 한 가지는: 당신이 더 많이 참여할수록, 당신에게 더 많은 요구가 생긴다는 것입니다. 나는 이러한 문제에는 해결 방법이 없다는 것을 깨달았습니다.
출처 명시:개발자 관계 »
