오픈소스는 GitHub에 코드를 던져놓는 것입니다. 그것이 무엇이고, 무엇이 아닌지 알아보세요.
가장 간단히 말해, 오픈소스 프로그래밍은 모든 사람이 자유롭게 가져다 쓰고 수정할 수 있는 코드를 작성하는 것입니다. 하지만 여러분은 Go 언어에 대한 오래된 농담을 들어본 적이 있을 것입니다. Go 언어는 “한 번 보면 규칙을 알 수 있을 만큼 간단하지만, 응용하는 데는 평생이 걸린다”는 것입니다. 사실 오픈소스 코드를 작성하는 것도 마찬가지입니다. GitHub, Bitbucket, SourceForge 등의 웹사이트나 자신의 블로그나 웹사이트에 몇 줄의 코드를 던져놓는 것은 어렵지 않지만, 효과적으로 하려면 개인의 노력과 높은 안목이 필요합니다.
오픈소스 프로그래밍에 대한 오해
먼저 분명히 해야 할 점이 있습니다: 코드를 GitHub의 공개 저장소에 올린다고 해서 코드를 오픈소스로 만드는 것은 아닙니다. 거의 전 세계적으로, 창작자가 아무것도 하지 않아도 작품이 형성되면 저작권이 자동으로 발생합니다. 창작자가 허가하기 전까지는 저자만 저작권 관련 권리를 행사할 수 있습니다. 창작자의 명시적 허가 없이 사용되는 코드는, 몇 사람이 사용하든 시한폭탄과 같으며, 어리석은 사람만이 그것을 사용할 것입니다.
일부 창작자는 친절하게도 “제 코드는 분명히 무료로 제공됩니다”라고 생각하며, 자신의 코드를 사용한 사람을 고소할 생각이 없습니다. 하지만 이것이 이 코드를 안심하고 사용할 수 있다는 것을 의미하지는 않습니다. 여러분의 눈에 창작자들이 얼마나 친절해 보이든, 그들은 모두 코드를 사용, 수정하거나 명시적 허가 없이 코드를 삽입한 모든 사람을 고소할 권리가 있습니다.
분명히, 오픈소스 라이선스를 지정하지 않은 상태에서 소스 코드를 온라인에 공개하고 다른 사람이 사용하고 기여하기를 기대해서는 안 됩니다. 저는 여러분에게 이러한 코드를 사용하지 말 것을 권장하며, 심지어 허가되지 않은 것으로 의심되는 코드도 사용하지 마세요. 만약 여러분이 어떤 함수와 루틴을 개발했는데, 이전에 허가되지 않은 코드와 매우 비슷하다면, 소스 코드 저작자는 여러분을 저작권 침해로 고소할 수 있습니다.
예를 들어, Jill Schmill이 AwesomeLib를 작성하고 명시적 허가 없이 GitHub에 올렸다고 가정해 봅시다. Jill Schmill이 아무도 고소하지 않더라도, 그녀가 AwesomeLib의 모든 저작권을 EvilCorp에 판매하면, EvilCorp는 이전에 이 코드를 불법 사용한 사람들을 고소할 것입니다. 이러한 행위는 컴퓨터 보안 위험을 묻어두는 것과 같아서, 언젠가 누군가가 이용할 것입니다.
라이선스 없는 코드는 위험합니다. 명심하세요.
적절한 오픈소스 라이선스 선택
새로운 프로그램을 작성하고 있고 사람들이 오픈소스 방식으로 사용하기를 바란다고 가정해 봅시다. 여러분이 해야 할 일은 여러분의 요구에 가장 잘 맞는 라이선스를 선택하는 것입니다. 홍보에서 말하는 것처럼, GitHub가 지원하는 choosealicense.com에서 시작할 수 있습니다. 이 웹사이트는 간단한 설문조사처럼 설계되어 매우 편리하고 빠르며, 몇 번 클릭하면 적합한 라이선스를 찾을 수 있습니다.
주의: 라이선스 선택 시 너무 자만하지 마세요. Apache 라이선스나 GPLv3과 같이 널리 사용되는 라이선스를 선택하면, 사람들이 여러분과 그들에게 어떤 권리가 있는지 쉽게 이해할 수 있으며, 변호사를 고용하여 구멍을 찾을 필요도 없습니다. 여러분이 선택한 라이선스를 사용하는 사람이 적을수록, 더 많은 문제가 발생합니다.
가장 중요한 점은: 절대 직접 라이선스를 만들지 마세요! 직접 라이선스를 만들면 모두에게 더 많은 혼란과 고통을 가져올 뿐이니, 그렇게 하지 마세요. 기존 라이선스에서 정말 필요한 조항을 찾을 수 없다면, 기존 라이선스에 요구 사항을 추가하고, 사용자들이 주의하도록 강조 표시할 수 있습니다.
“나는 라이선스 따위 신경 쓰지 않아, 이미 코드를 공개 영역에 공개했어”라고 말하는 사람들이 있을 것입니다. 하지만 문제는, 공개 영역의 법적 효력이 전 세계적으로 인정되지 않는다는 것입니다. 국가마다 공개 영역의 효력과 표현 형식이 다릅니다. 일부 국가의 정부 통제 하에서는 자신의 소스 코드를 공개 영역에 공개할 수도 없습니다. 다행히 Unlicense가 이러한 구멍을 메울 수 있습니다. 언어가 간결하고, 몇 마디로 “그냥 공개 영역에 둔다”를 명확히 설명하지만, 그 효력은 전 세계적으로 인정됩니다.
라이선스를 도입하는 방법
어떤 라이선스를 사용할지 결정한 후, 명확하고 모호하지 않게 지정해야 합니다. GitHub, GitLab 또는 BitBucket에 게시하는 경우, 많은 폴더를 구축해야 하며, 루트 폴더에서 라이선스를 LICENSE.txt라는 일반 텍스트 파일로 생성해야 합니다.
LICENSE.txt 파일을 생성한 후에도 다른 일이 있습니다. 모든 중요한 파일의 헤더에 주석 블록을 추가하여 라이선스를 선언해야 합니다. 기존 라이선스를 사용하는 경우, 이 단계는 매우 간단합니다. # 프로젝트명 (c)2018 저자명, GPLv3 라이선스, 자세한 내용은 https://www.gnu.org/licenses/gpl-3.0.en.html 참조과 같은 주석 블록은 모호하게 라이선스를 가리키는 것보다 훨씬 강력한 효력을 갖습니다.
자신의 웹사이트에 게시하는 경우, 단계도 비슷합니다. 먼저 LICENSE.txt 파일을 생성하고, 라이선스를 넣은 다음, 라이선스 출처를 표시합니다.
오픈소스 코드의 다른 점
오픈소스 코드와 전용 코드의 주요 차이점 중 하나는 오픈소스 코드는 다른 사람이 보도록 작성된다는 것입니다. 저는 40대 시스템 관리자로서 매우 많은 코드를 작성했습니다. 처음에는 일을 위해, 회사의 문제를 해결하기 위해 코드를 작성했기 때문에 대부분은 전용 코드였습니다. 이러한 코드의 목적은 간단했습니다. 특정 상황에서 특정 방식으로 작동하기만 하면 됩니다.
오픈소스 코드는 크게 다릅니다. 오픈소스 코드를 작성할 때, 그것이 다양한 환경에서 사용될 수 있다는 것을 알고 있습니다. 여러분의 사용 사례 환경 조건은 제한적일 수 있지만, 여전히 다양한 환경에서 이상적인 효과를 발휘하기를 바랍니다. 다른 사람들이 이 코드를 사용할 때 다양한 사용 사례가 나타나고, 여러분은 다양한 충돌과 여러분이 고려하지 않았던 아이디어를 보게 될 것입니다. 코드가 모든 사람을 만족시킬 필요는 없지만, 적어도 그들이 겪는 문제를 적절하게 처리해야 하며, 해결할 수 없더라도 일반적인 논리로 되돌려 사용자에게 불편을 주지 않아야 합니다. (예: “583행에서 0으로 나누기 오류 발생”은 잘못된 명령행 매개변수 제공에 대한 응답 결과가 될 수 없습니다.)
여러분의 소스 코드도 여러분을 미치게 만들 수 있습니다. 특히 오류가 있는 함수나 서브루틴을 반복해서 수정한 후 마침내 원하는 결과가 나타났을 때, 여러분은 한숨만 쉬고 다음 작업으로 넘어가지 않을 것입니다. 과정을 정리할 것입니다. 왜냐하면 다른 사람이 여러분이 반복해서 시도한 흔적을 보기를 원하지 않기 때문입니다. 예를 들어 $variable, $lol을 모두 의미 있는 $iterationcounter와 $modelname으로 바꿀 것입니다. 이것은 여러분이 진지하고 전문적으로 주석을 달아야 함을 의미합니다 (비록 여러분이 있는 배경 지식 열기에는 어렵지 않더라도). 왜냐하면 더 많은 사람이 여러분의 코드를 사용하기를 기대하기 때문입니다.
이 과정은 필연적으로 약간의 고통과 좌절이 따릅니다. 결국 여러분이 자주 하는 일이 아니어서 익숙하지 않기 때문입니다. 하지만 이것은 여러분을 더 나은 프로그래머로 만들고, 여러분의 코드를 승화시킬 것입니다. 여러분의 프로젝트에 공헌자가 여러분 한 명뿐이더라도, 코드를 정리하는 것은 후기에 많은 작업을 절약해 줍니다. 믿으세요, 1년 후에 여러분의 앱 코드를 다시 볼 때, $modelname과 명확한 주석이 있어서 기뻐할 것입니다. 알 수 없는 수열이나 $lol조차 아닌 것보다 훨씬 낫습니다.
여러분은 여러분 한 사람을 위해 작성하는 것이 아닙니다
오픈소스의 진정한 핵심은 코드가 아니라 커뮤니티입니다. 더 큰 커뮤니티의 프로젝트는 더 오래 유지되고, 사람들이 받아들이기 더 쉽습니다. 따라서 커뮤니티에 가입할 뿐만 아니라, 커뮤니티 발전에 아이디어를 많이 공헌하여, 자신의 프로젝트가 커뮤니티에 활용될 수 있도록 해야 합니다.
배트맨은 목표를 달성하기 위해 어둠 속에서 홀로 큰 노력을 기울였지만, 여러분은 그럴 필요가 없습니다. Twitter, Reddit에 로그인하거나, 프로젝트 관련자들에게 이메일을 보내, 새 프로젝트를 준비하고 있다는 소식을 발표할 수 있습니다. 프로젝트의 설계 의도와 계획을 자세히 이야기하고, 모두가 함께 도와달라고 하며, 데이터 입력, 유사한 사용 사례를 모집하여, 이러한 정보를 통합해 코드에 활용할 수 있습니다. 모든 제안과 요청을 받아들일 필요는 없지만, 대략적인 파악을 하고 있으면, 나중에 완성할 때 몇 가지 함정을 피할 수 있습니다.
첫 번째 공지를 발표한 후에도 과정이 완전히 끝난 것은 아닙니다. 여러분이 모두가 여러분의 작품을 받아들이고 사용하기를 바란다면, 그것을 염두에 두고 설계해야 합니다. 대중이 도움이 될 수 있으니, 공개하는 것을 큰 적으로 여기지 마세요. 그러니 문을 닫고 일하지 말고, 모두를 위해 작성하는 것이니, 진짜 공개 프로젝트를 만드세요. 커뮤니티의 도움과 감독 아래 진지하게 단계별로 완성한다고 상상해 보세요.
프로젝트 구축 방식
GitHub, GitLab 또는 BitBucket에서 무료로 계정을 등록하여 프로젝트를 관리할 수 있습니다. 등록 후, 저장소를 생성하고, README 파일을 만들고, 라이선스를 할당하고, 단계별로 코드를 작성합니다. 이렇게 하면 좋은 습관을 형성할 수 있어, 나중에 현실의 팀과 함께 일할 때도 목적이 명확하게 목표를 향해 안정적으로 진행할 수 있습니다. 이렇게 오래할수록 더 흥미를 갖게 됩니다—보통 먼저 사용자가 여러분의 프로젝트에 흥미를 갖게 됩니다.
사용자가 질문을 하기 시작할 것입니다. 이것은 여러분을 기쁘게도 하고 불쾌하게도 할 것입니다. 여러분은 그들에게 친절하고 예의 바르게 대해야 합니다. 그들이 프로젝트에 많은 오해를 하거나 심지어 여러분의 프로젝트가 무엇을 하는지도 모른다 하더라도, 예의 바르고 전문적으로 대해야 합니다. 한편으로는 그들을 안내하여 여러분이 무엇을 하는지 알게 할 수 있습니다. 다른 한편으로는 그들도 천천히 여러분을 더 큰 커뮤니티로 이끌 것입니다.
여러분의 프로젝트가 사용자에게 호응을 받으면, 항상 고급 개발자가 나타나 흥미를 표시할 것입니다. 이것은 좋은 일일 수도 있고, 여러분을 화나게 할 수도 있습니다. 처음에는 간단한 문제 해결만 할 수 있지만, 언젠가는 풀 리퀘스트를 받게 될 것입니다. 하드코딩이나 특수 사용 사례(프로젝트를 유지하기 어렵게 만들 수 있음)일 수 있고, 프로젝트의 범위를 바꾸거나, 심지어 프로젝트의 의도를 바꿀 수도 있습니다. 어떤 것이 공헌이 되는지 분별하는 법을 배우고, 이에 따라 어떤 것을 병합하고, 어떤 것을 정중히 거절할지 결정해야 합니다.
우리는 왜 오픈소스를 하는가?
오픈소스는 힘든 작업처럼 들리며, 실제로도 그렇습니다. 하지만 여러분에게도 많은 이점이 있습니다. 무형 중에 여러분을 단련시켜, 깨끗하고 지속 가능한 코드를 작성하게 하고, 다른 사람과 소통하고 팀으로 협력하는 법을 가르쳐 줍니다. 야망 있는 전문 개발자에게는 최고의 이력서 자료입니다. 미래의 고용주가 여러분의 저장소를 열어 역량 범위를 파악할 가능성이 높습니다. 커뮤니티 프로젝트의 개발자가 여러분에게 일자리를 가져다 줄 수도 있습니다.
마지막으로, 오픈소스를 위해 일한다는 것은 개인의 향상을 의미합니다. 여러분이 하는 일이 여러분 한 사람을 위한 것이 아니기 때문에, 이것은 자신을 부양하는 것보다 훨씬 더 중요합니다.
재인용 출처: 개발자 관계 »
