오픈 소스는 가격이 저렴함으로써 이기지 않는다

• 상용 오픈소스 회사는 기존 유료 제품에 MIT 라이선스를 붙인 대체재만으로 오래 버티기 어렵고, 오픈소스여야 하는 이유나 더 뛰어난 제품력이 필요함
• 비영리·후원 기반 프로젝트와 달리 오픈소스 비즈니스는 수익이 있어야 채용, 성장, 지속 개발을 이어갈 수 있음
• 초기 기업은 무료 티어나 오픈소스 버전을 고르기 쉽고, 대기업은 SaaS 비용을 예산 항목으로 처리하므로 저렴함만으로 구매 결정을 뒤집기 어려움
• 오픈소스가 강해지는 지점은 폐쇄형 소스가 고객 신뢰를 흔드는 투명성 문제와, 많은 연동·플러그인이 필요한 확장성 문제가 있을 때임
• PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte, Elastic 사례는 오픈소스가 감사 가능성, 자체 호스팅, 커뮤니티 기여를 통해 더 나은 제품으로 발전할 수 있음을 보여줌

---

오픈소스 대체재만으로는 부족함

• “Stripe Billing의 오픈소스 버전”, “Chargebee의 오픈소스 버전” 같은 설명은 제품을 빠르게 이해시키는 데는 유용하지만, 사업을 지속시키는 근거로는 약함
• 상용 오픈소스 도구는 이미 성공한 유료 제품의 오픈소스 대안이라는 포지션에만 의존하기 어려움
• 개발자가 제품을 모방하고 MIT 라이선스를 붙이는 것만으로는 충분하지 않으며, 오픈소스 자체도 성공을 보장하지 않음
• 논의 대상은 인기 있는 유료 솔루션과 경쟁하는 상용 오픈소스 프로젝트임
  • React, TypeORM, VSCode처럼 커뮤니티 중심이거나 후원을 받는 제품은 우선순위가 다름
  • React는 Meta 같은 더 큰 조직의 지원을 받고, TypeORM은 기부로 개발 자금을 마련함
  • 이런 프로젝트들은 본질적으로 사업체가 아님
• 오픈소스 회사가 성공하려면 오픈소스여야 하는 명확한 이유가 있거나, 경쟁자를 능가해야 함

성공 기준은 사용량이 아니라 수익

• 기부나 모회사 후원을 받는 비영리 프로젝트를 제외하면, 일반적인 오픈소스 비즈니스의 최종 기준은 수익임
• 영리 기업은 수익을 통해 직원 채용, 성장, 지속 가능성, 지속 개발의 재원을 마련함
• 무료 소프트웨어를 만들면서도 수익을 내는 기업은 긍정적인 사례이며, 오픈소스 회사도 고객을 과도하게 착취하려는 것이 아니라 사업을 계속하려는 것임
• MongoDB는 4,600명 이상의 직원을 둔 대형 데이터베이스 기업으로 성장함
  • 이후 Cloud Provider가 프로젝트에 기여하지 않고 서비스를 배포하는 것을 제한하기 위해 SSPL 라이선스로 전환함
  • SSPL은 OSI 승인을 받지 않았지만, 실질적으로는 오픈소스에 가깝다고 표현됨
• 장기 성공을 측정할 때는 채택률과 매출을 구분해야 함
  • 프로젝트 채택률이 높아도 매출을 만들지 못하면 사라질 수 있음
  • 커뮤니티가 프로젝트를 이어받을 것이라는 기대에는 이를 뒷받침하는 증거가 거의 없다고 봄

저렴함은 지속 가능한 승부처가 아님

• 가격에 민감한 고객만 겨냥하는 전략은 지는 싸움에 가까움
• Amplitude의 오픈소스 버전을 만든다는 가상의 사례에서는 Amplitude가 비싸고, 초기 기업에는 부담되며, 대기업도 비용을 아낄 수 있다는 논리가 가능함
• 그러나 초기 기업은 가격에 민감하기 때문에 오픈소스 버전이나 무료 티어를 선택할 가능성이 높고, 이는 사업을 지탱하기에 충분하지 않음
• 더 저렴한 대안을 만드는 전략은 보통 미래의 파산으로 이어지는 티켓에 가까움
• 대기업도 일반적으로 Amplitude 비용 때문에 회사가 망할까 걱정하지 않음
  • 계약 협상에서는 예산 안에서 가격을 따질 수 있음
  • 하지만 대부분의 SaaS는 결국 비용 항목 중 하나임
  • 더 중요한 조건은 좋은 솔루션인지, 장기적으로 지속될지, 관리가 쉬운지임
  • 오픈소스 솔루션 배포는 관리가 까다로울 수 있음
• 예외는 솔루션 비용이 전체 예산에서 매우 큰 비중을 차지할 때임
  • 데이터베이스 사용량 때문에 Oracle 비용이 급증해 Oracle을 줄여야 했던 회사들이 여기에 해당함
  • 그러나 대부분의 오픈소스 솔루션은 상위 3개 비용 항목을 대체하지 않으므로 가격이 최우선 결정 기준이 되기 어려움

오픈소스가 이기는 첫 번째 방식: 투명성

• 오픈소스 솔루션이 강력해지는 대표적 경우는 폐쇄형 소스가 고객과 벤더 사이에 불신을 만드는 투명성 문제가 있을 때임
• Amplitude의 오픈소스 대안으로는 PostHog가 있음
  • PostHog는 Airbus, DHL, Staples를 고객으로 두고 성장함
  • 여러 제품 SaaS 솔루션을 결합하며 오픈소스로 제공됨
  • 블로그 소스 코드와 roadmap까지 공개되어 있음
• PostHog는 분석 도구가 IP 주소, 이름, 세션 녹화 같은 민감한 고객 데이터를 처리한다는 점에서 경쟁 제품보다 나은 제품으로 자리 잡음
• GDPR, CCPA 같은 데이터 규제가 늘어나는 환경에서는 제3자가 이런 데이터를 저장하는 일이 부담스러울 수 있음
• PostHog는 두 가지 선택지를 제공함
  • 분석 솔루션을 직접 자체 호스팅함
  • PostHog를 제3자로 고용하되, 데이터 저장 방식과 향후 자체 호스팅으로 이전할 수 있는 방식에 대한 투명성을 확보함
• 가장 프라이버시 친화적인 방법이 자체 호스팅이라고 해도, 많은 회사는 여전히 호스팅 모델을 선택할 수 있음
  • 이 경우에도 소프트웨어가 줄 단위로 어떻게 동작하는지 볼 수 있음
  • 필요할 때 자체 호스팅 모델로 이전하는 절차를 알 수 있음
• 오픈소스 회사는 제3자의 필요성을 없애서 이기는 것이 아니라, 동작 방식을 공개 감사할 수 있게 해 신뢰를 얻음

투명성이 중요한 제품 사례

• Medplum은 폐쇄형 기존 업체와 경쟁하는 오픈소스 전자건강기록 플랫폼임
  • 오픈소스이기 때문에 플랫폼이 정확히 무엇을 지원하고 무엇을 지원하지 않는지 사용자가 확인할 수 있음
• SuperTokens는 Auth0 같은 인증 솔루션의 오픈소스 대안임
  • 로그인은 이름, 이메일, 비밀번호 같은 민감한 데이터를 다룸
  • 오픈소스라는 점이 더 많은 신뢰를 얻는 데 도움이 됨
• TableFlow는 Flatfile 같은 CSV 가져오기 플랫폼의 오픈소스 대안임
  • 가져오는 데이터가 민감하다는 점이 중요함
• Minio는 AWS S3 스토리지의 오픈소스 대안임
  • S3에는 스크린샷이나 구조화된 JSON 파일을 통해 고객 PII가 저장될 수 있음
  • 사용자 데이터에 누가 접근할 수 있는지 신경 쓰는 회사에 Minio가 대안이 될 수 있음
  • AWS는 AWS 직원이 고객 데이터에 직접 접근하지 않는다고 주장하지만, 폐쇄형 소스에서는 그 주장이 신뢰의 문제로 남음
• Lago 역시 청구와 제품 사용량 정보를 다루며, 이 정보는 민감한 콘텐츠에 가까워 오픈소스를 통해 사용자 신뢰를 더 잘 만들 수 있다고 봄

오픈소스가 이기는 두 번째 방식: 확장성

• 오픈소스의 큰 장점 중 하나는 틈새 기능 개발을 커뮤니티에 열어둔다는 점임
• 핵심 제품은 보통 중앙 엔지니어링 팀이 유지하지만, 연동이나 플러그인은 커뮤니티 개발자가 만들고 때때로 메인 브랜치에 병합됨
• 폐쇄형 솔루션은 자체 엔지니어링 팀에 의존해야 하므로 같은 방식으로 확장하기 어려움
• 많은 라이브러리, 프레임워크, 애플리케이션과 연결해야 하는 시스템을 만드는 오픈소스 회사에는 이 점이 특히 유리함
• Airbyte는 오픈소스 ELT 플랫폼으로, 커뮤니티가 추가한 커넥터 덕분에 크게 성장함
• Elastic도 원래 오픈소스였던 더 큰 회사로, 다수의 데이터 연동을 제공함
• SuperTokens는 확장성을 핵심 가치 제안으로 삼았고, 커뮤니티 구성원이 흔하지 않은 인증 제공자와의 연동을 만들 수 있어 모두에게 이익이 됨

오픈소스가 이기는 세 번째 방식: 더 나은 제품

• 투명성과 확장성은 상용 오픈소스가 장기적으로 더 나은 제품이 되는 데 기여함
• 오픈소스 프로젝트는 커뮤니티의 피드백과 도움을 활용해 폐쇄형 솔루션보다 더 빠르게 발전할 수 있음
• PostHog는 Amplitude와 FullStory의 대안으로 시작했지만, 이후 LaunchDarkly와 Pendo와도 경쟁하는 큰 포괄적 솔루션으로 성장함
  • PostHog는 1,500만 달러 규모의 Series B 투자를 유치함
  • 이 성장은 지난 몇 년 동안 일어났고, PostHog는 커뮤니티를 핵심 이유 중 하나로 봄
• 오픈소스 프로젝트는 상용 오픈소스에 한정되지 않고 수십 년 동안 제품 개선의 중요한 동력 역할을 해왔음
• 일부 소프트웨어는 선점 효과의 특성상 폐쇄형으로 남을 수 있음
• 하지만 투명성과 확장성이 문제가 되는 영역에서는 오픈소스 후발 주자가 실제 위협이 될 수 있음

[guarder]

검색하다가 우연히 발견했는데, 영어를 직역한 이런 번역(저렴함으로써)은 언제쯤 AI가 바로 잡을지 궁금해지네요.

[savvykang]

오늘(2026-01-12) 클로드 4.5 소넷 실행 결과입니다

---

"오픈 소스는 더 저렴하다는 이유로 승리하지 않는다"

프롬프트

"Open Source does not win by being cheaper" 한국어로 번역  

---

오픈 소스는 단순히 가격이 싸다는 이유로 승리하는 것이 아니다.
오픈 소스의 성공 요인은 저렴한 비용이 아니라 다른 곳에 있다.
오픈 소스가 우위를 점하는 것은 낮은 가격 때문이 아니다.

오픈 소스는 가격이 저렴함으로써 이기지 않는다  
  
Paraphrase  

[GN⁺]

Hacker News 의견들

• 여기서 수익(profit) 이라는 말은 이상하고 모호함
  24년 가까이 오픈소스·자유 소프트웨어 프로젝트를 운영했고, 그중 17년 정도는 매출도 냈지만 “수익”은 없었고 매출(revenue) 만 있었음
  보통 회사나 회계사가 보듯이 수익은 프로젝트에 참여한 사람들의 보수와 비용을 뺀 뒤 남는 돈이라고 봄
  이런 의미의 수익이 필요한 오픈소스 프로젝트는 투자자가 “수익률”을 기대하는 자본 투자를 받은 경우뿐이고, 그런 프로젝트도 있지만 대다수는 아님
  또 HN에 올라오는 글답게 전체적으로 웹·SaaS 쪽에 너무 치우쳐 있음. 믿기 어렵겠지만 오픈소스 프로젝트에는 다른 종류도 있음

  • 이 글은 수많은 오픈소스 프로젝트 전반이 아니라, 오픈소스를 기반으로 한 사업을 말하는 것임
    그 맥락에서는 매출을 받고 비용을 낸 뒤 남는 것이 수익이고, 그 비용에는 고정 급여, 고용 계약, 급여명세서 같은 것들이 포함됨
    사업이 수익을 어떻게 쓰는지는 다양함. 현금 보유고로 쌓아 매출이 낮은 달에도 비용을 낼 수 있고, 새 하드웨어 같은 자산을 살 수도 있으며, 추가 채용을 가능하게 할 수도 있음. 생각보다 흔하진 않지만 소유주에게 배당으로 지급할 수도 있음
    당신의 상황은 세부 정보가 많지 않아 추정할 수밖에 없지만, 혼자 운영하고 프로젝트가 작아서 직원을 늘릴 필요나 의지가 없다면 매출은 사실상 개인 소득에 가까움. 어떤 달은 더 받고 어떤 달은 덜 받는 구조라, 이 맥락에서는 “수익”이 아니라 매출이라고 보는 게 맞음
    특히 다른 간접비가 거의 없고 세무 목적 비용 추적도 큰 의미가 없는 소프트웨어라면 더 그렇고, 장부 자체를 제대로 두지 않을 수도 있음. 그런 상황이라면 글이 공감 안 되는 이유를 이해함. 글은 꽤 다른 상황을 다루고 있음
  • HN에서, 그것도 사업을 운영한다고 하는 사람이 profit이라는 단어에 겁먹은 따옴표를 붙이고 모호한 것처럼 말하는 게 좀 웃김
  • 벤처캐피털이 없어도 법인 형태로 운영하거나 성장·수익 중심 사고를 가질 수 있음
    순수 투자자가 지속적인 수익률을 요구하지 않으면 압박이 크게 줄고, 프로젝트에 맞는 일을 하기 쉬워짐
    하지만 야심적인 회사들과 경쟁하는 제품 영역에서는 성장도 필요하고 합리적일 가능성이 큼
    불황, 기회, 큰 지출에 대비해 수익을 남기는 건 단순히 합리적인 정도가 아님. 참여하는 사람과 고객이 많아질수록 들어오는 매출을 전부 태워버리지 말아야 할 이유가 커짐
  • 스스로에게 보수를 지급한다면 결국 수익에 의존하는 것임. 장부상으로는 수익이 0이 되지만, 실제로는 수익을 배당에 쓰는 것과 다르지 않음
  • 수익은 회계 용어라서 모호함. 정말 명확히 하려면 예를 들어 “과세 수익”이나 “투자자 관점 수익”처럼 한정하는 게 유용함
    실제로 큰 회사에서는 이 둘이 서로 무관한 숫자인 경우가 많고, 각각은 누구에게 전달하는지와 그 전달에 적용되는 규칙에 따라 정의됨
    “경영 수익” 같은 것도 있을 수 있는데, 표준화·규제되지 않은 지표를 통칭하는 말임. 예를 들어 어떤 사업이 세무와 투자자 보고 목적에서는 현금주의 회계를 벗어났더라도, 기존 경영진에게는 예전 방식의 수익 정의를 계속 추적하는 게 유용할 수 있음. 습관 때문일 수도 있고, 현금 흐름을 잘 보여주거나 다른 방식으로 유용하기 때문일 수도 있음
    이런 건 포스트모던한 문제 중 하나임. SEC, IRS, 은행 담당자는 “SEC 수익” 같은 표현을 받아들이지 않고 “진짜” 수익을 요구함. 병원이 시공사에게 “진짜로” 얼마 들었는지 순진하게 따지는 지역 정치인 같은 모습임
    어쨌든 글쓴이도 SEC나 IRS처럼 자기 관점의 용어를 쓰고 있음. “오픈소스는 더 싸서 이기는 게 아니다”라고 할 때의 “오픈소스”는 MongoDB 같은 모델의 오픈소스 사업을 가리킴. 그래서 투자자, 성장 목표 같은 것이 전제되어 있음
    글에서도 이 점을 스스로 명확히 했으니, 의미론적 으르렁거림으로 갈 필요는 별로 없음

• 이 사업 모델의 문제는 OSS 버전과 유료 버전 사이의 긴장을 만든다는 것임
  OSS 버전이 좋기를 바라지만, 아무도 SaaS나 컨설팅 등에 돈을 낼 필요를 못 느낄 정도로 좋으면 안 됨
  그 긴장은 결국 명백히 필요한 기능이 빠지거나, 규모 있게 운영하는 데 필요한 기능·지식이 후원 기업의 수익화를 위해 폐쇄 소스로 숨겨지는 쪽으로 이어지는 듯함
  제품이 인프라 성격이면 Elastic, Hashicorp처럼 대형 클라우드 사업자가 원클릭 서비스로 잡아먹지 못하게 보기만 가능하고 건드릴 수 없는 라이선스로 바꾸는 패턴도 이미 자리 잡음
  글이 틀렸다는 뜻은 아니지만, 상업적으로 후원받는 OSS가 모두에게 좋은 kumbaya식 윈윈인 척하지 않았으면 함. 실제로는 스타트업이 신뢰를 키우는 성장 해킹으로 쓰다가, 매출을 내야 하는 시점이 오면 성장을 도와준 커뮤니티를 어떤 식으로든 조이게 되는 구조에 가까움

  • “후원 주체가 돈을 벌기 위해 명백한 기능이나 규모 운영에 필요한 기능·지식을 폐쇄 소스로 숨긴다”는 부분은 전혀 문제라고 보지 않음
    작은 모듈을 유지보수하면서 수년간 기능 요청과 지원 요청을 많이 받았음. 집세를 낼 만큼 벌기 전까지는 그런 일에 돈을 받는 데 조금도 죄책감이 없음
    심지어 Pull Request 병합 버튼을 누르는 것까지도 내 시간이 1초라도 들어가면 비용을 청구함. 코드에는 몇 달, 몇 년을 들였고 그 코드를 세상에 무료로 공개했음
    추가 기능이나 내 시간이 필요하면 돈을 내야 함
  • 그 긴장이 있는 건 맞지만, 필연적인 건 전혀 아님. OSS 사용자와 상업 고객을 모두 만족시키며 제대로 해내는 회사들도 있음
    많은 회사가 못 한다고 해서 이 사업 모델이 작동하지 않는다는 뜻은 아니고, 제대로 하기가 매우 어렵다는 뜻에 가까움
  • 사용자의 발밑에서 깔개를 빼버리는 건 확실히 찝찝하게 느껴짐
    그래도 대부분의 사람은 대체로 선하다고 본다면, 이런 회사나 사람들이 시장 접근을 잘못한 것일 가능성도 고려할 만함. 악의라기보다 무능일 수 있음
    첫날부터 무엇이 영원히 무료이고 무엇이 결국 유료가 될지 투명하게 밝힌다면, 커뮤니티를 배신했다고 보지는 않겠음
    물론 로드맵을 지키고 피드백과 기여에 따라 조정한다는 전제가 필요함
  • 많은 프로젝트가 쓰는 아주 쉬운 구분이 있음. 기업 사용자와 개인 사용자를 나누는 것임
    유료 지원이나 확장 기능은 어차피 소프트웨어가 대부분의 돈을 버는 상업 영역에 남겨둘 수 있음
    모든 사용 사례에 맞지는 않겠지만 그럴 필요도 없음. 대부분의 컴퓨팅은 개인적이어야 함
  • 어떤 패턴을 말하는 건지 궁금함. 이런 인프라 프로젝트들이 AWS나 GCP에 죽지 않으려면 어떻게 하는지 알고 싶음

• “MinIO는 사용자 데이터에 누가 접근하는지 신경 쓰는 회사에 좋은 대안”이라는 말이 있는데, 어떤 회사가 오픈소스 소프트웨어로 호스팅한다고 주장하면서 실제로는 같은 API 엔드포인트를 흉내 내는 사내 폐쇄 소스 소프트웨어를 쓸 수도 있지 않나?
  그러면 AWS와 같은 종류의 신뢰가 여전히 필요함

  • 어떤 회사가 고객 데이터를 무서운 대형 클라우드로부터 보호하기 위해 온프레미스에 둔다고 진심으로 말할 수도 있지만, 지역 IT 컨설팅 생태계의 온갖 사람이 도메인 관리자 권한을 가지고 있고, 동네 절반이 네트워크 드라이브의 KeepassX에 접근한다는 부분은 빠뜨릴 수 있음
    자가 호스팅이 보안 의식이 높다는 뜻이라고 가정하면 안 됨. 대부분의 기업에서 온프레미스 IT는 HVAC나 전기 설비처럼 취급되지만 더 귀찮을 뿐임
    작업복을 입은 사람이라면 누구든 접수대에서 서버실 열쇠를 속여 받아낼 수 있음
  • 맞음. 이 주장은 놀라울 정도로 흔하지만 말이 안 됨. SaaS에서 오픈소스라는 말은 별 의미가 없음
    공급자가 자기 서비스 뒤에서 돌고 있다고 말하는 소스 코드를 공유한다는 뜻일 뿐임
    설령 그 코드가 정확히 맞더라도, “공식” 서비스 뒤에서 도는 유일한 코드일 가능성은 낮음. 그리고 사용자가 직접 빌드해서 그들의 서버에 배포할 수도 없음
    오픈소스가 진짜 의미를 갖는 건 자가 호스팅할 때뿐이고, 그렇지 않으면 사실상 독점 소프트웨어와 다를 바 없음. 모든 것이 공급자에 대한 신뢰, 그리고 가능하다면 계약에 달려 있음
  • 순수하게 기술적인 의미의 “신뢰”라면 맞지만, 우리는 사회 안에서 살고 있음. 공급자가 계약에 넣은 조항 때문에 거짓이면 사기 책임을 질 수 있다면, 고객은 보통 그것을 독립적으로 검증할 수 있는지까지 걱정하지 않음
    예를 들어 계약서에 데이터가 이 오픈소스 코드로 들어가고 나와서 다른 곳으로 가지 않는다고 쓰고, 이를 보장하기 위한 절차들을 열거했는데 그 전체가 노골적인 거짓이라면, 명확하고 집행 가능한 방식으로 큰 문제가 됨
    내부 직원들에게 숨기기도 어렵고 사람은 들어오고 나감. 실제가 아니라면 그런 주장을 할 가능성은 낮음
  • 전 직원이 그 사실을 알고 있기만 해도 소송 기회가 아주 좋아짐
  • 그렇지는 않음. 회사가 어떤 주장을 하고 실제로는 다른 일을 한다면 그건 속임수이고, 법적 조치를 취할 수 있음. 이건 신뢰와는 별개의 문제임

• 글쓴이는 유료 제품과 경쟁하는 오픈소스 솔루션을 구체적으로 말한다고 밝히고 있음
  개인적으로는 이 맥락에서 오픈소스가 “이기는지”는 아직 결론이 나지 않았다고 봄
  지난 10년간 오픈소스 제품이 크게 늘었고, 최근 5년 정도는 그중 많은 제품이 오픈소스에서 멀어지는 모습도 봤음. MongoDB, Hashicorp 스택, Elastic, Red Hat, MinIO 등이 그 예임
  진정으로 오픈소스이면서 상업적으로 경쟁력 있는 제품은 많이 남아 있지 않고, 그중 다수는 이게 실행 가능한 사업 모델임을 증명하려 애쓰는 중임

  • Caddy 프로젝트는 이 모델이 가능하다는 걸 보여주려고 싸우고 있고, 어느 정도 성공하고 있음
    몇 주 전 회사 내부 행사에서 이 주제로 발표했고, 몇 주 뒤 GoWest에서도 다시 발표할 예정임
    핵심 전제는 오픈소스 라이선스는 말 그대로 자유를 부여하지만, 회사가 돈을 낼 만한 다른 것들을 제공하지는 않는다는 점임. 독점 라이선스는 회사가 필요로 하는 것을 제공하지만 자유를 희생함
    자유나 신뢰성을 타협하지 않고 중간에서 작동하는 세 번째 모델이 있다고 믿음. 오픈소스로 남으면서 회사가 필요로 하는 간극을 후원으로 채우면 일부 프로젝트에는 가능할 수 있음
    지금 Caddy 웹사이트를 이 메시지에 맞게 다시 설계 중이고, 잘 작동하길 바람
  • 그게 이 글의 요지 아닌가? 오픈소스가 반드시 이긴다는 말이 아니라, 이긴다면 가격으로 경쟁사를 깎아내려서가 아니라 글쓴이가 열거한 강점들 때문에 이긴다는 것임
  • MinIO 저장소를 보니 APL2에서 AGPL3로 바꾼 것 같음
    MinIO에 대해 말한 “오픈소스에서 멀어짐”이 그걸 뜻하는 건가?
  • VLC와 Blender는 어떻게 운영되는 걸까?

• 제목이 멍청함. 당연히 오픈소스는 더 싸서 이김
  글쓴이가 말하려는 건 오픈소스 사업은 더 싸서 이기는 게 아니라는 것임
  오픈소스 코드베이스는 항상 더 싸서 이김. 압축 알고리즘, 네트워크 시간 데몬, 미디어 트랜스코더에 돈 내는 사람은 없음. 오픈소스가 그런 시장을 완전히 없애버렸음

  • 실제로는 오픈소스 코드를 만드는 사업에 대한 꽤 흥미로운 글처럼 보임
    다만 제목이 문자 그대로 단어 하나 때문에 틀린 게 짜증남
  • “성공의 척도는 사용이 아니라 수익”이라는 제목에서 오픈소스 도구 얘기에서 오픈소스 사업 얘기로 맥락이 너무 급하게 바뀌어서 목이 꺾이는 느낌이었음
    내가 뭔가 놓쳤나 싶어 앞부분 문단들을 다시 읽어봤음

• 기술 도입에 영향을 주는 엔지니어 입장에서는, 오픈소스는 이해 가능함으로 이김
  동료들과 내가 소스 코드를 볼 수 있으면, 그 제품이 주장하는 기능을 해낼지 판단할 수 있음
  사용 중 버그나 예상 못 한 사용 사례를 만나면 최소한 해결책을 조사해서 버그 보고에 제안할 수 있고, 아니면 PR을 열 수도 있음

  • 이건 확실히 가치 있음. 의존성이 뭘 하는지 보려고 소스 코드를 읽는 일이 거의 매주 있음
    그러면 빠른 우회책을 만들 수 있고, 보통 버그 보고도 할 수 있음

• 기업은 코드 자체를 그다지 신경 쓰지 않음. 신경 쓴다 해도 사업 연속성 조항이 폐쇄 소스에 대한 우려를 대부분 줄여줄 수 있음
  결국 Excel 대신 OpenOffice Calc로 갈아탄 금융사가 얼마나 되나?
  AWS의 시장 진입 전략은 스타트업과 개인 개발자에게 저비용 종량제 서비스를 제공해 끌어들이는 데 달려 있었고, 이 부분은 아주 잘 맞았음. Airbnb, Stripe, Twitch 등이 대기업으로 성장하며 AWS와 함께 커졌기 때문임
  저비용이나 무료와 경쟁할 수 있는 것은 많지 않음. 나중에 상위 시장으로 올라가면 됨. ARM과 Intel에 물어보면 됨
  개발 도구 신생 기업에게 오픈소스는 사실상 기본 시장 진입 전략이 되었음. 글이 맞게 짚듯이 사업 모델은 아니지만 말임
  그래서 Snowflake급으로 뛰어나고 Databricks 같은 자유·오픈소스 진영과도 맞설 수 있는 게 아니라면, 오픈 코어 모델이 더 나음

  • Excel 같은 도구에는 맞는 말이지만, 서버 인프라 같은 것들에서는 특히 큰 기술 회사들이 소스 코드 접근 없이 프로덕션에 넣는 걸 매우 꺼림
    직접 컴파일할 수 있으면 훨씬 더 선호함
  • 아직 비용을 신경 쓰는 초기 스타트업에 참여해 본 적이 없음. 대체로 비용보다 시간을 신경 썼고, Amplitude, Segment, AWS, Heroku 등을 사는 것이 대안보다 빠르다고 여겼음. 그 판단이 맞든 아니든 그랬음
    물리 서버에 Postgres를 직접 올리고 있다면 투자자들은 신경 쓰지 않거나, 얼마나 많은 시간을 낭비했는지 어려운 질문을 할 것임. 그때는 꽤 괜찮은 답이나 공감해줄 투자자가 있어야 함

• 벤더 종속을 언급하지 않은 게 놀라움. 오픈소스의 확실한 판매 포인트임

  • 동의함. 이건 사소한 포인트도 아님. 의사결정자 입장에서는 최우선 고려사항 중 하나임
    물론 조직과 사람마다 다르고, 신뢰하는 회사라면 종속을 신경 쓰지 않는 사람도 많지만, 결코 0은 아님
    Red Hat에서 OpenShift 컨설턴트로 일할 때 벤더 종속을 걱정하는 임원들을 많이 만났음. 그들에게 OpenShift를 선택하는 건 당연한 결정이었음
  • 실제로 자가 호스팅으로 전환할 수 있다는 이야기를 할 때 벤더 종속 부재를 암시하긴 함

• 소프트웨어 판매라는 영역에서만 약간 관련된 얘기인데, 오래전에 설계가 형편없는 게임의 사용자 인터페이스 업데이트를 팔았음
  가격을 게임 자체 가격의 2배로 책정했는데도 사람들이 샀음. 전문적으로 설계됐기 때문임
  전문 디자이너인 내가 본업 시간을 떼어, 그 개발자가 아마 못 했던 일을 한 것이었음
  당시 판매하던 디지털 유통 플랫폼 댓글에서 가장 뚜렷한 불만은 업데이트가 너무 비싸다는 것이었고, 사람들은 당연히 가격 포지셔닝에 대해 논평했음
  하지만 한 가지는 분명했음. 게임 자체가 너무 쌌음
  사람들이 가격만 불평하면서도 계속 산다면, 그 외에는 불평할 만한 게 없다는 뜻임
  새들은 언제나 공짜 먹이를 원함. 새들에게 맞춰주지 말아야 함
  덧붙이면, 그 업데이트는 불법 배포도 되었고 해적판 사용자들에게 꽤 퍼졌음. 대부분의 고객이 돈을 냈기 때문에 오히려 기뻤음
  또한 다른 곳에서 제공되지 않던 원하는 기능 묶음을 내가 충족하고 있다는 것도 분명했음. 그런 문제는 사람들이 원하는 것을 만들었다는 증상으로서는 꽤 괜찮은 문제임

• 많은 오픈소스 프로젝트는 선택이 아니라 필요 때문에 오픈소스가 된다고 봄
  어떤 제품은 오픈소스로 만들어야만 채택 가능성이 조금이라도 생김
  글쓴이는 소수의 엘리트 오픈소스 프로젝트에 집중하고 있고, 그것들은 대다수 오픈소스 프로젝트를 대표하지 않음
  어떤 회사들은 적절한 비즈니스·정부 인맥을 갖고 있어서 제품 라이선스를 쉽게 비싸게 팔 수 있지만, 그런 곳은 소수임
  대부분의 사람과 소기업에는 그런 네트워크가 없음. 적절한 비즈니스 네트워크가 없으면 돈을 조금이라도 벌기가 힘듦
  제품이 얼마나 좋든, 누군가의 비용을 얼마나 줄여줄 수 있든 상관없음. 아무도 믿지 않고, 시험해보지도 않음. 장기적 이익이 엄청날 수 있어도 채택 장벽이 너무 큼
  제품을 오픈소스로 만드는 건 발이라도 들여놓는 유일한 방법임. 제품이 눈에 띌 아주 작은 가능성을 주기 때문이고, 때로는 그게 전부임