내 회사를 오픈 소스로 전환해야 할까? (2022)

• Supabase는 창업 초기부터 오픈 소스를 선택했고, 공개적으로 제품을 만들면서 커뮤니티·채용·제품 확장에서 예상보다 큰 이점을 얻음
• 대표적인 걱정은 코드 품질 비판, 보안 취약점 노출, 경쟁사의 복제지만 공개성은 개선 참여와 빠른 반복으로도 이어질 수 있음
• 채용에서는 저장소 기여가 후보자의 실제 코드와 협업 방식을 보여줘, Supabase는 32명의 개발자를 채용한 뒤에야 아웃바운드 채용을 시작함
• 소수 사용자 기능, 통합, 어댑터는 커뮤니티가 직접 만들 수 있어 제품 범위가 넓어지고 내부 팀의 우선순위 한계를 보완함
• 오픈 소스 회사의 방어력은 코드를 숨기는 데보다 실행 속도, 브랜드, 팀, 커뮤니티를 장기간 쌓는 데서 나옴

---

Supabase가 처음부터 오픈 소스를 택한 이유

• Supabase는 시작일부터 오픈 소스였고, 창업자들이 PostgreSQL, Python, Bitcoin, React 같은 공개 프로젝트의 오랜 사용자이자 지지자였기 때문에 당시에는 어려운 결정으로 느끼지 않았음
• 공개적으로 비즈니스를 만들면 부담이 클 것이라는 예상과 달리, 제품과 회사를 키우는 과정에서 여러 예상 밖의 장점이 나타남
• 개발자 도구 또는 PaaS 회사의 경험이지만, 많은 내용은 소프트웨어 회사 전반에도 적용될 수 있음
• 오픈 소스 전환을 막는 반복적인 걱정은 크게 세 가지임
  • 사람들이 지저분하거나 미완성인 코드를 비판할 수 있음
  • 해커가 보안 구멍을 찾아 악용할 수 있음
  • 경쟁사가 지식재산권을 훔칠 수 있음

“내 코드가 나쁘다”는 걱정

• 나쁜 코드에 대한 불안은 대부분 자존심의 문제에 가깝고, 누군가 시간을 들여 들여다본다면 그 안에서 추구할 만한 무언가를 찾았을 가능성이 있음
• Stone Soup 이야기처럼 좋은 아이디어를 커뮤니티와 공유하면, 다른 사람들이 이를 받아들이고 함께 개선할 수 있음
• 커뮤니티는 나쁜 코드를 리팩터링하거나 대체할 수 있고, 새 코드 품질 가이드라인을 도입해 이후 기여 절차도 더 좋아질 수 있음
• 코드에 불평만 하고 개선 제안을 하지 않는 독성 구성원은 애초에 원하는 커뮤니티 구성원이 아님
• 오픈 소스 기여자들은 오래된 프로젝트의 “무덤”을 갖고 있으며, 비슷한 것을 만들려는 사람들에게는 아이디어와 접근법의 라이브러리가 됨
  • 누군가는 특정 문제 해결 방식에서 영감을 얻을 수 있음
  • 최소한 같은 실수를 반복하는 시간을 줄일 수 있음
  • 오래된 프로젝트가 평판을 망칠 가능성보다, 유용하게 쓰이거나 아예 주목받지 않을 가능성이 큼

공개 코드와 보안

• 공개 코드로 호스팅 솔루션을 운영할 때 가장 큰 두려움은 악의적 행위자가 코드를 읽고 취약점을 찾아 서비스를 해킹하는 상황임
• Supabase 경험상 Linus's law의 “충분한 눈이 있으면 모든 버그는 얕다”는 말은 보안 문제에도 적용됨
• 초기부터 익명인 경우가 많은 보안 연구자들이 코드와 플랫폼을 살피며 잠재 문제를 찾는 데 도움을 줌
• SaaS를 제공한다면 /.well-known/security.txt에 간단한 안내를 제공해, 선의의 연구자들이 잠재 문제를 어떻게 공개해야 하는지 알 수 있게 해야 함
• 공개 프로젝트가 독점 코드베이스보다 더 안전할 수 있는 사례로 Bitcoin을 듦
  • Andreas M. Antonopoulos는 2015년 강연에서 폐쇄형 은행 시스템이 소프트웨어적으로 약한 면역체계를 갖는다고 말함
  • 폐쇄형 시스템에서는 큰 보안 구멍이 오랫동안 가려질 수 있고, 결국 악용될 때 큰 피해가 날 수 있음
  • Bitcoin 같은 오픈 소스 프로토콜에서는 보안 구멍이 모두에게 보이고, 익스플로잇이 일찍 자주 발견된 뒤 패치됨
• 성공적인 소프트웨어 회사는 10년 넘게 만들어질 수 있으므로, 장기적으로 오픈 소스 시스템은 비밀스러운 독점 시스템보다 더 안전한 상태에 가까워질 수 있음
• 뛰어난 보안 엔지니어 채용 경쟁이 매우 치열한 시기에는 공개 검토의 가치가 더 커짐

경쟁사와 지식재산권 우려

• 소프트웨어에서 아이디어는 싸고, 가치는 거의 항상 아이디어의 실행에서 만들어짐
• 아이디어를 세상과 공유하면 누가 코드베이스에 접근할지 걱정하는 대신 더 빠르게 반복하는 데 집중할 수 있음

• 전문가 커뮤니티 만들기

  • 성공적인 회사를 만들려면 긴 기간, 예를 들어 10년 동안 잘 실행하고 고객 기반을 키워야 함
  • 이 장거리 레이스에서 경쟁사가 코드베이스를 들여다보며 얻는 이점은 10년 전체로 보면 크지 않을 가능성이 높음
  • 그 기간 동안 코드베이스는 여러 번 반복되고 리팩터링될 가능성이 큼
  • 장기적으로는 자신의 솔루션을 세계에서 가장 잘 반복 개선하는 팀과 커뮤니티를 만드는 것이 승리 방식임

• 시장에서 이기기

  • 크고 성장하는 총주소시장(TAM)이 정말 추구할 가치가 있다면, 승자독식 상황일 가능성은 낮음
  • 먼저 감탄시킬 수 있는 사용자 세그먼트를 찾고 빠르게 반복해야 함
  • 경쟁사에 집중하는 시간은 제품이나 팀 개선에 쓰일 수 있는 시간임
  • 경쟁사가 오픈 소스 프로젝트를 포크해 더 빠르게 출시할 수 있다면, 그 경쟁에서는 어차피 질 운명이었다고 봄
  • 소프트웨어에서 IP와 특허는 집행하기 어렵기로 유명하므로, 변호사로 소프트웨어 아이디어를 보호하려는 걱정을 줄이면 시간·돈·정신적 에너지를 아낄 수 있음
  • 비즈니스는 소프트웨어 아이디어를 세계에서 가장 잘 구현하는 방식으로 더 잘 보호될 수 있음

• 후기 단계의 클라우드 경쟁

  • 프로젝트가 상당한 규모에 도달하면 Elastic이나 Mongo처럼 대형 클라우드 제공자가 더 강한 배포 모델로 제품을 제공하는 상황을 맞을 수 있음
  • 막 시작한 회사의 가장 큰 문제는 먼저 그 지점까지 가는 것임
  • AWS가 수십억 달러 규모 제품군 중 하나에서 리소스를 빼내 호스팅 제품으로 경쟁할 정도라면, 이미 매우 잘하고 있는 상태임
  • 더 건설적인 대응은 누구와도 경쟁에서 앞설 수 있는 영역을 미리 찾는 것임
  • 많은 클라우드 제공자는 개발자 경험(DX) 이 좋지 않은 경우가 많으므로, DX를 핵심 역량으로 삼을 수 있음
  • 6년 뒤 Google이 점심을 빼앗으려 한다면, 그전 몇 년 동안 브랜드·팀·커뮤니티가 David 대 Goliath식 싸움을 준비하고 있어야 함
  • 이런 상황에 기습당하지 않도록 처음부터 계획해야 하며, 시간과 집중력을 활용해 승리 전략을 만들 수 있음
  • 경쟁사가 아이디어를 찾으러 온다면 늘 한 발 뒤에 있고, 특히 초기처럼 리소스가 부족할 때는 경쟁 걱정에 더 많은 에너지를 쓰게 됨

개발자 채용에서의 효과

• 스타트업이 규모와 무관하게 겪는 큰 문제 중 하나는 개발자 채용의 어려움임
  • 소싱이 어려움
  • 개발자 평가가 어려움
  • 미래 동료의 수준을 설득하기 어려움
• 오픈 소스는 개발자 채용 문제를 줄이는 데 도움을 줄 수 있음

• 공개적인 소싱

  • 모든 개발자는 오픈 소스의 혜택을 받고, 많은 개발자는 흥미로운 오픈 소스 프로젝트에 기여해 그 혜택을 되돌리려 함
  • 기여 이유는 좋은 커뮤니티, 새 기술 학습, 낯선 코드베이스에서 어려운 기술 문제를 푸는 즐거움 등일 수 있음
  • 오픈 소스 프로젝트의 코드 기여 장벽을 낮추면 훌륭한 개발자가 프로젝트를 찾을 가능성이 있음
  • 기여자는 이슈 토론, 버그 수정, 문제 식별, PR 리뷰에 참여할 수 있음
  • 모든 기여자가 구직 중인 것은 아니지만, 많은 사람은 풀타임으로 오픈 소스 코드를 다룰 수 있다는 전망에 끌릴 수 있음
  • Supabase는 2년 넘게 운영하고 32명의 개발자를 채용한 뒤에야 아웃바운드 채용을 시작함
  • 오픈 소스는 Supabase의 주요 인재 발굴 경로였고 앞으로도 그럴 예정임
  • 원격·비동기 회사에서는 오픈 소스 채용 전략이 후보자의 역량을 스스로 드러내게 만들어, 해당 역량을 검증하기 쉬워짐

• LeetCode와 과제형 테스트를 대체하는 실제 기여

  • 개발자들이 다음 직장을 찾을 때 가장 크게 불만을 갖는 요소 중 하나는 인터뷰 과정에서 LeetCode 문제를 풀거나 과제형 테스트를 해야 하는 일임
  • 이런 방식은 시간이 많이 들고 힘들며, 실제 업무에서 하게 될 일을 대표하지 않는 경우가 많음
  • 누군가 저장소에 기여하면 이미 다음 자료가 생김
    • 원격·비동기 환경에서 팀과 커뮤니티 구성원과 어떻게 소통하는지에 대한 사례
    • 실제 코드 기여 사례
  • 후보자도 회사 쪽을 볼 수 있음
    • 팀이 코드 품질을 중시하는지 확인할 수 있음
    • 효과적으로 소통하는지 볼 수 있음
    • 좋은 기술 결정을 내리는지 판단할 수 있음
  • Supabase 저장소를 통해 채용된 사람들은 스스로 없어서는 안 될 존재가 되었고, 기존 저장소 개발을 이끌거나 새 클라이언트 라이브러리와 SDK를 시작한 경우도 있음
  • 이들은 Zoom에서 LeetCode 문제를 풀 필요가 없었음

소수 사용자 기능과 통합의 확장

• 스타트업을 만들 때는 가장 큰 문제만 해결할 시간이 있는 경우가 많음
• 빠르게 움직이려면 사용자 기반의 80% 가 요청하는 것에 집중해야 함 {p:80}
• 소수 사용자가 요청하는 기능은 무기한 뒤로 밀리기 쉬움
• 시스템이 오픈 소스라면 이런 사용자들이 직접 기능을 기여할 수 있어 소프트웨어의 유용성이 커짐
• 이런 효과는 통합과 어댑터에서 자주 나타남
  • 사용자가 Azure 또는 Vercel 통합을 원할 수 있음
  • 다른 누군가가 그 연결을 만들 개발 리소스를 제공하면 프로젝트 사용자 모두가 이익을 얻음

같은 바퀴를 반복해서 만들지 않기

• 오픈 소스가 없는 세계에서는 기술 회사들이 계속해서 바퀴를 다시 발명하게 됨
• Supabase는 새 프로젝트를 오픈 소스로 공개할 뿐 아니라, 새로 만들기 전에 기존 오픈 소스 프로젝트를 지원하려고 함
• 자동차 회사들이 독점 함수, 독점 UI 요소, 독점 윈도잉 라이브러리, 독점 운영체제, 독점 드라이버를 사용해 거의 보지 않을 오류 메시지를 표시하는 상황은 개발자 시간과 노력의 낭비임
• Supabase Launch Week는 팀과 커뮤니티가 지난 3개월 동안 작업한 결과의 집합이며, 오픈 소스 회사 운영의 장점은 커뮤니티의 진행 속도에서 드러남
• 자세한 내용은 Launch Week 4 post에서 확인할 수 있고, 참여하려면 Supabase GitHub를 방문할 수 있음

[GN⁺]

Hacker News 의견들

• 여기에는 지속 가능한 수익성에 대한 큰 가정이 숨어 있고, 특히 미국 개발자 급여 같은 현실을 감안하면 실제 체감과 어긋나는 부분이 있음
  요약하면 오픈소스 회사는 번개가 두 번 맞아야 함. 한 번은 오픈소스 프로젝트에, 또 한 번은 회사에 맞아야 함
  Graphistry 팀은 매일 오픈소스를 좋아하고 다루며, Apache Arrow와 Nvidia RAPIDS로 이어진 프로젝트의 시작을 도왔고 Python/JS 클라이언트도 오픈소스로 공개했음. PyGraphistry[AI]는 그래프용 스위스 군용 칼 같은 도구이고, GFQL처럼 Cypher 그래프 질의 언어를 임베드 가능하고 데이터프레임 네이티브이며 GPU 가속까지 되는 형태로 구현한 도구도 포함
  하지만 지속 가능한 성장은 주로 기업, 정부, 데이터 회사에 GPU 그래프 시각화 서버의 클라우드/온프레미스 자체 호스팅 라이선스를 판매하면서 나옴. 몇 년간 버틴 끝에 다행히 이 사업은 잘 성장 중이고, SaaS 호스팅 매출만으로도 작은 팀은 유지되지만 팀 대부분은 감당하지 못함. 자체 호스팅 라이선스 매출이 없으면 혁신 주기의 대부분이 사라질 것임
  이 글은 복권 당첨 같은 운, SaaS 시장 특성, 기술적 방어력의 교차점을 놓치고 있는 느낌임. Louie.AI와 GFQL 출시가 우리 경우에는 오픈소스의 사업 가능성을 바꾸고 있어서 불가능하다는 뜻은 아니지만, 여기까지 온 경험을 보면 이 글을 읽는 신규 창업자들이 걱정됨

  • “our GPU graph viz server”라는 표현에서 헷갈렸음. GPU에서 graphviz[1]를 어떻게 확장하고, graphviz 호스팅으로 어떻게 돈을 버는지 이해가 안 됐는데, 웹사이트를 빠르게 보고 나니 정리됐음
    [1] https://graphviz.org/
  • 온프레미스 솔루션을 사는 회사들은 소스 코드를 사는 건지, 지원을 사는 건지 궁금함
    즉 “이제 소스를 공개합니다”라고 말하면 “좋네요, 그럼 계약 취소할게요”라고 할 고객들인지가 핵심임

• “오픈소스 비즈니스 모델을 다른 창업자들과 이야기하면 반복해서 나오는 걱정이 세 가지 있다: 지저분하거나 나쁘거나 미완성인 코드를 비판받을 수 있음, 해커가 보안 구멍을 찾아 악용할 수 있음, 경쟁사가 지식재산을 훔칠 수 있음”이라고 했는데, 네 번째가 빠졌다고 봄
  Amazon/AWS가 내 코드를 기반으로 서비스를 상용화해서 팔고 아무것도 지불하지 않을 수 있다는 점임

  • 20년 동안 오픈소스 프로젝트를 만들고 유지해온 입장에서, “사람들이 내 지저분한 코드에 뭐라 할까 봐”라는 걱정은 좀 웃김
    사용자와 피드백을 주고받을 때는 예의를 지키지만, 속으로는 “말은 쉽지. 나는 실제로 만들었어. 조용히 하거나 PR을 보내”라고 생각함. 놀랍지 않게도 그런 사람들은 거의 절대 PR을 보내지 않음
    계속 실제로 만드는 일을 하고, 비난하는 사람들은 털어내면 됨
    [0] - https://heywillow.io/
  • 그 부분은 뒤쪽의 “후기 단계” 문단에서 다뤄짐
    큰 회사들이 따라 하려 한다면 이미 이기고 있는 셈이고, 이를 완화하기 위한 사전 계획은 필요함. 다만 글을 제대로 해석했다면, 시작 단계에서 집중하거나 걱정할 문제는 아니라는 뜻으로 보임
  • 가장 큰 건 따로 있음: 제품을 공짜로 배포하면서 돈을 벌기는 정말 어렵다는 점임
  • GPL이나 AGPL처럼 더 나은 라이선스를 고르면 됨
    클라우드 회사들이 다른 오픈소스 제품을 집어삼키는 건, 그 제품들이 자기 작업물을 제대로 보호하는 라이선스를 고르지 못했기 때문임

• 정말 깊이 있는 좋은 글이지만, 많은 프로젝트가 놓치는 한 가지가 있음: 민간 정부 부문에 팔면 됨
  미국 정부에는 NSF 보조금 같은 기술 프로그램이 많고, 민간 기관·정보기관·주 정부가 서로 분절돼 있어서 결국 엄청나게 넓은 소프트웨어 조달 지형이 생김. 규제와 컴플라이언스 진입 장벽도 생각만큼 높지 않고, 특히 첫 몇 건을 협력사와 함께 따면 더 그렇다. 보통 3~5년 약정으로 프로젝트에 자금을 댈 수 있는 안정적이고 보장된 매출이며, 수익성도 대단히 높음
  더 많은 오픈소스 회사가 이걸 활용했으면 함. 완전 민간 기업들이 오픈소스 라이브러리를 자기 제품에 넣고 거대한 마진을 붙여 팔면서 전부 가져가는 경우가 많기 때문임
  예: https://x.com/ssankar/status/1749202248700420587?s=20
  정부에 있을 때, 사실상 오픈소스 지도 + 오픈소스 DB 조합인데 1,200만 달러짜리인 소프트웨어를 많이 봤음. 다른 기준으로는 PDF OCR에 연 200만 달러, weights & biases 같은 도구에 연 3,000만 달러가 붙는 것도 봤음
  소프트웨어 배포 외에도 유인이 있음. 예를 들어 특정 버그나 보안 결함을 우선 수정하는 일임. 정보기관은 safetensors에 큰돈을 냈을 가능성이 큼
  Supabase가 할 수 있는 네 가지 경로는 Cybercom 직접 판매, DOS 직접 또는 팀 계약, VA에 PWS를 통한 판매, 대형 정부 계약 소프트웨어 업체에 직접 판매임
  실행 방법은 GS 14/15 또는 동급에게 콜드 이메일을 보내거나, 전직 GS15를 고용하거나, SAM.gov에서 맞는 입찰을 찾은 뒤 GovPro.ai는 풀서비스로, rogue는 직접 처리 방식으로 제안서를 만드는 것임

  • 정부와 스타트업은 보통 잘 맞지 않는다고 봄
    정부 관료조직이 계약을 최종 승인할 때쯤이면, 대부분의 스타트업은 이미 돈이 떨어졌을 가능성이 큼
  • 정부 연구 계약을 막 시작했는데, 이와 조금이라도 비슷하다면 조심해야 함
    계약은 수익성이 좋을 수 있지만, 관료 절차가 엄청나고 이를 다룬 경험이 있는 사람이 필요함. 모두에게 맞는 길은 아니고 시간과 협상도 많이 들어감
  • 정부가 간과된 시장이라는 데는 동의하지만, 연방정부부터 시작하진 않겠음
    거대한 관료제는 차치하고도, 연방정부는 가장 크고 느리며 다루기 어려운 정부 조직임. 미국 안에만 학교, 도시, 카운티, 주, 수도·소방 지구, 도서관 등 수만 개의 다른 정부 주체가 있음
    공공 부문에 들어가고 싶다면, 가장 큰 곳에 올인하지 말고 작고 넓게 접근하는 편이 나음
  • 좋다면 좋은 길이지만, 아닐 이유도 많음
    전 세계에서 가장 수익성 높은 정부 부문은 미국 국방부임.
    그런데 국방부는 믿을 수 없을 만큼 관료적이고 일정에 민감하며, 비밀에 집착함

• Supabase의 비즈니스 모델은 스스로를 오픈소스 회사로 마케팅하는 것이지만, 실제로는 제정신이라면 아무도 프로덕션용으로 직접 호스팅하려 하지 않을 것임
  미묘하게 빠진 문서, 미묘한 버그, 미묘하게 빠진 중요한 기능 같은 것들 때문임. 그래서 오픈소스라는 칭찬은 받지만 실제로는 실용적이지 않고, 그냥 마케팅 수단이라고 봄

  • Supabase 같은 제품이 오픈소스인 데는 실제 장점이 있음
    첫째는 마음의 여유임. 지금 직접 호스팅하지 않더라도 서비스가 마음에 들지 않을 때 빠져나갈 길이 하나 더 생김. 물론 원시 데이터 접근도 제공해야 함
    둘째는 코드 품질임. 겉보기엔 잘 작동하지만 정말 나쁜 코드를 다뤄본 적이 있다면, 공개해도 부끄럽지 않은 코드를 갖는 게 얼마나 중요한지 알 것임
    셋째는 기여 가능성임. 예전에는 별것 아니라고 봤지만, 실제로 여러 번 겪어보니 기능 누락, 버그, 성능 문제 등이 있을 때 요청하거나 직접 기여할 수 있다는 게 큼. 대부분의 폐쇄형 소스 프로젝트에서는 기능 요청을 투명하게 할 채널만 있어도 운이 좋은 편임
  • 상용 버전만 쓰더라도 오픈소스 제품의 장점은 회사가 얼마나 “악해질” 수 있는지에 상한선을 둔다는 점임
    어느 임계점을 넘으면 사람들이 포크에 노력을 들이기로 할 수 있음. MariaDB가 그런 예임
    우리 회사의 관리형 서비스를 쓰는 이유로 바로 그 점 때문에 안심된다고 직접 말한 사람들도 있었음
  • Supabase가 일부러 오픈소스 커뮤니티에 결함 있는 별도 소프트웨어를 내놓아서, 상용 서비스가 더 안정적인 선택이라고 설득하려 한다는 뜻이 아니라면, 왜 어떤 회사가 그렇게까지 할지 모르겠음
    합법적이고 진짜인 오픈소스 회사가 되는 편이 훨씬 쉬워 보임
    그런 뜻이 아니고 내가 잘못 읽은 것이라면, 나머지 내용은 오히려 Supabase를 매우 긍정적으로 보이게 함
  • 이 부분은 동의함. “제대로 된” 오픈소스 소프트웨어라면 배포판 패키지 관리자로 설치할 수 있고, 특정 사용 목적을 향해 어느 정도 의견이 들어갔더라도 최소한의 주의를 기울인 작동 가능한 기본값이 있어야 함
    상업적으로는 가능하지 않을 수도 있지만, 지금 상태는 오픈소스 소프트웨어에 기대할 수 있는 기준을 강하게 갉아먹고 있으며, 그런 방식을 택한 회사들에도 뚜렷한 장기 이득이 없어 보임
  • 오픈소스는 직접 호스팅만의 문제가 아님
    개발자가 직접 실행하지 않더라도, 실제로 돌아가는 코드를 볼 수 있게 해줌

• Supabase도 좋고, 상업적 오픈소스 전반도 좋아하며, 글의 많은 부분에 동의함
  하지만 “소프트웨어에서 아이디어는 싸다. 가치는 거의 항상 아이디어 실행에서 만들어진다”는 부분은 어색하게 느껴짐
  이 표현은 “멋진 스타트업 아이디어가 있는데 말하기 전에 NDA에 서명해줄래?” 같은 상황에서 들어봤음
  그런데 소프트웨어를 오픈소스로 공개한다면 단순히 아이디어를 제공하는 게 아니라, 그 아이디어의 상당한 실행 결과도 제공하는 것임
  물론 코드가 실행의 전부는 아니고, 영업·마케팅·지원 등으로 확장됨. 그래도 이 글은 코드의 가치를 너무 가볍게 보고, 영업·마케팅 등이 없으면 무가치하다고 암시하는데, 그건 사실이 아니라고 봄

  • 코드는 무가치하진 않지만, 영업·마케팅·고객 대화가 없으면 거의 무가치에 가까움
    가치를 나누자면 영업/마케팅/고객 검증 90%, 코드 10% 정도로 봄. 7자리 초반 매출의 부트스트랩 SaaS를 운영하고 있는데, 코드는 대체로 엉망이고 계속 진화한다는 걸 말할 수 있음
  • 코드는 일단 만들어지고 나면 무가치하다고 봄. 복사 비용이 0이기 때문임
    집은 공짜로 복사할 수 없지만, 소프트웨어는 가능함
    개발자가 돈을 받는 대상은 코드를 만드는 과정과, 보이지 않는 자잘한 문제들을 해결하는 일임
    그래서 소프트웨어 판매가 그렇게 수익성이 높음. 소프트웨어를 팔지 않으면 그것으로 돈을 벌 수 없음. 소프트웨어는 우리가 공유하는 현실의 물리적 물건과 같지 않음

• 내게 핵심 질문은 코드가 충분히 좋은지, 경쟁사가 베낄지보다 지속 가능한 사업을 만들 만큼 돈을 벌 수 있느냐임
  인용되고 사랑받는 오픈소스 프로젝트들은 좋은 사업이 아님: PostgreSQL, Python, Bitcoin, React
  Mongo와 Elastic은 훌륭하지만 예외임. 성공한 폐쇄형 소스 데이터베이스 회사가 오픈소스 데이터베이스 회사보다 더 많음
  오픈소스 회사는 어렵다. 하지만 사용자에게는 매우 가치 있음

  • Mongo와 Elastic은 “서버 측 공중 라이선스”인 SSPL로 라이선스를 바꿨고, 이는 AGPL의 자체 변형에 가까움. OSI는 이것이 오픈소스 라이선스가 아니라고 밝힘 [1]
    어떤 라이선스가 “오픈소스”인지 논쟁을 제쳐두면, 중요한 건 이 회사들이 널리 쓰이는 (A)GPL, Apache, MIT 같은 라이선스가 경쟁사에게 관리형/호스팅 서비스를 만들고 규모로 경쟁할 여지를 많이 남긴다고 판단했다는 점임. 예를 들어 Amazon의 OpenSearch가 ElasticSearch를 더 싸게 제공한 경우임
    [1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

• 이 질문은 “우리 회사가 소프트웨어의 소스를 공개해야 하는가?”라는 뜻으로 쓰인 것 같음
  하지만 내게는 원래 질문에 답하는 것이, 바꿔 쓴 질문에 답하는 길을 제공함. 원래 질문은 회사가 파는 소프트웨어가 아니라 사용하는 소프트웨어의 성격에 관한 것임
  개인적으로는 대안이 있다면 항상 오픈소스 제품을 고를 것임. 지원 비용을 기꺼이 내거나 프로젝트에 기부하더라도 그렇다. 소스를 자유롭게 볼 수 있는 접근권은, 내가 절대 수정할 생각이 없는 소프트웨어에서도 근본적으로 중요함
  많은 사람에게는 극단적인 입장처럼 보인다는 걸 앎. 하지만 전자레인지, 문손잡이, 변속기를 분해할 수 없다는 생각이 싫음. 다시 제대로 조립하지 못할 수도 있지만, 이가 빠진 기어를 찾아 90달러 교체 대신 2달러 수리를 할 수도 있음. 아니면 변속기가 달린 프랑켄슈타인 전자레인지를 만들 수도 있음
  웹 서버 기능을 확장하거나 내 플러그인이 호스트 앱을 왜 크래시시키는지 이해하는 일은 내게 중요함. 사회에도 중요하다고 봄. 그래서 내 오픈소스 극단주의를 붙잡고 있음. 내장 AI로 5KB 안에 HTTPS/4를 처리하는 최신 초소형 웹 서버를 보여줘도 흥미는 생기겠지만, 오픈소스가 아니라면 기존 스택을 계속 쓸 것임
  이런 마음가짐 때문에 내가 만드는 소프트웨어는 오픈소스이고, 때로는 사람들이 그 대가를 지불함

• “6년 뒤 Google이 점심을 훔치려 한다면, 지난 몇 년간 다윗 대 골리앗 싸움을 준비해온 브랜드, 팀, 커뮤니티가 있어야 한다”는 부분에 대해, 내 경험상 조달 담당자에게는 브랜드·커뮤니티·팀·개발자 경험 같은 것들이 컴플라이언스에 비하면 거의 의미가 없음
  Google 같은 기존 공급사와 정면으로 붙는다면 특히 그렇다

  • 좋은 포인트임. 글에 추가해야 할 것 같음
    Supabase의 경우 실제로 지난 몇 년간 이런 요구를 맞추기 위해 SOC2, HIPAA, GDPR 같은 컴플라이언스를 준비해왔기 때문에 정확한 지적임

• 우리 제품도 이 문제를 고민해왔음. 언젠가는 전부 MIT나 Apache 중 그때 마음에 드는 라이선스로 오픈소스화할 예정이고, 이 점은 사이트에도 공개해두었음. AGPL이나 오픈 코어 같은 방식은 아님
  하지만 그런 구조로 제품에서 돈을 버는 건 완전히 불가능하다고 느꼈고, 이전 경험에서도 그랬음. 컨설팅은 가능하겠지만 제품은 다름. Supabase는 막대한 벤처 투자를 받았고, 거의 모든 “큰” 오픈소스 프로젝트도 마찬가지임
  부트스트랩이라면, 특히 야심차고 어려운 프로젝트에서는 한동안 청구서를 낼 수 없음. 사람은 공짜로 일할 수 있는 기간이 제한돼 있고, 비공개 코드에 작은 팀이 계속 밀접하게 소통하면 성공적인 오픈소스 프로젝트에 필요한 오버헤드를 줄이며 훨씬 빨리 움직일 수 있음
  비슷한 규모인데 투자금 0달러, 최근 5년 안에 시작, 풀타임 팀원이 2명 이상, 3년 이상 지속했고, 여전히 이 접근을 추천하는 프로젝트 사례를 듣고 싶음. 어떻게 생계를 맞추고 있는지 궁금함. Redis 같은 일은 이제 더 이상 일어나지 않는다고 봄. 적어도 본 적은 없음. 심지어 langchain 같은 단순한 프로젝트도 수천만 달러의 벤처 투자를 받는데, 그런 프로젝트야말로 몇 명짜리 팀이 여러 수익원으로 돈을 벌며 해볼 수 있는 후보라고 생각했을 정도임

  • 모든 코드를 자유 소프트웨어 라이선스로 공개하면서도 “성공적인 오픈소스 프로젝트”나 그에 따르는 오버헤드를 목표로 하지 않을 수 있음
    내 소프트웨어는 전부 퍼블릭 도메인, 즉 자유 소프트웨어로 공개하지만, 그중 성공적인 오픈소스 프로젝트나 커뮤니티가 된 것은 없음. 자유 소프트웨어는 무엇보다 먼저 이념이고, 그다음이 실천이나 기능임
  • Sourcehut은 AGPL이고 Redis만큼 많이 쓰이지는 않을 수 있지만, 직원 2명 이상을 고용해왔고 2022년 마지막 보고 기준으로 수익도 났으며 3년 이상 지속됐음

• 회사를 오픈소스화하는 건 개발자를 대상으로 하거나, 현실적으로 아무도 직접 호스팅하지 않을 제품을 만드는 경우가 아니라면 말이 안 된다고 봄
  Supabase는 이 둘 모두의 대표 사례임. 후자의 예로는 Plausible Analytics가 있는데, 직접 호스팅할 수는 있음. 나도 Coolify.io로 그렇게 하고 있음. 하지만 릴리스에서 업데이트를 가져와 병합하는 자체 CI/CD 시스템을 만들지 않으면 업데이트를 놓치게 됨