오픈소스가 공개 커뮤니티를 의미하지는 않는다

 (blog.feld.me)
10P by GN⁺ | ★ favorite | 댓글 2개
  • 오픈소스 소프트웨어는 (D)VCS 이전에도 HTML 페이지, txt 파일, FTP의 tarball, 이메일 연락처만으로 배포될 수 있었고, 공개 커뮤니티가 없어도 오픈소스였음
  • 메일링 리스트나 IRC 채널이 있으면 운이 좋은 편이었지만, pull request, issue, wiki, core team, Code of Conduct는 오픈소스의 필수 조건이 아니었음
  • Sourceforge는 CVS/SVN과 메일링 리스트를 거의 무료로 제공해 공개 개발을 쉽게 만들었고, 이후 git이 DVCS 경쟁에서 이기며 세계가 GitHub로 수렴함
  • GitHub 이후 오픈소스 유지보수는 issue, 범위를 벗어난 pull request, 불평과 요구, 채팅 그룹 관리까지 떠안는 무급 업무처럼 변해 번아웃과 통제력 상실로 이어질 수 있음
  • 프로젝트가 반드시 공개적으로 개발될 필요는 없으며, issue tracker와 pull request를 끄거나 bare git 서버를 쓰고, 신뢰하는 작은 그룹 또는 혼자서 오픈소스를 운영할 수 있음

GitHub 이후 유지보수 부담

  • GitHub는 오픈소스를 유지보수자에게 무급 업무처럼 느껴지게 만듦
  • 직장에서 티켓, 이해관계자 회의, 로드맵, 정치, 산만함, 마감, 지표, KPI, 변경된 요구사항, standup, one-on-one, Agile, Waterfall을 처리한 뒤에도, 집에 오면 오픈소스 알림이 쌓이는 구조가 됨
  • issue가 쌓이고, 프로젝트 범위를 벗어난 방향으로 소프트웨어를 재설계하는 pull request가 들어오며, 불평과 요구가 늘어남
  • 채팅 그룹과 “커뮤니티”가 생기면, 유지보수자는 참을성 없는 사람들을 관리하고 일대일로 상대해야 하는 책임까지 떠안게 됨
  • 그 결과 오픈소스가 두 번째 직업처럼 변하고, 유지보수자는 번아웃을 겪으며 자기 프로젝트의 통제권과 방향성마저 잃을 수 있음

다시 단순하게 운영하기

  • 일부 프로젝트는 너무 크고 복잡해서 팀 관리가 필요하지만, 이는 예외이며 일반적인 경우는 아님
  • 새로운 사람들과 AI 봇이 주의를 빼앗는 상황에 화가 난다면, 예전 방식으로 돌아갈 수 있음
  • issue tracker와 pull request를 끄거나, 코드 공개용으로 bare git 서버를 운영할 수 있음
  • 정말 알고 신뢰하는 작은 그룹과 함께 작업하거나, 완전히 혼자 프로젝트를 진행할 수도 있음
  • 낯선 사람들이 자신의 공간을 침범하도록 허용할 필요가 없고, 보여주기식 Code of Conduct나 LLM 정책도 필수는 아님
  • 오픈소스가 “오픈소스”이기 위해 반드시 공개적으로 개발될 필요는 없음
  • 원하는 도구를 쓰고, 좋아하는 것을 만들고, 크리스마스 새벽 2시에 code drop을 해도 되며, 기술 인큐베이터와 보육 시설이 섞인 듯한 운영체제로 끌려갈 필요는 없음
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 이런 생각 때문에 https://casuallymaintained.tech/ 를 만들었고, 아주 마음에 듦

  • 가장 유명한 예는 SQLite인데, 외부 기여를 거부함
    Airbus 항공기 같은 임무 핵심 애플리케이션에도 쓰인다는 점을 생각하면 합리적인 정책임

  • 꽤 신선한 관점임
    어쩌면 저자가 맞고, 우리가 유지관리자에게 너무 많은 걸 요구하고 있는 것일 수 있음
    망가진 건 오픈소스 전체가 아니라, 오픈소스가 무엇을 제공해야 하는지에 대한 기대의 인플레이션일지도 모름
    GitHub의 사회적 요소도 한몫할 수 있음. 별과 일반 사용자가 늘수록 프로젝트를 보러 오는 새 사람들을 만족시켜야 한다는 압박이 커짐
    특히 커뮤니티의 관심과 요구가 만든 사람의 초기 비전과 맞지 않을 때 위험해짐

  • 관련 글: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/

  • 탄탄한 접근이고, 더 많은 사람이 기본값으로 삼았으면 함
    커뮤니티 만들기나 어떤 책임을 떠안는 일은 예외적이고 의도적인 행동이어야 함
    행동 강령과 LLM 정책을 보여주기식이라고 한 부분은 조금 동떨어져 보이지만, 민감한 주제라 그러려니 함

    • 모든 행동 강령이나 LLM 정책이 보여주기식이라는 뜻은 아님
      하지만 사용자도 커뮤니티도 없고 앞으로 만들 생각도 없는 1인 저장소에 붙여두면 보여주기식이 됨
      혼자 쓰는 저장소에 나 자신을 위한 행동 강령은 필요 없음

  • 이 논의가 힘을 얻고 실제로 통하는 합의로 이어지면 정말 좋겠음
    소프트웨어를 만들고 건강하게 기여하는 방식은 많음
    다만 서로 양립하지 않거나, 오픈소스의 높은 기준과 맞지 않거나, 가시성과 인기의 비용을 치르거나, 라이선스·자체 호스팅·코드 기여 미수락 같은 서로 다른 장치를 쓸 수 있음
    커뮤니티 소프트웨어에서 재미와 공정함을 앞에 두는 좋은 길을 함께 찾았으면 함

  • 글에서 제시한 상태는 유명인이 아닌 사람이 막 만든 모든 개인 오픈소스 프로젝트의 자연스러운 상태임
    우리 모두 그런 식으로 운영되는 프로젝트를 꽤 많이 갖고 있음
    문제는 사람들이 프로젝트에서 무엇을 얻고 싶은지 모르거나, 인기 있는 프로젝트를 운영하면 멋질 거라고 생각하면서 그 비용을 제대로 따져보지 않는 데 있음
    그래서 의식적이든 아니든 관심 추구가 시작됨
    “GitHub가 오픈소스 전체를 유지관리자에게 무급 일자리로 만들었다”는 말은 허용할 때만 맞음
    막연한 명성의 약속을 빼면, 대부분의 상황에서 GitHub가 원래 하고 싶지 않은 일을 하게 만들 지렛대는 별로 없음

  • 맞는 말임
    예전에 약간 인기 있던 프로젝트가 있었고, 원하지 않는 기능에 대한 버그 보고와 풀 리퀘스트가 들어와 처리하느라 스트레스를 받았음
    그때 이런 글을 읽을 수 있었다면 좋았을 것 같음
    덧붙여 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 도 볼 만함

  • 작은 프로젝트에 대해서는 이 글에 강하게 동의함
    더 큰 프로젝트도 가장 성공적인 것들은 처음부터 열린 커뮤니티로 시작하지 않는 경우가 많음
    좋아하는 프로젝트 중 다수는 대형 조직에서 개발을 시작했고, 핵심은 그 소프트웨어를 내부에서 실제로 적극 사용하고 있었다는 점임
    그래서 유지관리자도 이미 보수를 받고 있었음
    개인 프로젝트든 내부 팀이든, 개발자 자신의 일상적인 문제를 풀기 위해 만든 소프트웨어가 명성이나 사업화를 위해 만든 소프트웨어보다 더 성공적이고 덜 착취적으로 보임

답변달기
GN⁺   [-]
Hacker News 의견들

  • 가장 닫힌 공동체라도 예의 있게 이메일을 보내면 기여를 받아주는 경우가 많음
    어떤 오픈소스 개발자가 괴롭힘에 지쳐 저장소의 풀 리퀘스트와 여러 기능을 꺼둔 적이 있었고, 그 시기에 매우 까다로운 사람이라는 평판도 생겼음
    나는 그 사정을 모르고 그냥 프로젝트가 원래 그런 방식이라고 생각해서, 이메일 주소를 조금 찾아낸 뒤 부담 없는 정중한 메일로 비공식 패치를 보냈고, 써도 되고 무시해도 된다고 분명히 했음
    그 개발자는 고맙다고 답하면서 상황을 설명하고, 불편하게 해서 미안하다고까지 했으며, 그런 식으로 잠그는 것밖에 대응 방법을 몰랐다고 말한 뒤 당연히 수정도 반영해줬음

  • 이 글이 자유 소프트웨어 프로젝트들이 토론이나 버그 보고를 Discord로 강제하는 널리 퍼진 문제를 다루는 줄 알았음
    한두 주 정도는 다른 도구로 옮기자는 관심이 보였지만 이미 식은 듯하고, 결국 다들 포기하고 Discord로 돌아간 것 같음

    • 지금 보는 거의 모든 오픈소스 프로젝트가 Discord를 써서 아쉬움
      Discord가 완전히 끔찍한 건 아니지만, 휘발적이고 거대한 비대한 웹 앱을 요구함

  • 회색수염 입장에서, 글쓴이의 태도가 마음에 듦
    ARPANET 원로들 앞에 앉아 있던 시절, 1밖에 없어서 그중 절반쯤을 손으로 0으로 벼려내야 하던 때를 기억할 만큼 오래됐음
    예전 소프트웨어 개발 방식에서는 프로젝트가 대개 한두 명에 의해 작성되거나 유지됐고, 인터넷 전체가 그들의 이메일 주소를 알고 직접 버그 보고를 보냈음
    어떤 프로젝트는 IRC나 메일링 리스트에서 논의됐고, 대체로 전문적으로 행동했으며, 그렇지 않으면 메일링 리스트에서 삭제되거나 iirc와 pine의 차단 파일에 들어갔음
    핵심은 어느 시점이든 활성 개발자 그룹이 매우 작았다는 것임
    make, Sendmail, sed, awk 같은 작은 유틸리티를 주로 말하는 것이고, Perl도 1990년 전까지는 대부분 Larry Wall과 tchrist만 있는 것처럼 보였음
    gcc는 수천 명이 패치를 보내고 업스트림에 넣으려면 RMS와도 잘 조율해야 했던 미친 반례였음
    새 도구들은 더 큰 팀이 계속 상호작용하도록 지원하고, 작은 팀으로 인터넷의 아무나가 신장 하나를 걸고 패치를 내지 않는 한 신경 쓰지 않는 방식에도 큰 장점이 있음
    다만 그런 방식은 사람들을 작업물에 끌어들이는 데는 장점이 아니므로, 구식 방식으로 가도 되지만 팀은 작아지고 사용자를 끌어들이기 어려울 수 있음
    그래도 사용자는 알 바 아니고, 나는 내 사용 사례를 지원하려고 소프트웨어를 쓰며, 혹시 다른 사람에게도 유용할까 봐 오픈소스로 공개함

  • 더 구체적으로 말하면, 오픈소스는 네 가지 기본 자유만 약속함(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
    그 외에는 문자 그대로 아무것도 약속하지 않으며, 무료도 포함되지 않음
    자유·오픈소스 소프트웨어는 돈을 받을 수 있고 그래야 하며, 여기서 “free”는 돈 얘기가 아님
    최근 여러 공동체에서 일어난 오픈소스 “공급망” 공격을 꽤 긍정적으로 보는데, 낙관적으로는 사람들이 오픈소스가 공급망이 아니라는 점을 깨닫게 해주길 바라기 때문임
    자세한 내용은 https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...에 있음
    공급업체에 돈을 내고 있거나, 일정 보장을 담은 계약이 있지 않다면 공급망이 있는 게 아님
    거의 모든 FOSS 라이선스에는 “이 소프트웨어는 보증 없이 제공된다”는 조항이 있고, 공급망은 보증을 함의하므로 FOSS는 공급망이 아님

    • 그건 FSF의 자유 소프트웨어지, 오픈소스가 아님
      여기 와서 “오픈소스”가 “도덕적 가치”를 가진 것처럼 다뤄지고, 자유 소프트웨어에서 훔쳐온 개념을 둘이 같은 것처럼 섞는 걸 보는 데 질렸음
      오픈소스는 거대 소프트웨어 회사들이 수많은 자원봉사자에게서 가져가는 것일 뿐임

  • 행동 강령 쪽 사람들은 문제를 일으키려고만 있는 것임

    • 모든 정치적 집단에는 진실보다 논쟁에서 이기는 데 더 관심 있는 악의적 행위자가 있고, 그냥 욕하러 온 더 나쁜 사람들도 있음
      빨간 버튼/파란 버튼 논쟁만 봐도, 그 격한 독설은 버튼이 실제로 있거나 사람들이 못되게 굴기를 좋아할 때나 말이 됨
      선의의 행동 강령 지지자들은 결사의 자유와 표현의 자유를 말함
      플랫폼이 상대를 싫어하면 금지해도 괜찮은가, 아니면 메일링 리스트의 실용적인 “친절하게 굴자” 관습으로만 다뤄야 하는가 같은 문제임
      물론 누가 결정권을 쥐느냐에 달렸지만, 그건 어떤 프로젝트든 마찬가지임
    • 겉으로 보면 행동 강령은 오픈소스 프로젝트 리더가 누가 프로젝트와 상호작용할 수 있는지 정하는 방법임
      프로젝트 리더십의 바람과 모순되는 조건을 내세우면서 남의 프로젝트에 참여하겠다고 요구하면서 동시에 결사의 자유를 가질 수는 없음
      추측하자면 글쓴이가 “과시적인 Code of Conduct는 필요 없다”고 한 뜻은, 작은 프로젝트에서 세상에 공유만 하고 나중에 외부 기여를 받을 선택지만 열어두고 싶다면 실제 상황을 겪기 전부터 행동 강령을 갖출 필요는 없다는 말일 수 있음
      순전히 가상의 문제를 두고 머리를 싸맬 필요가 없음
    • 포럼, 메일링 리스트, 버그 추적기에 규칙을 게시하는 게 문제를 일으키기 위해서만 하는 일이라고? 정말?
      행동 강령이 있는 이유는 대안이 임의의 위반에 대한 임의 처벌이거나, 완전한 스팸 무정부 상태이기 때문임
      예전에 네티켓을 설파하던 사람들이 이제는 명확성과 건강한 공동체에 그렇게 반대한다는 게 이해가 안 됨
      다시 생각해보면 Goomba fallacy일 수도 있고, 행동 강령을 경멸하는 사람들은 1990년대 유즈넷에서 계속 불꽃 싸움과 스팸을 뿌리던 사람들일지도 모름

  • 오픈소스는 단순한 라이선스 선택이 아님
    기업에 더 매력적으로 보이도록 자유 소프트웨어를 재구성한 것이고, 오픈소스의 핵심은 기업이 비공개로 개발하는 것보다 대중과 협업해 소프트웨어를 개발하는 편이 더 효과적이라는 데 있음
    그래서 오픈소스는 열린 공동체를 함의함
    허용적 라이선스로 코드를 대중에게 던져놓되 협업 개발은 하지 않고 싶다면 물론 그렇게 할 수 있고, 그 코드는 오픈소스 코드임
    코드를 여는 건 좋은 일이고 그 이상을 할 의무는 없지만, 오픈소스가 설계된 목적대로 하는 것은 아니며 핵심 일부를 무시하는 것임
    오픈소스 코드를 보고 협업 개발 중이라고 가정하는 사람들은 비합리적이지 않음
    그게 오픈소스 운동의 목적이기 때문임
    당신 소프트웨어에는 그 가정이 맞지 않아도 괜찮지만, 사회적 규범을 깨는 쪽은 그들이 아니라 당신임

    • 오픈소스의 요점이나 목적을 말할 때 무엇을 가리키는 건지 궁금함
      나는 Stallman, 프린터 드라이버, 사용자가 자기 작업을 소유하는 일을 떠올리기 때문에, 오픈소스의 목적에 대한 그런 단정은 맞지 않게 들림
    • 왜 이 스레드의 모두가 30년 전에 이미 이 논쟁이 있었고, 그래서 OSI가 무엇이 오픈소스이고 무엇이 아닌지 명확히 적은 문서를 냈다는 사실을 무시하는지 모르겠음
      https://en.wikipedia.org/wiki/The_Open_Source_Definition
      거기에는 협업 개발에 대해 아무 말도 없음

  • 사람들은 감정적이 되어, 기본을 배우고 싶어 하지 않는 신규 사용자나 사용자를 돌보려 하는 경우가 많음
    지원 포럼과는 분리되어 있지만 엄격하고, 제때 답하되 무심한 관계를 유지하는 게 좋음
    coreboot나 MrChromebox가 좋은 예이고, 그는 필요할 때만 답함

  • 동의하고 하나 더 보태자면, 사람들에게 소프트웨어를 쓰라고 설득하는 마케팅 페이지를 만들 필요도 없음
    대신, 또는 함께, 왜 이 소프트웨어를 쓰면 안 되는지 모든 이유를 설명해보는 것도 좋음
    사용자가 많을수록 문제도 많아짐

  • FOSS 애플리케이션이 반드시 공개 배포될 필요는 없고, 그건 흔한 사회적 기대일 뿐임
    FOSS라고 해서 고객이 아닌 사람에게 코드가 제공되어야 한다는 뜻도 아니며, 누가 고객인지는 개발자가 정함
    FOSS는 돈을 받고 팔도록 권장되며, 원래 무료였던 다른 사람의 소프트웨어도 팔 수 있음(https://www.gnu.org/philosophy/selling.en.html 참고)
    비자유 라이선스를 붙인 오픈소스도 여전히 오픈소스이지만 비-FOSS이고, 개발자는 소프트웨어로 더 많은 돈을 벌거나 자신에게 유리한 추가 제한을 두고 싶다면 비자유 오픈소스 라이선스를 선택하는 데 부끄러워할 필요가 없음
    그것도 copyleft일 수 있음
    요약하면 우리는 LICENSE.md를 만들고 거기에 크게 의존하지만, SOCIAL.md를 만들 생각은 아무도 하지 않았음
    누군가 “오픈소스”라고 말하면 많은 사람이 “저자는 사람들, 사회, 주변 모두를 위해 만들고 있으며, 프로젝트 개발과 새 기능 추가, 특히 내가 필요한 기능, 그리고 모든 사용자의 이익을 위한 개선에 관심이 있다. 그렇지 않다면 왜 공개하겠는가?”라고 가정함
    하지만 이는 FOSS에 대한 가장 흔한 사회적 기대일 뿐, 유일한 경우와는 거리가 멂
    기술적 오픈소스와 사회적 오픈소스의 구분이 빠져 있는 것이 의견 불일치, 논쟁, 결국 어긋난 사회적 기대에서 오는 번아웃의 주된 원인임
    예전에는 분노한 대중에게 이 문제와 차이를 설명해야 했는데, 최근 Jeffrey Paul의 글 https://sneak.berlin/20250720/the-agpl-is-nonfree/에서 오픈소스 코드를 선물에 비유한 것을 봤음
    내 설명은 결국 “선물이 마음에 안 들고 맞지 않으면 버리고 잊어라”였음

    • 비자유 라이선스를 붙인 오픈소스도 여전히 오픈소스이지만 비-FOSS라는 말은 틀림
      OSI가 승인했지만 자유 소프트웨어로 보지 않는 라이선스는 몇 개뿐임
      https://www.gnu.org/licenses/license-list.html에서 GPL과 호환되지 않는 자유 소프트웨어 라이선스의 긴 목록을 보면 됨
      게다가 “비-FOSS 오픈소스”는 말이 안 되는데, FOSS가 문자 그대로 Free and Open Source Software이기 때문임
    • “우리는 LICENSE.md를 만들고 거기에 크게 의존하지만, SOCIAL.md를 만들 생각은 아무도 하지 않았다”는 부분이 예전부터 늘 그랬는지, 아니면 이 괴롭힘이 지난 10년쯤 오픈소스 소프트웨어의 노출 증가에서 나온 산물인지 궁금함
      이제는 수상한 웹사이트나 이상한 빌드 파이프라인을 거칠 필요 없이, 누구나 쓸 수 있는 실행 파일과 함께 GitHub에 거의 바로 올라와 있음

  • “공동체” 없음, 정치 없음, 행동 강령 없음, 풀 리퀘스트나 이슈 없음, 위키 없음, 핵심 팀 없음이라니 낙원처럼 들림
    요즘은 프로젝트 자체에 해가 되는 공동체가 너무 많다고 느낌
    더 나아가 공동체가 오픈소스 프로젝트에 어떤 식으로든 도움이 된 적을 단 한 번도 떠올릴 수 없음

    • Jia Tan이 구하러 오기 전까지는 그렇겠지
    • 기여나 피드백을 전혀 받을 생각이 없고, 프로젝트의 심각한 문제를 고치는 것조차 원하지 않는다면 낙원처럼 들릴 수 있음
      품질을 희생해서 통제권을 극대화하는 게 목표라면 괜찮음
      다만 그런 경우 정말 FLOSS를 찾는 게 맞는지는 의문임
답변달기