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

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

시작하기 전에

이 글은 참고한 글의 번역이 아닙니다. 거칠게 뭉뚱그러모아 요약한 것입니다. 자세한 것은 하단의 참조 문서를 봐주세요.
대부분 목록을 발췌하여 필요한 설명만을 붙인 것입니다.

오픈소스에 참여하는 것이 아니라, 직접 오픈소스 프로젝트를 시작하고 싶은 사람, 팀, 회사를 위한 요약 글입니다.

목표

첫 목표는 언제나 쓸만한 무언가 를 만드는 것.
그 다음은 계속 개발 하는 것.
마지막으로 기여자를 받아 들이는 것.

왜 오픈소스인가?

  • Technical brand
    사람들에게 좋은 인상을 심어주기 위해서 오픈소스 프로젝트를 하는 경우.
  • Recruiting
    자사 오픈소스에 기여하는 사람을 채용하기 위해.
  • Giving back
    순수한 선의에서, 받은 만큼 세계에 돌려주기 위해.

성공적인 오픈소스 프로젝트로서 시작하려면

성공한 오픈소스 프로젝트는 다음의 요소를 갖추고 있다.

  1. 최적의 시장 진입 타이밍. 적당한 때에 문제를 해결하는데 필요한 제품을 제공.
  2. 개발자와 비개발자가 포함된 능력있는 팀
  3. 참여 설계. 이 리스트에 언급되는 것보다 훨씬 구체적인, 코드와 코드의 구조를 포함하고, 그 너머까지 포함하는 설계.
  4. 모듈화가 잘 되어있는 코드. 기여자가 한번에 어느 기능이 어떤 파일의 어느 부분에 있는지 알 수 있어야 한다. 코드의 구조와 연결되는 얘기.
  5. 넓게 적용할 수 있는 코드. 또는 니치한 필요보다 좀 더 많은 사람들에게 도달가능한 코드.
  6. 훌륭한 최초 코드.
  7. 관대한 라이센스.

코드 관리

라이센스 License 선택하기

널리 사용되는 라이센스

그 중 다음 4가지가 많이 사용된다.

  • GPL
    자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이선스다. 미국의 리처드 스톨만(Richard Stallman)이 GNU-프로젝트로 배포된 프로그램의 라이선스로 사용하기 위해 작성했다. ‘① 컴퓨터 프로그램을 어떤 목적으로든지 사용할 수 있다 ② 컴퓨터 프로그램의 복사를 언제나 프로그램의 코드와 함께 판매 또는 무료로 배포할 수 있다 ③ 컴퓨터 프로그램의 코드를 용도에 따라 결정할 수 있다 ④ 변경된 컴퓨터 프로그램 역시 프로그램의 코드와 함께 자유로이 배포할 수 있다’라는 네 가지 조항을 명시하고 있다. 대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위 고안되었다. 반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다. 즉, 소프트웨어가 사용자 모두에게 자유롭게 이용될 수 있도록 하는 것이다. 이 일반 공중 라이선스는 자유 소프트웨어 재단의 소프트웨어 대부분을 비롯하여, 저작자가 이 라이선스의 사용을 지정한 기타 모든 프로그램에 적용된다. (자유 소프트웨어 재단의 소프트웨어 중 일부는 이 라이선스 대신 GNU 라이브러리 일반 공중 라이선스가 적용된다.) 누구나 자신의 프로그램에 이 라이선스를 적용시킬 수 있다.
  • LGPL
    라이브러리는 공유하되 개발된 제품에 대해서는 소스를 공개하지 않고 상용 SW 판매가 가능한 GPL 보다 완화된 라이선스를 말함. GNU 약소 일반 공중 라이선스의 이름으로 공표된 최초의 버전이다. 본 라이선스는 GNU 라이브러리 일반 공중 라이선스 버전2의 후속판으로 간주되기 때문에 버전 번호를 2.1로 붙인 것이다.
  • MIT
    MIT 라이선스(MIT License)는 미국 매사추세츠 공과대학교(MIT)에서 해당 대학의 소프트웨어 공학도들을 돕기 위해 개발한 라이선스다. MIT 라이선스를 따르는 소프트웨어를 개조한 제품을 반드시 오픈 소스로 배포해야 한다는 규정이 없으며 GNU 일반 공중 라이선스의 엄격함을 피하려는 사용자들에게 인기가 있다. 이 라이선스를 따르는 대표적 소프트웨어로 X 윈도 시스템이 있다.
  • BSD3
    캘리포니아 대학이 관장하고 있는 공개 라이선스 및 라이선스 문장. 유닉스(Unix) 의 양대 뿌리 중 하나인 버클리의 캘리포니아 대학에서 배포하는 공개 소프트웨어의 라이선스이다. GNU 자유 소프트웨어 재단의 일반 공중 라이선스(GPL)보다 훨씬 개방적인 4개항의 간단한 문구로 되어 있다. 그동안 sendmail을 비롯하여 수 많은 인터넷 관련 소프트웨어의 소스나 바이너리가 BSD 라이선스로 공개되어 소프트웨어 및 인터넷 발전에 기여한 바 크다. 이러한 정신은 FreeBSD, NetBSD, OpenBSD, BSDi 등 파생된 라이선스에서도 그대로 이어지고 있다.

코드 구조 Code Organization

코드가 어떤 구조로 구성된 디렉토리에 저장될지를 결정한다. 기여자가 프로젝트 전체 구조를 쉽게 알아챌 수 있게 구성하는 것이 중요하다. 코드 구조 또한 코딩 스타일의 일부이며, 공개하기전에 충분히 고려해야 할 사항이다.
예를 들어 이런식으로 구성이 가능하다. 하지만 사용하는 언어나, 프로젝트의 목적에 따라 이런 구조는 충분히 바뀔 수 있다. 여러가지 다른 오픈소스 프로젝트를 참고하여 구성하는 것이 좋을 것이다.

Project
├─lib: 외부 의존성을 가진 라이브러리
├─src: 소스 코드
└─tests: 테스트 코드

문서 Documentation

최종 사용자와 개발자 양쪽을 위한 문서를 전부 작성하는 것이 좋다. 대부분의 오픈소스 프로젝트는 문서가 없는 경우가 많다. 문서가 없다는 건 사용할 의지를 꺽는 가장 큰 요소다.
문서는 코드 push가 필요하지 않게 관리해야 한다. 사용자의 피드백을 받아서 매우 빠르게 수정되어야 하기 때문이다. 즉, 코드와 같은 저장소를 사용하지 않는 것을 추천한다.
GitHub를 사용중이라면, 저장소를 만들때 제공되는 빌트인 Wiki를 사용하여 문서를 만드는 것을 추천한다. 그 외의 곳에서 코드를 관리한다면, 다른곳에 위키나 그와 비슷한 것을 만들어서 관리하는 것을 추천한다.
이때 사용하는 문서 관리 시스템은 업데이트가 매우 쉬워야 한다. 안그러면 문서 업데이트조차 매우 귀찮고 힘든일이 되어버리기 때문에, 업데이트를 빨리 할 수 없게 된다.

최종 사용자용 문서

최종 사용자를 거치지 않고 바로 기여자가 되는 경우는 없다. 때문에 최종 사용자를 언제나 염두에 두어서 문서를 만드는 것이 좋다.
최종 사용자는 직접 코드를 들여다 보지 않고, 사용만 한다. 때문에 애매함이 없이 명확하게 프로젝트가 무엇을 달성하려 하는지, 어떻게 사용해야 하는지 작성해야한다.

개발자 가이드

좋은 개발자 가이드 문서는 다음을 충분히 설명할 수 있어야 한다.
1. 소스코드를 체크아웃 하는 방법.
사용하는 저장소의 시스템에 따라 기여자가 코드를 획득하는 방법이 달라진다. 때문에 이미 해당 저장소 서비스에 익숙한 사람보다, 처음 접하는 사람도 쉽게 알 수 있게 설명하는 것이 좋다.
2. 코드의 구조.
코드와 디렉토리 구조가 그 자체로 충분히 어떻게 코드가 조직되어야 하는지 나타낸다고 해도, 문서로써 명확하게 설명을 해야 한다.
3. 빌드 시스템을 설정하는 법.
프로젝트가 빌드 시스템을 사용하고 있다면, 어떻게 그 빌드 시스템을 구성하는지에 대해 설명하는 것이 좋다. 저장소에 포함되어 있지 않지만, 빌드 할때 의존성을 가지는 것을 어떻게 설치하고 설정하는지도 설명해야 한다.
4. 빌드를 실행하는 법
개발 빌드를 실행하고, 유닛 테스트를 하는법에 대한 순서를 설명해야 한다.
5. 기여하는 법
기여하기 위해 필요한 단계를 설명한다. 유닛테스트가 필수라면 그에 대해 언급하고, 문서 작성이 필수라면 그에 대해 언급한다. 기여하기 필요한 체크리스트를 만들어 제공하는 것이 좋다.

버전 넘버 사용

버전 넘버를 사용함으로써 장기간의 안정성, 유지 보수성을 가지게 할 수 있다. 버전 넘버링을 함으로써, 새 버전이 릴리즈 되었음을 잘 알릴 수 있고, 이미 수정된 버그가 리포트 되는 것을 방지 할 수 있다.
버저닝에 대해서는 다음의 문서를 참고하는 것을 추천한다.

APR’s Version Numbering
Semantic Versioning 2.0.0

변경 내역

버저닝을 함으로써 각각의 버전에서 어떤것들이 변화되었는지를 추척하고, 그에 기반하여 사용자와 기여자들간에 소통할 수 있다. git등을 이용한 형상관리를 하고 있다면 형상관리에서 지원하는 태그 기능을 사용하여 쉽게 변경 내역을 작성할 수 있다.

커뮤니티 키우기

커뮤니티를 통해서 프로젝트를 더욱 크게 만들 수 있다. 다음의 문서를 참고하여 취합 및 의견을 더했다.
http://www.visionmobile.com/blog/2011/01/open-source-community-building-a-guide-to-getting-it-right/
http://www.smashingmagazine.com/2013/01/03/starting-an-open-source-project/
http://www.smashingmagazine.com/2013/12/27/open-sourcing-projects-guide-getting-started/

메일링 리스트

사람들에게 질문을 받고 그에 답하는 제일 간단한 방법은 메일링 리스트를 만드는 것. 구글 그룹스를 이용하여 쉽게 메일링 리스트를 만들 수 있다. 메일링 리스트를 운영하면서, 적극적으로 메일링 리스트를 모니터링 하면서 답변을 하는 것이다. 이런식으로 메일링 리스트를 만들어 관리하는 것은 프로젝트에 참여하는 개발자 커뮤니티를 조성하는 최고의 방법이다.

기여자 관리

받아들이기

contributor license agreement (CLA) 라는 것을 만들어 기여자가 동의하게 한다. CLA는 법적 문서로, 보통 다음을 포함한다.

  • The contributor asserts that they are the original author of the code they are submitting.
  • The contributor grants the project the right to use and distribute the code they are submitting.
  • The contributor has the right to grant the previous two points.
  • Any code submitted by a contributor is not guaranteed to be accepted or used.

    Node.js CLA를 참조하면 좋다.

기여자 단계

대부분의 오픈소스 프로젝트는 다음과 같이 기여자들을 구분한다.

  • Contributor
    저장소에 merge된 소스코드를 제공한 사람. 저장소에 직접 접근을 할 수 없다. 하지만 적용된 패치를 제출한 사람
  • Committer
    저장소에 직접 접근할 수 있는 사람. 기능과 버그 픽스를 정기적으로 수행한다. 저장소에 직접 코드를 제출한다.
  • Reviewer
    제일 높은 레벨의 기여자. 리뷰어는 프로젝트에 직접 영향을 미친다. 컨트리뷰터와 커미터가 제출한 코드를 리뷰한다. 패치를 받아들이거나 거부하며, 컨트리뷰터를 커미터로 승격시키거나, 그 반대를 수행한다.

웹사이트: 포럼, 게시판

커뮤니티 제어

어떤 코드를 받아들일지 규칙을 확실히 하여 예시를 보여준다. 혹은 직원(이나 커미터)들만이 커밋할 수 있다고 확실하게 해둔다.

커뮤니티 진입 장벽

커뮤니티 진입 장벽 체크리스트를 참고하여 커뮤니티를 구성한다.

커뮤니티 프로세스

환경만 조성한다. 사람들을 통제하려하지 말 것. 어떻게하면 프로젝트의 다양한 리소스에 접근 할 수 있는지, 그 프로세스를 문서화 해둘 것.

할 수 있는 만큼 하기

커뮤니티를 조성하는 것은 많은 자원을 필요로 한다. 하지만 그만큼 가치가 있는 일이다. 커뮤니티를 조성하는 것은 새 프로젝트를 런칭하는 것보다 더 오래 걸리고, 더 비용이 많이 들고, 새 (커뮤니티)참여자를 찾는 것이 더 힘들다.

커뮤니티 안티-패턴: 하지 말아야 할 것

  1. Command & Control – 커뮤니티는 파트너다. 통제하려 하지 말 것.
  2. Water cooler – 너무 많은 것을 비공개로 진행하지 말 것. 커뮤니티는 그 동기와 중요성을 이해하지 못하게 되고, 참여도가 떨어지게 된다. 공개적으로 의논할것.

  3. Bikeshed – 중요하지 않은 문제로 논의를 질질 끌지 말 것. 말에서 행동으로 옮겨야 하는 시기를 알아야 한다.

  4. Black hole – 커뮤니티에서 활동하고 있던 개발자를 채용하는 것은 구미가 당기는 일이다. 하지만 이로 인해 커뮤니티 전체의 활력이 사라질 수 있다.

  5. Cookie licker – 앞으로 구현할 중요 기능들을 로드맵에 올려두고, 이미 초안이 있다면서 다른 사람이 건드리지 못하게 하지 말라.

기여 가이드라인

참고 1

참고 2

기여자에게 알려야 할 것

다음의 것들을 참여자들에게 이해하게 함으로써 기여에 적극적이 되게 할 수 있다.

  1. a way to understand the value of your project
    프로젝트의 가치를 이해하는 것
  2. a way to understand the value they could provide to the project
    기여자가 프로젝트에 제공하는 것에 대한 가치를 이해하는 것
  3. a way to understand the value they could receive from contributing to the project
    프로젝트에 기여함으로써 받을 수 있는 것에 대한 가치를 이해하는 것
  4. a way to understand the contribution process, end-to-end
    기여 프로세스에 대해 처음부터 끝까지 이해하는 것
  5. a contribution mechanism suitable for their existing workflows
    이미 존재하는 작업 흐름에 기여 메카니즘이 알맞음을 보이는 것.

구체적인 기여 방법

참고 1 에서 목록을 발췌하여, 필요한 경우에만 설명을 붙였다.

Start listening

어떤 프로젝트든 현재 어떤 상황이고, 어떤 일이 필요한지 파악하는 일이 필요하다. 다음의 방법으로 파악할 수 있다.

  1. Join a mailing list
  2. Follow a blog

  3. Join an IRC channel

Work with Tickets

코드를 쓰는 것만이 기여할 수 있는 유일한 방법은 아니다.

  1. Diagnose a bug
    버그를 원인을 진단하는 것도 훌륭한 기여 방법이다. 원인이 무엇인지 정확히 몰라도, 버그가 일어나는 상황을 좁혀나갈 수 있다. 이는 다른 사람이 버그를 고칠때 매우 큰 도움이 될 것이다.

  2. Close fixed bugs
    이미 고쳐진 버그지만 이슈트래커에서 닫히지 않는 경우가 있다. 그런것을 찾아서 닫아주는 것만으로도 도움이 될 수 있다.

Working with Code

초보부터 구루까지 모든 레벨의 개발자가 프로젝트에 기여할 수 있다.

  1. Test a beta or release candidate
  2. Fix a bug

  3. Write a test

  4. Silence a compiler warning
    컴파일러 경고가 반드니 코드의 잘못된 점을 가리키는 것은 아니다. 컴파일러 메시지와 코드를 보고 그게 문제가 되지 않는다면 해당 경고를 안나게 하는 것으로 사람들이 겪는 문제(처럼 보이는 것) 하나를 줄일 수 있다.

  5. Add a comment
    코드를 읽으면서 헷갈리는 부분이 있다면, 그 부분에 대해서 주석을 작성하고, 다른 사람이 이해할 수 있게 도와주는 것으로도 기여할 수 있다.

Work with Documentation

  1. Create an example
    예제는 많으면 많을수록 좋다. 어떤 프로젝트든간에, 프로젝트를 활용할 수 있는 예제를 작성해서 다른 사람이 수월하게 사용하게 만드는게 좋다.

Work with Community

  1. Answer a question

  2. Write a blog post

  3. Improve a website

프로젝트 관리하기

참고 문서

  1. The public repo is the source of truth.
    공개된 저장소에서 개발을 한다. 비공개 저장소에서 개발하고 공개하는 것은, 사람들이 프로젝트를 포킹하거나 풀 리퀘스트를 보내는 것을 매우매우 힘들게 한다.
  2. Plan in public.
    공개된 이슈 트래커 시스템을 사용한다. 로드맵을 공개하여 개발 계획을 보여준다. 가능한 개발 과정을 투명하게 보여준다.
  3. Dedicate company time.
    프로젝트의 주요 기여자가 되었다면, 더이상 취미로 하는 것이 아니라 일의 일부분이라고 생각하는 것이 좋다. 프로젝트에 대한 일에 대해서 신속한 반응을 해야한다.
  4. Open channels of communication.
    유지 보수를 하는 사람과 직접적으로 소통 할 수 있는 창구가 있어야 한다.
  5. Commit to document.
    문서화를 잘 해두어야 한다. 사람들은 문서를 보고 프로젝트 결과물을 사용한다. 문서가 없다면 사용자들은 쓸 생각을 못한다.
  6. Maintain regular outgoing communication.
    주기적인 발표를 해서 사람들이 예측할 수 있게 하라.

위험 신호

  • “Not enough time”
  • Too few contributors

  • Too many open issues and pull requests

  • No way to contact the maintainer

살아남기

프로젝트가 오래도록 살아남기 위해 새겨두어야 할 것들

  1. Try to come up with an original idea
  2. Decide how much time you are willing to spend on the library before you start writing.

  3. Set up a mailing list so that others can contact you about the library

  4. Always take note of criticism, especially when it concerns bugs

  5. Set up a website to increase user awareness

  6. Distribute some responsibilities to loyal mailing list members

  7. Do everything you can to assist newcomers to your library

  8. Maintain neutrality in your community

  9. Set up a company to deal with commercial requests

  10. Keep at it!

나름의 결론

단순히 좋은 코드를 작성하는 것은 누구나 할 수 있다. 하지만 오픈소스 프로젝트의 핵심은 열려있는 커뮤니티라고 생각한다. 코드 파일들을 잘 구조화 하고, 코드 자체도 사람들이 알아보기 쉽게 하고, 누구나 참여할 수 있게 공개된 저장소에 올리는 것은 (비교적) 쉽다.
하지만 프로젝트에 관심있는 사람들을 모으고, 프로젝트의 가치를 전파하고, 참여하게하는 것은 결국 커뮤니티다.

개발과 커뮤니티 관리 둘 다 똑같이 중요한게 아닌가 싶다.


참조 문서

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중