오픈 소스: 그렇게 무섭지 않습니다!

다음은 여성 개발자를 위한 탑탈 장학금 런칭에 앞서 게시된 내용입니다.

개발자로서 최신 기술 동향을 파악하는 것은 흥미롭고 도전적인 일입니다. 매일 새로운 언어, 프레임워크 및 장치가 우리의 관심을 끌고 모임, 포럼 및 채팅에서 대화에 박차를 가합니다. 그러나 우리 개발자 커뮤니티는 도구가 아니라 사람으로 구성되어 있으며 사회정치적 측면을 탐구하는 것이 매력적입니다.

Toptal에서 우리는 최근 여성이 오픈 소스에 기여하는 정도와 여성들이 더 많은 기여를 하는 것을 방해하는 요인에 대해 흥미로운 대화를 나눴습니다. 그래서 우리는 이 문제를 조사했습니다. Breanden Beneschott 및 Bozhidar Batsov와의 대화에 참여하면서 궁금한 점이 생겼습니다. Bozhidar는 GitHub의 최고 오픈 소스 기여자 중 하나입니다. 내가 어디 있지? 오늘 현재 저의 공개 GitHub 계정을 확인해보면, 주로 학생들을 대상으로 수업에서 사용한 소규모 테스트 프로젝트입니다. 그것들은 반쯤 구운 것이며 확실히 내 기술이나 전문 지식을 대표하지 않습니다. (당신은 이것에 대해 내 말을 들어야 할 것입니다.) 누군가가 그 계정에서 찾을 수 있는 것을 기반으로 나를 고용하는 것을 고려한다면 나는 생계를 유지하기 어려울 것입니다. 그래도 저는 20년 이상 전문 개발자였으며 ​​일상 업무에서 기억하고 있는 것보다 더 많은 오픈 소스 소프트웨어를 사용해 왔습니다. 시간이 지남에 따라 Linux 커널을 해킹하여 특정 요구 사항에 맞게 구부렸고, 내가 구입한 모든 라우터와 NAS를 조정했으며, Raspberry Pi 대기자 명단에서 몇 달을 참을성 있게 기다렸다가 손에 들고 집에서 만든 domotics를 다음과 같이 얻을 수 있었습니다. 좋아요. 그럼에도 불구하고 이러한 조정과 테스트 중 어느 것도 내 GitHub에 공개 소스가 되지 못했습니다. 또한 Tomcat의 첫 번째 버전 중 하나에서 버그를 수정하는 것 외에는 오픈 소스 프로젝트에 기여한 적이 없습니다. 궁금하지 않나요?

단순히 시간이나 관심이 부족해서라고 생각할 수 있지만 그렇지 않다는 것을 알고 있습니다. 내 개인 프로젝트에 관해서는, 아무도 내가 한 일에 정말로 관심을 가질 수 없다고 생각했을지 모르지만, 대부분은 모든 사람이 보고 후손을 위해 내 작품을 출판한다는 바로 그 생각이 저를 많이 두렵게 합니다. 그리고 GitHub에서 개인 프로젝트를 언제든지 해제할 수 있지만 널리 사용 가능한 오픈 소스 프로젝트에 기여하려고 하는 날에는 되돌릴 수 없습니다. 내 코드가 충분하지 않으면 어떻게 합니까? 문제를 제대로 이해하지 못했다면? 내 pull 요청이 거부되면 어떻게 됩니까? 사람들이 나를 트롤한다면?

대부분이 여성인 동료 친구 개발자와의 빠른 통화는 곧 저에게 이 문제가 있는 유일한 사람이 아니라는 확신이 들었습니다. 하지만 엔지니어에게는 문제가 없고 해결책만 있지 않습니까?

오픈 소스 프로젝트에 기여하면 극적인 차이를 만들 수 있기 때문에 이것은 해결해야 할 중요한 문제입니다.

• 당신의 경력 동안 : 많은 고객들이 당신을 고용하기로 결정하기 전에 당신의 사회적인 모든 것을 살펴볼 것입니다. GitHub 계정 및 LinkedIn 이력서가 Facebook 및 Twitter 프로필과 함께 목록의 맨 위에 있습니다. 현명하게 사용해야 합니다.
• 당신의 기술적 능력을 위해 : 다른 개발자들이 작성한 코드베이스, 그리고 종종 아주 좋은 코드베이스를 살펴보면 많은 것을 배울 수 있습니다. 잘못 작성된 코드베이스에서 의미를 추출하는 능력은 당신에게 도전하고 가르쳐 줄 것입니다.
• 귀하의 소프트 스킬 : 오픈 소스 소프트웨어는 협업 프로세스이며 거의 모든 흥미로운 프로젝트가 팀에 의해 구축됩니다. 모든 사람이 사용하는 도구를 통해 다른 개발자와 협력하고 팀과 조화를 이루며 효율적으로 의사 소통하는 방법을 배우는 것은 숙련된 개발자가 아니라 훌륭한 개발자가 되는 것입니다.
• 커뮤니티를 위해 : 오픈 소스 프로젝트에 기여하는 모든 비트가 중요합니다. 더 많이 기여할수록 더 좋지만 번역에서 작은 오타 하나라도 수정하면 최종 제품이 더 좋아질 것입니다.
• 네트워크의 경우 : 수백 개의 이력서를 회사에 보낼 수 있지만 개인적인 인맥을 가진 동료를 갖는 것만큼 효과적인 것은 없습니다. 오픈 소스 프로젝트에 적극적으로 참여하면 사람들을 만나고 존경을 받을 수 있으며 평판이 높아지며 이는 모든 전문가에게 매우 중요합니다.

이것은 이 두려움과 싸우기 위한 나의 작은 개인적인 여정입니다. 이 기사를 게시하는 것은 여정 자체의 일부입니다. 블로그 글 작성이 막혔거나 작은 기여라도 하기 두려운 분들이 결국에는 그렇게 무섭지 않았다는 것을 알게 되기를 바라는 마음에서 글을 씁니다. 또한 오픈 소스에 기여하고 싶지만 어디서부터 시작해야 할지 잘 모르는 사람을 돕기 위한 것이므로 기본부터 시작하겠습니다.

오픈 소스 소프트웨어란 무엇이며 어디에서 찾을 수 있습니까?

오픈 소스 소프트웨어(줄여서 OSS)는 소스 코드와 함께 릴리스된 모든 소프트웨어이며 수정 및 재배포할 수 있는 라이선스가 포함되어 있습니다. 웹사이트, 메일링 리스트 또는 올빼미를 통해 어디든지 전달할 수 있습니다. 가장 일반적인 시나리오이자 우리가 관심을 갖고 있는 시나리오는 코드베이스가 협업 리포지토리에서 유지 관리되는 경우입니다. 여기서는 GitHub에 중점을 두고 있지만 SourceForge 및 Bitbucket과 같은 다른 옵션이 있습니다. GitHub는 매우 친숙하고 방대한 사용자 기반을 가지고 있으며 모든 종류의 코드와 사용하는 모든 개발 환경에서 사용할 수 있습니다. 중요하게도 비 오픈 소스 프로젝트에도 널리 사용됩니다. 다음 클라이언트 프로젝트가 그곳에서 호스팅될 가능성이 있으므로 작업 방법을 아는 것은 그 자체로 유용한 기술입니다.

코딩을 할 줄 모른다면?

이 글을 읽고 있다면 코딩을 배우고 싶을 것입니다. 여러 무료 및 유료 웹사이트에서 놀라운 과정을 찾을 수 있습니다. 배울 언어를 선택해야 합니다. 기본 설정이 없으면 JavaScript로 이동하십시오. 웹 브라우저에서 시작하는 데 필요한 모든 것이 이미 있으며 가장 널리 사용되며 시장성이 있는 기술 중 하나입니다. 개인적으로 가장 좋아하는 것은 웹 개발과 과학 응용 프로그램 모두에서 사용되는 Python입니다. 또한 Udacity에서 개인적으로 가장 좋아하는 초급 과정인 "Intro to computer science"를 가지고 있습니다. 학습하면서 프로젝트를 진행하는 실습 과정이기 때문에 마음에 듭니다. Coursera, Khan Academy 및 PluralSight에서 다른 여러 과정을 찾을 수도 있습니다.

Git을 모른다면?

앞서 언급했듯이 Git을 아는 것이 중요하므로 Git 클래스를 수강하세요. 잠시 동안 Git으로 작업한 경우에도 수행하십시오. Git을 실제로 공부하기 전까지는 Git에 대해 얼마나 모르는지 모릅니다. rebase 명령이 수행하는 작업을 자신 있게 설명할 수 없는 경우 수행하십시오. 잘못된 리베이스가 두렵지 않더라도 그렇게 하십시오. Code School에서 전체 Git 경로를 선택했지만 다른 사이트에서 더 많은 옵션을 탐색할 수 있습니다.

GitHub에서 프로젝트를 선택하려면 어떻게 해야 하나요?

일상적인 개발에서 일부 OSS를 사용하고 있을 가능성이 있습니다. 친숙한 프레임워크를 선택하는 것이 좋은 출발점입니다. 기능과 프레임워크 작동 방식에 이미 익숙합니다. 소스 코드를 자세히 살펴보면 더 많이 배우고 그 논리를 훨씬 더 명확하게 이해할 수 있습니다. 특히 좋아하는 기술이나 도구가 있는 경우 이를 언급하는 프로젝트나 도구의 프로젝트 자체를 찾으십시오. 최후의 수단으로 GitHub Showcases에서 프로젝트를 확인하고 관심 있는 카테고리를 선택하여 시작할 수 있습니다.

예를 들어 GitHub 검색에서 "Raspberry"를 빠르게 검색하면 17,000개 이상의 저장소가 표시됩니다. 길을 잃기 쉽기 때문에 좋은 커뮤니티와 좋은 문제 추적 기능이 있는 프로젝트를 찾으십시오. 프로젝트를 선택할 때 다음 수를 확인하십시오.

• 기여자 : 10명 이상의 기여자를 대상으로 합니다. 이것은 프로젝트에 충분한 관심이 있어야 하며 단순히 작은 팀 노력이 아님을 확인해야 합니다. OSS를 처음 접하거나 너무 숙련되지 않은 경우 최대 50명의 기여자가 있는 프로젝트로 검색을 제한하십시오. 더 큰 커뮤니티는 더 큰 코드베이스와 더 복잡한 프로젝트를 의미합니다.
• 커밋 : 최소 1,000개의 커밋이 있고 가장 최근 활동이 1주일 이내인 프로젝트로 이동합니다. 한 달 이상 비활성 상태인 프로젝트는 OSS 용어로 오래되고 오래되었으며 빠른 응답을 받지 못할 것입니다. 매일의 활동은 건강한 프로젝트의 표시입니다.
• 문제 : 문제는 공개된 문제, 보고된 버그 또는 구현을 위해 요청된 기능입니다. 그것들은 당신에게 출발점을 제공할 것이고 프로젝트에 대한 관심의 좋은 지표가 될 것입니다.

또한 프로젝트의 주요 언어가 무엇인지 알아보십시오. 메인 프로젝트 페이지의 상단 바에서 언어 통계를 볼 수 있습니다. 시간을 내어 토론의 어조를 읽고 의견이 얼마나 친절하고 교육적인지 확인하십시오. 일부 프로젝트는 공격적인 커뮤니티로 악명이 높기 때문에 올바른 시작점이 아닐 수 있습니다.

성능과 관련된 모든 데이터에 매료되어 컬럼 기반 데이터 스토리지 프로젝트인 ScyllaDB를 선택했습니다. 나는 그것으로 일한 적이 없지만 코드베이스에 뛰어들 수 있기를 기대합니다. 내가 알고 있는 도구로 작업하는 것이 더 간단할 수도 있지만 저는 이것을 새로운 것을 배울 수 있는 도전이자 기회로 삼고 있습니다. 나머지는 청구서에 완벽하게 맞습니다. 18명의 기여자, 6.5k 커밋(가장 최근은 작성 당시 23시간 전), 178개의 미해결 문제가 있으며 활성 상태로 보입니다.

지금 무엇을 합니까?

먼저 저장소를 복제하고 컴퓨터에 소프트웨어를 설치하여 움직이는 부분에 대한 아이디어를 얻으십시오. 그런 다음 문제를 읽기 시작합니다. 준비가 되면 컴퓨터에서 문제를 재현할 수 있는지 확인한 다음 소프트웨어가 오작동하는 원인을 분석하기 시작합니다.

또 다른 접근 방식은 스스로 개선하거나 수정할 수 있는 것을 찾는 것입니다. 예를 들어 오타나 잘못 정렬된 글꼴을 발견했을 수 있습니다. 나는 작은 버그, 특히 스크립트 문서에 사용된 잘못된 변수 이름을 수정하기로 결정했습니다.

작은 것 같지만 잘못된 문서는 문서가 없는 것보다 훨씬 나쁩니다. 사용자는 ScyllaDB를 설치하고 설치 단계를 따르고 해당 스크립트에 작성된 내용에 맹목적으로 의존하게 되며 결국에는 많은 좌절을 겪게 될 것입니다. 이것은 제 능력에 완벽했으며, 이를 수정하려면 전체 프로세스를 따라야 하고 코드베이스에 약간 익숙해져야 합니다. 버그 수정은 지루하지만 프로젝트에 참여할 수 있는 좋은 시작입니다.

포크 만들기

이것은 사소할 수 있지만 현재 ScyllaDB 프로젝트의 경우 저는 Ms. nothing입니다. 내가 감독 없이 그들의 코드를 변경하도록 허용하는 것은 위험할 것입니다. 내가 해야 할 일은 내 GitHub 계정에 "포크"를 만드는 것입니다. 여기 내 ScyllaDB 포크가 있습니다. 모든 코드에 액세스할 수 있는 나만의 놀이터이며 원하는 대로 파일을 수정할 수 있습니다. 나만의 ScyllaDB 버전을 만들고 원래 목적과 완전히 다른 작업을 수행하도록 조정하고 싶다면 여기에서 할 수 있습니다. 포크를 만드는 것은 간단합니다. 프로젝트의 메인 페이지로 이동하여 "fork" 버튼을 클릭합니다. 전혀 무섭지 않습니다.

버그를 고칠 시간

이제 컴퓨터에서 코드를 테스트하고 필요한 수정을 할 때입니다. 먼저 컴퓨터에 Git 클라이언트를 설치했는지 확인합니다. 그런 다음 SSH 공개 키를 GitHub에 추가하고 ssh-agent에 의해 로드되었는지 확인합니다. 코드를 로컬로 가져오는 것은 간단합니다. 기본 분기 대신 포크를 가리키는 git clone 명령을 사용하세요.

 git clone [email protected]:acbellini/scylla.git

지금쯤이면 메인 브랜치에서 프로젝트를 테스트해야 하므로 로컬에서 코드를 빌드하고 동일한 방식으로 테스트할 것입니다. 참조는 상대적이므로 프로젝트가 의존하는 다른 GitHub 프로젝트를 분기해야 한다는 점을 명심하십시오. 제 경우에는 seastar, scylla-ami 및 scylla-swagger-ui를 포크해야 했습니다.

내가 수정해야 하는 버그는 비교적 간단합니다. conf/scylla.yaml 의 문서에는 3개의 구성 가능한 디렉토리가 언급되어 있습니다. 하나는 데이터 파일용, 하나는 커밋 로그용, 다른 하나는 분명히 사용되지 않는 캐시용으로, 모두 기본적으로 $CASSANDRA_HOME 의 일부 하위 디렉토리로 설정되어 있습니다.

코드를 자세히 살펴보면 기본값이 다르며 내가 시작한 문제 #372에서 언급했듯이 $CASSANDRA_HOME 을 사용해서는 안 된다는 것을 알 수 있습니다. 몇 가지 다른 설정으로 코드를 테스트하고 구성 파일에서 설정을 제거하고 사용되는 디렉토리를 확인하여 가설을 검증합니다. 모든 것이 정확하다고 확신하면 수정된 파일을 추가, 커밋 및 푸시할 수 있습니다.

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

커밋 메시지에서 해시가 앞에 오는 문제 번호를 도입했습니다. 이렇게 하면 GitHub에 내 코드를 문제 자체에 자동으로 연결하도록 지시합니다.

또 다른 중요한 점은 코드를 조사했을 때 캐시용 디렉토리인 세 번째 디렉토리가 실제로 사용되지 않는다는 것을 깨달았다는 것입니다. 너무 멀리 가서 이 설정 자체를 제거하거나 사용되지 않는 주석을 추가하고 싶지만 이는 문제 #372의 범위를 벗어나므로 이것과 엄격하게 관련되지 않은 모든 것을 커밋하는 것은 잘못된 것입니다. 문제. 변경 사항에 초점을 맞추고 당면한 작업으로 제한해야 합니다.

이 시점에서 코드는 수정되었으며 내 개인 포크의 GitHub에 있습니다. 여기서 무서운 부분이 발생합니다. ScyllaDB 사람들에게 내 코드를 수락하도록 요청하는 것입니다. 이것을 풀 리퀘스트라고 합니다.

마지막 단계: 풀 리퀘스트

GitHub의 웹 인터페이스에서 직접 pull 요청을 만드는 것을 좋아합니다. 명령줄에서 하는 것보다 더 직관적이고 오류가 없습니다. 풀 리퀘스트를 생성하려면 브랜치 이름 옆에 있는 작은 녹색 버튼을 클릭하기만 하면 됩니다.

주석은 GitHub에서 자동으로 계산되었습니다. 내 분기에는 이제 하나의 새 커밋이 있지만 포크를 만든 이후로 기본 저장소에 14개의 커밋이 더 있으므로 왼쪽에 있는 녹색 아이콘을 클릭하겠습니다.

운 좋게도 내 단일 커밋은 14개의 다른 커밋과 충돌하지 않으므로 GitHub에서 내가 가도 된다고 알려줍니다. 다른 의견이나 메시지를 추가할 필요가 없습니다. 커밋 메시지는 매우 짧지만 모든 것을 말해줍니다. 내 코드 변경이 수행하는 작업과 관련된 내용입니다. 내 요청을 확인하기 위해 마지막 버튼을 클릭하면서 불과 며칠 전 내가 무엇을 그렇게 무서웠는지 궁금합니다. 지금 나를 향해 포효하는 괴물은 없고, 지옥의 불길이 타오르지 않는 것 같다. 솔직히 전혀 무섭지 않았다. 드문 경우지만 내가 잘못 이해한 경우 수정 사항이 수락되지 않으며 그렇게 될 것입니다.

이제 문제 세부 정보를 확인하면 GitHub에서 이 문제를 참조하는 pull 요청이 있다는 메모를 자동으로 추가한 것을 볼 수 있습니다. 이것이 커밋 메시지에 있는 #372의 마법입니다. 이것은 이미 수정된 것을 수정하기 위해 다른 사람들이 시간을 낭비하는 것을 피하는 데 도움이 될 것입니다.

최종 메모

이제 pull 요청이 수락되기를 기다리고 있습니다. 그런 일이 발생하면 알림을 받게 됩니다. 이 작업에는 며칠, 심지어 몇 주가 소요될 수 있습니다. 누군가 내 코드를 검토하고 설명된 대로 작동하는지 테스트하고 문제를 수정하고 궁극적으로 코드의 나머지 기능에 부정적인 영향을 미치지 않는지 확인해야 합니다(읽기: 새 버그 생성). 이 모든 것은 누군가의 시간을 필요로 하므로 인내심을 가지십시오. 결국 내 풀 요청이 수락되면 ScyllaDB에 한 명의 기여자가 추가되고 문제가 하나 줄어들며 저는 첫 번째 OSS 기여를 받게 됩니다. 이제 여러분도 시도해 볼 때입니다. 결국, 그것은 전혀 무섭지 않습니다.