▲

당신의 오픈소스를 유명하게 만드는 방법

 (evilmartians.com)
37P by GN⁺ 17일전 | ★ favorite | 댓글 1개

오픈 소스를 유명하게 만들기 전에 알아야 할 점

  • 오픈 소스를 통해 유명해지거나 부자가 되고 싶다면 잘못된 접근임
  • 인기 있는 프로젝트를 만들기보다 블로그 작성이나 컨퍼런스 발표가 더 효과적임
  • Redux와 React Router는 인기 있는 프로젝트지만 유지 관리자는 소셜 미디어 팔로워가 많지 않음 → 프로젝트의 인기가 개인의 인기로 이어지지 않음

오픈 소스를 이력서에 쓰기 위해 만들지 말 것

  • 오픈 소스 참여가 필수라는 인식은 거짓임
  • 유명해지기 위해 오픈 소스를 시작해도 성공 보장은 없음
  • 좋은 프로젝트라도 별이 하나뿐이라면 우울해질 수 있음
  • 채용에서 오픈 소스 활동이 도움이 될 수는 있으나, 직접 프로젝트를 만들기보다 기존 유명 프로젝트에 기여하는 것이 더 효과적임

먼저 기여부터 시작하기

  • 큰 오픈 소스 프로젝트에서 문서 수정이나 버그 수정부터 시작
  • 코드 작성보다 PR 작성이 훨씬 쉬움
  • 좋은 오픈 소스를 만들기 위한 가장 좋은 이유는 세상을 바꾸고 싶기 때문

오픈 소스를 통해 세상을 바꾸는 방법

  • PostCSS를 만든 이유는 CSS 도구 생태계를 다양화하고 더 쉽게 CSS 처리가 가능하게 하기 위함 → 성공적
  • 인기와 성공은 중요한 요소임

인기 프로젝트의 비결

프로젝트의 인기 = 인지도 + 프로모션 + 사용자에게 주는 이점 + 운

  • 인기 있는 개발자가 만든 프로젝트가 더 쉽게 인기를 얻는 경향이 있음 → 부당할 수 있지만 현실임
  • 인기의 원인을 이해하고 전략적으로 접근해야 함

사람들이 오픈 소스를 선택하는 방식

  • 사람들은 합리적으로 도구를 선택하지 않음
  • 대부분 GitHub에서 Star 개수를 보고 결정
  • 또는 컨퍼런스에서 언급된 프레임워크를 따라가는 경우가 많음

사람들이 실제로 정보를 읽는 방식

  • 사용자는 README나 문서를 처음부터 끝까지 읽지 않음
  • 정보를 '프로그레시브 JPEG'처럼 간단히, 점진적으로 제공해야 함
  • 첫 블록에서 혜택을 명확히 설명해야 함

인기 얻기 전략

  • 소셜 미디어 계정을 잘 정리해야 함
    • 저자는 처음에 영어 소셜 계정을 만들지 않아 사람들이 저자를 찾기 어려웠음
    • 비영어권 개발자라면 영어 소셜 미디어 계정을 만드는 것이 유리함
    • 프로젝트가 언급될 때 프로필 링크를 제공해야 사용자 연결이 쉬워짐
  • 현실적인 마인드 설정
    • 운이 중요하지만 전부는 아님
    • 저자는 56개의 프로젝트 중 4개만 성공
    • 인기 프로젝트를 만들기까지 여러 번의 실패를 경험
    • 성공한 프로젝트는 꾸준한 시도와 반복된 실패의 결과
  • 실패를 당연하게 받아들이기
    • 인기 프로젝트는 마라톤처럼 오랜 시간의 노력 필요
    • 실패는 과정의 일부 → 지속적인 개선과 반복 시도가 필요
    • 처음부터 실패를 예상하고 시작하되, 작업의 퀄리티는 포기하지 말아야 함

오픈 소스를 인기 있게 만드는 법 : README

  • README와 문서는 프로젝트의 첫인상을 결정함
  • 사용자가 README를 통해 프로젝트의 가치를 빠르게 파악해야 함
  • README는 다음과 같은 경로를 통해 사용자에게 노출될 수 있음
    • 발표, 블로그 글, 팟캐스트 등 다양한 프로모션 경로
    • 결국 README로 연결되기 때문에 신경 써서 작성해야 함
  • 독자는 README를 처음부터 끝까지 꼼꼼히 읽지 않음
  • 따라서 README 첫 부분에서 프로젝트의 가치를 명확히 전달해야 함
  • 첫 블록에서 사람들이 프로젝트의 이점을 빠르게 이해할 수 있어야 함

질문: 프로젝트의 가치를 효과적으로 전달하고 있는가?

  • 사람들은 여유롭게 문서를 자세히 읽지 않음
  • 따라서 핵심 정보와 이점을 명확하고 간결하게 정리해야 함
  • 문서를 잘 정리함으로써 사용자 경험을 개선하고 프로젝트의 인기를 높일 수 있음

1. 사용자에게 이점을 효과적으로 전달하기

  • 사용자에게 프로젝트의 이점을 전달하는 것은 프로모션과 직접적으로 연결됨
  • 이전에 언급한 성공 공식에서 사용자에게 이점을 제공하는 것이 중요한 요소임

프로젝트의 인기 = 인지도 + 프로모션 + 사용자에게 주는 이점 + 운

  • README, 문서 또는 간단한 소개글에서 사용자에게 이점을 명확하게 전달해야 함
  • 인기나 평판이 아닌 실제 가치로 주목받기 위해서는 다음과 같은 점을 고려해야 함
    • 정보의 가독성: 사용자가 빠르게 핵심 내용을 파악할 수 있어야 함
    • 스캔 가능성: 중요한 정보가 쉽게 눈에 띄도록 구성해야 함
    • 첫인상: 첫 몇 초 안에 프로젝트의 가치가 명확히 드러나야 함

2. 메시지를 빠르고 효과적으로 전달하기

  • README의 첫 블록에는 다음 세 가지 요소가 반드시 포함되어야 함
    1. 명확한 설명
    2. 사용자에게 어떤 도움이 되는지 명확히 제시
    3. 다른 제품과의 차별점 명시
  • 사용자가 문서를 읽어야 할 이유를 첫 문장에서 명확히 전달해야 함
    • 첫 문장이 가장 중요함 → 대부분의 사용자는 첫 문장만 읽고 프로젝트의 가치 판단
    • 따라서 첫 블록에서 프로젝트의 이점이 명확히 드러나도록 해야 함
  • README의 첫 블록 작성에 며칠에서 일주일 정도 투자해도 괜찮음
  • PostCSS의 첫 블록 작성에 약 일주일이 걸렸음
  • 첫 블록에 충분한 노력이 들어가야 프로젝트의 성공 가능성 증가

3. 제품을 사람들이 쉽게 이해할 수 있도록 설명하기

  • 프로젝트 설명은 명확하고 직관적이어야 함
  • 멋있어 보이는 표현보다 실질적인 설명이 더 중요함
  • ❌ "Svelte is cybernetically enhanced web apps"
    • 너무 모호함 → 구체적으로 어떤 장점이 있는지 불명확함
  • ✅ "Svelte is a web UI framework with a unique compiler which generates smaller JS fixes."
    • 구체적이고 명확함 → 어떤 문제를 해결하고 어떤 이점이 있는지 설명
  • 동료와 술집에서 대화한다고 생각하고 설명 작성하기
    • "새로운 도구를 만들었다고? 뭐 하는 도구야?" → 자연스럽게 설명하기
  • 설명이 정리되면 더 간결하게 다듬기
    • 설명을 작성한 후 2~4번 더 다듬어서 짧고 명확하게 만들기

4. 리스트와 볼드 텍스트로 정보를 빠르게 전달하기

  • 정보를 명확하게 전달하려면 리스트와 볼드 텍스트를 적극 활용해야 함
  • Nano Stores의 기존 설명 (텍스트 블록 형태)
    • Nano Stores는 다양한 프론트엔드 프레임워크에서 사용할 수 있는 상태 관리자임
    • 크기가 작고, 의존성이 없음
  • 수정된 설명 (리스트 및 볼드 강조 사용)
    • Nano Stores는 다음과 같은 특징이 있음:
      • 작은 크기: 286~818바이트 (minified 및 brotlied)
      • 다양한 프레임워크 지원: React, Vue, Svelte, Angular 등
      • 의존성 없음

  • 가독성을 높이는 포인트

    • 리스트 사용: 정보를 구조화해 한눈에 파악 가능
    • 볼드 텍스트 사용: 핵심 정보를 강조해 빠르게 인지 가능
    • 간결한 문장: 중요한 정보만 남기고 불필요한 내용 삭제
      • 텍스트를 줄여도 메시지가 명확하게 전달되어야 함

5. 코드 예제와 이미지 활용하기

  • 복잡한 개념은 예제 코드나 이미지를 통해 쉽게 설명할 수 있음
    • "백 마디 말보다 한 장의 그림이 낫다"는 말처럼 시각 자료는 이해를 돕는 강력한 도구임

6. 실제 통계 자료 사용하기

  • 모호한 표현이나 추상적인 약속은 신뢰를 얻기 어려움
    • 실제 성능, 크기, 속도 등의 구체적인 통계를 제시해야 함

  • 예시: Nano ID의 실제 통계 사용

    • 크기 증명: Nano ID는 141바이트로 작음 → 명확한 수치 제공
    • 속도 증명: Nano ID는 UUID보다 16% 더 빠름 → 벤치마크 결과 제시
  • 효과적인 통계 자료 활용 팁
    • 수치화된 성능 데이터 제공 → 신뢰도 강화
    • 벤치마크 결과 명시 → 다른 제품과의 차별화 강조
    • API 성능이나 사용법도 실제 예제와 함께 명확히 제시
      • 성능, 크기, 속도 등은 구체적인 수치와 데이터로 증명

7. 단계별 시작 가이드 제공하기

  • 프로젝트의 장점이 명확히 전달되었다면, 그다음은 구체적인 사용 방법을 제공해야 함
  • 사용자가 README를 읽은 후 프로젝트에 흥미를 가지면, 다음 단계로 자연스럽게 이어져야 함

  • 효과적인 시작 가이드 작성 팁

    • 구체적인 단계별 가이드 제공
      • "PostCSS를 사용하세요" 같은 모호한 설명 대신 명확하고 구체적인 단계를 제시
      • 각 단계에서 필요한 명령어 및 설정 방법 명시
    • 대체 경로 제공
      • 사용자의 상황에 따라 다른 접근 방법을 제시
      • 예: PostCSS가 설치되지 않은 경우의 처리 방법 추가
    • 사용자 유형별 섹션 제공
      • 대규모 라이브러리와 소규모 라이브러리 사용자에게 각각 맞는 가이드를 제공

  • 테스트 필수

    • 직접 작성한 가이드를 따라 보며 실제로 잘 작동하는지 테스트해야 함
      • 가능한 경우, 프로젝트에 대한 배경 지식을 잊고 처음부터 다시 따라 하기
      • 문제가 발생하면 즉시 수정하고 보완

효과적인 오픈 소스 홍보 전략

1. 반복적인 홍보의 중요성

  • 많은 사람들이 다음과 같은 실수를 함
    1. 소셜 미디어에 한 번만 게시
    2. 반응이 없음
    3. 우울해짐
    4. 프로젝트 중단
  • 한 번의 대규모 홍보는 효과적이지 않음 → 점진적이고 반복적인 홍보 필요
  • 효과적인 반복 홍보 사이클
    1. 새로운 기능 릴리스, 블로그 포스트, 소셜 미디어 게시물 등 콘텐츠 생성
    2. 사용자 피드백 받기
    3. 피드백 기반으로 프로젝트 수정
    4. 수정 사항에 대한 새 콘텐츠 생성 → 다시 시작
  • 초기에는 사용자 수가 적은 것이 오히려 유리함 → 스트레스 없이 수정 가능
  • 지속적인 개선과 반복적인 홍보를 통해 인지도 상승

2. 효과적인 소셜 미디어 홍보 전략

  • 단순히 링크만 공유하거나 짧은 설명으로 끝내지 말 것
  • 다음 2가지를 포함할 것
    • 코드 예제 또는 이미지 → 사람들이 쉽게 이해함
    • 명확한 프로젝트 설명 → 새로운 사용자도 이해 가능

  • 홍보 글 템플릿 예시

    • 새 기능 발표 → 명확한 설명 → 코드 예제 포함 → 소셜 미디어에 공유
    • Reddit에서 관련 서브레딧에 게시 (각 서브레딧 규칙 확인)
    • Hacker News에 게시 → 초기 traction 확보 가능
    • Dev.to, Smashing Magazine, CSS-Tricks 등에 기사 작성 → 노출 확대

3. PR을 통한 홍보 전략

  • 다른 프로젝트에 자신의 오픈 소스를 도입하는 PR 제출
    • 예: PostCSS는 다른 프로젝트에 PR을 통해 홍보 성공
    • "도움이 필요하면 제가 이 도구를 적용해 볼 수 있습니다."
  • PR이 승인되면 README에 적용 사례 명시 → 신뢰도 상승
  • 인기 있는 프로젝트에서 자신의 도구를 사용한다고 명시하면 신뢰도 강화

4. 반복하되 스팸은 금물

  • 지속적인 반복 홍보 필요
  • 그러나 스팸은 절대 금지
    • 동일한 메시지를 반복하지 말고 새로운 가치 제공
    • 변화와 발전된 내용을 포함할 것
  • 모든 사용자가 모든 게시물을 읽는 것은 아님 → 주기적으로 다양한 형태로 반복 홍보 필요

반복 홍보의 이유

  • 사람들은 합리적으로 도구를 선택하지 않음
  • 반복적인 홍보를 통해 인지도를 자연스럽게 형성
  • 오랜 기간 동안 인지도를 쌓아야 성공 가능

보너스

1. 프로젝트가 유명해졌을 때의 문제 해결법

  • 프로젝트가 인기를 얻으면 해결해야 할 이슈가 폭발적으로 증가할 수 있음
  • 스스로 모든 문제를 해결하려고 하면 부담이 커져 우울감과 생산성 저하로 이어질 수 있음

  • 해결책

    • 모든 문제를 직접 해결하려 하지 말 것 → 사용자에게 PR 작성을 권장
    • "이 문제를 해결하고 싶다면 PR을 보낼 수 있나요?"라고 요청
    • 문제 해결에 할당된 시간(예: 하루 15분)을 설정하고 그 시간 안에서만 처리
    • 어려운 문제는 즉시 해결하려 하지 말고 "해결 방안을 검토 중입니다"라고 응답 → 사용자는 문제를 인지하고 있다는 피드백만으로도 안심함
    • 문서 수정도 사용자에게 맡길 수 있음 → "이 부분을 수정해줄 수 있나요?"라고 요청

2. 부정적인 피드백에 대처하는 방법

  • 부정적인 피드백은 동기 저하로 이어질 수 있음
  • 프로젝트 초기에 부정적인 피드백은 의욕을 꺾을 수 있고, 인기가 많아지면 자신감을 약화시킬 수 있음

  • 대응 전략

    • 감정적으로 반응하지 말 것
    • 비판에 대해 질문 → "왜 B가 A보다 낫다고 생각하나요?"라고 물어볼 것
    • 비판이 단순한 감정 표출인 경우가 많음 → 사용자와 대화를 시도해 신뢰 구축
    • 비판을 통해 개선의 기회를 얻을 수 있음

3. 경쟁 프로젝트 등장 시 대처 전략

  • 경쟁 프로젝트가 등장해도 걱정할 필요 없음
  • 경쟁 프로젝트가 나오면 다음과 같은 이점이 있음
    • 프로젝트 유지 부담에서 벗어날 수 있음
    • 경쟁을 통해 더 나은 솔루션이 나올 수 있음 → 결국 사용자에게도 이익
  • 오픈 소스의 궁극적인 목적은 세상을 바꾸는 것 → 독점이나 지배가 아님
  • 경쟁 프로젝트 등장 → 더 나은 도구 탄생 → 윈윈 상황

최종 요약

인기 있는 오픈 소스를 만들고 가시성을 확보하는 법

  1. 오픈 소스를 만드는 가장 좋은 이유는 유명세나 이력서 보강이 아니라 세상을 바꾸기 위해서임
  2. 좋은 아이디어가 인기 프로젝트가 된다는 보장은 없음
  3. 오픈 소스 프로젝트의 인기도 공식 = 인기도 + 홍보 + 사용자 혜택 + 운
  4. 소셜 미디어 계정은 활성화하고, 검색 가능하도록 하며, 영어 등 널리 사용되는 언어로 작성해야 함

효과적인 문서 작성법

  1. README와 문서는 친구에게 설명하듯 명확하고 자연스럽게 작성해야 함
  2. 강조 텍스트, 목록, 체계적인 구성으로 복잡한 정보를 점진적으로 전달
  3. 실제 벤치마크와 코드 예제 등 구체적 증거를 제공해야 함
  4. 가능한 경우, 초보자와 고급 사용자에 맞춘 구체적인 시작 가이드를 제공

홍보 전략

  1. 한 번의 대규모 홍보보다 반복적인 홍보가 더 효과적임 → 출시 → 피드백 → 개선 → 반복
  2. 정기적으로 게시하되 스팸은 피할 것
  3. 코드 예제와 이미지를 포함한 게시물 작성
  4. 다른 프로젝트에 PR을 제출해 홍보 효과 극대화

프로젝트가 유명해졌을 때의 팁

  1. 모든 문제를 스스로 해결하려 하지 말고, 사용자가 PR을 제출하도록 유도
  2. 문제 해결을 위한 일정 시간을 정해놓고 관리 (예: 하루 15분)
  3. 부정적인 피드백이 있을 경우 질문을 통해 대화 시도
  4. 경쟁 프로젝트를 두려워하지 말 것 → 경쟁이 오히려 책임에서 자유롭게 해줄 수 있음
▲
roxie 5일전  [-]

조금씩 다른 내용의, 하지만 멀리서 보면 반복적인 내용의 홍보가 용인되는 장소를 찾아내는 것도 중요할 것 같습니다. 예를 들면 트위터요.

답변달기