GN⁺: 오픈 소스에 대한 비코드(non-Code) 기여

비코드 기여가 오픈 소스 성공의 비결

• 수학 교사인 사라 레인스버거는 자발적으로 오픈 소스 기여자가 되려던 것은 아니었으나, 자신의 합창단 웹사이트를 재구축하면서 자바스크립트와 웹 개발을 배우기 시작함.
• 프론트엔드 프레임워크인 Astro를 사용하면서 프로젝트에 작은 코드 조각인 설정 파일을 기여하게 되었고, 커뮤니티에 참여하며 새로운 Astro 사용자를 지원하는 역할을 맡게 됨.
• 레인스버거는 현재 Astro의 핵심 유지 관리자 그룹의 일원이지만, 코드베이스에는 크게 관여하지 않고 문서 작업을 주로 담당하며 다른 이들이 Astro를 배울 수 있도록 돕고 있음.

오픈 소스 프로젝트의 중요한 비코드 작업

• 오픈 소스 프로젝트에는 코드 작성 외에도 문서화, 현지화, 마케팅, 그래픽 디자인, 테스팅, 커뮤니티 관리, 릴리스 관리 등이 필요함.
• 비코드 기여의 중요성은 매우 크며, 복잡한 프로젝트일수록 더 많은 문서, 튜토리얼, 지원이 필요하여 코드를 유용하게 만듦.
• 그래픽 디자인, 브랜딩, 아웃리치는 프로젝트의 건강과 진지함을 나타내는 신호로 작용하여 다른 프로젝트나 회사가 의존성으로 활용할 수 있음.

비코드 기여를 시작해야 하는 이유

• 비코드 기여는 기술 커뮤니케이션, 그래픽 디자인, 사용자 경험 디자인 등 프로그래밍을 포함하지 않는 역할에 관심이 있는 사람들에게 포트폴리오를 구축할 기회를 제공함.
• 프로그래머도 글쓰기와 커뮤니케이션 기술을 갈고닦는 데 혜택을 받으며, 개발자 관계나 제품 관리와 같은 역할로 전환하는 데 도움이 될 수 있음.
• 오픈 소스 프로젝트에는 모든 기술 수준의 사람들이 참여할 기회가 있으며, 프로젝트에 대한 깊은 이해 없이는 의미 있는 코드 기여를 하기 어려움.

비코드 기여자 찾기 및 감사 표현

• 유지 관리자는 특정 작업을 요청함으로써 기여자를 찾는 것이 가장 좋으며, 커뮤니티를 구축하고 "도움 요청" 및 "좋은 첫 이슈"로 태그된 이슈를 파일링하는 것이 도움이 됨.
• 멘토십은 기여자를 성공으로 이끄는 가장 좋은 방법 중 하나이며, 비코드 기여자를 높이 평가하고 인정하는 것은 현재 기여자를 동기 부여하고 새로운 기여자를 유치하는 데 도움이 됨.

GN⁺의 의견

• 오픈 소스 프로젝트의 성공은 단순히 코드를 작성하는 것 이상의 다양한 기여가 필요하다는 점이 중요함. 이는 프로젝트의 지속 가능성과 성장에 필수적인 요소임.
• 비코드 기여는 기술적이지 않은 사람들에게도 오픈 소스에 참여할 수 있는 기회를 제공하며, 기술적인 역량을 개발하는 데도 도움이 됨.
• 이 글은 오픈 소스 커뮤니티에 관심이 있는 사람들에게 영감을 주고, 자신의 기술을 활용하여 커뮤니티에 기여할 방법을 찾는 데 도움이 될 수 있음.

[secret3056]

조금 다른 이야기긴 하지만 얼마 전에 누가 Express.js의 리드미 파일에 PR하는걸 강좌로 올려서 수백개의 의미 없는 PR이 올라왔습니다.

Pull requests · expressjs/express

[mdisprgm]

민폐..ㅠㅜ

[edunga1]

100개가 넘는 PR 이네요 ㄷㄷ

[sagee]

'바코드'로 어떻게 참여하는지 잠깐 혼란이 있었지만..ㅋ
상세한 문서화라는건 어찌보면 양날의 검일수도 있겠네요.
개발자가 감당하기 힘들정도로 문서와 스크린샷이 상세해져서 문서 업데이트 할 자신이 없어서 개선 개발을 포기하는 케이스가 발생할수도..

[cosine20]

("비(非)") 코드 입니다)

[neo]

Hacker News 의견

• 소규모 라이브러리의 저자/관리자로서 외부 기여가 없었다면 매뉴얼이 지금만큼 좋지 않았을 것이라고 확인함. 매뉴얼은 프로젝트의 사용성에 크게 기여함.

  • libcurl의 새 사용자로서 튜토리얼과 API 문서 덕분에 FTP 업로드를 빠르게 구현하고 특정 사용 사례에 맞게 조정할 수 있었음.
  • 문서를 통해 구버전의 스레드 안전성 부족을 인지하고 팀에 업데이트할 것을 경고할 수 있었음.
  • 문서는 코드와 테스트 스위트만큼 중요함.

• 오픈 소스 프로젝트에 대한 바람:

  • 많은 스크린샷
  • 매우 길고 상세한 README.md
  • 튜토리얼, 참조 문서, 설계 문서, 아키텍처 다이어그램
  • 저자가 생각하는 방식을 설명하는 정신 모델 문서

• 오픈 소스에 있어 문서, 자산 등이 중요하지만, 비개발자에게 권력을 주어 프로젝트를 망칠 수도 있음.

  • UX를 매 릴리스마다 다시 만드는 등 안정성, 기능성, 채택에 해를 끼칠 수 있음.
  • 정치에 관심이 많은 사람들을 끌어들이고, 누구나 할 수 있다고 생각하는 영역에서 'bikeshedding'이 발생하기 쉬움.

• 커뮤니티 구축을 위해 Discord, Gitter, Slack과 같은 채팅 플랫폼을 사용하는 것이 좋음.

  • 사람들이 레포지토리에서 질문하는 것을 주저하지 않게 만듦.
  • GitHub에서 질문을 하거나 문제를 해결하는 풀 리퀘스트를 만드는 것이 종종 무의미하게 느껴짐.
  • GitHub 프로젝트 생성자들 사이에서 "코드를 공개했으니 그 이상의 것은 빚진 것이 없다"는 태도가 널리 퍼져 있음.

• WordPress 커뮤니티에서 활동한 경험을 바탕으로 초기 문서화와 Codex의 강력한 문서화가 WordPress의 성장에 크게 기여했다고 생각함.

  • Joomla, Drupal, WordPress가 설치 기반면에서 비슷했던 시기에 WordPress는 풍부한 문서 덕분에 시작하기가 더 쉬웠음.

• 오픈 소스 프로젝트에 대한 가장 큰 바람은 사람들이 그것을 사용하고 사용한 내용에 대해 어떤 형태로든 기록을 남기는 것임.

  • 프로젝트의 Discord 채널에 메시지를 남기거나, 트윗, 짧은 메시지, 스크린샷, gist, 공개 GitHub 레포지토리, YouTube 또는 TikTok 비디오 등이 모두 프로젝트에 매우 가치 있는 기여임.

• 비코드 기여가 프로젝트의 성공 비결인지는 확실하지 않지만, 매우 중요하다는 데 동의함.

  • 예를 들어, Eclipse Foundation은 버그 리포트도 가치 있는 기여라고 사용자들에게 상기시킴.

• 오픈 소스 프로젝트를 시작하는 과정에서, 실제로 코드를 작성할 엔지니어보다 10배 많은 엔지니어가 소프트웨어를 사용할 것이라는 예상이 있음.

  • 사용자가 문서를 개선하는 방법으로 기여할 수 있어야 함.
  • Hugo와 같은 정적 사이트 생성기를 사용하여 문서(사용자 매뉴얼)를 생성할 때, 사용자가 GitHub 이슈를 생성하지 않고도 문서에 대한 수정/업데이트를 제출할 수 있는 방법이 필요함.

• 비기술적인 사람들이 프로젝트를 이해하고 가치를 찾는다면, 프로젝트가 성공할 좋은 지표임.

• 제품이 알려지지 않은 상태에서 팬들에 의해 사용되는 단계에서 더 많은 사용자를 찾는 단계로 넘어갈 때 문서화가 중요함.

  • 좋은 문서 없이는 이 단계를 넘기 어려움.
  • Neural Amp Modeller의 사용자 가이드를 작성해야 한다는 것을 상기시킴.