오픈소스를 사용하고 있다면, 코드 기여를 통해서 또는 스폰서나 현금 기부 등의 방법으로 그 오픈소스 프로젝트에 기여함으로써 더 많은 것을 얻을 수 있습니다. 여러분이 지원하는 소프트웨어에서 활용할 수 있는 도구나 플랫폼의 추가 기능, 플러그인과 같이, 핵심적이지는 않은 오픈소스 프로젝트를 만드는 것부터 시작할 수 있습니다.
이 절은 이미 진행되고 있는 프로젝트에 기여하는 방법을 설명하고, 이어서 다음 장에서는 직접 오픈소스 프로젝트를 시작하기 위해 밟아야하는 단계들도 살펴보겠습니다.
이제 오픈소스를 적용하는 것은 소스를 그저 복사해 붙여넣기 하는 것이 아니라, 당신의 조직이 오픈소스를 진지하게 생각하고 있다는 것을 의미한다는 것을 이해했을 것입니다. 관리자들은 앞서 이야기했던 커뮤니티에 참여 활동을 포함하여 오픈소스에 투입하는 리소스를 승인해야 합니다. 그를위해 코드의 검증과 커뮤니티 자체, 그리고 커뮤니티 구성원으로서의 활동에 자원을 투자하는 것을 정당화하기 위한 근거를 만들어야합니다. 다시 말하면, 오픈소스를 이용하는 것이 조직의 사업 목표들에 어떻게 도움이 되는지 명확하게 설명할 수 있어야 합니다. 또한, 개발자들의 개별적인 목표가 조직의 상위 목표들에 부합한다는 점을 확신할 수 있도록 정기적으로 확인해야 합니다. Mozilla and Open Tech Strategies에서 발간한 백서에서는 오픈소스 프로젝트를 만들고 운영하는 전반에 대한 열 가지 전략이 적혀 있습니다. 백서에서는 다양한 거버넌스 구조와 동기 부여를 위한 프레임워크들이 설명되어 있으며, 그것들이 성과에 미친 영향을 볼 때 오픈소스를 선택하는 것이 얼마나 중요한지 보여줍니다.
기존의 오픈소스 프로젝트를 단번에 활용하는 가장 좋은 방법은 해당 프로젝트에 활발하게 기여하고 있는 역량 높은 컨트리뷰터를 고용하는 것입니다. 몇몇 기업들은 프로젝트 리더나 주요 커미터들을 해당 프로젝트를 위해 풀타임으로 일하는 조건으로 고용하기도 합니다. 또 어떤 기업들은 직원들에게 일정 시간을 오픈소스에 기여하고 그 외의 시간은 해당 오픈소스를 기업에 적용하는 데에 쓰거나 다른 내부 프로젝트에 쓰도록 하는 식으로 균형을 맞추기도 합니다.
사실 내부 프로젝트와 오픈소스 프로젝트 참여 사이에서 균형을 유지하는 것은 쉽지 않습니다. 관리자들은 언제나 내부 프로젝트에 더 힘을 쏟기를 바라고 있고, 개발자의 일정에 더 많은 내부 프로젝트 작업을 끼워넣기를 원하기 때문입니다. 회사가 커뮤니티에서 개발자를 고용하기 위해서는, 비즈니스 계획과 프로젝트 실제 참여를 통해 해당 프로젝트에 대한 진지한 의지가 있다는 것을 보여주어야 합니다. 개발자들이 자기 시간을 오픈소스 프로젝트에 투자할 수 있도록 고용 계약을 다시 확인하고 수정해야 할 수도 있습니다. 개발자가 고용이 되면, 관리자와 개발자 모두 시간을 어떻게 분배하기로 했는지에 대한 약속에 꾸준히 신경써야 합니다.
여러분이 오픈소스 프로젝트에 얼만큼의 시간을 들였던지 적재적소에 활용한 건강한 오픈소스는 "왜 기업과 정부는 오픈소스로 전환하는가?" 장에서 언급했던 대로 여러분에게 반드시 득이 될 것입니다.
회사의 직원이 회사의 새로운 코드를 가지고 작업하거나 오픈소스 프로젝트에 참여하려면 어느 정도 훈련이 필요합니다. 만약 오픈소스 환경에서 일하는 것에 익숙한 직원이 없다면 - 한번 조사해보면 이미 오픈소스 경험이 있는 직원들이 이미 꽤 있다는 점에 놀랄지도 모릅니다 - 앞 절에서 이야기한 것과 같이 오픈소스 경험이 있는 개발자를 고용하는 것도 좋습니다. 이 개발자들이 다른 사람들을 멘토링하도록 하면 됩니다. 회사 내부이든 외부의 더 큰 커뮤니티이든 개발자들을 오픈소스 프로젝트에 참여시키기 위해서는 이 부분이 중요합니다. 앞서 언급했듯, 오픈소스 프로젝트에 참여하는 것은 어떤 회사의 개발 역량을 향상시키는 최고의 방법입니다.
외부 프로젝트 하나에 참여하는 것만으로도 오픈소스는 그것을 채택하는 모든 조직을 변화시킵니다. 조직의 다양한 직급의 개발자들과 다른 직원들의 대화나 결정 사항들이 모두 공개되어 외부 사람들이 볼 수 있는 상태가 됩니다. 오픈소스 프로젝트 온라인 포럼에서 개발자가 했던 말이 전세계에 공개되고, 온라인 상에 영원히 남겨진다고 가정해 봅시다. 이 상황은 오픈소스 프로젝트에 참여할 의지를 떨어뜨릴 이유처럼 들릴 수 있지만, 실제로는 그렇지 않습니다. 이건 단지 정직하고 존중이 담긴 대화를 하도록 하고, 차별과 학대 금지하는 인권 존중 규정이 담긴 행동 강령을 만들어 지키도록 할 필요가 있다는 것을 의미할 뿐 입니다. 많은 오픈소스 프로젝트가 가져다 쓸만한 좋은 행동 강령을 제공하고 있습니다. 주의 깊게 시험하고 검증한 여러 강령을 TODO Group이 이미 제공하고 있습니다. 이 행동 강령의 개정본이 아마존웹서비스와 같은 회사의 오픈소스 프로젝트들에도 적용되고 있습니다.
최근 컴퓨터 산업(과 사회의 다른 부분에서) 여성과 소수자들의 기여를 좌절시키거나 비협조적이고 고통을 주는 환경을 조성하는 관행에 대한 주의가 높아지고 있습니다. 여러분들도 공개 조사로 들어났는지의 여부를 떠나서 이러한 악습들이 조직에서 근절되길 원할 것입니다. 기업과 커뮤니티는 다양성과 포용성을 위한 긍정적이면서도 차별을 철폐하는 조치를 취해야만 합니다.
존중을 넘어, 여러분의 개발자들이 오픈소스 커뮤니티에 생산적으로 참여할 필요가 있으며, 그를 위해서는 문화적인 변화도 요구됩니다. 개발자들은 두 명에서 네 명 정도의 비공식 미팅을 통해서 설계와 관련된 결정을 내리는 데에 익숙했을 것입니다. 일부 애자일과 스크럼 방법론은 이런 활동을 장려하기도 하고, 조직 내에서 폭 넓은 의견을 수렴하는 기술도 제공합니다. 따라서, 애자일 스크럼 방법론은 오픈소스에 적용할 수 있습니다. 실제로 오픈소스는 다양한 종류의 개발 방법론에 열려 있습니다.
개발자들은 이제 다른 사람들도 볼 수 있고, 모든 기록이 지워지지 않고 보존되는 포럼에서 중요한 설계 결정에 대한 논의를 수행하는 법을 배워야 합니다. 커뮤니티 코드에 기여하고자 하는 변경 사항에 대해서는 커뮤니티 메일링 리스트 혹은 모든 사람이 참여할 수 있는 슬랙, 지터, 스택 오버플로우, 구글 그룹스와 같은 커뮤니케이션 채널을 통해 토론해야 합니다. 그렇게 하지 않고 변경 사항을 제출하면, 커뮤니티는 화들짝 놀라게 되고 아마도 변경 사항은 받아들여지지 않을 것입니다.
시의적절하게 정보를 제공하는 것 뿐만 아니라, 개발자들은 소속 팀 내의 좁은 시야를 넘어, 사내 다른 부서나 심지어는 지구 반대편에 있는 외부인에 이르기까지 다양한 범위의 사람들로부터 의견을 얻는 것의 가치를 인식해야만 합니다. 존중이 담긴 대화의 기술이 여러분의 기업 문화에 꼭 도입되어야 하는 것은 이 때문입니다. 이제 개발자들에게 다음과 같은 다른 새로운 기술도 요구됩니다: 타인의 말을 잘 들어주어야 하고, 다양한 개발자들로부터 피드백을 받아야 하며, 부적절한 기여를 거절하는 한편으로는 기여자가 학습을 한 뒤 다시 시도하도록 격려하고, 다양한 언어 능력을 가진 서로 다른 배경의 사람들을 다루어야 합니다.
개발자들이 복도에서의 대화나 전화 통화를 통해 설계 결정을 내리는 데에 익숙해져 있다면, 좀 더 공개된 방식으로 결정을 내리고 메일링 리스트나 버그 트래킹 시스템이 제공하는 덜 직관적인 소통 방식을 배우는 데에 다소 시간이 필요할 수도 있습니다. 오픈소스 프로젝트에 참여하는 것은 여러분의 조직 내에서 훌륭한 커뮤니케이션과 솔직한 반대, 그리고 존중이 담긴 열린 대화의 우선 순위를 높이는 훌륭한 방법입니다.
더 많은 사람이 참여하게 되면 결정에 더 오랜 시간이 걸릴 수 있습니다. 제품을 빨리 내놓기 위해 오픈소스 토론 절차를 생략하고 빠른 결정을 내리게 되면, 수행한 작업의 일부를 롤백하여 되돌려 놓아야 할지도 모릅니다. 그렇게해야 코드는 유지 보수가 될 수 있고, 미래의 요구 사항들을 반영할 수 있게 됩니다.
성실하게 결정 사항을 기록할 때에 얻을 수 있는 중요한 부수적인 이점은 그 프로젝트가 특정 개인에게 덜 의존하게 되고, 프로젝트의 핵심 인물들이 떠나더라도 무리없이 재구성될 수 있게 된다는 것입니다. 어느 한 사람이 유일하거나 대체불가능한 정보를 가지고 있으면 안됩니다.