오스틴에서 열린 OpenStack 정상회의는 오픈소스 프로젝트 관리 경험을 교환하는 훌륭한 플랫폼이 되었습니다. 사실 다년간의 커뮤니티 참여와 프로젝트 기여 작업을 거친 후, 저는 이 분야에 대해 어느 정도 발언권이 있습니다.
하지만 오늘 글에서는 반대 관점에서 이 주제를 해석하고, 오픈소스 프로젝트 관리에서 취해서는 안 되는 여러 관행에 대해 논의하려 합니다.
1. 기여자들에게 번거로움을 더하기
소프트웨어 개발자와 유지관리자는 이미 바쁩니다. 따라서 과도한 작업 배분은 더욱 반감을 불러일으킬 뿐입니다. 사실 오픈소스 분야의 가장 큰 오해 중 하나는 관리자가 종종 엄청난 양의 작업이 구성원의 참여감을 높일 수 있다고 생각하는 것입니다. 솔직히 말해, 작업이 너무 많으면 사람들이 그냥 떠날 수 있습니다.
제 친구 한 명은 2013년부터 Ceilometer에 기여해 왔습니다. 그의 코드 리뷰 수준은 상당히 높아, 다른 사람들이 인식하지 못하는 많은 오류를 발견할 수 있습니다. 프로젝트 관리 팀은 결국 그를 핵심 리뷰어로 승진시켰습니다 —— 단순히 더 많은 작업을 맡긴 것이 아니라. 믿으세요, 바로 이런 성취감이 수준 높은 기술 인력이 프로젝트에 계속 남게 만듭니다.
2. 사람들에게 지루한 작업만 참여시키기
새로운 사람이 합류할 때, 그들의 동기는 종종 다릅니다. 일부 사용자는 기여를 통해 자신의 가치를 실현하고 싶어 하고, 어떤 사람들은 배움의 목적을 가지고 있습니다. 하지만 일반적으로 사람들은 항상 가장 낮은 수준의 지루한 작업을 접하는 것을 꺼립니다. 관리자가 하위 기여자의 감정을 전혀 고려하지 않는다면, 지루한 내용에 앞서 언급한 작업 강도까지 더해지면 많은 오픈소스에 뜻을 둔 친구들이 빠르게 떠날 것입니다.
3. 작은 기여를 중요시하지 않기
오타를 수정하는 것도 기여인가요? 설명 문서를 다시 정리하는 것도 기여인가요? 이런 마음가짐은 오픈소스 프로젝트에서 드물지 않지만, 사실 이런 작업도 중요한 가치가 있습니다.
저는 개인적으로 어느 프로젝트에서 문서 오류 수정을 담당했고, 짧은 시간 안에 56개의 패치를 발표하고, 일부 버그를 수정하고, 추가 기능을 더했습니다. 아무도 이것이 작은 일이라고 저를 무시하지 않았고, 저 또한 제 작업이 진정으로 가치가 있다고 믿습니다.
4. 새로운 사람들에게 너무 높은 장벽 설정하기
새로운 사람이 오픈소스 프로젝트에 참여할 때, 그들의 개인 기술 수준과 경력은 천차만별입니다. 많은 관리자는 그들에게 너무 복잡한 작업을 직접 설정하는데, 이것은 많은 사람에게 좌절감을 주고, 심지어 자신이 너무 멍청하다고 느끼게 하여 조용히 떠나게 합니다.
사실, 우리는 새로운 사람의 기술 수준을 평가해야 하며(간단한 대화로 대략적인 수준을 파악할 수 있음), 그 후 그들이 할 수 있지만 약간의 도전이 있는 작업을 배정해야 합니다.
5. 사람들에게 개인 생활을 희생하도록 요구하기
대다수 참여자는 여가 시간에만 오픈소스에 기여하며, 이것은 매우 건강한 발전 방식입니다. 프로젝트 구성원이 개인 생활을 희생하여 기여할 것을 기대하지 마세요. 그것은 비현실적이고 프로젝트의 장기 발전에도 좋지 않습니다.
또한, 너무 잦은 화상 회의나 IRC 회의도 사람들을 지치게 합니다. 오픈소스 프로젝트는 사람을 중심으로 해야 하며, 다른 구성원에 대해 다른 소통 및 기여 방식을 취해야 합니다.
6. 잠재적 행동 강령이 너무 융화하기 어려움
커뮤니티가 발전함에 따라, 항상 잠재적인 스타일이나 행동 방식이 개성 있는 라벨이 됩니다. 이것이 베테랑들을 즐겁게 하지만, 새로운 사람들을 주저하게 할 수도 있습니다.
물론, 행동 규범에 대한 안내서를 작성할 필요는 없습니다. 하지만 프로젝트 관리자로서 팀이 개성을 유지하면서 새로운 사람의 감정을 충분히 고려하는 것이 가장 좋습니다. 내부 용어나 “밈”을 무턱대고 던지는 것은 조직 규모 확대를 방해할 뿐 정말 이득이 없습니다.
7. 영어가 모국어가 아닌 발언자가 참여감을 느끼지 못하게 하기
대다수 오픈소스 프로젝트 커뮤니티는 영어로 소통하며, 이것이 협업의 중요한 전제가 됩니다. 하지만 일부 기술 인력이 영어가 모국어가 아닌 국가에서 온다는 점도 고려해야 합니다. 이것은 그들이 기존 구성원과 원활하게 소통하기 어렵고, 심지어 이로 인해 위축될 수 있음을 의미합니다.
이런 방식에 대비해 다른 대안을 생각할 수 있습니다. 예를 들어 비동기 소통 방식을 채택하고, 텍스트를 매개로 소통 내용을 보냅니다. 이렇게 하면 상대방이 번역 소프트웨어를 사용해 대략적인 의미를 이해할 수 있고, 외국어를 말하는 긴장감도 피할 수 있습니다.
8. 선견지명이 부족하고, 권한을 위임하지 않음
이 두 가지 오류는 다양한 오픈소스 프로젝트에서 흔히 볼 수 있습니다. 사실 일부 기여자는 합류 후 새로운 기능을 개발하고 기존 구성원에게 피드백을 구하는데, 이때 유지관리를 담당하는 관리자는 자신이 이 부분 기술에 익숙하지 않다는 것을 깨닫고 심지어 그만두기로 결정할 수 있습니다. 반드시 강조해야 할 것은 프로젝트의 발전 비전과 이를 둘러싼 소통이 매우 중요하다는 것입니다. 이렇게 해야 각 구성원이 동일한 판단을 가지고 팀에 남아 역할을 해야 하는지 이해할 수 있습니다.
또한, 일부 책임을 다른 구성원에게 안심하고 맡겨야 하며, 모든 것을 자신이 통제해서는 안 됩니다. 패치 리뷰, 하위 시스템 설계, 버그 수정 및 문서 작성 등은 모두 전담자가 담당할 수 있습니다. 이런 방식을 통해 각 구성원은 자신의 역할과 가치를 느끼고, 더 적극적으로 프로젝트 팀에 남을 수 있습니다.
9. 기여자들의 성과를 인정하지 않기
오픈소스 프로젝트에 기여하는 방법은 다양하며, 코드 작성에 국한되지 않습니다. 설명 문서, 버그 디버깅, 사용자 지원, 경험 설계, 홍보 및 번역 등, 이 모든 것이 매우 중요한 작업입니다.
따라서 비기술적 기여를 충분히 중요시하고, 팀 구성원 계층을 구축할 때 어떤 종류의 인재도 누락되지 않도록 주의하고 또 주의해야 합니다.
10. 감사의 마음이 부족함
마무리로, 오픈소스 프로젝트에서 감사의 마음이 중요하다는 것을 강조하고 싶습니다. 이런 프로젝트는 종종 참여자가 무상으로 구축한 것입니다. 관리자로서 우리는 각자의 공유 정신에 박수를 보내야 합니다 —— 물론 그들이 직접 느낄 수 있는 방식으로!
전재请注明：개발자 관계 »
