오픈소스가 오픈 커뮤니티를 의미하는 것은 아니다

Source: Hacker News

Early Open‑Source Practices

오픈 소스 소프트웨어는 (D)VCS가 발명되기 훨씬 이전부터 존재했습니다.
작성자는 프로젝트를 설명하는 최소한의 HTML 페이지나 일반 텍스트 파일을 호스팅했을 가능성이 높습니다. 어딘가에 tarball을 제공하는 FTP 서버가 있었고, 작성자는 이메일로 연락이 가능했을 수 있습니다. 운이 좋았다면 공지와 토론을 위한 메일링 리스트가 있었고, 소프트웨어 이름을 딴 비공식 IRC 채널이 있었을지도 모릅니다.

이것은 과거에도 현재에도 오픈 소스였습니다.

정식 “커뮤니티”도 없고, 정치도 없으며, 행동 강령도 없고, 풀 리퀘스트나 이슈도 없으며, 위키도 없고, 핵심 팀도 없습니다.

이후 SourceForge 같은 사이트가 CVS/SVN 호스팅과 메일링 리스트를 사실상 “무료”로 제공하면서 오픈 방식으로 개발하기가 쉬워졌습니다. 가장 주목받는 DVCS 도구인 Git의 등장으로 GitHub로의 집중이 이루어졌습니다.

GitHub은 많은 오픈 소스를 유지 관리자를 위한 무보수 작업으로 바꾸어 놓았습니다. 기여자는 이제 티켓, 회의, 로드맵, 사내 정치, 마감일, 지표, KPI, 스탠드‑업, 일대일 미팅, 애자일 혹은 워터폴 프로세스, 그리고 끊임없는 알림, 이슈, 풀 리퀘스트와 씨름합니다. 유지 관리자는 자신이 원하지 않았음에도 “커뮤니티”가 형성되었다고 느끼게 되고, 이는 번아웃과 자신의 프로젝트에 대한 통제력 상실을 초래할 수 있습니다.

It Doesn’t Have To Be This Way

일부 프로젝트는 규모와 복잡성 때문에 팀이 필요하지만, 이는 예외일 뿐 일반적인 경우는 아닙니다.

새로운 기여자와 AI 봇의 급증에 좌절감을 느낀다면, 더 단순한 관행으로 돌아가는 것을 고려해 보세요:

• 이슈 트래커와 풀‑리퀘스트 시스템을 끄거나, 릴리스를 위한 최소한의 Git 서버만 운영합니다.
• 소수의 신뢰할 수 있는 협업자와 작업하거나, 혼자 진행합니다.
• 낯선 사람을 자신의 공간에 들여오도록 강제하지 않습니다.
• 프로젝트에 도움이 되지 않는 형식적인 행동 강령이나 LLM 정책은 건너뛰세요.

오픈 소스는 “오픈 소스”가 되기 위해 반드시 공개적으로 개발될 필요는 없습니다. 코드를 작성하고, 즐기는 것을 만들며, 자신이 선호하는 도구를 사용하세요—예를 들어 크리스마스 날 새벽 2시에 커밋을 하든, 자신에게 맞는 어떤 일정이든 상관없습니다. 프로젝트를 사회성이 부족한 사람들을 위한 반은 기술 인큐베이터, 반은 보육원 같은 형태로 전락시키는 일을 피하세요.