▲

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

 (blog.feld.me)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 오픈소스 소프트웨어는 (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을 해도 되며, 기술 인큐베이터와 보육 시설이 섞인 듯한 운영체제로 끌려갈 필요는 없음

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
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 도 볼 만함

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

답변달기