Month: March 2006

어제 Vim 개발자 Bram Moolenar가 구글에서 일하게 되었다고 발표하였습니다. 물론 업무 중에 Vim 개발을 일부분 할 수 있도록 했다는데.. 무섭게 오픈소스 인력들을 빨아들이고 있는 구글이 독립 오픈소스 개발자들을 과연 몇 명이나 남겨놓을지 모르겠군요. -O-

Vim은 원래 우간다 어린이들을 도와주세요! 를 하고 있었지만, Bram이 모든 시간을 Vim 개발에 쓰면서 쉬는 동안에는 Bram의 생활비 지원으로 스폰서십이 바뀌었다가, 다시 Bram이 구글로 들어가고 나서부터는 우간다의 키발레 어린이를 돕는 것으로 원래대로 돌아간다고 합니다.

Vim 7에는 FreeBSD에서 EUC 환경에서 문서 끝을 다 깨먹는 버그가 수정되어 있으니 이제 편하게 살 수 있을 것 같아서 기대가 됩니다. 🙂 우간다 어린이들을 도와줘야겠네요;;

그동안 오픈소스 프로젝트 몇 개에서 활동을 하면서 느꼈던 생존 전략을 몇가지 올려 봅니다. 물론, 이런 것들은 절대적인 것은 아니고, 상황에 따라서 다를 수도 있지만 그런 상황도 있을 수 있구나 하고 나중에 패치를 제출하실 때 참고가 되실까 해서 몇 가지 적어 봅니다.

우선은 눈치를 잘 보고 관례를 따르자.

어느 커뮤니티던 각자 고유의 성질이 있습니다. 어떤 곳은 생각보다 엄청나게 보수적인 곳도 있고, 어떤 곳은 새로운 패치가 올라오면 열렬히 좋아하면서 달려들어서 오히려 부담되는 곳도 있고.. 어떤 곳은 모르는 사람이 글을 올리면 반감을 보이는 곳도 있고.. 주제에 약간 벗어나는 글(OT)에 대해 어떻게 상대하는지도 각각의 커뮤니티에 따라서 많은 차이를 보입니다.

대부분의 커뮤니티는 각각의 관례가 있는데 그 관례를 외부인이 쉽게 눈치채지 못해서 처음에 실수하는 경우도 많이 있습니다.
예를 들어, 어떤 곳은 패치를 버그트래커에 올리는 것을 좋아하는 곳도 있고, 또 다른 어떤 곳은 개발자에게 직접 사적으로 보내는 것을 좋아하는 경우도 있으며 그 구분의 정도도 각각 다른 편입니다. 첫 패치가 문서나 테스트를 포함해야 하는지, 어느 정도의 패치는 미리 작업 전에 아이디어를 올려야할지 등 많은 차이가 있기 때문에, 관심있는 곳은 어느 정도 익숙해지는 편이 참여하기가 쉽습니다. 물론, 참여할 때 아는 사람이 원래 참여하고 있었다면 그 사람에게 조언을 구하는 것도 좋습니다.

초반에는 묻어가기를 잘 하자

입지가 어느 정도 굳어지기 전까지는 “묻어가기”가 아주 쉬운 참여법입니다. 각 커뮤니티들은 주제가 아무리 넓어도, 대략적인 흐름이 있어서 유행하는 토픽이 몇개가 항상 떠 있기 마련입니다. 자신과 관련된 주제가 스물스물 올라올 때, 자기가 갖고 있던 생각이나 패치나 그런 것들을 괜시리 관련 지어서 같이 올려버리고 하면, 그냥 올리면 별 관심 없었을 사람들도 같은 쓰레드에 있다보니 덩달아 보고 해서 좋습니다. 🙂 같이 커밋되는 경우도 있고, 상대방들도 마침 관련 코드를 보고 있던 상황이면 아무래도 쉽다보니 같이 리뷰해 줄 확률도 올라갑니다.

한 박자 빠르게

각 커뮤니티에는 오랫동안 개발에 참여하던 개발자들이 직접 하기에는 따분하고 여유가 없는 일들이나, 새로운 아이디어가 있긴 한데 구현이 쉬울지 확신이 안 가는 경우가 생각보다 자주 발생합니다. 바로 이 경우가 터줏대감 개발자들과 친하게 지낼 수 있는 절호의 기회입니다. 그 때 잽싸게 패치를 만들어서 올려주면 패치 리뷰도 하고 하면서 좋은 기회가 많이 생기게 마련이고, 다른 사람들에게 이름 언급도 많이 돼서, 구글 히트도 올라가고 인지도도 올라갑니다. ^.^ 물론, 여기서 중요한 것은 잽싸게 패치를 만들 수 있느냐가 관건인데, 사실 저같은 경우에도 잽싸게 패치를 만들어야지 하고 마음을 먹어도 10번 시도하면 1번 정도만 끝까지 하고 나머지는 뭐가 문제인지 파악하고 대충 그냥 그렇구나 하고 중단합니다. 여러 번 시도하다보면 어쩌다 한 번은 땡잡아서 이른바 “low-hanging fruit”를 쉽게 따는 경우가 있습니다. 🙂

한 박자 느리게

중요한 일일수록 한 박자 느리게 할 필요도 있습니다. 기회를 잡을 때는 잽싸게 하면 되지만, 다른 경우에는 메일에 답장할 때도 써놓고 1~2시간 정도 놔두고 있다가 보내거나, 저장해 놓고 아무도 비슷한 글을 안 올린다 싶으면 올리면 좋은 경우가 많습니다. 1~2시간 정도 놔두면 다른 사람들이 답글을 올리는데, 훨씬 더 경력이 많고 뛰어난 사람들의 답글을 읽다보면 자기 글이 틀렸다고 생각이 드는 경우가 제법 있습니다. 아무래도, 계속 틀린 말을 하게되면, 자기 스스로도 위축되게 되고 다른 사람들한테도 이미지 저하가 제법 일어나서 패치를 리뷰해줄 때 협조를 얻기가 힘들어지고, 새로운 주장을 할 때도 동의를 얻기가 힘들어집니다.

첫인상이 중요하다

개인적인 첫인상도 물론 중요하긴 하지만, 오픈소스에서 가장 중요한 것은 코드의 첫인상입니다. 패치의 앞 몇 줄의 코드 품질이나 예시로 올린 글에 포함된 몇 줄의 예제 코드가 다른 사람들의 동의를 얻느냐 아니면 답글 하나도 안 달리고 아카이브의 한 줌의 비트로 묻히게 되느냐를 결정하게 됩니다. 따라서, 코드를 올릴 때는 반드시 프로젝트에서 쓰는 코딩 컨벤션을 지켰는지 꼼꼼하게 체크를 하고, 제공되는 테스트는 모두 확실히 돌리는 것이 좋습니다. 패치 하자 마자 바로 커밋만 하면 되는 상태까지 완벽하게 해서 패치를 제출했다면, 곧 커밋 권한을 받을 가능성이 매우 높아집니다. 🙂

변화는 조금씩

전통적인 구조의 회사에서 일하는 프로그래머들은 깜짝쇼를 좋아합니다. 뒷방에서 몰래 만들고 있다가, 데모 날짜 잡고 전직원 모아놓고 와~~ 하면서 짝짝짝 하면 물론 쇼하는 분위기도 나고 좋긴 하지만, 코드 통합의 관점에서는 최악의 경우입니다. 오픈소스 프로젝트들은 개발자들이 하위 호환성 유지에 쏟고 있을 여유가 많지 않기 때문에, 너무 많이 확 바꿔버리는 패치나 하위호환성을 완전히 깨버리는 패치를 올려버리면, 패치는 올라오자마자 팽당하는 사태를 맞게 됩니다. 패치는 최소한으로 분리를 해서 따로 따로 제출하는 것이 그 유명한 “divide and conquer”의 관점에서도 더 옳은 방법이며, 한꺼번에 패치를 많이 올리면 최근 메일 목록에서 확 도배를 하는 효과도 있기 때문에 강한 인상을 줄 수 있습니다. –; (그렇다고 일부러 패치를 몰아서 보낼 필요는 없습니다. =3)

공손한 사람이 되자

공손하게 말을 하면, 간혹 상대방의 역공을 받더라도 공격이 무디게 들어옵니다. 자신의 입지가 확고하지 않을 때에는 would, may, could , think 등.. 애매모호한 말을 총동원해서 애매한 해석이 가능하도록 여지를 남겨두는 것이 좋습니다. 🙂 물론, 익숙해지기 전까지는 Thank you for 뭐해줘서! 는 필수입니다. 항상 서로에게 감사하는 것이 오픈소스이지요 ;;;

그냥 재미로 하자

뭔가 목적을 두고 목적에 대한 과정으로 쓰게되면, 곧 그 과정이 싫증이 나기에 마련입니다. 헌신적인 마음이나 목적에 의한 노력은 일시적으로는 프로젝트에 힘을 쏟을 수 있게 하지만, 곧 시들게 마련입니다. 오픈소스 프로젝트들은 보통 아주 장기간의 릴리스 엔지니어링과 커뮤니티의 피드백 수렴 과정 같은 것이 있기 때문에, 단기간에 끝낼 수 있는 경우가 드뭅니다. 따라서, 장기간 동안에도 지치지 않게, 그냥 여유 있는 시간에 무리하지 않고 재미로 스트레스는 최대한 피하면서 참가하는 것이 좋습니다. 스트레스를 피해 잠시 도망가 있으면 다른 사람들이 해 줍니다. ^^; (자기에게 스트레스를 주는 일이라도 다른 사람들은 재미있는 일인 경우가 많습니다.)

상대방의 입장에서도 생각해 보자

처음 오픈소스 프로젝트에 참여할 때에는, 패치를 제출했을 때 금방 응답이 오지 않으면 굉장히 조바심이 나기에 마련입니다. 저도 처음 패치를 내고서 5분 안에 답장이 안 와서, 무시됐나 하고 생각했는데.. 결국은 첫 패치가 5달만에 답장이 와서 적용이 됐습니다. -O-

프로젝트에 참여하고 있는 다른 사람들도 대부분은 바쁜 사람들이고 자신과 관련이 없다 싶은 것에는 관심이 전혀 안 생길 수도 있습니다. 그래서 더 재미있겠다 싶은 것을 먼저 처리해 주거나 관심을 보이는 것도 그 사람 입장에서는 어찌보면 당연한 일입니다. 끈기를 가지고 여유있게 기다린다거나 바람을 잡는다거나 뭐 몇가지 선택지가 있는데 더 능동적인 방안으로는 기존에 영향력이 있다고 생각되는 사람들의 관심사를 파악한 다음에 그 관심사와 겹치는 것에 대한 작업을 어느 정도 해서 올려서, 피드백을 하면서 친해진 다음에 부탁한다거나, 다른 사람들이 관심을 가질 수 있게 화려한 수식어나 표준 참조를 마구 갖다 끌어붙이는 등의 동기 부여가 필요합니다. 부가적인 다른 패치를 올린 다음에 그 패치가 앞 패치에 의존성을 갖도록 해버리는 것도 하나의 테크닉이죠. 🙂

그 외의 일일이 언급하기 힘든 여러가지 것들..

오픈소스 커뮤니티의 다른 조직에 대한 가장 큰 특징은

• 대부분의 사람들이 온라인에서 만나서 원거리에서 얘기한다
• 여러 참여자들은 각기 다 다른 시간대에서 생활하며, 여유시간이 모두 다르다
• 대부분의 코드는 집합적 소유권(collective ownership)의 특성이 매우 강하지만, 나름대로 암묵적인 소유권이 있는 경우도 많다
• 대부분의 커뮤니케이션이 전화나 오프라인의 동기식 통신이 아니라 비동기식 통신이므로 답변의 순서도 뒤죽박죽이고 답변이 늦거나 아예 없을 수도 있다
• 일반적인 회사 조직은 피라미드형 구조로 위계 구조가 단순화 되어 있는 편이지만, 오픈소스 커뮤니티들은 커뮤니케이션에 있어서는 굉장히 평면적이고 수백~수천명까지 한꺼번에 참여를 하지만, 안 보이는 인지도와 협력관계, 친분관계 등이 많은 작용을 한다
• 재미와 흥미가 동기를 부여하는 경우가 매우 많다. 따라서, 지루하고 힘든 일은 처리되는데 시간이 굉장히 오래 걸린다

이런 것들이 있습니다. 그래서, 참여하기 전까지는 막막하기만 한 편이 많은데, 실제로는 해 보면 생각보다는 프로그래밍 경력이 40년이 넘은 프로그래머들도 아주 친절하고 잘 대해줍니다. 물론, 이 글에서 쓴 것들은 제 개인적인 경험에 의한 의견일 뿐이고, 전혀 그렇지 않은 프로젝트도 많이 있을 수가 있지만, 어느 정도 참고해 보시고 앞으로 오픈소스 프로젝트에 참여하실 일이 있으시면 잘 되시길! Happy Hacking! ^_^*