가장 유명한 예는 SQLite인데, 외부 기여를 거부함
Airbus 항공기 같은 임무 핵심 애플리케이션에도 쓰인다는 점을 생각하면 합리적인 정책임
SQLite는 외부 기여를 거부하지 않음. 저작권 페이지에도 이 점이 분명히 적혀 있음
SQLite는 오픈소스라서 원하는 만큼 복사하고 제한 없이 사용할 수 있지만, 공개 기여(open-contribution) 프로젝트는 아님
SQLite를 퍼블릭 도메인으로 유지하고 독점·라이선스 코드가 섞이는 일을 막기 위해, 기여를 퍼블릭 도메인에 바친다는 진술서를 제출하지 않은 사람의 패치는 받지 않음
꽤 신선한 관점임
어쩌면 저자가 맞고, 우리가 유지관리자에게 너무 많은 걸 요구하고 있는 것일 수 있음
망가진 건 오픈소스 전체가 아니라, 오픈소스가 무엇을 제공해야 하는지에 대한 기대의 인플레이션일지도 모름
GitHub의 사회적 요소도 한몫할 수 있음. 별과 일반 사용자가 늘수록 프로젝트를 보러 오는 새 사람들을 만족시켜야 한다는 압박이 커짐
특히 커뮤니티의 관심과 요구가 만든 사람의 초기 비전과 맞지 않을 때 위험해짐
탄탄한 접근이고, 더 많은 사람이 기본값으로 삼았으면 함 커뮤니티 만들기나 어떤 책임을 떠안는 일은 예외적이고 의도적인 행동이어야 함
행동 강령과 LLM 정책을 보여주기식이라고 한 부분은 조금 동떨어져 보이지만, 민감한 주제라 그러려니 함
모든 행동 강령이나 LLM 정책이 보여주기식이라는 뜻은 아님
하지만 사용자도 커뮤니티도 없고 앞으로 만들 생각도 없는 1인 저장소에 붙여두면 보여주기식이 됨
혼자 쓰는 저장소에 나 자신을 위한 행동 강령은 필요 없음
이 논의가 힘을 얻고 실제로 통하는 합의로 이어지면 정말 좋겠음
소프트웨어를 만들고 건강하게 기여하는 방식은 많음
다만 서로 양립하지 않거나, 오픈소스의 높은 기준과 맞지 않거나, 가시성과 인기의 비용을 치르거나, 라이선스·자체 호스팅·코드 기여 미수락 같은 서로 다른 장치를 쓸 수 있음
커뮤니티 소프트웨어에서 재미와 공정함을 앞에 두는 좋은 길을 함께 찾았으면 함
글에서 제시한 상태는 유명인이 아닌 사람이 막 만든 모든 개인 오픈소스 프로젝트의 자연스러운 상태임
우리 모두 그런 식으로 운영되는 프로젝트를 꽤 많이 갖고 있음
문제는 사람들이 프로젝트에서 무엇을 얻고 싶은지 모르거나, 인기 있는 프로젝트를 운영하면 멋질 거라고 생각하면서 그 비용을 제대로 따져보지 않는 데 있음
그래서 의식적이든 아니든 관심 추구가 시작됨
“GitHub가 오픈소스 전체를 유지관리자에게 무급 일자리로 만들었다”는 말은 허용할 때만 맞음
막연한 명성의 약속을 빼면, 대부분의 상황에서 GitHub가 원래 하고 싶지 않은 일을 하게 만들 지렛대는 별로 없음
작은 프로젝트에 대해서는 이 글에 강하게 동의함
더 큰 프로젝트도 가장 성공적인 것들은 처음부터 열린 커뮤니티로 시작하지 않는 경우가 많음
좋아하는 프로젝트 중 다수는 대형 조직에서 개발을 시작했고, 핵심은 그 소프트웨어를 내부에서 실제로 적극 사용하고 있었다는 점임
그래서 유지관리자도 이미 보수를 받고 있었음
개인 프로젝트든 내부 팀이든, 개발자 자신의 일상적인 문제를 풀기 위해 만든 소프트웨어가 명성이나 사업화를 위해 만든 소프트웨어보다 더 성공적이고 덜 착취적으로 보임
Lobste.rs 의견들
이런 생각 때문에 https://casuallymaintained.tech/ 를 만들었고, 아주 마음에 듦
가장 유명한 예는 SQLite인데, 외부 기여를 거부함
Airbus 항공기 같은 임무 핵심 애플리케이션에도 쓰인다는 점을 생각하면 합리적인 정책임
SQLite는 오픈소스라서 원하는 만큼 복사하고 제한 없이 사용할 수 있지만, 공개 기여(open-contribution) 프로젝트는 아님
SQLite를 퍼블릭 도메인으로 유지하고 독점·라이선스 코드가 섞이는 일을 막기 위해, 기여를 퍼블릭 도메인에 바친다는 진술서를 제출하지 않은 사람의 패치는 받지 않음
꽤 신선한 관점임
어쩌면 저자가 맞고, 우리가 유지관리자에게 너무 많은 걸 요구하고 있는 것일 수 있음
망가진 건 오픈소스 전체가 아니라, 오픈소스가 무엇을 제공해야 하는지에 대한 기대의 인플레이션일지도 모름
GitHub의 사회적 요소도 한몫할 수 있음. 별과 일반 사용자가 늘수록 프로젝트를 보러 오는 새 사람들을 만족시켜야 한다는 압박이 커짐
특히 커뮤니티의 관심과 요구가 만든 사람의 초기 비전과 맞지 않을 때 위험해짐
관련 글: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
탄탄한 접근이고, 더 많은 사람이 기본값으로 삼았으면 함
커뮤니티 만들기나 어떤 책임을 떠안는 일은 예외적이고 의도적인 행동이어야 함
행동 강령과 LLM 정책을 보여주기식이라고 한 부분은 조금 동떨어져 보이지만, 민감한 주제라 그러려니 함
하지만 사용자도 커뮤니티도 없고 앞으로 만들 생각도 없는 1인 저장소에 붙여두면 보여주기식이 됨
혼자 쓰는 저장소에 나 자신을 위한 행동 강령은 필요 없음
이 논의가 힘을 얻고 실제로 통하는 합의로 이어지면 정말 좋겠음
소프트웨어를 만들고 건강하게 기여하는 방식은 많음
다만 서로 양립하지 않거나, 오픈소스의 높은 기준과 맞지 않거나, 가시성과 인기의 비용을 치르거나, 라이선스·자체 호스팅·코드 기여 미수락 같은 서로 다른 장치를 쓸 수 있음
커뮤니티 소프트웨어에서 재미와 공정함을 앞에 두는 좋은 길을 함께 찾았으면 함
글에서 제시한 상태는 유명인이 아닌 사람이 막 만든 모든 개인 오픈소스 프로젝트의 자연스러운 상태임
우리 모두 그런 식으로 운영되는 프로젝트를 꽤 많이 갖고 있음
문제는 사람들이 프로젝트에서 무엇을 얻고 싶은지 모르거나, 인기 있는 프로젝트를 운영하면 멋질 거라고 생각하면서 그 비용을 제대로 따져보지 않는 데 있음
그래서 의식적이든 아니든 관심 추구가 시작됨
“GitHub가 오픈소스 전체를 유지관리자에게 무급 일자리로 만들었다”는 말은 허용할 때만 맞음
막연한 명성의 약속을 빼면, 대부분의 상황에서 GitHub가 원래 하고 싶지 않은 일을 하게 만들 지렛대는 별로 없음
맞는 말임
예전에 약간 인기 있던 프로젝트가 있었고, 원하지 않는 기능에 대한 버그 보고와 풀 리퀘스트가 들어와 처리하느라 스트레스를 받았음
그때 이런 글을 읽을 수 있었다면 좋았을 것 같음
덧붙여 https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 도 볼 만함
작은 프로젝트에 대해서는 이 글에 강하게 동의함
더 큰 프로젝트도 가장 성공적인 것들은 처음부터 열린 커뮤니티로 시작하지 않는 경우가 많음
좋아하는 프로젝트 중 다수는 대형 조직에서 개발을 시작했고, 핵심은 그 소프트웨어를 내부에서 실제로 적극 사용하고 있었다는 점임
그래서 유지관리자도 이미 보수를 받고 있었음
개인 프로젝트든 내부 팀이든, 개발자 자신의 일상적인 문제를 풀기 위해 만든 소프트웨어가 명성이나 사업화를 위해 만든 소프트웨어보다 더 성공적이고 덜 착취적으로 보임