오픈소스 생태계 일원으로서의 개발자(자막 버전)
•
3 recomendaciones•3,200 vistas
2nd Naver OpenSource Seminar에서 발표한 내용입니다. https://naver.github.io/OpenSourceGuide/book/Seminar/2nd-seminar.html
Recomendados
Más contenido relacionado
Similar a 오픈소스 생태계 일원으로서의 개발자(자막 버전)
Similar a 오픈소스 생태계 일원으로서의 개발자(자막 버전) (20)
Más de JeongHun Byeon
Más de JeongHun Byeon (20)
오픈소스 생태계 일원으로서의 개발자(자막 버전)
- 1. 오픈소스 생태계 일원으로서의 개발자 2018.02.23 Outsider @ Naver OpenSource Seminar
- 3. I ♥ OpenSource 저는 오픈소스를 좋아합니다. 여기서 오픈소스는 여러가지 의미로 사용할 수 있 습니다.
- 4. 개인 프로젝트의 소스코드 공개 (저장소 사용 목적) 1
- 5. 개인 프로젝트의 소스코드 공개 (저장소 사용 목적) 1 오픈소스라는 말 그대로 그냥 소스코드를 공개한 프로젝트들이 있습니다. 이는 보통 저장소를 사용하는 목적입니다.
- 6. 2 다른 사람들이 사용하는 오픈소스 (프레임워크, 라이브러리, 도구)
- 7. 2 다른 사람들이 사용하는 오픈소스 (프레임워크, 라이브러리, 도구) 사람들이 주로 오픈소스라고 할때 생각하는 다른 사람들이 사용하는 오픈소스 프로젝트들이 있습니다.
- 8. 2 다른 사람들이 사용하는 오픈소스 (프레임워크, 라이브러리, 도구)보통은 1번에서 2번으로 발전하는 것이 자연스러운 흐름이라고 생각합니다. 요즘은 회사가 주도하는 오픈소스 프로젝트도 많지만 이도 역시 회사가 내부에서 필요해서 만들었다가 공개하는 자연스러운 흐름을 가집니다.
- 9. “ 처음에 왜 오픈소스를 시작했나요?
- 10. “ 처음에 왜 오픈소스를 시작했나요? 얼마전 면접을 보다가 이런 질문을 받았습니다.
- 12. https://unsplash.com/photos/yjePAp-tpmQ 언제 왜 오픈소스에 관심을 가지고 하기 시작했는지 잘 기억이 나지 않았습니다. 그래서 GitHub 히스토리를 찾아보기 시작했습니 다.
- 14. 주로 GitHub을 사용했는데 2010년에 처음 가입했고 이때는 주로 다음과 같은 용도로만 사용했습니다.
- 15. 2010 개인 목적의 웹사이트 dotfiles 관리 학습 목적으로 만든 데모 프로그램 주변 개발자들과의 그룹 프로젝트
- 16. 2010 개인 목적의 웹사이트 dotfiles 관리 학습 목적으로 만든 데모 프로그램 주변 개발자들과의 그룹 프로젝트 앞에서 말한 1번 목적의 개인 저장소 목적이 위주였습니다.
- 17. 공개 저장소는 공짜니까
- 18. 공개 저장소는 공짜니까 지금은 private 저장소를 이용하고 있지만 public으로 공개하면 저장소가 공짜이므로 그냥 공개해서 쓰고 있었습니다. GitHub의 이런 정책은 코드 공개를 장려합니다.
- 20. 다른 저장소에 처음 이슈를 남긴건 2011년 중순이었습니다. 어떤 프로젝트인지 기억도 나지 않지만 뭔가 인증을 구현하려다가 오류가 나서 보고한 것으로 보입니다.
- 22. 이슈를 올리고 왜 오류나는지 좀 더 찾아봤는지 이슈를 수정해서 몇일 뒤에 PR을 올렸습니다.
- 23. 첫 PR은 무참히 Closed! 회심의 첫 Pull Request가!!
- 25. 첫 PR이 닫혀서 상처받았는지 다음 PR은 2년 정도가 지난 2013년에서야 당시 관심있던 Node.js에 올렸습니다. Closed로 나오지만 직접 커밋을 가져가서 합친거라 이 PR은 머지되었습니다.
- 27. 2015 2013 2014 2014 이후에는 개인적으로 시작했던 프로젝트가 우연히 사람들의 관심을 모아서 이슈 보고나 PR을 받게 되었습니다. 이후 제가 직접 관리하는 오픈소스 프로젝트가 생기게 되었습니다.
- 28. 개발하다 보니 어느새 오픈소스에 참여
- 29. 개발하다 보니 어느새 오픈소스에 참여 히스토리를 다 보고나니 특별한 계기를 가지고 오픈소스에 참여했다기 보다는 자연스럽게 오픈소스를 하게 되었습니다
- 30. 오픈소스가 없는 개발은 상상하기 어렵다
- 32. 오픈소스 프로젝트에 참여(기여)하는 방법 다른 오픈소스 세미나도 참석해 봤지만 사람들이 이런 부분을 궁금해 하는 것 같았습니다.
- 33. 나 회사 오픈소스
- 34. 나 회사 오픈소스 이런 질문을 보고 있다보면 사람들이 오픈소스를 자신이나 회사와는 별도의 세계(?)처럼 생각하는 느낌을 받았습니다.
- 35. 나 회사 오픈소스
- 36. 나 회사 오픈소스 저는 이런 모양이 아니라고 생각합니다.
- 37. 나 회사 오픈소스
- 38. 이미 오픈소스 생태계에 속해 있다 참여하는게 아니라...
- 39. Contribution?
- 40. Contribution? 그럼 기여라는 것은 무엇일까요?
- 42. Contribution 사용 홍보 번역 리포팅 문서화 코드 제출 상당히 많은 부분이 기여입니다. 소프트웨어는 사용자가 필요하니 사용하는 것도 기여이고 글을 쓰거나 세미나에서 발표, Stackoverflow에 질문,답변을 올리는 것도 기여입니다.
- 43. Contribution 사용 홍보 번역 리포팅 문서화 코드 제출 저희는 영여권이 아니니 문서나 글을 번역하는 것도 생태계에 큰 기여를 하는 것이고 좀 더 나아가서 이슈가 생기면 이슈 보고를 하고 올라온 이슈에 답변을 달고 요즘은 문서화가 너무 중요하므로 실제와 다르거나 누락된 문서를 채우는 부분도 너무 중요한 부분입 니다.
- 44. Contribution 사용 홍보 번역 리포팅 문서화 코드 제출 물론 코드 제출을 할 수 있으면 제일 좋다고 생각합 니다. 물론 이 모두가 중요한 기여이지만 사용자 수에 비해서 코드 제출을 하는 사람이 훨씬 적기 때문에 중요성면에서 아래에 적은 것일 수록 더 중요하게 생각하고 있습니다.
- 45. 오픈소스를 하는 이유는....
- 46. 오픈소스를 하는 이유는.... 오픈소스 생태계에 의존하고 있으므로
- 47. 오픈소스 회사 나
- 48. 오픈소스 회사 나 오픈소스 생태계에 의존하고 있고 거기에서 도움을 받고 있으므로 자연스럽게 오픈소스에 관심을 가지고 참여하려고 하고 있습니다.
- 49. I ♥ OpenSource
- 50. I love 오픈소스 프로젝트 오픈소스 생태계 소스 코드 공개 공유 문화 사이드 프로젝트
- 51. 오픈소스가 가장 진보된 개발 프로세스를 가지고 있다
- 52. 오픈소스가 가장 진보된 개발 프로세스를 가지고 있다 오픈소스가 가장 진보된 개발 프로세스를 가지고 있다고 생각합니다. 그리고 저는 대부분의 개발 프로세스를 오픈소스에 서 배웠습니다.
- 53. What I learned 커뮤니케이션의 방법 협업의 방법과 중요성 테스트 코드의 중요성 지속적 통합 / 지속적 배포 코드의 품질 관리
- 54. 오픈소스 개발자들에게 조금 더 고마운 마음을 가질 필요가 있다
- 55. 내가 못하는 영역을 대신 개발해 주는 사람 오픈소스 개발자들에게 조금 더 고마운 마음을 가질 필요가 있다
- 58. 오픈소스 생태계가 더 잘 돌아가도록 만들 책임이 있다
- 59. 오픈소스 생태계가 더 잘 돌아가도록 만들 책임이 있다 알아서 잘 돌아가지 않는다
- 60. 대부분의 프로젝트는 컨트리뷰션이 더 필요하다
- 61. 버스 팩터(Bus factor): 팀원 중 일부가 버스에 치였을 때 프로젝트에 영향을 줄 수 있는 수
- 62. 버스 팩터(Bus factor): 팀원 중 일부가 버스에 치였을 때 프로젝트에 영향을 줄 수 있는 수 버스 팩터는 팀에서 일부가 갑자기 빠졌을 때 프로젝트에 영향을 줄 수 있는 수를 의미합니다. 팀원이 5명인데 1명이 프로젝트의 핵심부분을 거의 개발하고 나머지는 그 내용을 잘 모르는 경우 이 1명 이 빠지게 되면 프로젝트의 큰 영향을 주므로 이 경우 버스팩터는 1입니다. 버스팩터는 높을수록 좋습니다.
- 63. babel/babel
- 64. babel/babel 현재 대부분의 JavaScript 프로젝트가 트랜스파일에 사용하는 bable의 상위 커미터입니다. 여기서 2명은 2016년 이후에는 참여하지 않습니다.
- 65. webpack/webpack
- 66. webpack/webpack 웹 번들링에 사용하는 webpack은 1번에 있는 사람이 대부분의 커밋을 하고 있고 6위로만 내려가도 커밋수가 38개 밖에 되지 않습니다. 오픈소스 프로젝트의 커밋수가 전부는 아니지만 전세계가 사용하는 webpack이 sokra 한명한테 거의 의존하고 있는 것이나 마찬가집니다.
- 68. expressjs/express Node의 웹 프레임워크인 express도 상황이 크게 다르진 않습니다. tj는 이제 물러났고 dougwilson이 혼자 관리하는 것이나 마찬가지인 상황입니다. 앞의 설명대로면 버스 팩터가 1입니다.
- 70. spring-projects/spring-framework Spring 프레임워크는 뒤에 Pivotal이라는 회사가 있어서 좀더 상황이 좋습니다.
- 72. spring-projects/spring-framework 그래도 커밋 순위 50위 까지만 가도 커밋수가 3개밖에 되지 않습니다. 스프링 프레임워크에 커밋을 4개만 넣으면 커밋순위 50위 안에 들 수 있습니다. (스프링에 커밋넣기가 쉽지는 않지만...)
- 75. 오픈소스 생태계에 생산적인 방향으로... 메인테이너들이 지치지 않도록 해야 한다 의견은...
- 76. 오픈소스 생태계에 생산적인 방향으로... 메인테이너들이 지치지 않도록 해야 한다 의견은... 프로젝트때문에 고생을 할 수도 있고 맘에 안드는 부분이 있습니다. 이럴때 비난하거나 탓하기 보다는 메인테이너들이 지치지 않게 생산적인 피드백을 하고 도와줄 필요가 있습니다.
- 79. 이는 주요 프로젝트를 watch 걸고 24시간 뒤에 새로 업데이트된 이슈의 알림 숫자입니다. 이 프로젝트의 메인테이너라면 매일 100개 정도의 이슈를 읽어봐야 하는 겁니다.
- 80. 특정 오픈소스에 대한 비난 보다는 피드백 1
- 81. 특정 오픈소스에 대한 비난 보다는 피드백 1 굳이 메인테이너들이 지칠만한 얘기는 안하는게 좋습니다.
- 82. 이슈 보고를 할 때는 재현가능한 예제와 상황을 제공해야 한다 2
- 83. 이슈 보고를 할 때는 재현가능한 예제와 상황을 제공해야 한다 2 앞에서 본것처럼 메인테이너들은 오픈소스가 풀타임 잡이 아닌데도 처리해야 할 이슈가 많습니다. 그들의 시간을 줄여줄 수 있게 많은 정보를 한꺼번에 제공할 필요가 있습니다.
- 84. 자신의 이슈를 빨리 처리해 달라고 요청하지 말자 3
- 85. 자신의 이슈를 빨리 처리해 달라고 요청하지 말자 3 급하면 어떻게 진행중인지 물어볼 필요는 있습니다. 하지만 메인테이너들이 저희가 급하다가 먼저 처리해 줄 의무는 없고 앞에서 얘기했듯이 보아야 할 이슈가 많습니다. 좀더 느긋하게 기다리거나 적극적으로 해결책을 제시할 필요가 있습니다.
- 86. 처리할 수 있는 이슈는 답변을 달거나 Pull Request를 제출한다 4
- 87. 후원하기
- 88. 후원하기 돈은 많은 문제를 해결할 수 있으니 오픈소스 프로젝트가 돌아가도록 후원하는 것도 한 방법입니다.
- 92. 후원한 돈을 프로젝트가 어떻게 사용하는지도 볼 수 있습니다.
- 93. 한달에 $2씩 5개 프로젝트에 기부
- 94. 한달에 $2씩 5개 프로젝트에 기부 저는 저한테 부담안되는 정도도인 한달에 $10 정도를 기부하고 있습니다. 주로 사용하는 프로젝트에 정기적으로 기부하고 있습니다.