소스를 공개하는 법

어제 거대한 세금이 들어간 모 국가 R&D의 의미있는 결과물이 어쩌면 어설픈 마무리로 사장될지도 모르겠다는 느낌이 들어서 얼마 전에 페이스북에 적었던 소스 공개에 관한 글을 좀 더 정리한 내용입니다.

"please" 를 하는 심정으로 궁서체로 씁니다.

--

우선 사해동포주의적 관점에서 자신(개인, 회사)의 소프트웨어 코드 자산을 오픈 소스로 공개하는 것은 무조건 좋은 일입니다. 폴더 안에서 사장 될뻔한 그 코드가 단 한 사람의 누군가에게 유용했다면 아마도 그 결과가 지구를 구하는 일이 될 수 도 있을 겁니다. 이 글을 읽으시고, 어딘가 폴더에 잠자고 있던 코드를 가지신 분, 특히 세금을 들여 개발하신 소프트웨어가 산업적으로 잘 활용되고 있지 않아서 이러지도 저러지도 못하고 계신 분들이 자신있게 소스를 공개하는 계기가 되면 좋겠습니다. 응원합니다.

일단 오픈소스를 한다는 것은 소스를 공개한다는 좁은 의미가 아니고, 포괄적으로 모든 것 (소스, 문서, 로드맵, 남아 있는 이슈, 뭔가 프로젝트에 관한 의사 결정 과정)을 공개하여 남들도 보고, 가져다 쓰고, 수정하고, 또 다른 사람도 쓸 수 있게 전달하며, 바라기는 프로젝트에 그 수정된, 개선된 내용을 거꾸로 기여하는 방식으로 참여할 수 있도록 열어 놓는다는 것이며 궁극적으로는 프로젝트가 커뮤니티에 의해 지속가능한 발전을 할 수 있게 만든다는 것을 의합니다. 

물론 그냥 소스만 공개해도 안하는 것 보다는 좋을 가능성이 높습니다.

프로젝트가 끝나서 코드를 안보게 되는 그 순간부터 그 소프트웨어는 기술부채가 됩니다. 그 기술이 누군가에게 의미로운 것이라면 오픈하는 순간 부채에서 자산으로 바뀌어 새로운 생명을 얻게 됩니다. 

공개할 때는 이 프로젝트가 시작된 동기, 해결하려는 문제, 그 기술적인 해결 방안과 함께 아마도 남아있는 이슈(추가해야할 기능이던 버그던)를 정리해서 같이 공개하는 것이 중요할 것입니다. 아마도 국가 R&D 결과물 또는 어떤 연구의 결과라면 동기, 문제, 해결 방안의 디테일은 당연히 제안서, 보고서 그리고 정량적 목표를 달성하기 위해 만들었던 논문, 사용자 매뉴얼 (API 문서), 특허 등등으로 이미 정리가 되어있을 거라고 생각합니다. 그걸 같이 공개하면 됩니다. 

특히 아직도 진행 중인 프로젝트라면, 그 프로젝트의 소스를 공개하려는 의도는 

- 누군가 우리 프로젝트에 관심을 가지게 하고

- 그 누군가가 자신의 일에 우리 프로젝트 결과물을 활용하게 하고

- 외부 개발자가 우리 프로젝트에 참여하도록 유도하고

- 동시에 커뮤니티의 리뷰를 통하여 프로젝트 결과물들의 품질을 개선하고

- 더 산업 친화적으로 프로젝트의 방향성을 잡고

- 우리 기술의 우수성이 세계 만방에 빨리 퍼지게 하여, 뭔가 비지니스를 도모하고

- 프로젝트에 참여하는 개발자들이 커뮤니티에 노출되어 훌륭한 커리어를 쌓게 하고

- 프로젝트 펀딩이 중단되도 커뮤니티에 의해 지속적으로 발전하도록 하고

등등 일 겁입니다.

하여간 고맙게도 오픈을 하신다면 다음을 고려하시면 됩니다.

1. 소스는 full source를 공개하여야 합니다.

Full Source라 함은 프로젝트의 모든 소스를 의미하지 않습니다. 대개 핵심 기술 영역의 소스와 예제 소스를 build 가능한 형태로, build 방법과 함께 오픈합니다. 예제 소스 (즉, use case)를 같이 제공하지 않으면 이 소스의 유용성을 알아차리기 쉽지 않기 때문입니다. Full source의 의미는 build해서 실행 가능한 소스를 의미합니다. 

* 이 장면에서 서랍에 쳐 박혀 있던 오래 전 프로젝트들은 더 이상 build에 필요한 도구의 예전 버전을 구할 수가 없기 때문에 build가 현실적으로 불가능할 수도 있겠습니다. 

프로젝트의 모든 소스 100%를 공개할 필요는 없습니다. 언저리 소스도 나름 유용할 수도 있지만, 핵심 기술 부분을 공개하는 것이 중요합니다. 그래야 남들도 쓰겠죠. 특정 고객을 위한 모듈은 어쩌면 그 고객의 영업 비밀이 들어있을 수도 있고, 또 고객과의 계약에 의해서 공개하지 않아야 할 수도 있겠습니다. 그런 문제가 없다면 다 공개하면 됩니다. 하지만 핵심 영역을 공개하는 것이 무엇보다 중요합니다. 커뮤니티 또는 다른 회사에서도 그 핵심 영역의 소스를 이용해서 비지니스를 할 수 있게 해야 합니다.

그럼 나는 뭐먹고 사냐고요? 핵심기술은 내가 만든 것이기 때문에 그 소스가 유용하다고 생각되면, 그 기술을 만든 나는 시장의 신뢰를 한 몸에 받습니다. 그건 꽤 짭짤한 기회로 이어지죠.

2. 핵심 기술과 관련된 문서를 같이 공개해야 합니다.

그 기술을 설명하는 논문 링크도 좋고, 그 기술을 설명하는 블로그도 좋고, 심지어 책이 있다면.. 하여간 그 기술을 설명하는 모든 리소스를 잠재적인 사용자에게 알려주어 자신이 나중에 엄한 걸로 고생하지 않겠구나 하는 생각이 들게 해야 합니다.

진행 중인 프로젝트라면, 그 프로젝트의 Architecture (전체 환경, 계층적 구조...), 응용 예 등등을 블로깅하는 것이 좋은 방법입니다. 포럼, 메일링 리스트를 열어 내부 개발자들과 커뮤니티의 개발자, 사용자들과 소통해야 합니다.

당연히 API 문서가 필요합니다. man page 수준의 대단한 것이면 좋겠으나 doxygen 등으로 생성된 것도 충분히 유용합니다. *doxygen 사용법 <-- 링크 

3. 아직도 할 일이 많은 (진행중인) 프로젝트라면

프로젝트 roadmap이 커뮤니티에 공유되어야 합니다. roadmap이 아주 세부적인 거창한 것이면 좋겠지만, 다음 릴리즈 계획 (언제, 그 안에 어떤 기능이 포함될 것인지), 장기적으로 고려하고 있는 기능들을 간략하게 정리한 것이어도 됩니다. 프로젝트를 리드하는 그룹의 고민을 이해해야 외부의 개발자들이 contribution을 할 수 있습니다. 

또 외부의 도움이 필요한 영역을 밖에 알려주면 큰 도움이 됩니다. 예를 들면, 이런 시스템에서의 test가 필요하다. 이런 환경에 build를 도와주면 좋겠다. 이런저런 feature를 만들어 주면 좋겠다. 이 문서를 여러 언어로 번역할 사람이 필요하다.  등등입니다.

4. 공개하기 전에 라이선스를 정합니다.

이 쪽은 복잡한데, https://www.olis.or.kr/ossw/license/compareGuide.do 에 보시면 다양한 오픈소스 라이선스가 제시되어 있습니다. 또 세상의 모든 의미있는 오픈소스 라이선스 목록이 OSI(Open Source Initiative) 홈페이지, https://opensource.org 에 있습니다.  보통은 permisive 한 (막 가져다쓰고, 수정된 부분을 공개하지 않아도 되는) 라이선스가 좋습니다. 그래야 더 많이/빨리 프로젝트를 확산시킬 수 있습니다. 제 개인적인 생각으론 학교나 연구소에서 만든 소프트웨어라면 MIT 라이선스가 대부분 오픈 정신에 적당합니다. 완전 교육적 비영리적 성격의 이용만을 허용하실 참이라면 GPL(copyleft) 라이선스류를 선택할 수도 있습니다. 회사에서 만든 것이라면 Apache 라이선스가 더 좋습니다. 그 차이는 앞에 언급한 설명 문서를 보시고 결정할 수 있습니다.

5. 특허가 내재되어 있다면 약간 더 생각을 합니다.

소스를 공개한다는 것은 대개, 그 소프트웨어 내재된 특허를 무상으로 사용할 권리를 같이 제공한다는 것을 의미합니다. 또 라이선스에 따라 내가 오픈한 소스를 가져다 쓴 쪽에서 다른 특허 기술을 섞어 다시 오픈 소스로 배포할 때, 그 추가된 특허 권리의 제한에 관한 조건이 있습니다. 이런 특허 관련 이슈가 소스를 오픈하지 않으려는 중대한 이유가 될 수도 있습니다. 우선 서랍 깊은 곳에서 썩고 있는 프로젝트는 그 특허가 별 가치가 없다는 것을 이미 증명하고 있는 것이므로 문제가 안될 것입니다. 지금 active하게 개발되고 있는, 또는 최근에 마무리된 프로젝트의 특허라면 냉정한 특허 가치 평가가 먼저 있어야 하겠습니다. 또 로열티를 지급받는 방식만 기술이 돈으로 바뀌는 것이 아니라는 사실을 생각을 하시면 좋겠습니다. 기술은 그 본질적 가치, 그것을 시행할 때의 가치, 그 기술이 내게서 만들어졌다는 사실이 내포하는 가치 등 여러 면을 가지고 있습니다.

5. 어디에 공개할지 결정합니다.

당연히 github를 강력 추천합니다. 2016년 6월 현재 1,400만명 이상의 개발자가 Github에 모여있습니다. 또, 별도의 서버를 유지할 여력이 없는데 우아한 프로젝트 안내 페이지가 필요하면 github.io 홈페이지를 이용합니다. (github.io 검색하시면 많은 도움글이 나옵니다.) 다운로드 가능한 tarball 보다 github 라파지터리에 공개하는 것이 좋은 이유는 커뮤니티와의 인터랙션을 github이 잘 지원하기 때문이며, 밖에서 볼 때 이 프로젝트에 기여를 할 수 있겠구나 하는 느낌이 들기 때문입니다. 

그리고 이 프로젝트에 참여했던/기여하는 사람들의 그 늠름한 활동들이 그대로 보여서 그들의 커리어에 큰 도움이 될 수 있기 때문입니다. 이 커리어 개발에 도움이 된다는 장면이 개발자들이 금전적 대가없이 오픈소스에 참여하는 세번째 이유입니다.  (첫번째 이유는 뭐냐고요? '재미'이고요. 두번째 이유는 나도 그 멋진 프로젝트에 참여했다는 'pride' 입니다.)

6. 홍보를 합니다.

소스를 공개한 시점부터는 심하게 홍보하는 것이 중요합니다. 내 소프트웨어가 얼마나 유용할지는 결국 사용자가, 내 소스를 이용해서 더 멋진 것을 만들려는 개발자들, 내 소스를 제품/서비스에 사용하려는 훌륭하신 분들이 증명합니다. 해서 그럴 기회를 만드는 것이 결국 홍보입니다. 페이스북, 관련 커뮤니티 사이트 등등에 열나게 홍보하는 겁니다.  홍보는 기술에 대한 홍보보다는 사용 사례에 대한 홍보가 훨씬 더 효과가 있을 겁니다. 

공개된 소스는 보통 여러 개의 모듈(컴포넌트)로 구성될 텐데, 핵심적인 부분도 중요하지만, 안에 있는 주변 모듈들이 또 다른 오픈소스에 붙었을 때 어떻게 되는지 (즉 부산물의 유용성)를 보여주는 것이 효과적일 수도 있습니다. 묻어가기를 하는 거죠.

적극적인 홍보는 더 큰 도움이 됩니다. 내 프로젝트와 연관성이 있는 이미 성공한 큰 프로젝트의 컨퍼런스, 워크샵, 커뮤니티 모임에서 그 프로젝트와 내가 공개한 핵심기술과의 연관성, 내 결과물이 그 성공한 프로젝트를 얼마나 더 유용하게 만드는지, 내 프로젝트의 부산물만 써도 이런 식으로 좋다 등등의 발표를 함으로써 내 프로젝트를 다른 커뮤니티에 알리는 겁니다. 홀로 있는 내 프로젝트는 사람들이 찾아보기가 어렵습니다. 어딘가에 기대서 서 있는 것이 좋겠죠. 그 다른 프로젝트가 아주 핫한 프로젝트라면 더욱 효과가 좋겠죠. 그 핫한 프로젝트와 내 프로젝트가 연동되어 의미있는 결과룰 내주는 간단한 (따라할 수 있는) 예제 프로그램을 같이 설명하면 더 좋겠고요.

사용자 수준에서 유용한 실행파일, 라이브러리(사용자=개발자)가 제공된다면  Wikipedia의 'List of Open Source Software Packages' article에 등록하는 것도 방법입니다. Wikipedia는 누구나 수정할 수 있습니다. ID를 만들어 내가 등록하면 됩니다. (관리자, 또는 다른 리뷰어가, 내 프로젝트가 백과사전에 올라갈 만 하지는 않다고 심각하게 생각하면, 내 프로젝트가 리스트에서 삭제될 수도 있습니다.^^)

7. 공개하고, 어떤 일이 벌어지는지 봅니다.

무려 공개를 했는데도 아무 일이 안 벌어질 가능성이 높습니다. 홍보를 하지않으면 더 그렇습니다. Github에는 3,500만개의 리파지터리가 있고 그 가운데에서도 뜨는 프로젝트는 극히 일부 입니다. SourceForge에서도 그랬습니다. 대부분 동기가 부족한 프로젝트는 공개한다해도 그렇게 잊혀집니다. 하지만 당신의 프로젝트는 당신이 믿는 중차대한 동기를 가지고 꽤 많은 세금을 들여 개발된 훌륭한 것입니다. 분명히 잘 될 겁니다.

가끔은 기대하지 않았던 반응이 기대하지 않았던 곳에서 오기도 합니다. 누군가 관심을 보인다면 참으로 친절하게 대해줍니다. 뭔가 기여를 해준다면 심심한 감사를 표해야 하고, 도와줘야 합니다. 그의 기여가 부실하여 채택하기 어렵거나 내 프로젝트의 품질을 떨어뜨리는 것이라면 그 기여 내용이 더 개선된 모양이 될 수 있도록 기술적인 지원을 해주면 좋습니다. 나도 그런 시절이 있었다는 생각을 하셔야 합니다. 누군가 강력한 기여를 지속적으로 해온다면, 그에게 프로젝트 운영/관리에 관한 더 높은 권한을 주는 것을 고려합니다.

* 한발 물러서서, 저자는 이 글에 대하여 법률적 책임을 지지 않습니다. 제가 변호사도 변리사도 아닌 관계로 라이선스, 특허와 관련한 이글의 해석은 정답이 아닐 수도 있습니다. 하지만 공개하는 쪽(이용하는 쪽이 아니라)이라면 라이선스 또는 IP 위반에 관한 걱정을 거의 안하셔도 됩니다. 또 공개를 하실 프로젝트와 관련하여 아주 특별한 뭔가가 있다면 예외적인 특수한 상황이 발생할 수 있겠습니다. 특히 모든 리스크에 민감한 큰 회사의 경우에는, 어떤 이유에서든 지켜야할 내부의 지적 자산들의 보호를 위한 작전과 고민이 먼저 있어야 할 것입니다.

**