▲

오픈 소스의 미래

 (blog.gitbutler.com)
19P by xguru 1달전 | favorite | 댓글 5개
  • 우리 COO이자 공동창업자인 Anne이 독일 식품회사 Delinero의 CEO였을때 소송을 당했음. 공급업체가 제공한 라즈베리 잼을 "Himbeermarmelade"라고 표기했는데, 독일에서는 마멀레이드가 최소 20%의 감귤류를 포함해야만 "마멀레이드"라고 표기할 수 있는 'Konfitürenverordnung(잼 규정)'이 있었기 때문
  • 이는 일반적으로 사용되는 단어의 의미와는 상반되는 규정이었지만, 소수의 이해관계자들이 오래 전에 만든 법이기에 따라야만 했음
  • 현재의 "오픈 소스"도 이와 유사한 상태라고 볼 수 있음. OSI가 Konfitürenverordnung처럼 일반적인 용법과는 달리 진화한 용어를 여전히 엄격하게 규제하고 있음
  • 하지만 어떻게 하면 건설적인 방향으로 나아갈 수 있을까?

"오픈 소스"를 하지 않는 방법

  • GitButler가 클라이언트 코드를 "Fair Sourcing"하여 OSI 승인되지 않은 라이선스로 공개했을 때, 어떻게 발표할지 고민했음
  • 대부분의 사람들은 "오픈 소스"를 "GitHub에 공개된 것"과 동일시하고, 또한 GPL/카피레프트 라이선스의 다소 위험한 의미로 인해 사람들은 어떤 라이선스가 적용되는지 확인하는 데 매우 익숙함
  • 그렇다고 "Source Avaialable'd" 같은 모호한 말은 쓰고 싶지 않았고, 혼동을 피하기 위해 "오픈"이라는 말을 사용했지만, 공격을 받았음
  • 소수의 목소리 큰 사람들이 이 용어를 보호하고 구체화하려 한다는 것을 깨달음
  • "오픈 소스"는 "클로즈드 소스"의 논리적 부정이 아님. GitHub에 공개되고 참여하는 것과 OSI가 자체 규제하는 "오픈 소스"의 기술적 10가지 정의 사이에는 대중적 이해의 격차가 존재함

오픈 소스의 간략한 역사

  • 1950-60년대 초기 컴퓨팅 시대에는 소프트웨어가 하드웨어에 묶여 있어 별도로 구분할 필요가 없었고, 하드웨어 회사들이 자유롭게 배포했음
  • 1970-80년대 하드웨어가 상품화되면서 소프트웨어만의 가치가 생겼고, IBM, AT&T 등 대기업들이 비용을 들여 만든 소스 코드의 접근을 제한하기 시작함
  • 이에 Richard Stallman 등이 기업의 이해관계로부터 보호되는 자체 OS와 도구들을 만들기 시작했고, GPL 등 상호주의적 라이선스로 IBM, AT&T가 그들의 것을 사용하면 모두 자유 소프트웨어로 만들도록 강제했음

    "우리가 당신의 장난감으로 놀 수 없으면, 당신도 우리 장난감으로 놀 수 없습니다."

    • 그들은 이 운동을 "자유 소프트웨어"라고 명명하고 Emacs와 GNU 컴파일러 시스템과 같은 많은 놀라운 도구를 만들었음. 이는 오늘날에도 대부분의 현대 컴퓨팅의 기본 도구임
    • 자유 소프트웨어 운동의 근본적인 초점은 사용자가 소프트웨어를 실행, 복사, 배포, 연구, 변경 및 개선 할 수 있는 자유를 보장하는 것이었음. 그 당시 그들을 둘러싼 기업 이익에 의해 그들에게서 빼앗긴 자유
  • 1990년대 초 Linus Torvalds의 리눅스 커널로 완전한 OS를 갖추게 되었고, LAMP 스택 등 자유 소프트웨어 생태계가 성장하며 기업들도 사용하고 의존하게 됨
  • 1997년 Eric Raymond가 자유 소프트웨어 개발 모델이 폐쇄형보다 우월하다는 에세이 "성당과 시장"을 발표했고, 이는 Netscape가 Navigator Suite의 소스 코드를 공개하는 것을 정당화하는 데 인용 됨
    • 넷스케이프가 소스 코드를 공개하기로 결정했을 때, 팔로알토에서 열린 전략 세션에서 레이몬드와 몇몇 저명한 Linux 및 자유 소프트웨어 개발자들은 "오픈 소스"라는 새로운 용어를 만들어 사용하기로 합의

    "회의 참석자들은 넷스케이프가 코드를 공개하도록 동기를 부여한 실용적이고 비즈니스적인 근거가 잠재적인 소프트웨어 사용자 및 개발자와 소통하고 커뮤니티에 참여하여 소스 코드를 만들고 개선하도록 설득할 수 있는 가치 있는 방법이라고 믿었습니다. 회의 참석자들은 또한 이러한 접근 방식을 식별하고 철학적, 정치적으로 초점을 맞춘 “자유 소프트웨어”라는 라벨과 구별할 수 있는 단일 라벨이 있으면 유용할 것이라고 믿었습니다."

  • 중요한 것은 "자유 소프트웨어"와 "오픈 소스" 사이에는 실질적인 법적 또는 실용적인 차이가 없다는 것
    • 대부분의 라이선스는 두 정의 모두에서 호환되고 인정됨
    • "오픈 소스"는 넷스케이프와 같은 더 많은 회사가 전문 소스 코드의 개방을 수용하도록 하기 위한 스톨만과 그의 운동의 정치적인 목표와 소프트웨어 개방의 실용성을 분리하기 위해 비즈니스 친화적으로 브랜드를 변경한 것일 뿐
  • 또는 자유 소프트웨어쪽 사람들이 얘기했듯이

    "오픈소스는 개발 방법론이고 자유 소프트웨어는 사회 운동입니다."

오픈 소스와 GitHub 시대

  • "오픈 소스"라는 문구의 정의와 마케팅은 1998년, 지금으로부터 25년 이상 전이었음. 그렇다면 컴퓨팅의 지난 25년 동안 오픈 소스와 소프트웨어 개발 분야에서 무슨 일이 일어났을까?
  • 특히 지난 10년간 GitHub와 GitHub 스타일의 소프트웨어 개발이 오픈 소스에 엄청난 영향을 미쳤음
  • 1998년에는 기업들에게 오픈 소프트웨어를 받아들이도록 설득하려 했지만, 현재는 거의 모든 오픈 소스 소프트웨어를 기업이 작성하거나 후원함
  • 가장 큰 변화 중 하나는 "개발 워크플로우의 표준화", 특히 GitHub에 의해 주도됨
  • 이전에는 오픈 소프트웨어 프로젝트와 기업의 프로젝트 사이에 큰 차이가 있었지만 이제는 거의 차이가 없음
    • 모두가 Git을 사용
    • 거의 모든 사람이 풀 리퀘스트(또는 병합 요청, 또는 이 기능을 복제한 다른 ​​방법)를 사용
    • 대부분의 팀은 GitHub Flow ( Trunk 기반 개발 , Gitlab Flow 등) 의 어떤 형태를 사용
  • 이제 저장소의 공개 여부만이 유일한 차이점임. 25년 전에는 프로세스에 많은 마찰이 있었지만 이제는 오픈 소스화하는 데 거의 프로세스 변화가 필요하지 않음

오픈 소스의 다음 단계는 무엇인가

  • 거의 모든 기업이 오픈 소스 소프트웨어를 사용하고 생산하게 되면서 오픈 소스 (자유 소프트웨어) 운동이 성공한 것일까?
  • 오픈 소스 세계에는 현재 두 가지 큰 문제가 있음. "개발자 지속 가능성"과 "상용 오픈 소스가 Viable한가"

개발자 지속 가능성 문제

  • 오픈 소스에 크게 의존하게 되면서 지속 가능성과 유지 보수 문제가 발생하고 있음. XZ Utils 백도어 악용 사건이 최근 유명한 사례
  • 거의 모든 유지 관리자가 소진과 괴롭힘으로 어려움을 겪고 있음. 오픈 소스 소프트웨어를 작성하고 유지 관리하면서 돈을 버는 것은 거의 불가능함
  • 대부분의 오픈 소스 개발자와 유지 관리자는 이제 대기업의 후원을 받고 있음
    • Linux, Git, Ruby, React 등을 살펴보면 중요한 오픈 소스 프로젝트의 대부분 기여자는 GitHub, Microsoft, Red Hat 등 기업 후원자가 전문적으로 고용함.
  • 개발자가 XZ Utils와 같은 프로젝트를 유지 관리하면서 제대로 된 생계를 꾸리기는 어려움
    • 한 회사가 개발자에게 지불하는 대신, 수천 개의 회사가 전문 유지 관리자에게 작은 금액을 지불하는 것이 이상적일 것
  • 주요 문제는 현재 이를 할 수 있는 좋은 방법이 없다는 것
    • GitHub Sponsors, Thanks.dev, Liberapay, Tidelift 등 유망한 이니셔티브가 있지만, 기업이 기부할 수 있는 적절한 인센티브 문제는 아직 해결하지 못함
  • Sentry는 OSS Pledge 라는 새로운 이니셔티브를 추진해 왔으며 , GitButler는 10월에 출시되면 참여할 계획
  • 하지만 이와 같은 방식이 오픈 소스 생태계에서 개발자의 지속 가능성이라는 크고 점차 커지는 문제를 해결할 수 있을지는 아직 알 수 없음

상용 오픈 소스의 문제

  • 개발자들은 오랫동안 오픈 소스와 오픈 커뮤니티를 사랑하며 자랐고, 회사와 프로젝트를 시작할 때 기본적으로 오픈하길 원함
    • 그러나 개별 유지 관리자와 마찬가지로 오픈 소스에도 기업의 지속 가능성 문제가 있음
  • Elasticsearch와 Redis의 사례에서 볼 수 있듯이, 전문적으로 소프트웨어를 개발하는 데 시간과 돈을 투자할 때 Amazon 등 대기업이 자신들의 작업물을 이용해 직접 경쟁하는 위험이 있음
  • 많은 전문 제작자들은 소프트웨어에 투자하고 나중에 그것이 자신들에게 불리하게 사용되지 않도록 하고 싶어함
    • 이는 라이선싱에 창의적이 되거나 소스 코드를 폐쇄하는 것을 의미함
  • 나는 Fair Source 운동이 이 증가하는 문제에 대한 훌륭하고 필요한 해결책이라고 믿으며, 지난 몇 년 동안 점점 더 많은 문제와 혼란을 야기한 오픈 소스 생태계의 격차를 메꾼다고 생각
    • 이는 대부분 허용되고, 소스를 사용할 수 있으며, GitHub 커뮤니티가 참여하는 전문 프로젝트를 가리키는 새로운 용어로, 이전에 비공개로 진행되던 프로젝트가 더 많이 공개되도록 장려하기 위해 절실히 필요한 솔루션이라고 생각

협업의 미래

  • 오픈 소스의 미래는 그저 "Open Source" 그리고 OSI의 10가지 Konfitürenverordnung만이 아님
  • 모두에게 가능하고 가치있는 Open Source, 안전한 투자를 위해 필요한 Fair Source, 중요한 기초 오픈 라이브러리와 프로젝트에 대한 대규모 공동 펀딩의 조합임
  • 중요한 오픈 소스 라이브러리 유지 관리를 지속 가능하게 만들어야 하고, 지속 가능한 상용 소스 사용 가능 라이선스 클래스를 수용하고 정상화해야 함
  • 가능한 한 모든 것을 허용하는 OSI 라이선스로 오픈 소스화해야 하며, 무엇보다 폐쇄형 소스를 과거의 일로 만들어야 함
  • 지금 당신이 할 수 있는 일은
    • 폐쇄형 소프트웨어를 Fair Source로 만들고
    • 오픈 소스에 의존한다면 OSS Pledge에 동참하는 것
▲
bus710 1달전  [-]

자본주의 세상에 살면서 오직 오픈소스에만 몰두 할 수 없는게 현실이죠. 한편으로는 정말 중요한 라이브러리나 유틸리티라면 기업들의 스폰서쉽이 더 주어지면 좋겠다 생각 합니다.

유저 스페이스의 데스크탑/터미널 유틸리티가 특히 이런 지원 받기가 어렵습니다. 커널이라면 대기업들이 지원을 많이 하고, 모바일이라면 앱스토어가 상업화가 잘 되어 있으며, 웹이나 펌웨어 등은 어느정도 마켓 분석을 하고 개발을 하기 때문에 걱정이 덜 한데, 일반 사용자들이 알게모르게 쓰는 소프트웨어와 라이브러리들은 허들 설정하기도 어려운 편이라 돈 벌기 정말 어려운 것 같습니다. 오픈소스가 꽤 활발하면서도 그 이상 발돋움하기 쉽지 않죠.

답변달기
▲
bus710 1달전  [-]

오픈소스를 사랑하고 즐겨쓰는 만큼, 보이지 않는 곳에서 열심히 다수를 위해 헌신적으로 개발하는 사람들 또한 적절한 라이센스 설정으로 혜택을 받으면 좋겠다 생각 합니다.

답변달기
▲
chabulhwi 1달전  [-]

드루 디볼트(Drew Devault)가 쓴 글 'So you want to compete with or replace open source(오픈 소스와 경쟁하거나 오픈 소스를 대체하고 싶다고요?)'에 다음 문구가 나옵니다.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

자유 및 공개 소스 소프트웨어는 서로 다른 조직에 속하는 기여자들이 협업할 때 공동 이익이 발생하지만, 공정 소스 소프트웨어는 독점적 지위를 누리는 개인이나 조직을 위해 다른 기여자들이 공짜로 협업할 이유가 적거나 없습니다.

어쨌든 저도 공정 소스가 폐쇄 소스보다 낫다고 생각하고, 오픈 소스 소프트웨어의 관리자가 자신의 노력에 대한 보상을 받고 싶은데 그러지 못하는 것을 저도 원치 않습니다.

다만 공정 소스가 무료로 개발 기여라는 혜택을 오픈 소스처럼 누릴 수 있을지는 의심스럽습니다. 그리고 누가 자신의 소프트웨어를 오픈 소스로 배포할 때, 그 사람은 자신이 아무 이용자에게도 금전적 보상을 받지 못하{고/거나}, 그 소프트웨어가 클라우드 대기업의 '공짜 점심'이 될 수 있다는 점을 명심해야 합니다.

답변달기