오픈소스 활동의 오해

많은 사람들이 오픈소스 활동에 대해서 관심이 무척이나 많다. 척박한 국내환경을 벗어날 수 있는 유일한 대안처럼 여기는 듯하다. 오해는 오해를 만들어 내며 잘못된 방향(묻지마 창업투자, 소프트웨어 수능과목 추진처럼)으로 이끌기도 한다. 난 예전부터 늘 지식공유 활동에 대해서 관심이 많았고, 오픈소스 활동을 한지는 사실 얼마되지는 않았다. ( 다른 사람들처럼 수년에서 십수년한게 아니니… ) 실제로 오픈소스 활동들을 하다보니 밖에서 보는 것과 실제로 느끼는 감정들이 다르다. 실제로 오픈소스 활동을 고민하고 있는 사람들을 위해서 글로 적고 싶다는 생각을 하였다.

1. 오픈소스를 꼭, 반드시 해야만 한다?

개발자 커뮤니티의 모임, 각종 컨퍼런스와 세미나에서 오픈소스 활동을 권장을 하고 있다. 큰 맥락에서 다 옳은 길이며 나또한 그렇게 믿고 사회를 발전 시키는 한 방법이라고 생각한다. 실제로 오픈소스 활동을 하면서 나의 보잘것 없는 실력을 깨닫기도 하고, 이런저런 시도를 하면서 발전을 하기도 한다. 하지만, 이 모든 것은 본인과 오픈소스 활동이 잘 맞을 때의 이야기이다. 오픈소스 활동은 일종의 문화활동, 취미활동과 유사하다. 따라서 본인과의 궁합(?)이 잘 맞는지가 아주 중요하다.

많은 엔지니어가 년초마다 새해결심들을 한다. 많은 항목들이 운동하기, 영어공부, 책 몇권 이상 읽기, 스터디 참석, 오픈소스 활동 등등의 것들일 것이다. 하지만,  우리에게는 24시간 밖에 주어지지 않고 모든 것을 다할 수 없다. 따라서, 결심이 실제 행동으로 옮겨지기까지는 많은 노력이 필요하다. 오픈소스 활동을 하기 위해서는 본인의 시간을 할애해야 한다. 실제로 행동에 옮겼더라도 많은 장애요소들이 많다. 특히 남의 코드를 읽는 일, 실력, 언어의 장벽은 노력해도 참 어렵다.

업무와 어느정도 연관이 있어 활동하는 나도 주당 몇시간 이상을 퇴근 후 메일링리스트를 읽고 답변하고, 코드를 읽으며 활동하다보면 어느덧 자정이다. 회사에서 일하며 지친몸으로 친구와의 치맥의 유혹을 벗어던지고도 이러한 활동들이 즐겁다면 본인에게 맞는 것이다. 그렇지 않다면, 기혼자라면 자식들과의 시간을, 미혼자라면 연애를 하는것이 인생을 훨씬 잘살아가는 방법일 것이다. 사랑을 하기에도 인생은 짧은거 같다. 오픈소스활동은 개발을 좋아하는 사람들의 한가지의 방법이라는 것으로 인식하는 것이 중요하며 단지 무슨 무슨 커미터라는 타이틀만 보고 덤비기에 이세계 사람들은 뜨네기를 너무나도 잘 안다.

2. 오픈소스 커미터들은 슈퍼개발자?!

스타트업에서 정의하는 슈퍼개발자와 일정규모 이상의 조직에서 정의하는 슈퍼개발자가 다르듯 상황에따라 슈퍼 개발자는 다르게 정의된다. 단어 자체가 가지는 모호한 성격이 있다. 오픈소스 커미터 또한 슈퍼개발자로 바라보는 일부 시선이 있는듯 하다. 나또한 예전에는 그렇게 바라보았고 동경해왔던 것이 사실이다.

하지만, 실제 활동을 하다보니 앞서 얘기한 것처럼 활동 자체를 즐기는 사람들이 아니면 꾸준히 하기 어렵고, 개발(프로젝트)을 정말 좋아하는 사람들이 아니면 이러한 활동들을 하기 어렵겠다라고 많이 느낀다. 시간을 많이 쓰다보니 커미터들의 개발실력은 당연히 어느정도 갖추어지는 것은 맞는듯하지만(확률상) 모든 것을 다 알며 개발하는 것은 아니다. ( 느끼기에 타고난 머리가 있는 사람들도 있지만 사실 시간을 많이쓴 사람들이 더 많은 느낌이다.) 따라서, 오픈소스 커미터를 슈퍼개발자 혹은 동경의 대상으로 바라보기보다는, 활동자체를 즐기며 개발을 즐기는 사람이라고 보는 것이 더 객관적인 평가일듯 하다.

마무리,

오픈소스가 무조건적인 ‘선’, 상업적인 소프트웨어가 무조건 ‘악’ 이 아니다. 서로의 영역들이 존재하고 서로 긍정적인 경쟁을하며 IT업계가 더 발전하고 있다. 지식이 공유되며 사회가 발전하는 것이라고 믿고 있고, 오픈소스 활동또한 이러한 맥락이라고 생각한다. 하지만, 무조건적인 찬양은 지양해야하며 객관적인 시선을 유지할 필요가 있다. 자기의 시간을 할애하면서도 오픈소스 활동에 도전을 하고 싶다면 아래 슬라이드가 도움이 될 것이다.

2013년 10대 키워드

  • 첫사랑 설램과 사랑
  • 영어
  • OSCON 2013 발표
  • 아파치 커미터
  • KTH 구조조정, 그리고 KT
  • 두번째 미국 방문
  • 공개 소프트웨어 공헌상
  • 컨설팅과 한계
  • L* 로 차 변경
  • 모모팀 여행

아파치 프로젝트 메일링 리스트 구독하기( How to subscribe or unsubscribe ASF mailing list )

많은 사람들이 오픈소스 활동에 관심이 많지만 ( 스스로 프로젝트를 만들든 기존 프로젝트에 참여하든 ) 참여하는 비율은 굉장히 적다.
오픈소스 프로젝트라고해서 엄청 특별하다거나 이런게 아니다(어차피 사람들이 하는거니) 회사에서의 프로젝트 처럼 코드작성 외에 많은 일들이 있고, 어떤 형태든 참여가 필요하다.
짧은 생각으로는 많은 사람들이 코드커밋만이 참여라고 생각해서 참여가 적은듯한데, 참여의 시작은 ‘관심’이다. 어차피 오픈소스 프로젝트도 사용자가 있고 다양한 의견을 바탕으로 프로젝트의 품질을 더 높이게 된다. 보통 오픈소스 프로젝트들은 메일링 리스트로 서로의 의견을 나누게 되는데, 이번 글에서는 아파치 메일링리스트를 구독하는 법을 알아보도록 하겠다. 아래 예제는 유저그리드 프로젝트를 기반으로 되어있는데 아파치재단 하에 있는 프로젝트는 다 비슷하다.

1. 오픈소스 프로젝트 사이트 방문

아파치 유저그리드 사이트

사이트 주소 : http://usergrid.incubator.apache.org/

2. 메일링 리스트 주소 확인

메일링 리스트를 설명해둔 란을 찾는다. 보통 사용자, 개발자, 커밋 3가지 메일링리스트가 있고 3개의 역할이 조금씩 다르다. 보통 사용자, 개발자 2개를 구독한다.

Check mailing list

3. 메일링 구독하겠다고 발송

메일을 받고 싶은 곳에 로그인 후에 메일을 쓴다. 수신인에 user-subscribe@usergrid.incubator.apache.org 으로 1통, dev-subscribe@usergrid.incubator.apache.org 1통을 보내자. (제목, 내용은 상관없다)

4. 인증메일이 도착하고 다시 메일 발송

위와같이 확인을 위해서 다시 짧은 답장을 보내라고 한다. 그래서 바로 그냥 답장하면…

5. 메일링 구독완료

아파치재단의 모든 사이트는 메일링 리스트 구독에 대해 안내하게 되어있는데, 예시로 그루터에서 활발히 개발하고 있는 타조(Tajo) 또한 이렇게 메일링 리스트가 공개되어있고 구독할 수 있다. 그냥 관심만 가지는게 아니라 관심이 조그마한 행동으로(메일링 리스트 구독)이어지고 이렇게 계속적으로 관심이 이어지다보면 우연찮은 기회로 여러분들이 오픈소스 프로젝트에 참여하게 될 것이다. ;)

6. 메일링 구독해지신청

2013.12.07 추가된 내용이다. 페이스북이나 트위터를 통해서 구독방법을 공유했고, 해지하는 법도 알았으면 좋겠다는 피드백을 받고 이렇게 추가를 한다. 해지방법은 구독방법과 유사하지만 해지신청하는 메일주소가 다르다. 방금전 구독완료되었다는 메일에서 조금만 내려보면 아래와같은 내용과 메일주소가 나온다.

위메일로 메일을 보면 바로 해지가 된다.

해지완료메일

아파치 커미터가 되다! ( Apache Usergrid )

저는 한국에서 BaaS(Backend As A Service) 프로덕트인 baas.io 를 만들고 있습니다. 국내에서 보기드물게 개발자 문화를 만드려고 노력하였던(만들어 나가던) KTH에 합류해서 baas.io 를 만들게 되었고, 2012 H3에서 baas.io 런칭을 위해서 동료들과 함께 고생했던 기억들이 새록새록 떠오르네요.

2012.11.01 부터 비공개 서비스를 시작하게 되었고 현재까지 꾸준히 서비스는 성장을 하고 있습니다. 안타깝게도(혹은 좋은 경험을 한 개발자를 업계로 돌려보내서 고맙게도) KTH는 구조조정을 하게 되었고 수익성이 없는 사업은 접혔고, 보았던 동료를 내일 볼 수 없는 안타까운 상황을 맞이했습니다.( 인생에서 한번의 경험이면 족할듯 합니다… ) 올해 초 이런저런 복잡한 상황들을 뒤로하며 우여곡절끝에 baas.io 프로젝트는 KT에 이관되어 계속 훌륭한 팀장, 동료들과 함께 일하고 있습니다.

baas.io는 많은 오픈소스를 사용하고 있고(공개SW로 일체 구성된 백엔드 서비스로 BaaS 시장 개척), 해당 프로젝트에서 사용하고 있는 Usergrid 프로젝트에 지속적으로 컨트리뷰션하게 되었습니다. 소소한 버그, 기능개선 등 꾸준히 그냥 재미있어서 내가 쓰고 있는 오픈소스에 내 이름이 올라가는 게 신기하고 그리고 오픈소스를 사용하며 받은 많은 것들 중 일부는 돌려줘야 한다는 생각들로 컨트리뷰션을 하였습니다. 그게 벌써 1년이 되었네요. 그리고 Usergrid는 아파치 인큐베이터로 편입되고 저는 Apache Usergrid의 커미터로 활동하게 되었습니다!

Apache Usergrid

Usergrid는 Ed Anuff(http://www.crunchbase.com/person/ed-anuff) 가 창시했고, Apigee 에 인수 되면서 Apigee의 App Service라는 이름의 제품으로 자리매김하였습니다. BaaS의 형태가 그럿듯 Web+Mobile 에서 서비스를 만들기 위해서 공통기능들이 있고 해당 기능들을 쉽게 만들 수 있도록 도와줍니다. Usergrid는 RESTful API + Cassandra Cluster 에서 동작하며 다양한 엔티티간의 관계들을 연결해주며 확장가능한 서비스를 할 수 있도록 도와줍니다.

아파치 인큐베이터로 편입되었으니 여러가지 목표를 가지고 진행하게 될 것입니다. 기대됩니다. 2012 H3 때 오픈소스로 개발 실력쌓기라는 내용을 공유했는데, 더욱 더 한단계 도약할 수 있는 기회를 얻게 되었네요.

이런 경험들이 한국에서 많아져야 한다는 것이 저의 생각이고 그 길을 꾸준히 가면 된다고 생각합니다. 아파치 프로젝트로 편입되면서 SW마에스트로와 모모팀을 통해서 알게된 한륜희라는 후배와 함께 Apache Usergrid 웹사이트 제작을 공헌하며 이러한 생각들이 더욱 명확해졌습니다. 오픈소스 활동을 하며, 경험한 내용들은 많은 분들을 위해서 공유드리겠습니다.

사실, 이건 길을 가다보면 만나는 행운이라고 생각합니다. 정말 감사한 일이고 주변에서 도와주신 많은 분들에게 마음 깊이 감사함을 느낍니다.
그리고 이런 행운을 만끽하고 싶네요. 여러분들 새로운 도전을 응원해주세요! ;)

PS. OSCON 발표도전부터 아파치커미터가 되기까지의 기회와 도전에 대한 이야기는 DEVEIW 2013 에서 “당신의 인생에 오픈소스를 더하라 – OSCON 발표자 뒷담화” 라는 내용으로 함께 공유할 것이니 오시는 분들은 많은 참석해주세요.

Speaking about Asia Open Source Community at OSCON!

세계에서 가장 큰 오픈소스 컨퍼런스이고 오픈소스 개발자들의 축제인, OSCON 2013( http://www.oscon.com/oscon2013 ) 에서 KTH 에서 연을 맺게 된 박민우님과 발표를 진행하게 되었습니다.
“An Overview of Open Source in East Asia” 라는 주제이고 동아시아(중국, 일본, 한국) 대한 문화, 오픈소스, 커뮤니티들에 대한 소개를 진행합니다.

정식발표제안으로 발표하는 한국 첫 사례라는 뿌듯함을 가지고 있습니다. 저는 OSCON 처음 참석인데 발표자로 가게되어 굉장히 영광스럽고 그리고 긴장이 됩니다.
3월달부터 계속 준비를 하였고 이제 열흘정도 남았네요. 이 발표를 위해서 많은 분들이 도와주시고 계십니다. 한분한분 찾아뵙고 인사를 드리지 못하지만 도움에 회답하는 것은 잘 마무리하는 것이라고 생각하여 오늘도 힘을 냅니다.

OSCON 2013 참석 후 후기들도 함께 정리하여 개발커뮤니티에 다시 전파할 생각합니다.
배운것을 나누며 성장할 수 있는 멋진 개발자가 되기위해서 한걸음 나가니 응원해주세요! 이힛 ;)

Join us if you are interested in Asia open source community!
An Overview of Open Source in East Asia (China, Korea, Japan)


I'm Speaking at OSCON 2013 (size 300 X 250)

jgitflow를 사용하여 Java+Maven 프로젝트 릴리즈를 쉽게하는 법

소프트웨어개발에 있어서 릴리즈는 중요한 절차중에 하나입니다. 여기서 얘기하려는 것은 릴리즈를 쉽게 하려는 것인데 적용대상은 아래조건이 만족해야 합니다.

- SCM(Source Code Management) : git
– Language : java
– Build system : maven

git 을 SCM 으로 사용하며 브랜치를 관리하는 것은 다양한 방식이 있을 수 있습니다만 어느정도 보편화 되어있는 git-flow 를 먼저 얘기드려야 할듯합니다.

git-workflow-release-cycle-2feature
source : http://blogs.atlassian.com/2013/04/git-flow-comes-to-java/

git-flow는 안정브랜치(master), 개발브랜치(develop), 기능브랜치(feature/*) 를 나누어서 개발하고 이들간의 관계를 정리하는데 있습니다. 또한 이걸 쉽게 적용할 수 있는 명령도구도 제공되죠. 여튼 git-flow 에서 사용되는 브랜치의 규칙을 찾아보면 다음과 같습니다.

1. 안정(Stable) 브랜치 : master
2. 개발(develop) 브랜치 : develop
3. 기능(feature) 브랜치 : feature/{ISSUE}
4. 핫픽스(hotfix) 브랜치 : hotfix/{ISSUE}
5. 릴리즈 브랜치 : release/{VERSION}
참고. 버전관리용 태그 : {VERSION}

git-flow 에 대해서는 구글링을 하면 많이 나오기도하고 좋은 컨텐츠가 많기때문에 굳이 설명하지 않고 넘어가도록 하겠습니다. ( 참고. http://dogfeet.github.io/articles/2011/git-flow.html ) git-flow 를 사용하고 있고 Java + Maven 프로젝트에서 릴리즈를 하기 위해서 거치는 단계는 아래와 같습니다.

1. 개발 브랜치에서 배포 브랜치 생성
2. Bump version : maven modules (pom.xml)
3. 원격 저장소에 릴리즈 브랜치 배포(git push)
4. 테스트 서버에 배포 후 테스트 진행
5. 배포 하기로 결정
6. 릴리즈 브랜치에서 안정화 브랜치로 머지작업
7. 원격 저장소에 안정화 브랜치 배포(git push)
8. 실 서버에 배포

1 ~ 8 의 단계에서 몇가지 단계들은 사실 귀찮은 작업들(git checkout, maven pom file 수정, merge conflict)이며 진행하는데 작업시간들이 들어가고 실수가 생길 수 있는 여지가 있습니다. 사실 이게 필요하지만 귀찮고 또한 시간도 잡아 먹죠.위와같은 작업들이 일반적으로 한다면 다음과 같은 명령어 실행하고 진행해야 합니다.

git flow release start 1.0
mvn release:prepare -DreleaseVersion=1.0
mvn release:perform
git tag 1.0
git flow release finish 1.0
merge conflict and need to resolve ;(

1 ~ 8 의 과정을 겪은 사람들이 귀찮은 작업을 줄이고자 JIRA, Sourcetree로 유명한 Atlassian 에서 근무하는 Jonathan Doklovic 사람이 maven release plugin 으로 만들어서 오픈소스로 공개했습니다. jgitflow (https://bitbucket.org/atlassian/maven-jgitflow-plugin) 입니다.

jgitflow 를 자세히 설명한 자료
http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases
https://bitbucket.org/atlassian/maven-jgitflow-plugin/wiki/Home

jgitflow 를 사용하면 1~2의 단계를 다음과 같이 줄일 수 있습니다.

명령어 : mvn jgitflow:release-start

➜  usergrid-stack git:(develop) mvn jgitflow:release-start
......
[INFO] --- maven-jgitflow-plugin:1.0-alpha8:release-start (default-cli) @ usergrid ---
[INFO] Checking for SNAPSHOT version in projects...
[INFO] ensuring origin exists...
What is the release version for "org.usergrid [org.usergrid]"? (org.usergrid:usergrid) [0.0.28]:
What is the release version for "org.usergrid.config [org.usergrid]"? (org.usergrid:usergrid-config) [0.0.28]:
......
➜  usergrid-stack git:(release/0.0.28)

6 ~ 7 의 단계를 다음과 같이 줄일 수 있습니다.

명령어 : mvn jgitflow:release-finish

적용은 쉽습니다. pom.xml 파일에 다음 플러그인 설정을 해주시면 됩니다.

<build>
    <plugins>
        <plugin>
            <groupId>com.atlassian.maven.plugins</groupId>
            <artifactId>maven-jgitflow-plugin</artifactId>
            <version>1.0-alpha26</version>
            <configuration>
                <!-- see goals wiki page for configuration options -->
            </configuration>
        </plugin>
    </plugins>
</build>

몇 단계 아닌거 같지만 실제 작업량은 해당 단계에서 많이 잡아먹으니 적용을 고려해도 좋을거 같습니다. ;)

설정 내용이 문서로 정리된게 없으니 설정을 하시려면 다음 소스를 보고 넣으시면 됩니다.

https://bitbucket.org/atlassian/maven-jgitflow-plugin/src/9d1b93be8bfc4c863f1ade7ac5f618fe15aa2ad0/src/main/java/com/atlassian/maven/plugins/jgitflow/ReleaseContext.java

2013.12.05 추가.
1. maven-jgitflow-plugin 버전업(1.0-alpha8->1.0-alpha26)
2. 설정 소스코드 설명 추가