24.11.16(토) 인천스타트업파크 6층 커넥트홀
Keynote
오픈소스 멘토링
오픈소스는 문화다
#1 토스 오픈소스 이야기: 이 중 하나는 터지겠지
github id : raon0211 토스 head of fe engineering
1) 왜 오픈소스를 만드는가?
채용, 브랜딩, 있어빌리티 ← 지속가능성이 낮음
“아무것도 없으니까 오픈소스를 한다”
있어보이려고 만들어서 공개하고보니 힘들었다.
요청사항들이 많이 들어오다보니 리뷰 비용과 소통하기가 힘들었다.
그럼에도, 생각지도 못한 발전이 있기는 했었다.
즉, 완성된 것을 자랑하기 위해 내놓는 것이 아닌, 내가 만들고 싶은 것을 도움을 얻어가며 만들기 위해 오픈소스를 한다.
완성되지 않은 것을 공개해도 반응이 뜨거울 수 있다. 기여자들 덕분에 순식간에 완성될 수 있고, 재밌다.
무언가 만고 싶다면, 혼자서 일부만 만들어서 공개하고, 사람들과 소통하며 재밌게 완성시켜보세요
2) 오픈소스 라이브러리를 성공시키는 법
사실 es-toolkit도 사내에서 반응이 좋지 않았다
오픈소스 라이브러리 성공 방정식 : 관심 = 가치 x 홍보 x 운
(값이 0이 되는게 있어선 안된다)
3) 한국에서 오픈소스
미국에서 보통 오픈소스를 시작하는 개인적 견해 :
완벽하지 않아도 지식을 개방하고 공유하는 Geek스러운 문화가 있기 때문
#2 식탁보 프로젝트의 어제, 오늘, 그리고 내일
메가존 소프트웨어 클라우드 엔지니어 github repo : yourtablecloth
#3 오픈소스 웹브라우저 개발자는 이렇게 일한다
chromium committer
1.
웹 표준 : WHATWAC W3C
2.
문서 : chromium docs
3.
구현 내용 선정 : Issue Tracker
4.
Feature 문서(Blink Intents)
5.
Design Doc(필수X) : 테크 스펙 개발 계획서 명세서
6.
개발 준비
7.
스타일 가이드 / 정적 분석
8.
테스트 : unit test web-platform-test(wpt)
9.
리뷰
#4 오픈소스 매커니즘 : 오픈소스 생태계 전반에 대해
github repo : skydoves
오픈소스 생태계
1.
메인테이너, 주 기여자
2.
소비자, 2차 기여자
3.
잠재적 소비자
첫 번째 기여하기
•
공개 공포증 극복하기
•
버그 수정 말고도, 오탈자 수정이나 번역의 작은 기여부터 시작
•
사용자 경험 공유
코드 투명성
•
코드의 공개를 두려워하지말자. 평가에 무서워할 필요 없음
오픈소스 라이프 사이클
1.
설계
•
청사진에 대해 프로젝트 실행 가능성(구현 가능성) 검증 단계
•
문제 정의 : 왜 문제? 무엇이 문제?
•
존재하는 아이디어 있는지 체크
•
의존성 검증
2.
개발
•
구현 & 테스트 단계
•
구현 도중에 API 설계가 바뀔 수 있음
•
API 표면을 최소화 & 외부 API 의존성 최소화 필요
3.
준비
•
API 코드 주석 구체화
•
API 문서 엔진을 통한 페이지 제공
•
라이브러리 문서화 : README 파일
4.
배포
5.
피드백 및 마케팅 루프
•
지인 활용
•
커뮤니티 활용
#5 오픈소스로 공부하기
flutter_naver_map maintainer github repo : note11g
오픈소스 ← 뭔가 어려워보임
(건드려볼 자신이 없음)
천리길도 한걸음부터 : 하나의 메서드부터 한줄씩 뜯어보자
(코드를 읽는 순간에는 항상 “왜?”라는 의문점을 가지기)
장점
•
고품질의 코드 확인 가능
•
기술 습득
•
코드 작성의 자신감 획득
•
두려움 사라짐
#6 주니어도 한다! 업무에선 쓰지 못하는 오픈소스 기여하며 성장하기
github repo : chickenchickenlove
오픈소스는 취준에 좋은 수치를 나타내는 증거가 되어줄 수 있다.
오픈소스의 이슈가 명확하다고 생각된다면, PR을 생성하는 데 까진 생각보다 엄청 얼마 안 걸린다.