아무도 자유/오픈소스 소프트웨어에 돈을 내지 않는다, 우리는 내게 할 수 있다

소프트웨어로 돈을 받고 싶다면 무료로 만드는 일을 멈춰야 함. 반대로 무료로 만든다면 돈을 받을 거라 기대하지 말아야 함. 부탁도 받지 않고 교차로에서 자동차 유리를 닦은 뒤 돈을 요구하는 것과 다를 바 없음.
초기 자유 소프트웨어·오픈소스 개발자들은 다른 업무로 급여를 받는 직업 학자 등이거나 과학·국방 연구비를 지원받는 이들이었음. FOSS 자체로 돈을 벌 수 있다는 발상이 어디서 나왔는지 모르겠고, 그런 시도는 거의 매번 실패했음. 수정 전에는 이 문장을 “Netscape부터 그 아래까지”라고 끝맺었음.

FOSS에 돈을 받는 것을 막는 건 아무것도 없음. 첫 사본을 개발비만큼 받고 팔면 됨.

Netscape가 실패했다니 무슨 기준인가? 누군가에게 엄청난 돈을 벌어줬고 Firefox까지 남겼으니 실패와는 거리가 멂.

유리 닦는 사람에 대한 개인적인 반감이 비유에 끼어든 것 같음. FOSS 개발자는 사용을 강요한 적이 없음. 처음에 무료라고 홍보한 제품에 나중에 돈을 요청하더라도 마찬가지임.
기술업계와 번듯한 사무직이 사회에 끼치는 피해를 생각하면, 오히려 유리 닦는 사람만큼이라도 선량하길 바라야 함. 서비스를 제공하고 돈을 받으면 한동안 귀찮게 하지도 않으며, 구독 꼼수나 신용카드 요구, 광고 이메일, 중독을 유도하는 설계도 없음. Adobe, Google, Facebook, Amazon 직원들과 비교하면 성인처럼 보일 정도임. 냉방되는 사무실에서 일한다는 이유만으로 스스로에게 너무 관대함.

무료로 제공하지 않으면 다른 누군가가 무료 대안을 내놓을 테니 아무도 쓰지 않을 것임. 게다가 소프트웨어가 해결하는 가장 어려운 문제들은 중요하더라도 눈에 보이지 않으며, 시스템 장애도 직접 겪기 전까지는 아무도 신경 쓰지 않음. 신뢰성을 홍보하기도 어려움. 거의 모든 소프트웨어가 신뢰할 만하다고 자칭하지만 실제로는 그렇지 않아서, 그 표현 자체가 의미를 잃었기 때문임. 이런 과잉 경쟁 속에서 경제적 발언권이 없는 개발자에게 오픈소스는 사용자를 확보할 유일한 수단처럼 보일 수 있음. 선택이 아니라 절박함에서 나온 사업 모델임.

자유 소프트웨어 철학에 맞는지는 모르겠지만, 무료 오픈소스 소프트웨어를 독점 편의 기능과 함께 상용 앱 장터에서 유료로 판매하는 방식을 좋아함. Krita가 좋은 예임. https://krita.org/en/download/에서 무료로 받을 수 있지만 Steam, Microsoft Store, Epic Store, Apple Store에서도 구매 가능함. 유료판은 자동 업데이트와 최근 추가된 Steam Cloud 동기화를 제공하고 개발자를 후원하는 수단도 됨. 다만 플랫폼 운영사도 수수료를 가져감.
Steam 후기에서도 무료 소프트웨어라는 사실을 알면서 간편하게 개발자를 후원하려고 샀다는 내용을 볼 수 있음. 플랫폼 자체의 구매 유도 효과도 있어서, 하지 않을 게임을 사듯 라이브러리에 넣어두려고 구매하기도 함. https://store.steampowered.com/app/280680/Krita.

Filebot이 오픈소스였을 때 개발을 후원하고 백그라운드 업데이트도 편하게 받으려고 App Store에서 구매했음.
그런데 Apple의 ARM 전환 이후 App Store판 업데이트가 뒤처졌음. ARM판은 별도 배포되고 있었지만 App Store에는 없었고, 유니버설 앱이 아닌 별도 다운로드였기 때문인 듯함. 기존 x86 앱은 당시 모든 기기에서 실행 가능했음.
지금은 비공개 소스 유료 앱이 됐고, Rosetta를 설치하기 싫어서 ARM판을 받으려니 배포 경로가 다르다는 이유로 다시 결제해야 했음. 이런 일을 여러 번 겪으면 “무료 앱을 유료 장터에서 판매”하는 모델에 정이 떨어질 수밖에 없음.

Inkscape, Gimp, Firefox, Libre Office에 기부한 돈이 독점 소프트웨어 구매에 쓴 돈보다 많은 것 같음. 앱 장터에 오픈소스 앱의 유료판이 있으면 구매하는 편이며, 간편한 기부 링크나 버튼이 있으면 좋음.
반면 비공개 소스 소프트웨어는 무료로 배포하더라도 훨씬 덜 신뢰함. 특히 무료라면 더 그럼.

자유 소프트웨어 철학과 별개로, 결제를 받기 시작하면 책임도 따라옴. 각종 의무와 법적 책임까지 감수할 만큼 가격이 높다면 괜찮겠지만, 사용자가 후원하려는 금액은 그 수준과 크게 다를 수 있음.

그걸 독점 기능이라고 보기는 어렵지만, 자유는 보장하되 바이너리는 유료로 판매하는 모델은 아주 좋다고 봄.

“아이디어를 설명하려면 5,000단어가 필요하니 시간이 없으면 레지스트리 부분으로 건너뛰라”는 안내가 있음. 글 전체에 LLM 특유의 문체가 가득한데, 직접 썼다면 5,000단어나 필요하지도, 이런 안내를 붙일 필요도 없었을 것 같음.

어떤 점에서 LLM 출력이라는 건가? LLM도 그 5,000단어를 쉽게 써낼 수 있음.

나도 다듬지 않은 AI 생성물에는 짜증이 나지만, 이 글은 전혀 LLM이 쓴 글처럼 느껴지지 않음. 그 안내도 저자가 진심으로 쓴 것 같음. LLM 글을 많이 읽는데, 어느 부분이 생성된 것처럼 보였는지 궁금함.
조금 길기는 해도 구성과 호흡이 좋고 충분히 고민한 글로 읽힘.

LLM 문체처럼 느낀 건 “load bearing”이라는 표현뿐임. 보통 질 낮은 LLM 글은 불쾌해서 끝까지 못 읽는데, 이 글은 그렇지 않았음. 모델이 좋아진 것일 수도 있지만, 어쨌든 사람이 전부 쓴 글처럼 읽힘.

LLM 문체에 대한 끊임없는 불평이 오히려 그 문체보다 더 거슬림.

몇 가지 세부 사항을 바로잡고 싶음. Ruby Central의 주요 후원사는 Alpha Omega와 Shopify 두 곳이었으며, 2025년 사태는 후원사보다 사람들 사이의 갈등과 훨씬 더 관련이 깊었음.
내가 작성한 보고서는 GitHub 관련 부분만 다룸. https://rubycentral.org/news/rubygems-fracture-incident-repo... AWS 루트 접근권 관련 사건은 그 도중 또는 직후에 발생했고, 별도 연표가 있음. https://rubycentral.org/news/rubygems-org-aws-root-access-ev....
“인력이 고갈된 팀”이라는 표현도 정확하지 않음. Sam은 이미 거의 떠난 상태였고 Andre도 비슷했음. Ellen은 해당 운영 업무를 맡지 않았고, Deivid는 레지스트리가 아닌 Bundler만 담당했음. 운영상 핵심 손실은 스스로 물러난 Josef였음. 어느 공격을 가리키는지는 불분명하지만, Colby는 이미 계획돼 있던 정규직 전환을 서류 처리가 끝난 뒤 완료했음.
기존 유지보수자와 보안 연구자들이 모두 떠난 것도 아님. 특히 Maciej Mensfeld가 결정적인 역할을 했고 Jenny Shen도 남아 있음. 이들 역시 유지보수자임. 나는 2025년 10월 합류한 자원봉사자이며, 기업이 직원의 근무 시간을 기부하는 형태로 참여하는 엔지니어도 여럿 확보했음.
보고서에 이름이 나오지 않은 GitHub 접근권 상실자 전원에게 연락했음. 관리자 권한 복구를 요청한 사람은 한 명이었고 복구해줬으며, 이들 중 운영에 활발히 참여하던 사람은 없었음. 이 구조가 취약하다는 Seldo의 핵심 논지는 여전히 유효하지만, 세부 사실과 맥락도 중요함. 글이 처음 공개됐을 때 Bluesky에서 Laurie에게 연락했지만 답을 받지 못했음.

허용적인 라이선스와 덜 허용적인 라이선스를 오가는 프로젝트의 근본적인 실수는 처음부터 완전히 허용적인 라이선스로 시작한 것이라고 봄.
처음부터 소스 공개형이나 OpenRAIL 같은 형태로 시작해서 연 매출 500만 달러 초과 기업에 대가를 요구하기로 모두 합의했다면 이런 상황은 피할 수 있었을 것임. https://fair.io/.

일종의 미끼 상술임. 오픈소스가 주는 명성과 초기 사용자 확보, 커뮤니티의 환영은 원하면서 고객을 묶어두는 사업 모델까지 원함.

처음부터 자유 소프트웨어가 아니면 같은 수준의 관심과 확산을 얻지 못하니 그렇게 하지 않을 것임. 결국 조건을 좋게 제시해 사용자를 모은 뒤 불리하게 바꾸는 서비스 개악의 한 형태임.

YC도 오픈소스 기금을 조성하면 좋겠음. 예를 들어 투자받은 회사들이 자발적으로 주식 0.5% 를 오픈소스 소프트웨어에 출연하는 방식이 가능함.

돈을 받기 쉬운 방법 중 하나는 커뮤니티 지원이 종료된 버전에 상용 지원을 제공하는 것임. 오래되고 문제가 있는 버전에서 벗어나지 못한다면 비용을 내고 지원을 연장하도록 하면 됨. 이런 지출은 회계 승인도 비교적 쉽게 받을 수 있음.
팁을 주거나 무료 소프트웨어에 돈을 내거나 핵심 인프라를 떠받치는 단체에 후원금을 보내는 일은 황당할 만큼 어려움. 반면 상용 지원은 회계 담당자도 쉽게 이해함.

공짜 맥주가 아니라 표현의 자유에서 말하는 자유임. AI가 만든 저질 글은 읽지 않겠지만, 자유 소프트웨어 정의나 오픈소스 정의 어디에도 판매를 제한하는 내용은 없음.
구매자가 다시 공유하는 것을 막을 수는 없지만, 목표액 달성형 모금을 이용하면 공개하기 전에 충분한 자금을 확보할 수 있음. https://en.wikipedia.org/wiki/Threshold_pledge_system.

“아무 조건 없이 상업적 이용까지 무료로 허용하는 MIT·BSD·Apache가 진화적으로 안정적인 전략이고, 조금이라도 덜 관대한 프로젝트는 더 관대한 프로젝트에 모두 패했다”는 논지에는 Linux의 GPLv2가 명백한 반례 아닌가?

실제로는 Linux가 가장 관대한 선택지였기 때문이라고 볼 수 있음. BSD 계열은 작은 내부 집단 밖의 기여자를 사실상 받아들이지 않았고, 좋지 않다고 여긴 하드웨어나 비자유 바이너리 지원 패치도 거부했음. 반면 Linux는 라이선스와 관계없이 무엇이든 담을 수 있는 모듈을 중심으로 구성됐고, 새로운 패치와 낯선 유지보수자도 적극적으로 받아들였음.
지금도 Linux는 자체 분산 버전 관리 시스템인 Git을 만들었지만, 일부 BSD는 여전히 강하게 중앙집중화된 CVS를 사용함. 이보다 더 관대한 대안이 없는 건 주류 운영체제를 만드는 일이 엄청나게 어렵기 때문임.