오픈소스프로젝트 #1 - 시작해볼까? | 매거진에 참여하세요

오픈소스는 무엇을 의미하나요?

프로젝트가 오픈소스라는 것은 누구나 어떤 목적으로든 프로젝트를 자유롭게 사용, 연구, 수정 및 배포할 수 있음을 의미합니다. 이러한 권한은 오픈소스 라이선스를 통해 보장됩니다.

오픈소스는 채택과 협업의 장벽을 낮춰 사람들이 프로젝트를 빠르게 확산하고 개선할 수 있도록 하기 때문에 강력합니다.

또한 폐쇄형 소스에 비해 사용자에게 자신의 컴퓨팅 환경을 통제할 수 있는 잠재력을 제공합니다.

예를 들어, 오픈소스 소프트웨어를 사용하는 기업은 폐쇄형 소스 공급업체의 제품 결정에만 의존하는 대신, 소프트웨어를 개선할 수 있는 사람을 고용할 수 있는 선택권이 있습니다.

"자유 소프트웨어"는 오픈소스와 동일한 프로젝트를 의미합니다.

때로는 이러한 용어가 "자유 및 오픈소스 소프트웨어"(FOSS) 또는 "자유, 무료 및 오픈소스 소프트웨어"(FLOSS)로 결합되어 사용되기도 합니다.

여기서 "자유"와 "무료"는 가격이 아닌 자유를 의미합니다.

사람들은 왜 자신의 작업을 오픈소스로 공개할까요?

오픈소스를 사용하고 협업하는 과정에서 얻는 가장 보람 있는 경험 중 하나는, 나와 같은 문제를 겪는 다른 개발자들과 관계를 맺는 것입니다.

개인이나 조직이 프로젝트를 오픈소스로 공개하려는 이유는 다양합니다. 예를 들면 다음과 같습니다:

• - 협업: 오픈소스 프로젝트는 전 세계 누구나 변경 사항을 제출할 수 있습니다.

• 예를 들어, Exercism은 350명 이상의 기여자가 있는 프로그래밍 연습 플랫폼입니다.

• - 채택 및 리믹스:

• 오픈소스 프로젝트는 누구나 거의 모든 목적으로 사용할 수 있습니다. WordPress는 b2라는 기존 프로젝트의 포크로 시작했습니다.

• - 투명성:

• 누구나 오픈소스 프로젝트를 검토하여 오류나 불일치를 찾을 수 있습니다.

• 불가리아나 미국과 같은 정부, 은행이나 의료와 같은 규제 산업, Let’s Encrypt와 같은 보안 소프트웨어에게 투명성은 중요합니다.

오픈소스는 소프트웨어에만 국한되지 않습니다. 데이터 세트부터 책까지 모든 것을 오픈소스로 공개할 수 있습니다. GitHub Explore에서 다른 아이디어를 찾아보세요.

오픈소스는 "무료"를 의미하나요?

오픈소스의 가장 큰 매력 중 하나는 비용이 들지 않는다는 것입니다. 그러나 "무료"는 오픈소스의 전체적인 가치에서 파생된 부산물일 뿐입니다.

오픈소스 라이선스는 누구나 프로젝트를 사용, 수정 및 공유할 수 있도록 요구하기 때문에 프로젝트 자체는 대부분 무료입니다.

프로젝트 사용에 비용이 든다면, 누구나 합법적으로 복사하여 무료 버전을 사용할 수 있기 때문입니다.

결과적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다.

이중 라이선스나 제한된 기능을 통해 간접적으로 수익을 창출할 수 있는 방법도 있습니다.

나만의 오픈소스 프로젝트를 시작해야 할까요?

짧은 대답은 "예"입니다. 결과와 상관없이, 자신만의 프로젝트를 시작하는 것은 오픈소스가 어떻게 작동하는지 배우는 훌륭한 방법입니다.

오픈소스 프로젝트를 처음 시작한다면, 사람들이 무엇이라고 말할지, 혹은 아무도 알아채지 못할지 걱정될 수 있습니다. 이런 느낌이 든다면, 당신은 혼자가 아닙니다!

오픈소스 작업은 글쓰기나 그림 그리기와 같은 창의적인 활동과 같습니다.

세상에 자신의 작업을 공유하는 것은 두려울 수 있지만, 더 나아지는 유일한 방법은 연습하는 것입니다. 청중이 없더라도 말이죠.

아직 확신이 서지 않는다면, 잠시 자신의 목표가 무엇인지 생각해 보세요.

목표 설정

목표는 무엇을 작업할지, 무엇을 거절할지, 그리고 다른 사람들의 도움이 필요한 부분을 파악하는 데 도움을 줄 수 있습니다.

먼저 스스로에게 물어보세요: "왜 이 프로젝트를 오픈소스로 공개하려고 하나요?"

이 질문에 대한 하나의 정답은 없습니다.

하나의 프로젝트에 여러 목표가 있을 수도 있고, 다른 프로젝트마다 다른 목표가 있을 수도 있습니다.

만약 당신의 유일한 목표가 자신의 작업을 자랑하는 것이라면, 기여를 원하지 않을 수도 있고, README에 그렇게 명시할 수도 있습니다.

반면에 기여자를 원한다면, 명확한 문서화와 새로 온 사람들을 환영하는 데 시간을 투자할 것입니다.

프로젝트가 성장함에 따라 커뮤니티는 코드 외에도 더 많은 것을 요구할 수 있습니다.

이슈에 응답하고, 코드를 검토하고, 프로젝트를 홍보하는 것 모두 오픈소스 프로젝트에서 중요한 작업입니다.

비코딩 작업에 소요되는 시간은 프로젝트의 규모와 범위에 따라 달라지지만, 관리자로서 이를 직접 처리하거나 도움을 줄 사람을 찾을 준비가 되어 있어야 합니다.

회사에서 프로젝트를 오픈소스로 공개하는 경우, 프로젝트가 성공적으로 운영될 수 있도록 내부 리소스를 확보해야 합니다.

출시 후 프로젝트를 유지 관리할 책임자가 누구인지, 그리고 커뮤니티와 어떻게 작업을 공유할지 결정해야 합니다.

프로젝트를 홍보하고 운영하며 유지 관리하기 위해 전용 예산이나 인력이 필요하다면, 이러한 대화를 일찍 시작하세요.

다른 프로젝트에 기여하기

다른 사람들과 협업하는 방법을 배우거나 오픈소스가 어떻게 작동하는지 이해하는 것이 목표라면, 기존 프로젝트에 기여하는 것을 고려해 보세요.

이미 사용하고 좋아하는 프로젝트부터 시작하세요. 프로젝트에 기여하는 것은 오타를 수정하거나 문서를 업데이트하는 것처럼 간단할 수 있습니다.

기여자로서 어떻게 시작해야 할지 모르겠다면, "How to Contribute to Open Source" 가이드를 확인하세요.

나만의 오픈소스 프로젝트 시작하기

작업을 오픈소스로 공개할 완벽한 시기는 없습니다. 아이디어, 진행 중인 작업, 또는 수년간 폐쇄형으로 유지된 후에도 오픈소스로 공개할 수 있습니다.

일반적으로, 다른 사람들이 자신의 작업을 보고 피드백을 제공하는 것에 대해 편안함을 느낄 때 프로젝트를 오픈소스로 공개해야 합니다.

어떤 단계에서 프로젝트를 오픈소스로 공개하든, 모든 프로젝트에는 다음 문서가 포함되어야 합니다:

• - 오픈소스 라이선스

• - README

• - 기여 가이드라인

• - 행동 강령

관리자로서 이러한 구성 요소는 기대치를 전달하고, 기여를 관리하며, 모든 사람의 법적 권리(자신의 권리 포함)를 보호하는 데 도움을 줄 것입니다.

이는 긍정적인 경험을 할 가능성을 크게 높여줍니다.

GitHub에서 프로젝트를 진행 중이라면, 이러한 파일을 루트 디렉토리에 권장 파일명으로 추가하면 GitHub이 이를 인식하고 자동으로 독자들에게 표시합니다.

라이선스 선택

오픈소스 라이선스는 다른 사람들이 프로젝트를 사용, 복사, 수정 및 기여할 수 있도록 보장합니다.

또한 복잡한 법적 상황으로부터 당신을 보호합니다. 오픈소스 프로젝트를 시작할 때는 반드시 라이선스를 포함해야 합니다.

법적 작업은 재미없는 일이지만, 기존 라이선스를 복사하여 저장소에 붙여넣기만 하면 됩니다. 단 몇 분만 투자하면 당신의 노력을 보호할 수 있습니다.

MIT, Apache 2.0, GPLv3는 가장 인기 있는 오픈소스 라이선스이지만, 다른 옵션도 있습니다.

GitHub에서 새 프로젝트를 생성할 때 라이선스를 선택할 수 있는 옵션이 제공됩니다. 오픈소스 라이선스를 포함하면 GitHub 프로젝트가 오픈소스로 간주됩니다.

README 작성

README는 프로젝트를 사용하는 방법을 설명하는 것 이상의 역할을 합니다. 또한 프로젝트가 왜 중요한지, 사용자가 무엇을 할 수 있는지 설명합니다.

README에서 다음 질문에 답해 보세요:

• - 이 프로젝트는 무엇을 하나요?

• - 이 프로젝트는 왜 유용한가요?

• - 어떻게 시작하나요?

• - 도움이 필요하면 어디서 더 많은 정보를 얻을 수 있나요?

README를 통해 기여를 어떻게 처리하는지, 프로젝트의 목표는 무엇인지, 라이선스 및 출처에 대한 정보를 제공할 수도 있습니다.

기여를 받고 싶지 않거나 프로젝트가 아직 준비되지 않았다면, 이 정보를 명시하세요.

기여 가이드라인 작성

CONTRIBUTING 파일은 청중에게 프로젝트에 참여하는 방법을 알려줍니다. 예를 들어, 다음과 같은 정보를 포함할 수 있습니다:

• - 버그를 보고하는 방법 (이슈 및 풀 리퀘스트 템플릿 사용)

• - 새로운 기능을 제안하는 방법

• - 환경 설정 및 테스트 실행 방법

기술적 세부 사항 외에도, CONTRIBUTING 파일은 기여에 대한 기대치를 전달할 수 있는 기회입니다. 예를 들어:

• - 어떤 유형의 기여를 원하는지

• - 프로젝트의 로드맵 또는 비전

• - 기여자가 어떻게 연락해야 하는지 (또는 하지 말아야 하는지)

따뜻하고 친근한 어조로 문서 작성이나 웹사이트 제작과 같은 구체적인 기여 제안을 제공하면, 새로 온 사람들이 환영받고 참여하고 싶어지게 할 수 있습니다.

예를 들어, Active Admin은 기여 가이드를 다음과 같이 시작합니다:
"먼저, Active Admin에 기여를 고려해 주셔서 감사합니다. Active Admin을 훌륭한 도구로 만드는 것은 여러분과 같은 사람들입니다."

프로젝트 초기 단계에서는 CONTRIBUTING 파일이 간단할 수 있습니다. 버그를 보고하거나 이슈를 제출하는 방법, 그리고 기여를 위한 기술적 요구 사항(예: 테스트)을 설명해야 합니다.

시간이 지남에 따라, 자주 묻는 질문을 CONTRIBUTING 파일에 추가할 수 있습니다. 이 정보를 기록해 두면 같은 질문을 반복적으로 받는 일이 줄어듭니다.

행동 강령 수립

행동 강령은 프로젝트 참가자들의 행동 규칙을 설정하는 데 도움을 줍니다. 특히 커뮤니티나 회사를 위한 오픈소스 프로젝트를 시작하는 경우 매우 유용합니다.

행동 강령은 건강하고 건설적인 커뮤니티 행동을 촉진하여 관리자의 스트레스를 줄여줍니다.

행동 강령은 참가자들이 어떻게 행동할 것으로 기대되는지 전달할 뿐만 아니라, 이러한 기대가 누구에게 적용되는지, 언제 적용되는지, 위반 시 어떻게 대처할지도 설명합니다.

오픈소스 라이선스와 마찬가지로, 행동 강령에도 표준이 생겨나고 있으므로 직접 작성할 필요는 없습니다. Contributor Covenant은 Kubernetes, Rails, Swift를 포함한 40,000개 이상의 오픈소스 프로젝트에서 사용되는 드롭인 행동 강령입니다. 어떤 텍스트를 사용하든, 필요할 때 행동 강령을 시행할 준비가 되어 있어야 합니다.

프로젝트 이름 및 브랜딩

브랜딩은 화려한 로고나 기발한 프로젝트 이름 이상의 의미가 있습니다. 프로젝트를 어떻게 이야기하고, 누구에게 메시지를 전달할지에 관한 것입니다.

기억하기 쉽고, 가능하면 프로젝트가 무엇을 하는지 알 수 있는 이름을 선택하세요. 예를 들어:

• - Sentry: 앱 충돌 보고를 모니터링합니다.

• - Thin: 빠르고 간단한 Ruby 웹 서버입니다.

기존 프로젝트를 기반으로 구축하는 경우, 해당 프로젝트의 이름을 접두사로 사용하면 프로젝트가 무엇을 하는지 명확히 할 수 있습니다

(예: node-fetch는 Node.js에 window.fetch를 가져옵니다).

명확성을 최우선으로 고려하세요. 말장난은 재미있지만, 일부 농담은 다른 문화나 경험을 가진 사람들에게 전달되지 않을 수 있습니다.

잠재적 사용자 중에는 회사 직원도 있을 수 있습니다. 그들이 직장에서 프로젝트를 설명할 때 불편함을 느끼지 않도록 해야 합니다!

이름 충돌 피하기

특히 동일한 언어나 생태계를 공유하는 경우, 비슷한 이름을 가진 오픈소스 프로젝트가 있는지 확인하세요.

인기 있는 기존 프로젝트와 이름이 겹치면 청중을 혼란스럽게 할 수 있습니다.

웹사이트, 트위터 계정 또는 기타 프로젝트를 대표할 속성이 필요한 경우, 원하는 이름을 얻을 수 있는지 확인하세요.

지금 당장 사용할 계획이 없더라도, 마음의 평화를 위해 해당 이름을 예약해 두는 것이 좋습니다.

프로젝트 이름이 상표권을 침해하지 않는지 확인하세요. 회사가 나중에 프로젝트를 삭제하도록 요청하거나 심지어 법적 조치를 취할 수 있습니다. 위험을 감수할 필요는 없습니다.

WIPO Global Brand Database에서 상표 충돌을 확인할 수 있습니다. 회사에 소속된 경우, 법무팀이 도움을 줄 수 있습니다.

마지막으로, 프로젝트 이름으로 구글 검색을 해보세요. 사람들이 프로젝트를 쉽게 찾을 수 있을까요? 검색 결과에 보고 싶지 않은 다른 것이 나타나나요?

글쓰기와 코딩 스타일도 브랜드에 영향을 미칩니다!

프로젝트의 수명 동안, README, 튜토리얼, 커뮤니티 문서, 이슈 응답, 심지어 뉴스레터와 메일링 리스트까지 많은 글을 쓰게 될 것입니다.

공식 문서이든 캐주얼한 이메일이든, 글쓰기 스타일은 프로젝트 브랜드의 일부입니다. 청중에게 어떻게 다가갈지, 그리고 그런 톤을 전달하고 싶은지 고려하세요.

따뜻하고 포용적인 언어(예: 단수 대명사로 "them" 사용)는 새로운 기여자들에게 프로젝트가 환영받는 느낌을 주는 데 큰 도움이 됩니다.

많은 독자들이 영어를 모국어로 사용하지 않을 수 있으므로 간단한 언어를 사용하세요.

단어를 어떻게 쓰는지 외에도, 코딩 스타일도 프로젝트 브랜드의 일부가 될 수 있습니다. Angular와 jQuery는 엄격한 코딩 스타일과 가이드라인을 가진 프로젝트의 예입니다.

프로젝트를 막 시작할 때 스타일 가이드를 작성할 필요는 없으며, 다양한 코딩 스타일을 프로젝트에 통합하는 것을 즐길 수도 있습니다.

출시 전 체크리스트

프로젝트를 오픈소스로 공개할 준비가 되셨나요? 다음 체크리스트를 확인해 보세요. 모든 항목을 체크했다면, 이제 "출시" 버튼을 누르고 자신에게 박수를 보내세요!

• 문서화: LICENSE 파일, README, CONTRIBUTING, CODE_OF_CONDUCT 파일이 포함되어 있는지 확인하세요.

• 코드: 일관된 코드 규칙과 명확한 함수/메서드/변수 이름을 사용하세요.

• 사람: 개인이라면 회사의 법적 부서와 상의했는지 확인하세요. 회사라면 마케팅 계획과 커뮤니티 관리자를 지정했는지 확인하세요.

위의 글은 아래 원문을 번역 및 재가공한 글입니다. 원문은 아래에서 확인하실 수 있습니다.

https://opensource.guide/starting-a-project/