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

• 오픈소스 소프트웨어는 (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을 해도 되며, 기술 인큐베이터와 보육 시설이 섞인 듯한 운영체제로 끌려갈 필요는 없음