‌한 예로 구글은 내부에서만 사용하던 Angular(web application framework)를 오픈소스로 공개하였고, Angular는 웹 개발자들에게 빠르게 확산되었다. 개발자들은 Angular를 사용하여 많은 확장 프로그램과 도구를 개발하고, 구글은 다시 그러한 확장 프로그램과 도구를 활용하는 이득을 취할 수 있었다. Angluar가 구글에 가져다 준 직접적인 매출을 산정하는 것은 쉽지 않겠지만, 링크드인의 Job Tag 분석에 따르면 약 70만개 이상의 일자리가 창출되었는데, 이러한 고용 시장을 고려할 때 Angluar를 이용한 상품 시장 역시 상당히 클 것으로 예상할 수 있다.

‌여러분의 프로젝트가 이와 같이 높은 투자 수익을 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

표준이 될 수 있다

오픈소스로 프로젝트를 공개하면 표준으로 채택될 가능성이 커진다.

프로젝트가 해당 기술 분야의 사실상의 표준이 되면 참여하는 외부 기여자가 많아지고, 프로젝트와 그 주변 생태계가 더 빠르게 진화한다. 이는 산업 전반의 혁신을 가속화하고 프로젝트를 이용하여 구축한 서비스 및 제품의 채택을 용이하게 한다.

GNU와 Linux를 예로 들어보겠다. GNU와 Linux는 Unix 운영체제를 표방하며 오픈소스로 공개되면서 빠르게 확산되었다. Linux는 이제 서버, 라우터, 커넥티드 디바이스에서는 사실상의 표준이며, 소비자 전자 제품에서도 점점 활용도가 증가하고 있다. 이로 인해 소프트웨어 공급 업체가 Linux를 지원하고 Linux 사용자에게 익숙한 도구도 제공한다(예: Microsoft Windows에서 Bash 지원).

여러분의 프로젝트를 오픈소스로 공개하면 업계의 표준이 되어 많은 외부 기여자를 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

생태계를 성장시킬 수 있다

‌오픈소스로 프로젝트를 공개하면 다른 사람들이 프로젝트를 채택하고 이를 이용하여 자신의 프로그램을 개발한다. 그렇게 되면 그들은 자신의 프로그램뿐만 아니라 프로젝트의 성공을 위해 투자한다. 오픈소스 커뮤니티에는 각자의 소속 회사와 상관없이 프로젝트 내에서 서로 협력하는 우수한 개발자들이 있다. 이러한 개발자는 프로젝트에 다양한 관점을 제공할 뿐만 아니라 생태계가 성장될 수 있게 한다.

이는 WordPress와 같이 확장 메커니즘이 있는 프로젝트의 경우 특히 효과적인 전략이다. WordPress는 플러그인 및 테마 API를 공개하여 개발자, 디자이너 및 컨설턴트 등 기여자들이 다양한 추가 기능을 제공하도록 생태계를 구성하였다. 이렇게 커뮤니티가 플러그인과 테마를 무료 혹은 유료로 제공함으로써 WordPress가 모든 플러그인이나 디자인을 다룰 필요가 없게 되었다. 이러한 생태계 환경은 WordPress 뿐만 아니라 커뮤니티 구성원 및 최종 사용자에게도 혜택을 줍니다.

또 하나의 예로 2008년, JavaScript는 너무 느려서 이를 많이 쓰는 웹사이트는 거의 사용할 수 없었다. 구글은 Chromium을 오픈소스로 발표하면서 V8 JavaScript 엔진도 공개하였다. V8은 JavaScript를 실행하기 전에 기계 코드로 컴파일하고 다양한 최적화 기술을 사용하는 엔진이다. 이로 인해 브라우저의 성능이 크게 향상되어 웹사이트의 사용자 환경이 개선되었고 웹 응용 프로그램 개발이 길이 열렸으며, JavaScript가 Node.js와 같은 서버 소프트웨어와 함께 사용될 수 있게 되었다. V8이 오픈소스로 공개되었기 때문에 단순히 크롬뿐만 아니라 전체 생태계가 함께 발전할 수 있었다.

여러분의 프로젝트를 오픈소스로 공개하였을때 이와 유사하게 프로젝트와 생태계의 성장을 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

우수한 개발자를 채용할 수 있다

‌채용이 오픈소스의 주요 목적은 아니다. 그러나 기업이 내부에서 널리 사용되는 소프트웨어를 오픈소스로 공개할 때 주로 나타나는 효과 중 하나이다.‌

예를 들어, 구글의 내부 빌드 시스템인 Bazel을 오픈소스로 공개하면서 이를 외부 개발자도 사용하게 되었다. 이렇게 도구가 오픈소스가 되면서 외부 인원들도 이 도구에 익숙해지고, 기업은 이미 이 도구를 잘 알고 있는 외부 기여자 중에서 채용할 인력을 선택할 수 있다는 장점이 생깁니다. 이러한 인력은 이미 기술, 커뮤니티 구축, 지원 등에 익숙하기 때문에 실무에 투입하기 위한 교육 프로세스가 훨씬 간소화될 수 있다.

기업은 이러한 오픈소스 활동으로 커뮤니티에서 명성이 높아지고, 오픈소스 개발자에게는 매력적인 일터로 비치게 되면서 인재를 확보할 수 있다.

2 - SK텔레콤 오픈소스 공개 Rule

SK텔레콤의 오픈소스 공개 Rule을 설명한다.

SK텔레콤은 오픈소스 커뮤니티와의 협업의 가치를 존중하고, 이를 내부 소프트웨어를 오픈소스 프로젝트로의 공개를 장려한다. 하지만, SK텔레콤의 지식재산 보호와 의도치 않은 저작권 침해를 방지하기 위해 준수해야 할 몇가지 규칙이 있다.

승인을 받아라

오픈소스 공개는 저작권 관점에서 저작자가 저작물을 누구나 수정/사용/배포할 수 있는 권한을 오픈소스 라이선스를 통해 부여하는 것이다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유한다. 즉, SK텔레콤 구성원이 만든 저작물은 SK텔레콤이 소유한다. 구성원이 임의로 저작물을 오픈소스로 공개하는 행위는 불필요한 저작권 침해 이슈를 유발시킬 수 있다.

따라서, 소프트웨어를 오픈소스로 공개하고자 한다면 SK텔레콤 오픈소스 공개 정책에 따라 리뷰 요청 및 승인 절차를 따른다. : 오픈소스 공개 절차

공개하는 과정에서 어느 것이라도 무언가 바람직하지 않아 보이는 상황이 있다면 주저하지 말고 OSPO에 문의하라.

공개할 권리가 있는 코드만 공개하라

여러분이 작성하지 않은 코드는 여러분이 공개할 권리가 없다.

오픈소스 프로젝트에서 발생할 수 있는 최악의 상황 중 하나는 법적으로 문제가 있는 코드가 프로젝트에 포함되는 것이다. 회사가 배포할 권리가 없는 코드이거나, 다른 회사의 특허와 같은 IP를 침해하는 코드가 법적인 문제를 유발시킬 수 있다. 따라서, 공개할 코드를 준비하면서 모든 코드의 출처를 확인하고 문제 소지가 있는 코드는 삭제해야 한다.‌

지식 재산 노출에 주의하라

민감한 정보, 특허 등 기업의 지식재산 노출이 우려되는 코드, 문서는 공개하지 마라.

공개하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 공개해도 되는지 확인하라. 모호한 부분이 있다면 OSPO에 문의하라.

수준 이하의 코드는 공개하지 마라

‌코드의 가독성과 성숙도는 오픈소스로 공개하기 위한 준비가 되었는지에 대한 척도가 된다. 성숙하지 않은 코드는 커뮤니티의 신뢰를 잃게 한다.

그렇다고 코드가 완벽해야 한다는 건 아니다. 코드를 완벽하게 준비하려고 한다면 아마 시작할 수도 없을 것이다. 주어진 환경에서 최선의 수준으로 준비하여 공개하라. 커뮤니티가 활성화되면 외부 기여자들이 코드를 개선하는 데 참여할 것이다.

유용한 코드를 공개하라

성공적인 프로젝트가 되기 위해서는 다른 사람들에게도 유용해야 한다. 만약, 유사한 프로젝트가 이미 존재한다면, 새로운 프로젝트를 만드는 것보다 기존의 프로젝트에 참여하는 게 낫다. 경쟁 업체가 추진하는 프로젝트라도 오픈소스에서는 협력하는 것이 중요하다. 함께 참여하고 협력하면서 모두가 훌륭한 코드를 가질 수 있다.

‌더 이상 유용하지 않은 코드인데도 공개만 하면 무조건 커뮤니티가 관리할 것으로 생각해서는 안된다. 오픈소스 커뮤니티는 오래된 코드를 관리해주는 조직이 아니다. 실제로 매력적이지 않은 코드를 반복해서 공개한다면 그 회사는 오픈소스 세계에서 신뢰를 잃게 되고, 나중에는 다른 코드를 오픈소스로 공개하여도 개발자는 관심을 두지 않을 것이다.

여러분이 공개하는 오픈소스가 (1) 오픈소스 커뮤니티에 차별화된 가치를 제공하고, (2) 커뮤니티가 해결되지 못했던 문제를 해결하며, (3) 우리의 기술력을 공개함으로 긍정적인 관심을 끌 수 있는 프로젝트가 되기를 기대할 수 있어야 한다.

여러분이 실제 제품이나 서비스에 사용하지 못한 코드라면 오픈소스로도 공개하지 않는 것이 좋다. 우리의 제품에도 사용하도록 설득할 수 없다면 다른 사람도 사용하도록 설득하기는 쉽지 않다.
오픈소스 커뮤니티에서 이미 해결한 문제를 다루는 코드는 공개하지 않다. 이런 경우라면, 기존의 오픈소스 프로젝트에 기여하는 것이 좋다.

공개하려는 코드가 외부에서도 유용할 수 있다고 판단이 되면 공개 절차를 계속 진행하라.

리소스를 확보하라

개발자를 포함해서 프로젝트에 투입해야 할 리소스를 확보해야 한다.‌

초기에는 일반적인 사내 프로젝트와 비슷한 수준의 개발자가 필요하다.
또한, 외부의 기여를 신속하게 리뷰 할 수 있는 개발자가 필요하다.
그리고, 법무팀, 마케팅팀의 역할도 필요하다.
또한, 프로젝트를 유지, 관리하는데 요구되는 인프라에 대한 예산을 확보해야 한다. 여기에는 Github와 같은 프로젝트 호스팅을 위한 도구가 포함된다.

충분한 리소스가 지원되는 환경을 조성할 수 없다면, 오픈소스로 공개하지 않는 것이 좋다.

회사 이메일을 사용하라

오픈소스 공개 활동 시 개인 이메일을 사용하지 말고, SK텔레콤 이메일을 사용하라. 이를 통해 (1) 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 되고, (2) SK텔레콤이 오픈소스 커뮤니티에 공개 활동을 활발히 하는 기업으로 인지도를 개선할 수 있다.

GitHub에서 이메일 설정하는 방법은 다음 Link를 참고한다.

3 - SK텔레콤 오픈소스 공개 절차

SK텔레콤의 오픈소스 공개 절차를 설명한다.

release-process

1. 소속 조직 내부 승인

소프트웨어를 오픈소스로 공개하기 위해 소속 조직의 담당 임원 혹은 리더에게 승인을 받는다.

2. OSPO 지원 요청

오픈소스 공개를 결정하고 소속 조직의 승인을 받은 후, OSPO에 지원을 요청한다. : Support (opensource@sktelecom.com)

OSPO는 이 가이드의 내용 위주로 오픈소스 공개 Rule 및 절차를 설명하고, 필요 사항을 지원한다.

3. 주요 의사 결정

프로젝트 이름 결정

듣기 좋고 외우기 쉬우며, 어떤 프로젝트인지 나타낼 수 있는 이름으로 짓는게 좋다. 문제가 될 소지가 있는 이름은 피해야 한다. 자세한 사항은 다음 페이지를 참고한다.

오픈소스 프로젝트 이름 결정

라이선스 결정

소프트웨어를 오픈소스로 공개하기 위해서는 라이선스를 부여해야 한다. 그래야 다른 사람들도 소프트웨어를 사용, 복사, 수정 및 배포할 수 있다. 또한, 라이선스는 법적인 문제로부터 기여자를 보호한다. 따라서, 오픈소스 프로젝트를 시작할 때 적절한 오픈소스 라이선스를 선택하고 이를 프로젝트에 적용해야 한다.‌

SK텔레콤은 소프트웨어를 오픈소스로 공개 시 기본적으로 Apache-2.0를 적용한다. Apache-2.0는 사용자에게 광범위한 자유를 제공하면서 명시적인 특허 허여 조항 등 법적인 관점에서도 잘 작성된 라이선스이다.

단, 예외적으로 다음과 같은 경우는 Apache-2.0 외의 라이선스도 적용할 수 있다.‌

커뮤니티에서 주로 사용하는 라이선스가 지정되어 있는 경우도 있다. 예를 들어, Node.JS 프로젝트는 MIT 라이선스를 사용한다. 이때는 해당 라이선스를 적용할 수 있다.
어떤 프로젝트는 GPL 라이선스의 라이브러리와의 종속성이 있어서 GPL로 공개해야 하는 경우도 있다. 이때는 GPL을 적용할 수 있다.

참고로, GitHub에서는 오픈소스 공개 시 라이선스 선택에 대한 가이드를 제공하고 있다. : https://choosealicense.com

문의

만약, 이외의 다른 라이선스를 선택해야 할 상황이라면 OSPO(_{Open Source Program Office}에 문의하라. : Support (opensource@sktelecom.com)

CLA 결정

오픈소스로 공개한 프로젝트를 운영하면서 어떤 이유에서든지 기존의 오픈소스 라이선스를 다른 라이선스로 변경해야 할 상황이 발생할 수 있다. 이때는 프로젝트의 Leader라고 해도 임의로 라이선스를 변경할 수 없으며, 프로젝트에 저작물을 기여한 모든 저작권자의 동의를 얻어야 가능하다. 오랜 기간동안 많은 기여자로부터 저작물을 기여 받은 프로젝트의 경우 모든 저작권자에게 동의를 받는 것은 사실상 거의 불가능하고, 따라서 오픈소스 라이선스의 변경 또한 불가능하다.

이와 같이 다수의 기여자의 저작물을 관리하면서 발생할 수 있는 분쟁을 줄이기 위해 기여자에게 사전에 동의를 구하는 약정서가 CLA (Contributor License Agreement)이며, 주로 기여자로부터 다음 사항의 동의를 구하는 내용을 담고 있다.

- 나(또는 소속 기업)는 내가 기여하려고 하는 기여물을 프로젝트에 기여할 권리가 있다. (즉, 이 기여물의 저작자이다.)
- 나(또는 소속 기업)는 나의 기여물을 프로젝트가 수정, 배포, 관리할 수 있는 권한을 프로젝트에 부여한다.
- 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
- 나(또는 소속 기업)는 프로젝트가 향후 필요에 따라 라이선스를 변경할 수 있는 권한을 프로젝트에 부여한다.

기여자에게 CLA 서명을 요구할 경우, 프로젝트가 기여자의 저작물을 관리하기 용이해지는 장점이 있지만, CLA 서명을 거부하는 기여자로부터 기여를 받을 수 없다는 단점이 있다.

SK텔레콤은 첨부의 CLA를 사용하고 있다. SK텔레콤 템플릿

프로젝트에 CLA를 사용할지 여부는 프로젝트 목적 및 환경에 따라 공개하는 조직에서 결정한다.
(1) 향후 오픈소스 라이선스를 변경할 계획이 없거나, (2) 다수의 기업이 참여하고 저작권 분쟁이 발생할 가능성이 크지 않을 경우, CLA를 사용하지 않아도 된다.

4. 공개할 코드 준비 및 점검

‌오픈소스로 코드를 공개하기 전에 불필요하게 이슈가 될 부분은 사전에 제거하는 등 정리하라.

3rd party 코드 정리

프로젝트에 3rd party 코드를 포함해야 하는 경우라면, 즉, SK텔레콤이 저작권을 갖고 있지 않은 코드를 프로젝트에 포함해야 한다면 먼저 SK텔레콤이 재배포할 수 있는 권한이 있는지 확인하라. 이미 오픈소스 라이선스가 적용된 코드라면 라이선스 의무를 준수하는 조건으로 재배포할 수 있다.

재배포할 수 있는 권한 확인에 대한 도움이 필요하다면 OSPO(_{Open Source Program Office}에 문의하라. : Support (opensource@sktelecom.com)

SK텔레콤이 재배포할 수 있는 3rd party 코드인 경우, 기존 코드와는 다른 디렉토리(예: third_party)에 위치시킨다. 이는 라이선스 관점에서 프로젝트의 투명성을 증대시키며, 향후 사용자도 3rd party 코드를 쉽게 찾게 찾게 되어 정확한 라이선스 요구사항을 준수할 수 있게 한다.

3rd party 디렉토리에 있는 모든 디렉토리는 각각 LICENSE 파일 (저작권 정보와 라이선스 전문을 포함하는 텍스트 파일)을 포함해야 한다. 예를 들어, Repository에서 third_party 디렉토리의 구조는 다음과 같다.

[Root Directory]
|-- SKT source code
|-- ....
`-- third_party
    `-- [external library A]
    |   |-- `LICENSE`
    |   `-- ...
    `-- [external library B]
        |-- `LICENSE`
        `-- ...

파일 내 저작권 및 라이선스 표시

‌소스 코드를 포함하는 모든 파일은 저작권 및 라이선스 표기를 포함하라. 이는 몇몇 파일만 복사해서 사용하려는 사용자들도 라이선스 의무를 준수하는데 도움이 된다. 자세한 내용은 다음 페이지를 참고하라.

저작권 및 라이선스 표시

불필요한 주석 제거

공개하려는 코드에 회사의 영업 비밀이나 문제를 일으킬만한 불필요한 주석이 포함되지 않도록 확인하라.‌

(굳이 외부에 공개할 필요가 없는) SK텔레콤 구성원의 이름과 이메일 주소를 삭제하라.
내부 정보를 삭제하라. (내부 코드 파일 이름 / 경로, 내부 호스트 / IP정보 등)

참고로, 아래의 명령어를 사용하면, 불필요한 주석을 쉽게 찾을 수 있다.

### 회사 웹사이트, 이메일, IP 주소 검색
$ egrep -r '\.sktelecom\.com|@sk\.com|@sktelecom\.com|([0-9]+\.){3}[0-9]+' <path-to-source-directory>

### Java/C/C++/Go/Objective-C/Objective-C++/Swift/Kotlin 주석 검색
$ find <path-to-source-dir> -type f | egrep '\.(c|cc|h|cpp|go|java|kt|m|mm|swift)' | \
  while read f; do echo "------------ $f ------------------"; sed -n -e '/\/\*.*\*\// {p; b}' \
  -e '/\/\*/,/\*\//p' -e '/\/\//p' "$f"; done

### Python/Bash 주석 검색
$ find <path-to-source-dir> -type f | egrep '\.(py|sh)' | while read f; \
  do echo "------------ $f ------------------"; grep -o "#.*" "$f"; done

라이선스 파일 포함

라이선스 사본을 담고 있는 LICENSE라는 이름의 텍스트 파일을 최상위 디렉토리에 포함한다.

라이선스 파일

Apache License의 경우, 공식 라이선스 사본 파일을 그대로 복사해서 사용하면 된다.
다른 라이선스를 적용하기로 한 경우, 라이선스 사본은 SPDX License List에서 받을 수 있다.

오픈소스 라이선스 점검

오픈소스 라이선스 점검 도구를 이용하여 공개할 소스 코드를 점검하여 다음 사항을 확인한다.

고지 / 소스 코드 공개 의무를 요구하는 라이선스 하의 다른 오픈소스 포함 여부
여러분이 공개할 권리가 없는 3rd party 소스 코드 포함 여부
여러분이 적용할 오픈소스 라이선스와 충돌하는 라이선스하의 코드 포함 여부

오픈소스 라이선스 점검 요청

오픈소스 라이선스 점검은 OSRB에 요청한다. : Support (opensource@sktelecom.com)

오픈소스 보안취약점 점검

오픈소스 보안취약점 점검 도구를 이용하여 공개할 소스 코드에 보안취약점 이슈가 있는 오픈소스가 포함되어 있는지 확인한다.

오픈소스 보안 취약점 점검 요청

오픈소스 보안 취약점 점검은 OSRB에 요청한다. : Support (opensource@sktelecom.com)

5. 개발 환경 / 인프라 구축

저장소/Issue Tracker

프로젝트를 위한 저장소를 준비하라. 많은 프로젝트가 GitHub 또는 GitLab repository를 사용하거나 Gerrit과 같은 도구를 사용하여 자체 저장소를 제공한다. Bug, issue, feature tracking을 위한 기능도 인프라 계획의 일부로 포함되어야 한다.

SK텔레콤 GitHub Repository를 이용할 것을 권장한다. : https://github.com/sktelecom

GitHub 멤버 등록은 OSRB에 요청한다. : Support (opensource@sktelecom.com)

테스트 자동화

오픈소스 개발은 원격지의 다수가 비동기로 협업해야 하는 특성을 갖는다. 그러면서도 우수한 품질을 유지하기 위해서는 테스트 자동화가 필수이다. 다음과 같은 테스트를 제공하고 자동화하라.

Unit Test
Integration Test
End-to-End Test

CI/CD

테스트 뿐만 아니라 빌드, 배포까지 개발 라이프 사이클 전체에 걸쳐 지속적인 자동화와 모니터링을 제공하는 환경을 구축하라. 다시 말하지만 오픈소스 프로젝트의 성공과 지속을 위해서는 자동화된 개발, 빌드, 테스트와 배포 환경이 필수이다.

웹사이트

사용자 가이드를 제공하고 프로젝트를 홍보하기 위한 웹사이트를 구축하라. 프로젝트의 리더십, 거버넌스 세부 사항 등에 대한 내용도 제공할 수 있다.

GitHub Pages는 간단히 웹사이트를 제작하고 호스팅할 수 있는 방법을 제공한다.

커뮤니케이션 채널

커뮤니티에서 원활한 커뮤니케이션이 가능하도록 채널을 제공하는 것이 중요하다. 또한 코드 체크인, 오류 로그 등 기타 작업에 대한 알림을 주는 등 전체 개발 Work Flow에 통합할 수 있는 도구가 필요하다. 이는 프로젝트를 실시간으로 진행하는 중요한 수단이 된다.

우수한 도구 중 하나는 Slack이다. Slack은 사용자가 메시지와 파일을 공유하고, Work Flow 구성, 정보 검색 등의 작업을 수행할 수 있게 하는 온라인 프로젝트 관리 및 통신 플랫폼이다. 그러나 Slack은 상용 도구이며 유지 관리 비용이 발생한다.
오픈소스로 공개된 도구들로는 IRC, Gitter.im, Rocket.Chat 등이 있다. Rocket.Chat은 오픈소스이며 Slack과 유사한 기능을 제공한다.

단, Slack과 같은 타사 서비스에서는 회사의 기밀 정보를 논의해서는 안된다. 이러한 커뮤니케이션 채널은 공개 토론으로만 사용해야하며 회사 내부 조직의 논의 도구로는 사용하지 않는다.

6. 거버넌스 체계 수립

멤버십

오픈소스 프로젝트는 여러 지역의 다양한 인원이 모여서 협업을 수행한다. 효과적인 협업을 위해서는 참여 인원의 명확한 역할 구분이 필요하다. 이를 위해 어떤 멤버십을 구성할지 결정하라.

일반적인 오픈소스 프로젝트의 멤버십은 다음 페이지를 참고하라. : 오픈소스 프로젝트 멤버십
또한, 멤버십의 한 예로 HANU 오픈소스 프로젝트의 멤버십을 참고할 수 있다.

CODE OF CONDUCT

CODE OF CONDUCT는 행동수칙, 행동강령이라고도 불리며 프로젝트가 건강하게 유지되기 위한 참가자의 행동 규칙을 정의한 문서이다. 예를 들어 성별, 인종, 종교, 나이 등의 차별이 있어서는 안 되고 누구나 따뜻하게 환영받고, 안전한 활동을 보장하기 위해 행동해야 함을 강조한다. 그리고 누군가 그 규칙을 어길 경우, 신고할 방법을 안내한다.

다음은 SK텔레콤의 오픈소스 프로젝트에서 사용할 수 있는 CODE OF CONDUCT 템플릿이다. :

7. 문서화

오픈소스 프로젝트가 많은 사용자와 기여자를 확보하기 위해 가장 중요한 부분이 문서화이다. 얼마나 자세하고 정확한 문서를 제공하느냐가 프로젝트의 품질로 인식된다. 소프트웨어의 기능이 아무리 우수하더라도 이를 문서로 성실하게 표현하지 않으면 사용자는 발길을 돌리고 말 것이다.

README 파일

여러분이 공개한 오픈소스를 많은 사용자들이 사용하기를 원하는가? 그렇다면 사람들이 쉽게 시작할 수 있도록 README 파일을 제공하라. README 파일은 새로운 사람들에게 프로젝트에 대해 설명하는 가장 중요한 문서이다.

README에서는 다음 질문에 답할 수 있는 내용을 포함해야 한다.‌

이 프로젝트는 무엇을 하는 프로젝트 인가?
왜 이 프로젝트가 유용한가?
어떻게 시작하면 되나?
도움이 필요하면 어디서 도움을 받을 수 있나?

프로젝트 사용자의 배경지식은 매우 다양한다. 프로젝트를 막 시작하여 경험이 없는 사람도 쉽게 이해할 수 있도록 자세하게 문서를 제공하는 것이 좋다. 문서가 충실하게 제공될 수록 더 많은 사용자와 기여자를 확보할 수 있음을 기억하라.

README 참고

README 템플릿 참고 : README Template
README 작성 가이드 참고 : Make a README

개발 가이드

프로젝트에 참여할 의지가 있는 예비 기여자들을 위해 개발 가이드를 제공하라. 이 문서에는 다음 내용을 포함한다.

How to build
Testing Guide
Coding Convention
CI/CD
Release

개발 가이드의 예는 HANU 프로젝트 Developing 문서를 참고한다.

CONTRIBUTING 파일

기여자들이 참고할 수 있는 “How to Contribute"에 대한 내용을 제공하는 파일이다. CONTRIBUTING 파일이 충실하지 않다면 프로젝트로의 기여에 관심이 있던 사용자들도 열정을 잃게 된다.‌

CONTRIBUTING 파일은 다음과 같은 사항을 포함한다.

버그 리포트를 제출하는 방법 (Issue 생성 / Pull Request 제출 방법)
새로운 기능을 제안하는 방법
개발 환경을 설정하고 테스트를 실행하는 방법‌

또한, 다음과 같이 기여자들로부터 기여받기를 바라는 바에 대해 안내할 수 있다.

원하는 기여 유형
프로젝트의 비전과 로드맵
기여자들이 프로젝트 관리자에게 연락을 취할 수 있는 방법

프로젝트의 초기 단계에서의 CONTRIBUTING 파일은 간단해도 된다. 단, 버그 리포트 및 이슈 제기 방법과 사전 테스트와 같이 기여를 하기 위한 필수 조건에 대해서는 꼭 설명해야 한다.

그리고, 따뜻하고 친근한 분위기의 문서를 제공하라. 이러한 문서가 잠재적인 기여자들에게 프로젝트에 참여하고 싶은 기분이 들게 한다. 예를 들어, Active Admin이라는 프로젝트의 Contributing 가이드는 다음과 같이 시작한다.

“먼저 Active Admin에 기여하는 것을 고려해주셔서 감사한다. Active Admin을 훌륭한 도구가 될 수 있는건 바로 당신 때문이다!”

CONTRIBUTING 참고

CONTRIBUTING 파일 템플릿 : CONTRIBUTING-template.md
CONTRIBUTING 파일 (예)

CONTRIBUTING 파일도 README와 마찬가지로 프로젝트 Repository내 최상이 폴더에 위치시킨다. 그리고, 사용자들이 접근하기 쉽도록 README 파일 내에 링크를 제공하라.

8. OSPO 리뷰 요청

위의 절차를 통하여 공개할 준비가 되면 다음 정보를 OSPO에 제공하고 리뷰를 요청한다. OSPO는 SK텔레콤의 소프트웨어를 오픈소스로 올바르게 공개하고 커뮤니티를 활성화하기 위해 지원한다. : Support (opensource@sktelecom.com)

제출해야 할 정보

현재 소스 코드 확인할 수 있는 프로젝트의 Repository 링크 (OSPO 인원이 접근할 수 있도록 권한 부여)
공개 예정인 저장소 링크 (예: github.com/?)
적용할 오픈소스 라이선스
이 프로젝트를 오픈소스로 공개 시 기대할 수 있는 비즈니스 가치는 무엇인가?
SK텔레콤 구성원이 작성하지 않은 코드가 있나? 있다면 어느 파일이고, 포함되어야 하는 이유 설명.
개발팀 담당 임원으로부터 오픈소스 공개에 대한 승인을 받았나?
이 코드가 사용된 제품 혹은 서비스는 무엇인가? (만약 사용되지 않았다면 그 이유)
오픈소스 공개 후 지원할 인력이 지정되었나?
가이드에 따라 공개 준비가 완료되었나?
프로젝트 공개를 알리기 위한 방법은 무엇인가? (예: Blog post, 콘퍼런스 발표)
공개하려는 코드와 관련한 특허가 있나?
보안 취약점을 검토하고 미비점을 보완하였나?

한번 공개를 하면 이를 되돌리는 것은 쉽지 않다. 그렇기 때문에 가능한 충분한 시간을 갖고 코드를 검토하고 준비하라. 물론 완벽한 코드를 요구하는 것은 아니다. 공개한 후 후회하는 부분이 없도록 실수를 줄여야 한다.

검토 과정에서 문제가 없다면 승인 과정은 매우 간단하며 신속하게 진행한다. OSPO는 오픈소스 공개를 막는 것이 아니라 장려하고 돕기 위한 서비스를 제공한다.

‌OSPO 승인이 된 후 프로젝트 공개를 진행하라.

9. 공개

모든 준비와 검토 단계를 마친 후에는 최종적으로 다음 사항을 확인한다.

공개를 위한 Repository에 모든 코드와 문서가 존재하는지 확인하라.
모든 프로젝트 인프라가 실행 중이고, 안전하며, 확장 가능한지 확인하라.
개발자가 커뮤니케이션 채널 (IRC, Mailing List 등)에 참여하고 모니터링할 수 있는지 확인하라.

그리고, 오픈소스 프로젝트를 런칭한다. OSPO의 안내에 따라 https://github.com/sktelecom에 소스 코드 저장소를 Public하게 공개하라. (개발팀의 필요에 따라 다른 repository를 이용하여 공개할 수 있다.)

10. 마케팅

프로젝트를 계속 진행하기 위해서는 마케팅이 필수적이다. 마케팅에는 프로젝트 홍보, 성공적인 운영 전략 수립, 현실적인 예산 및 프로젝트 브랜딩 제공, 소셜 미디어 계정 활성화 등 장기적인 성공을 위한 활동 등이 포함된다. 여기에서는 프로젝트를 공개하고 이를 알리기 위한 몇가지 방법을 안내한다.

프로젝트와 관련이 있는 커뮤니티의 메일링 리스트나 포럼에 프로젝트가 공개되었음을 알린다.
SK텔레콤 기술 블로그(https://sktelecom.github.io/)에 프로젝트에 대해 소개한다.
프로젝트의 소셜 미디어(Twitter, Facebook, LinkedIn 등)를 통해 홍보한다. SK텔레콤의 소셜 미디어 계정을 활용할 수도 있다.
프로젝트와 관련이 있는 오픈소스 컨퍼런스에서 주제 발표를 한다.

11. 커뮤니티 활성화

이제 프로젝트를 홍보하고 사람들에게 프로젝트를 사용할 수 있도록 알리는 것은 여러분의 임무이다. 얼마나 많은 사람이 프로젝트에 참여하여 코드를 사용하고, 버그를 수정하고, 문제를 보고하는지에 따라 프로젝트의 성공을 판단할 수 있다.

커뮤니티 구축은 자동으로 이루어지지 않다. 커뮤니티 구축을 위한 세부 활동은 다음 페이지를 참고하라. : (커뮤니티 활성화 가이드는 준비 중 : haksung@sk.com )
또한, 이를 위해 프로젝트를 측정할 수 있어야 한다. 측정 지표와 측정 방법에 대한 세부 내용은 다음 페이지를 참고하라. : (오픈소스 측정 가이드는 준비 중 : haksung@sk.com )

3.1 - 오픈소스 프로젝트 이름 결정

오픈소스 프로젝트 이름 정하기

듣기 좋고 외우기 쉬우며, 어떤 프로젝트인지 나타낼 수 있는 이름으로 짓는게 좋다. 문제가 될 소지가 있는 이름은 피해야 한다.

기억하기 쉬운 이름을 선택하라.

기억하기 쉽고, 프로젝트가 무엇을 하는지에 대해 알릴 수 있는 이름으로 선택하라. 예를 들면 다음과 같다.

Sentry (보초, 감시) : Crash Reporting을 모니터하는 앱이다.
Thin : 빠르고 간단한 Ruby web server 이다.

만약 기존의 어떤 프로젝트를 기반으로 한다면 그 프로젝트 이름을 앞에 붙여서 사용할 수도 있다. 예를 들어, node-fetch는 Node.js에 window.fetch를 제공하는 모듈이다.

무엇보다도 명확성을 고려하라. 조크가 가미된 이름이 재미있으나 다른 문화나 언어를 가진 사람에게는 이해되지 않을 수 있다.

SK텔레콤 브랜드 이름은 피하라.

SK텔레콤이 홍보하는 제품 혹은 서비스가 아니라면 SK텔레콤의 브랜드를 사용하지 마라. 또한 꼭 필요한 경우가 아니라면 “T-이름” 형태의 이름(예: T world)을 사용하지 마라.

중복되는 이름은 피하라.

유사한 이름의 오픈소스 프로젝트가 있는지 먼저 확인하라. 특히, 같은 생태계에 동일한 이름의 프로젝트가 있다면 그 이름은 피해야 한다. 이미 존재하는 인기있는 프로젝트와 이름이 겹칠 경우, 사용자에게 혼란을 줄 수 있다.

웹사이트, 트위터 등을 이용한 홍보를 고려해서 미리 원하는 도메인 이름이나 SNS 계정을 확보할 수 있는지 확인하라. 당장 필요하지 않더라도 미리 확보하는게 좋다.

타사 브랜드를 사용하지 마라.

즉, “Java Test Library” 보다는 “Test Library for Java"가 낫다.

상표권을 침해하지 마라.

프로젝트 이름이 상표권을 침해하지 않는지 확인하는 것도 중요하다. 추후 상표권을 가진 회사가 프로젝트 중단 요청이나 법적조치를 취해올 수 있다. 이러한 위험을 감수해야 하는 상황을 만들 필요는 없다. Kipris의 상표권 검색 (해외의 경우 WIPO Global Brand Databae)에서 상표권 충돌 여부를 확인할 수 있다.

T-legalnet

상표권에 대해 보다 자세한 확인이 필요할 경우, T-legalnet을 통해 IPR팀의 검토를 받아라.

저작권은 (베른 협약 이후) 저작자가 저작물 만들 때 자동으로 생성된다. 모든 저작물은 저작권에 의해 보호되며, 저작권 보유자에게 저작물에 대한 독점적인 권한이 부여된다. 따라서 우리의 저작물(소스 코드, 텍스트, 이미지, 기타 미디어 등)을 다른 사용자가 사용할 수 있게 하려면 그들에게 라이선스를 부여해야 한다. 라이선스의 사전적 정의는 “특정 권리를 실행하기 위해 자격이 있는 기관으로부터 받은 허가"이며, 이러한 허가 없이 특정 권리를 실행하는 것은 저작권 침해와 같은 불법 행위가 된다.

저작권 표시

최초 작성 연도
저작권 보유자 이름
- SK텔레콤 구성원이 저자인 저작물의 저작권은 SK텔레콤이 보유한다. 따라서, 회사 이름을 작성한다. (SK TELECOM CO., LTD.)
- SK텔레콤의 자체적인 개발보다 외부 기여를 적극적으로 수용할 계획이라면 저작권 정보를 “The [Project] Authors"라고 표시하고, 저자 정보를 AUTHORS 파일로 관리하는 것도 고려할 수 있다.
연락처 (Optional)
- 사용자가 저자에게 기술적, 법률적 문의를 위해 연락을 취하고 싶을 수 있다. 이를 대응하기 위한 저자의 이메일 정보를 제공할 수 있다. 이는 필수는 아니다.
- 또는, 사용자가 정보를 얻을 수 있는 프로젝트의 웹사이트 URL 등 연락처 정보를 작성한다.

SPDX-FileCopyrightText: Copyright 2021 SK TELECOM CO., LTD. <{$project-website-url}>

라이선스 고지

각 소스 코드 파일마다 라이선스가 무엇인지 알리는 것도 매우 중요한다. 라이선스는 혼란을 줄이기 위해 Linux Foundation의 SPDX 프로젝트에서 제공하는 SPDX ID를 사용하여 표시한다. SPDX ID를 사용하는 방법은 간단한다.

먼저 적용하고자 하는 오픈소스 라이선스의 SPDX Identifier가 무엇인지 SPDX License List 페이지에서 확인한다. 예를 들어, Apache License version 2의 SPDX Identifier는 Apache-2.0이다.

license-list

그리고 소스 코드 파일 상단에 SPDX-License-Identifier라는 tag를 이용하여 라이선스 Identifier를 표시한다. 그 예는 아래와 같다.

SPDX-License-Identifier: Apache-2.0

자동화 도구

(SPDX tag와 함께 추가되도록 도구 개선 후 가이드 개선 필요 : haksung@sk.com )

addlicnse

addlicense -c "SK TELECOM CO., LTD." -l apache [filename]

autogen

autogen : 새로운 파일에 주석 및 코드를 자동으로 추가한다.

autogen --no-code --no-tlc -c "SK TELECOM CO., LTD." -l apache [filename]

이를 batch 로 적용할 수도 있다. 아래 예는 Java 파일에 적용하는 batch이다.

find . -type f -name \*.java -exec autogen -i --no-code --no-tlc -c \
  "SK TELECOM CO., LTD." -l apache {} \;

오픈소스 공개하기

SK텔레콤 오픈소스 공개 Rule

SK텔레콤 오픈소스 공개 절차

1 - 오픈소스 공개의 혜택

경제적으로 이득이 될 수 있다.