오픈소스란?
queenac 프로젝트를 오픈소스로 만들어보자! 라고 마음먹게 된 계기는 일단 첫번째로 오픈소스의 컨트리뷰터가 아니라 메인테이너가 되보고 싶은 마음이 컸었다. 내가 만든 오픈소스 하나쯤 있으면 멋지지 않을까?라는 생각이었다. 오픈소스를 사용하고, 오픈소스를 통해 배우다보니 자연스럽게 오픈소스에 대한 좋은 이미지가 쌓였다.
그럼 오픈소스란 무엇일까? 그냥 깃허브에 public으로 코드만 공개해두면 오픈소스 아냐???라고 생각할 수 있는데 이렇게 간단하지는 않다.
깃허브에서 제공하는 오픈소스 가이드에서는 오픈소스를 이렇게 정의한다.
오픈소스 프로젝트에서는 누구나 어떤 목적으로든 프로젝트를 보고, 사용하고, 수정하고, 배포할 수 있습니다.
이 권한을 오픈소스 라이센스를 통해 명시한다.
오픈소스가 되기 위해서는...
GitHub Repository의 Insights에 들어가면 Community Standards라고 현재 Repository가 어느 정도까지 커뮤니티 스탠다드를 지켰는지 프로그레스바로 보여준다.
이렇게 7가지 정도를 채운다면 형식상의 커뮤니티 스탠다드를 만족할 수 있다.
- README.md 사용자와와 제일 먼저 마주치는 녀석이다. 리드미 문서가 친절하면 친절할수록 사용자가 늘어날 수 있다고 생각한다. (물론 제공하는 서비스도 맞받아쳐줘야 하겠지만)
- Code of conduct: queensac을 오픈소스로 만들기 위해 찾아보다 처음으로 유심히 살펴봤던 문서이다. 부끄러운 사실이지만 기존에 Code of conduct가 있는 Repository를 많이 보았음에도, 그 안에 내용을 꼼꼼하게 읽어본 적이 없었다. 이번 기회에 읽어보았는데 올림피아드에서 선서 읽을 때처럼(TMI지만 글쓴이는 올림피아드에 출전한 적이 있다) 읽고 나니 경건해졌다. 한국어 버전도 있으니 한번 읽어보는 것을 추천한다.
- Contributing: 이 문서는 기여자를 위한 가이드이다. 이 프로젝트를 클론하고 실행하는 방법, 테스트 방법, 컨벤션 등이 포함되어 기여의 가이드 라인을 잡아준다. 나는 아직 작성하지는 못했는데, 곧 작성할 예정이다.
- License: 내 프로젝트를 법적으로 보호할 수 있는 중요한 문서이다. 오픈소스에 꼭 포함되어 있어야 하는 문서라고 생각한다.
- Security policy: 이 문서도 기존에 유심히 살펴본적은 없었는데, 프로젝트에서 보안 관련한 이슈가 발견됐을 때 어떻게 제보하는지 방법을 알려주는 문서이다.
- Issue & Pull Request Template: 이슈와 PR 템플릿은 말그대로 템플릿이다.
이렇게 커뮤니티 스탠다드를 지키기 위한 방법을 살펴보았는데 위 7가지만 지켜진다면 오픈소스가 될 수 있을까?
좋은 오픈소스가 되기 위해서는 (좋은이라는 표현이 여기에 어울리는지는 잘 모르겠지만) 꾸준한 관리, 즉 유지보수가 되어야 한다고 생각한다.
reference: https://opensource.guide/ko/ (깃허브에서 만든 문서인데 흥미로운 내용이 많으니 한 번쯤 읽어봐도 좋을 것 같다.)
