10.18 오픈 소스 프로그램 오피스(OSPO)와 업스트림 기여

개요와 동기

조직은 이미 오픈 소스 소프트웨어 위에서 돌아갑니다. 제품을 나르는 운영체제, 언어, 데이터베이스, 라이브러리는 대부분 여러분을 위해 일하지 않는 사람들이 썼습니다. 10.3장은 조달과 라이선스 컴플라이언스를, 10.12장은 오픈 대 클로즈드 결정을 다룹니다. 이 장은 그 모두를 일관되게 만드는 기능에 관한 것입니다. 오픈 소스 프로그램 오피스(OSPO), 곧 회사가 오픈 소스를 소비하고, 기여하고, 공개하는 방식을 소유하는 팀입니다. OSPO는 그렇지 않으면 import를 입력하는 모든 엔지니어에게 흩어져 있을 관계의 무게 중심입니다.

대부분의 조직은 한 번에 하나의 의존성씩 오픈 소스로 뒷걸음질해 들어간 뒤, 쌓인 노출을 한꺼번에 발견합니다. 인수 실사 중의 라이선스 질문, 지친 메인테이너 한 명뿐인 핵심 라이브러리, 출하하는 줄 아무도 몰랐던 코드의 보안 권고입니다. OSPO는 그 허둥지둥을 관리되는 역량으로 바꿉니다. 막는 대신 가능하게 하는 소비 정책을 정하고, 업스트림 기여가 언제 비즈니스에 도움이 되는지 결정하고, 공개하는 프로젝트의 스튜어드십을 지고, InnerSource로 회사 안에서 개방적 협업을 적용합니다. 이것은 소프트웨어 엔지니어링 가치(1.1장)와 연결된 전략적 기능이지 컴플라이언스 체크박스가 아닙니다.

기업에게 동인은 규모입니다. 수천 개의 의존성, 관할권에 걸친 수출 및 라이선스 의무, 매일 작은 오픈 소스 결정을 내리는 수백 명의 엔지니어입니다. 하나의 오피스가 그 난립에 뼈대를 줍니다. 정부에게 동인은 정책과 공적 신뢰입니다. “기본 오픈 소스”와 “공적 자금, 공적 코드”는 점점 법이 되고 있어서, 공공 기관은 코드를 안전하게 공개하고, 기관 간에 재사용하고, 벤더에게 개방형 표준을 요구할 사람이 필요합니다. 두 환경 모두에서 OSPO는 보이지 않고 가격이 매겨지지 않은 위험을 의도적이고 예산이 배정된 일로 바꿔 비용값을 합니다.

핵심 원칙

오픈 소스는 공짜 창고가 아니라 쌍방향 관계입니다. 소비하고, 기여하고, 공개하며, OSPO가 셋 모두를 소유합니다.
기여는 자선이 아니라 전략입니다. 업스트림하면 비공개 패치를 짊어지는 비용이 줄고 영향력을 얻습니다.
빠른 길을 열어 주고 문을 지키지 마십시오. 코드를 복사하는 것보다 느린 정책은 무시되므로 준수하는 길을 가장 빠른 길로 만드십시오.
의존하는 메인테이너에게 자금을 대십시오. 공유지는 스스로 지속되지 않으며, 가장 핵심적인 라이브러리의 저자는 무급 한 명일 수 있습니다.
공개하는 것의 스튜어드십을 지거나, 공개하지 마십시오. 버려진 프로젝트는 프로젝트가 없는 것보다 평판을 더 해칩니다.
개선할 수 있도록 참여를 측정하십시오. 보도 자료가 아니라 기여, 의존성 건강, 승인까지의 시간을 세십시오.
정부에서는 기본을 개방으로, 기본 공개로. 개방이 규범이고 폐쇄는 문서화된 예외입니다.

권장 사항

현실에 맞는 크기로 OSPO를 세운다

시작하는 데 큰 팀이 필요하지는 않습니다. 스타트업에서 OSPO는 서면 권한과 주당 몇 시간이 있는 엔지니어 한 명일 수 있습니다. 기업에서는 소규모 중앙 집단에 제품 팀에 내장된 챔피언의 연합 네트워크가 더해집니다. 크기와 무관하게 네 가지 책임을 덮는 분명한 헌장을 주십시오. 소비 정책과 컴플라이언스, 업스트림 기여, 자체 프로젝트의 공개와 스튜어드십, 커뮤니티와 자금 관계입니다. 엔지니어링과 법무를 모두 볼 수 있는 곳에 두십시오. 흔히 CTO나 엔지니어링 VP에게 보고하면서 법무 및 보안으로 점선 연결을 둡니다. 실패 모드는 전적으로 법무 안에 살아 브레이크가 되는 OSPO입니다. 해법은 출하하는 엔지니어로 인력을 구성해 그 안내가 섬기는 팀에서 신뢰성을 지니게 하는 것입니다.

책임 있게 소비하고, 안전한 길을 쉬운 길로 만든다

소비는 대부분의 위험이 들어오는 곳이므로 좋은 행동을 힘들이지 않게 하십시오. 사전 검증된 구성 요소의 큐레이션된 내부 카탈로그, 파이프라인의 자동 라이선스 및 취약점 스캔, 개발자가 티켓을 올리지 않고도 따를 수 있는 분명한 기본값을 제공하십시오. 10.3장의 라이선스 규율과 2.18장의 공급망 및 의존성 건강 실천에 기대십시오. 버전을 고정하고, 소프트웨어 자재 명세서를 생성하고, 침해되거나 버려진 패키지가 있는지 소프트웨어 공급망을 지켜보고, 이전을 강요하기 전에 수명 종료를 추적하십시오. OSPO의 일은 모든 의존성을 손으로 승인하는 것이 아닙니다. 선택의 95%가 자동으로 안전하고 정말 특이한 경우만 사람에게 닿도록 가드레일을 짓는 것입니다.

좋아서가 아니라 보답하기 때문에 업스트림에 기여한다

업스트림 기여를 경제적 결정으로 다루십시오. 의존성에 대해 짊어진 모든 비공개 패치는 변경이 업스트림에 반영되거나 포크가 너무 멀리 갈라져 완전히 소유하게 될 때까지 모든 업그레이드마다 영원히 치르는 세금입니다. 수정을 되돌려 기여하면 그 세금이 사라집니다. 업스트림은 또한 방향에 대한 영향력을 사서, 의존하는 구성 요소의 로드맵이 여러분의 필요 쪽으로 기울고, 채용하려는 엔지니어에게 역량을 알립니다. 개발자에게 빠르고 문서화된 경로를 주십시오. 사전 승인된 기여자 라이선스 계약이나 개발자 출처 증명, 변경이 공유해도 안전한지 확인하는 가벼운 승인, 그 일에 배정된 관리 시간입니다. 대안이 통제하지 못하는 프로젝트의 영구적인 포크를 유지하는 것이라면, 되돌려 기여하는 것이 거의 언제나 더 쌉니다.

실제 거버넌스로 자체 프로젝트를 공개한다

직접 만든 소프트웨어를 오픈 소스로 할 때는 의도적으로 하거나 아예 하지 마십시오. 먼저 코드가 공유할 가치가 있는 범용품인지, 닫아 둘 가치가 있는 차별화 요소인지 10.12장의 추론으로 결정하십시오. 공개한다면 의도에 맞는 라이선스를 고르고(채택을 극대화하려면 허용형, 생태계를 상호적으로 유지하려면 카피레프트), 서면 거버넌스 모델로 누가 무엇을 결정하는지 문서화하고, 코드를 자유롭게 두면서 오용으로부터 지킬 수 있도록 프로젝트 이름의 상표를 등록하십시오. 진짜 스튜어드십을 약속하십시오. 공개 이슈 추적기, 기여 안내서, 행동 강령, 보고자가 여러분에게 닿는 방법을 알도록 조율된 공개가 있는 보안 정책입니다(4.2장). 메인테이너의 이름을 정하고 그의 시간을 예산에 잡으십시오. 요란하게 시작해 일 년 뒤 버린 프로젝트는 출하하지 않은 것보다 평판을 더 해칩니다.

회사 안에서 협업하도록 InnerSource를 적용한다

오픈 소스를 동작하게 하는 습관(공개 저장소, 분명한 기여 안내서, 능력에 따른 리뷰, 첫 패치의 낮은 장벽)은 방화벽 뒤에서도 똑같이 동작합니다. InnerSource는 어떤 엔지니어든 어떤 내부 프로젝트든 찾고, 쓰고, 개선할 수 있다는 뜻입니다. 티켓을 올리고 기다리는 대신 팀 경계를 넘어 풀 리퀘스트를 보냅니다. 이는 사일로를 허물고, 코드 재사용을 퍼뜨리고, 사람들을 외부에 기여할 때 쓸 바로 그 워크플로로 훈련시킵니다. OSPO는 이미 도구와 문화 플레이북을 소유하므로 InnerSource의 자연스러운 집입니다. 가치 높은 공유 라이브러리 몇 개로 시작하고, 기여 안내서를 내부에 공개하고, 외부 패치를 품위 있게 받아들이는 팀에 보상하십시오.

의존하는 메인테이너에게 자금을 대고 지속시킨다

프로덕션 시스템이 한 사람이 여가 시간에 유지하는 라이브러리 위에 서 있을 수 있습니다. 그것은 공급망 위험이며, 정직한 대응은 짐을 나눠 지도록 돕는 것입니다. 자재 명세서에서 가장 핵심적인 의존성을 식별하고, 메인테이너 기반이 얇은 것을 찾아, 각각에 대응을 고르십시오. 메인테이너를 직접 후원하고, 엔지니어링 시간을 기여하고, 프로젝트에 자금을 대는 재단에 가입하고, 최후의 수단으로 포크하거나 교체할 준비를 합니다. 공유지에 자금을 대는 것은 그 붕괴 뒤의 비상 사태보다 싸며, 의존하는 구성 요소를 건강하고 영향을 줄 수 있는 방향으로 움직이게 유지합니다.

빠르게 승인하는 기여 정책을 정한다

기여 정책은 느리게 거절하려는 것이 아니라 빨리 승낙하려고 존재합니다. 엔지니어가 묻지 않고 기여할 수 있는 것(버그 수정, 문서, 이미 쓰는 프로젝트의 작은 기능), 가벼운 확인이 필요한 것(차별화 요소나 특허에 닿는 모든 것), 지적 재산과 기여자 계약이 기여마다가 아니라 중앙에서 한 번 다뤄지는 방식을 명시하십시오. 지루한 부분을 자동화하십시오. 라이선스 점검, 사전 서명된 기업 기여자 계약, 사람의 눈이 필요한 드문 제출을 표시하는 봇입니다. 승인까지의 시간을 측정하고 느린 대기열을 정책의 버그로 다루십시오.

장단점

접근	장점	단점
중앙 OSPO	일관된 정책, 깊은 전문성, 분명한 소유권	막기만 하고 가능하게 하지 않으면 병목이 될 수 있음
연합형 OSPO(팀 속 챔피언)	확장됨. 결정이 엔지니어 가까이 있음	강한 조율이 필요하며 아니면 정책이 갈라짐
업스트림에 기여	비공개 패치 세금 제거, 영향력, 채용에 도움	지속적인 노력, IP 리뷰, 남의 일정에 따른 작업
비공개 포크 유지	완전한 통제, 자기 일정대로 출하	영구적인 유지 보수 세금, 업스트림 보안 수정에서 멀어짐
자체 프로젝트 공개	생태계, 평판, 공유된 유지	실제 스튜어드십 비용. 방치는 평판을 해침
메인테이너에게 자금	핵심 의존성을 보호, 호의를 얻음	직접 비용. 누구에게 자금을 댈지 고르는 일은 정치적
OSPO 없음(임시)	설정 비용 없음	보이지 않는 법적, 보안적, 지속가능성 부채

중심 긴장은 통제 대 가능하게 하기입니다. 모든 의존성과 모든 기여를 손으로 리뷰하는 OSPO는 안전하게 느껴지지만 엔지니어가 우회하는 대상이 되어, 막으려던 보이지 않는 그림자 의존성을 낳습니다. 자동화된 시행 없이 쾌활한 안내만 게시하는 OSPO는 마감이 닥치는 순간 무시됩니다. 해법은 10.3장 전체에 흐르는 것과 같습니다. 흔한 경우를 자동화해 준수하는 길이 가장 빠른 길이 되게 하고, 사람의 판단은 정말 새로운 것에 남겨 두십시오. 균형을 맞추면 오피스는 힘의 승수입니다. 어느 방향으로든 틀리면 브레이크이거나 장식입니다.

팀과 논의할 질문

오늘 오픈 소스와의 관계는 누가 소유하며, 그 사람이 내일 어려운 질문에 답할 수 있습니까? 인수 희망자의 변호사가 라이선스 목록을 요청하거나, 기자가 결제 경로에 어떤 유지되지 않는 라이브러리가 있는지 물으면, 답에 이름이 붙어 있습니까? 대부분의 조직에서 정직한 대답은 “아무도”이며, 이는 모든 엔지니어가 조용히 정책을 만들고 있고 합계에 책임지는 사람이 없다는 뜻입니다. 회의에 증거를 가져오십시오. 승인된 라이선스 목록, 소프트웨어 자재 명세서, 실사 중 카피레프트 질문을 받을 사람을 내놓아 보십시오. 그런 산출물이 없거나 아무도 가리키지 않는다면, 첫 OSPO 과업을 찾은 것입니다. 내릴 결정은 기능을 둘지 말지가 아니라 누가 소유하고 어떤 권한을 지니느냐입니다. 오피스가 주 하루짜리 한 사람이라 해도 그렇습니다.
업스트림할 수 있는 비공개 패치를 짊어지고 있으며, 그것이 얼마나 비용이 듭니까? 많은 팀이 의존성에 대한 로컬 수정의 조용한 더미를 유지하며, 매 업그레이드마다 손으로 다시 적용하고 병합의 고통을 자연법칙인 양 받아들입니다. 이런 패치 각각은 반복되는 세금이며, 각각이 되돌려 기여해 세금이 사라질 후보입니다. 구체적으로 가져오십시오. 빌드가 실제로 짊어진 포크와 로컬 패치의 목록, 각각이 연간 드는 엔지니어링 시간 추정, 어느 업스트림 프로젝트가 변경을 받아들일 가능성이 높은지입니다. 경쟁하는 고려는 실제입니다. 업스트림은 지금 노력을 들이고 메인테이너의 일정에 따라 진행되지만, 비교 대상은 패치 세금을 영원히 치르는 것입니다. 답은 “항상 그냥 다시 적용한다”를 엔지니어가 쓸 만큼 빠른 기여 경로가 있는 의도적 선택으로 바꿔야 합니다.
메인테이너가 떠나면 가장 아플 의존성은 무엇이며, 그것에 대해 무엇을 하겠습니까? 스택 어딘가에는 고장 나면 매출이나 임무에 핵심인 서비스를 멈출 구성 요소가 있고, 자금을 댄 적도 감사한 적도 없는 한 사람이나 소수가 유지합니다. 공유지는 그렇지 않게 되는 순간 직전까지 공짜처럼 느껴지며, 그 교훈의 비싼 버전은 방치 뒤의 허둥지둥이나 패치되지 않은 취약점입니다. 자재 명세서를 가져와 피해 범위로 의존성의 순위를 매기고, 상위 몇 개의 메인테이너 수와 자금 상태를 적어 두십시오. 핵심적이고 인력이 얇은 각각에 대해 후원할지, 시간을 기여할지, 재단에 가입할지, 교체를 준비할지 미리 결정하십시오. 그러면 잠재된 단일 장애 지점이 다른 운영 위험과 같은 기준으로 다뤄지는 관리되는 관계로 바뀝니다(2.18장).
다음 내부 도구를 오픈 소스로 하기 전에, 몇 년 동안 스튜어드십을 질 준비가 되어 있습니까, 아니면 출시와 결국의 사과를 출하하고 있습니까? 공개 릴리스는 상설 약속입니다. 누군가 분류해야 하는 이슈 추적기, 누군가 지켜봐야 하는 보안 수신함, 누군가 지켜야 하는 이름입니다. 팀은 채용이나 호의를 위해 오픈 소스화에 손을 뻗었다가, 오래된 이슈가 쌓인 버려진 프로젝트가 아무것도 출하하지 않은 것보다 쌓으려던 평판을 더 해친다는 것을 발견합니다. 증거를 가져오십시오. 이미 공개한 프로젝트를 나열하고, 각각의 열린 이슈의 나이, 이름 붙은 메인테이너에게 시간이 배정되었는지, 거버넌스 모델, 등록된 상표, 조율된 공개 정책이 있는지, 코드가 공유할 가치 있는 범용품인지 닫아 둘 차별화 요소인지(10.12장)를 보이십시오. 경쟁하는 고려는 실제 스튜어드십이 제품에 쓸 수 있는 엔지니어링 시간을 든다는 것이므로, 정직한 선택은 더 적게 공개하고 제대로 스튜어드십을 지는 것인 경우가 많습니다. 기업에게 이는 출시 전 법무와 브랜드 리뷰를 뜻하고, 정부에게는 저장소가 공개되기 전에 상표, 공개 채널, 기본 공개의 예외 프로세스가 정리되어 있음을 뜻합니다.
엔지니어가 의존성 승인이나 기여 허가를 받는 데 실제로 얼마나 걸리며, 여러분을 우회하는 것보다 느립니까? 오픈 소스 정책은 엔지니어가 찾을 수 있는 가장 빠른 우회와 직접 경쟁하며, 코드를 복사하는 것보다 느린 프로세스는 우회되어 오피스가 막으려던 보이지 않는 그림자 의존성을 낳습니다. 긴장은 통제 대 가능하게 하기입니다. 모든 수동 리뷰는 감사 추적을 더하고 드문 진짜 문제를 잡지만, 중앙값 경우를 준수하는 경로에서 밀어내는 지연도 더합니다. 회의에 숫자를 가져오십시오. 표준 의존성과 표준 기여의 측정된 승인까지의 시간, 자동으로 처리되는 결정 대 사람이 처리하는 결정의 비중, 지난 분기에 정말 판단이 필요했던 예외의 수입니다. 수백 명의 엔지니어가 매일 작은 결정을 내리는 기업에서 이틀짜리 대기열은 조용히 수천 건의 우회된 리뷰가 됩니다. 정부에서는 같은 지연이 우회가 건너뛰는 서류 추적을 요구하는 조달 및 감사 의무와 부딪히므로, 해법은 더 큰 관문에 인력을 두는 것이 아니라 흔한 경우를 자동화하는 것입니다.
어떤 내부 프로젝트가 InnerSource로 가장 이득을 보며, 오늘 다른 팀이 풀 리퀘스트를 보내는 것을 막는 것은 무엇입니까? 오픈 소스를 동작하게 하는 실천(공개 저장소, 기여 안내서, 능력에 따른 리뷰, 첫 패치의 낮은 장벽)은 방화벽 뒤에서 사일로를 허물고, 재사용을 퍼뜨리고, 사람들을 외부에 기여할 바로 그 워크플로로 훈련시켜 보답합니다. 경쟁하는 고려는 내부 프로젝트를 여는 일이 기여 안내서, 여분의 리뷰 역량, 보안이나 규제상의 이유로 어떤 코드를 제한해 둬야 하는지의 결정을 요구한다는 것입니다. 구체적으로 가져오십시오. 가치 높은 공유 라이브러리의 이름을 대고, 이미 내부 기여 안내서를 공개한 것을 적고, 오늘 팀 간 풀 리퀘스트가 환영받는지 대기열에서 사라지는지 설명하십시오. 기업에서 보답은 많은 팀에 걸쳐 피한 중복된 내부 구축으로 측정되고, 정부에서는 같은 습관이 기관 간 재사용으로 기관 경계를 넘어 확장되어, 기본 공개와 공유 구성 요소가 공공 지출의 중복을 늘리지 않고 줄입니다.

분야별 관점

스타트업. 위원회가 아니라 한 페이지 헌장을 가진 이름 붙은 엔지니어 한 명에게 주 몇 시간으로 오피스를 맡기십시오. 허용형 라이선스를 기본으로 하고 파이프라인에 스캐너를 두고, 모든 업그레이드마다 실제로 아픈 소수의 비공개 패치만 업스트림하고, 없이는 살 수 없는 단독 유지 라이브러리를 위해 작은 월간 후원을 설정하십시오. 여기서는 커버리지보다 속도가 중요합니다. 코드를 복사하는 것보다 빠른 준수 경로가 아무도 따르지 않는 철저한 정책을 이깁니다.

소기업. 전담 OSPO에 인력을 둘 수 없으니, 이미 돌리는 도구에 내장된 역량을 사십시오. 라이선스와 취약점 문제를 표시하는 스캐너와 사전 검증된 구성 요소의 큐레이션된 카탈로그입니다. 일을 프로그램이 아니라 라이선스 컴플라이언스와 의존성 건강 위생으로 구성하십시오. 소프트웨어 자재 명세서에 무엇이 있는지, 각 라이선스가 무엇을 의무화하는지, 사라지면 아플 단일 메인테이너 의존성이 무엇인지 아십시오. 직접 만드는 것보다 스캔과 카탈로그를 사는 쪽을 선호하십시오.

대기업. 정책은 일관되게 유지하면서 결정은 엔지니어 가까이 두도록 소규모 중앙 오피스에 제품 팀에 내장된 챔피언의 연합 네트워크를 운영하십시오. 라이선스, 취약점, 수출 스캔을 자동화하고, 모든 엔지니어를 사전 승인된 기여자 계약으로 덮고, 승인까지의 시간을 보고되는 지표로 추적하십시오. 핵심 의존성 뒤의 재단에 자금을 대고, 많은 저장소에 걸쳐 InnerSource를 운영하고, 개별 결정의 흩어짐이 아니라 건강과 참여 지표가 있는 포트폴리오로 자산 전체를 관리하십시오.

정부. 기본 오픈 소스와 공적 자금, 공적 코드 아래에서 운영하십시오. 보안이나 프라이버시에 대해 문서화된 예외가 적용되지 않는 한 새 서비스를 공개 저장소에 게시하십시오. 정부 전반의 카탈로그를 운영해 팀이 만들기 전에 재사용하게 하고, 벤더가 권리를 유지한 채 재사용 가능한 코드를 전달하도록 오픈 소스와 개방형 표준 요구 사항을 조달에 쓰고, 공개하는 것의 조율된 공개를 처리하십시오. 여러 기관이 의존하는 공유 라이브러리의 유지에 자금을 대어, 어느 한 팀도 정부 전체가 의존하는 인프라를 조용히 소유하지 않게 하십시오.

사례

스타트업. 스무 명의 스타트업이 수석 플랫폼 엔지니어를 한 페이지 헌장이 있는 파트타임 OSPO 소유자로 삼습니다. 그는 단순한 소비 정책(허용형 라이선스는 사전 승인, 카피레프트는 리뷰, 파이프라인의 스캐너)을 정하고, 팀이 오픈 소스 큐 라이브러리에 대한 세 개의 비공개 패치를 매 업그레이드마다 고통스럽게 다시 적용하고 있음을 알아챕니다. 셋 모두를 업스트림해 둘이 한 달 안에 수락되어 업그레이드 세금이 영구히 사라집니다. 진짜 README, 라이선스, 보안 연락처가 있는 작은 내부 도구 하나를 주로 엔지니어를 끌어들이려 오픈 소스로 하고, 제품이 의존하는 단독 유지 파서에 월간 후원을 설정합니다. 이 중 어느 것도 인원이 필요 없고, 이름 붙은 소유자와 분명한 권한만 있으면 됩니다.

기업. 한 글로벌 은행이 여섯 명의 중앙 OSPO와 각 제품 그룹에 내장된 오픈 소스 챔피언의 연합 네트워크를 운영합니다. 중앙 팀은 정책, 자동 라이선스 및 수출 컴플라이언스 스캔, 모든 엔지니어가 첫날부터 적용받는 기여자 라이선스 계약을 소유합니다. 챔피언은 로컬 리뷰를 처리하고 팀에게 기여를 코칭합니다. 은행은 거래 시스템을 받치는 프로젝트의 여러 재단에 자금을 대고, 포크 유지를 멈추도록 널리 쓰이는 데이터 프레임워크에 수정을 업스트림하고, 200개 내부 저장소에서 InnerSource를 운영해 어느 팀이든 다른 어느 팀에게나 풀 리퀘스트를 보낼 수 있습니다. 표준 기여의 승인까지의 시간은 이틀 미만이며, OSPO가 분기별로 보고하는 지표로 추적됩니다.

정부. 한 국가 디지털 기관이 “기본 오픈 소스”와 공적 자금, 공적 코드 의무 아래 운영됩니다. OSPO는 보안이나 프라이버시에 대해 문서화된 예외가 적용되지 않는 한 새 서비스를 공개 저장소에 게시하고, 기관들이 만들기 전에 코드를 재사용하도록 정부 전반의 카탈로그를 운영하고, 벤더가 정부가 권리를 유지한 채 재사용 가능하고 잘 문서화된 코드를 전달하도록 오픈 소스와 개방형 표준 요구 사항을 조달에 씁니다. 오피스는 공개하는 코드의 조율된 보안 공개도 처리하고, 이제 여러 기관이 의존하는 공유 신원 라이브러리의 유지에 자금을 대어, 어느 한 팀도 정부 전체가 의존하는 구성 요소를 조용히 소유하지 않게 합니다.

비즈니스 사례: 동기, ROI, TCO

가장 분명한 수익은 피할 수 있는 비싼 놀람의 제거입니다. 관리되지 않는 오픈 소스는 자기 일정대로 도착하는 위기를 낳습니다. 인수 실사 중 드러난 카피레프트 위반, 죽은 구성 요소에서의 긴급 이전, 어떤 목록에도 없던 의존성으로 추적되는 침해입니다. OSPO는 그런 확률이 낮고 비용이 높은 사건을 꾸준하고 예산이 배정된 일로 바꿉니다. 업스트림에서 오는 반복 절감도 더해집니다. 퇴역시키는 모든 비공개 패치는 앞으로의 모든 업그레이드에 매기던 세금을 멈추고, 큰 자산 전반에서 그것이 제품 일로 돌아오는 실제 엔지니어링 역량으로 복리가 됩니다.

총소유비용 장부에서 오피스는 보호하는 것에 비해 쌉니다. 비용은 작은 팀, 약간의 스캔 및 카탈로그 도구, 소박한 메인테이너 자금입니다. 그것을 없는 것의 비용에 대비해 보십시오. 법적 책임, 실패하거나 지연된 실사, 보안 인시던트, 이미 오픈 소스로 존재하는 것의 중복된 내부 구축, 아무도 유지하기로 선택하지 않은 포크의 느린 출혈입니다. 가격을 매기기 어렵지만 실제인 상승 수익도 있습니다. 의존하는 구성 요소의 방향에 대한 영향력, 신뢰할 만한 오픈 소스 존재감에서 오는 채용과 평판의 이점, 엔지니어가 다시 만드는 대신 재사용하므로 더 빠른 전달입니다. 리더십을 설득할 때 OSPO를 코드베이스 대부분에 대한 공급망 관리로, 그 위에 전략적 배당이 얹힌 것으로 구성하십시오. 정부에서는 컴플라이언스 차원을 더하십시오. 개방성은 의무인 경우가 많고, 잘하면 미준수와 중복된 공공 지출을 모두 피합니다.

안티패턴과 함정

관문으로서의 OSPO. 리뷰하고 막기만 하고 가능하게 하지 않는 오피스는 우회되어, 막으려던 그림자 의존성을 낳습니다.
기여 연극. 오픈 소스 전략을 발표하면서 승인 프로세스를 너무 느리게 만들어 아무도 실제로 기여하지 않는 것.
버려진 릴리스. 출시 블로그 글과 함께 프로젝트를 공개한 뒤 이슈 하나 분류하지 않아 침묵보다 평판을 더 해치는 것.
포크하고 잊기. 수정 하나 때문에 의존성을 포크한 뒤 영원히 짊어져 업스트림 보안 패치에서 멀어지는 것.
취약한 메인테이너에 무임승차. 핵심 단일 메인테이너 라이브러리에 의존하면서 그 뒤의 사람에게 자금도, 감사도, 도움도 주지 않는 것.
상표 방치. 이름을 보호하지 않고 프로젝트를 공개한 뒤 포크나 벤더가 여러분의 평판에 편승하는 것을 지켜보는 것.
법무만의 소유. OSPO를 전적으로 법무에 두어 안내가 엔지니어링 신뢰성을 지니지 못하고 팀이 무시하는 것.
허영 지표. 의존성 건강, 승인까지의 시간, 퇴역한 비공개 패치 대신 별과 언론 언급을 세는 것.

성숙도 모델

1단계, 시작: 엔지니어가 정책이나 소유자 없이 오픈 소스를 추가하고, 패치하고, 가끔 공개합니다. 소비, 기여, 공개는 반응적이고 임시적이며 개인의 주도에 좌우됩니다. 비공개 포크는 눈치채지 못한 채 쌓이고, 아무도 업스트림 프로젝트에 자금을 대지 않으며, 실사 중 라이선스 질문에 답할 사람이 없습니다.
2단계, 발전: 기본 실천이 나타나지만 팀마다 다릅니다. 대략적인 소비 정책과 승인된 라이선스 목록이 있고 누군가 느슨하게 책임지지만, 기여는 느리고 사안별이며 일부 집단이 다른 집단보다 훨씬 많이 합니다. 소수의 핵심 의존성이 알려져 있지만 지속가능성, 릴리스, 스튜어드십은 일관되지 않습니다.
3단계, 표준화: 헌장을 가진 OSPO가 소비, 기여, 공개, 커뮤니티를 소유하고, 실천이 문서화되어 조직 전체에 시행됩니다. 스캔과 소프트웨어 자재 명세서가 자동화되고, 사전 승인된 기여자 계약과 빠른 승인 경로가 있으며, 공개된 프로젝트에는 진짜 거버넌스, 상표, 보안 정책이 있고, InnerSource가 퍼지고 있습니다. 정부 팀은 기본으로 공개합니다.
4단계, 관리: 오픈 소스 기능이 기준선에 대해 측정되고 통제됩니다. 승인까지의 시간이 목표에 대해 추적되고, 기여량과 업스트림 수락률이 보고되며, 의존성 건강과 메인테이너 수 대시보드가 단일 장애 지점을 표시하고, 최고 위험 의존성의 자금 지원된 메인테이너 커버리지가 모니터링되며, 비공개 패치와 포크의 목록이 분기마다 줄어드는 추세입니다. 공개된 프로젝트는 이슈 응답 시간이 측정되고, 예외는 주기적으로 리뷰되며, 별 같은 허영 지표는 이것들로 대체됩니다.
5단계, 오케스트레이션: 오픈 소스가 엔지니어링, 법무, 보안, 조달 계획과 통합되어 지속적으로 적응하는 관리되는 전략적 역량입니다. 기여는 일상이고, 핵심 메인테이너와 재단에 자금이 지원되며, 조직은 잘 운영되는 프로젝트의 스튜어드십을 지고 의존하는 생태계를 이끌고, InnerSource가 규범입니다. 참여와 건강 지표가 지속적 개선에 공급되고, 의존성, 위험, 의무가 이동함에 따라 포트폴리오가 재균형됩니다.

논의를 위한 아이디어

가능하게 하는 OSPO와 막는 OSPO 사이의 선은 어디이며, 바깥에서 어느 쪽을 만들었는지 어떻게 알겠습니까?
필요가 아니라 습관 때문에 짊어지고 있는 비공개 패치나 포크는 어느 것이며, 상위 셋을 업스트림하려면 무엇이 필요합니까?
핵심 의존성의 목록이 예산보다 길 때 어떤 메인테이너와 재단에 자금을 댈지 어떻게 결정해야 합니까?
다음 릴리스를 첫날부터 진짜 거버넌스, 상표, 조율된 공개 정책과 함께 공개해야 한다면 무엇이 정말로 바뀌겠습니까?
공공 부문 독자에게: 원칙을 조용히 침식하지 않으면서 기본 공개에서 코드를 면제하는 방어 가능한 프로세스는 무엇입니까?
어떤 내부 라이브러리가 InnerSource로 가장 이득을 보며, 오늘 다른 팀이 풀 리퀘스트를 보내는 것을 막는 것은 무엇입니까?

핵심 요점

OSPO는 오픈 소스와의 관계 전체를 소유합니다. 책임 있게 소비하고, 업스트림에 기여하고, 자체 프로젝트를 공개하고, 의존하는 메인테이너를 지속시킵니다.
업스트림 기여는 자선이 아니라 전략입니다. 비공개 패치의 반복 세금을 없애고, 방향에 대한 영향력을 사고, 채용에 도움이 됩니다.
자동화와 큐레이션으로 준수하는 길을 가장 빠른 길로 만들어, 오피스가 엔지니어를 막는 대신 가능하게 하십시오.
자체 프로젝트는 진짜 거버넌스, 선택한 라이선스, 보호된 상표, 조율된 보안 공개와 함께만 공개하거나, 아예 공개하지 마십시오.
프로덕션 시스템이 의존하는 핵심 메인테이너에게 자금을 대고 도우십시오. 공유지는 스스로 지속되지 않기 때문입니다.
InnerSource를 적용해 오픈 소스 협업을 회사 안으로 가져오고, 정부에서는 기본을 개방으로, 기본 공개로, 만들기 전에 재사용하십시오.

참고 문헌과 더 읽을거리

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance