6개월만의 포스팅.. 뷁!
예전에 해석했던 내용인데 다시 맘이 끌려서 올림...
다음 포스팅은 언제쯤일라나.. 에횽..
Lessons from an open source project
오픈 소스 프로젝트로부터 얻은 교훈
Published by Tom on 02/07/2003 in IT.
Some useful lessons learned from the Peekabooty project.
Sadly no permalink, so this won’t last long. I’ve put the text in the extended entry.
Peekabooty 프로젝트로부터 유용한 교훈을 얻었다. 슬프지만 홈페이지를
영원히 유지할 수 없어, 이 글은 오래 남아있지 못할 것이다. 이 글을 가입
연장 내역에 넣도록 하겠다.
Here is a review of the first two years of the Peekabooty
Project. Over that time I have had to
re-evaluate many of the things I learned in university and in the working world
– many of the engineering lessons that I had been taught turned out not to work
so well. The project management of an
open source project is very different from old-school engineering project management,
so I had to learn a lot about how open source project management works.
여기에 쓰는 글은 Peekabooty(역주: 분산형 프록시 서버로 검열이 심한
국가에서 사용하도록 고안된 프로그램이다.) 프로젝트 첫 2년간의
반성이다. 이 기간동안 대학과 실무에서 얻은 많은 지식을 다시 평가하는
시간을 가졌다 - 내가 배웠던 많은 공학 지식이 실제로는 제대로 동작하지
않는 다는 것을 알게 되었다. 오픈 소스 프로젝트의 운영은 기존 학문에서
말하는 것과는 많은 차이가 있으며, 따라서 어떻게 오픈 소스
프로젝트를 운영할지에 대해 많은 것을 배워야했다.
All of these problems have been seen before – by no means do
I see these as unique. They are simply
more data points on the “How To Do Open Source
Development” graph.
이런 문제점은 이전부터 보아왔다 - 결코 이는 특이한 것이라고 할 수 없는
것이다. 이들 문제는 단순히 "어떻게 오픈 소스를 개발하는가" 그래프에
대한 더 많은 점을 찍는 것에 불과하다.
What did I learn from the first version of Peekabooty?
Peekaboty의 첫 버전으로부터 무엇을 배웠는가?
Open-Source Project Management Lessons
오픈 소스 프로젝트 관리의 교훈들
1. Don’t release before it does something useful.
절대 유용한 결과를 얻기전에 배포하지 말라.
This lesson is recounted in Open Sources: Voices from the Open Source
Revolution as well as other places.
I had even read about this rule before we released, but I had to learn
it for myself. If you release too soon,
you spend a lot of your time answering emails instead of developing.
이 교훈은 "오픈소스: 오픈 소스 혁명에서의 외침" 이나 다른 곳에서
언급되는 내용이다. 이 규칙을 실제로 배포전에 읽었지만, 결국 몸으로
직접 체득하게되었다. 너무 빨리 배포를 하게되면, 개발보다 더 많은
시간을 이메일에 답변하는데 보내야 할 것이다.
2. The press is a tool – more like a hammer than a Swiss army knife.
언론은 도구이다 - 스위스 군용칼보다는 망치에 가깝다.
The press is like a hammer – it can help you or hurt you, depending onhow you use it. But like a hammer, it can’t do everything,
like cut a tree in half. It has limited capabilities and you cannot expect too
much from it.
언론은 일종의 도구이다. - 어떻게 사용하느냐에 따라, 당신을 도울 수도
있지만, 해를 입힐 수도 있다. 그렇지만, 망치처럼, 모든 일을 할 수
있지는 못한다. 예를 들어 나무를 반으로 자르는 일이 그렇다. 제한된
기능만을 할 수 있기때문에, 많은 것을 기대하지는 못한다.
How the Press has Helped
어떻게 언론이 도움이 되는가?
The press has helped to bring awareness to key
people that have the ability to help the project grow.
언론은 프로젝트가 성장하는 것을 도울 수 있는 사람들에게 알림으로써,
프로젝트에 도움이 된다.
Press will get you more downloads. Whether this is good or bad depends on lesson
#1.
언론을 통해서 더 많은 다운로드가 일어난다. 이것의 장단점은 교훈 1번을
통해서 확인할 수 있다.
Press will not get you more developers unless #1 is in place. The fastest way to get more developers is to
network with other developers.
교훈 1번이 충족되지않았다면, 언론을 통해서는 많은 개발자를 얻기
이렵다. 더 많은 개발자를 얻는 가장 좋은 방법은 다른 개발자와의
네트웍을 통해서 얻는 것이다.
How the Press Has Hurt
어떻게 언론이 해를 입히는가
The press loves infighting because
it’s a good story. However, the
infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund thingsthey feel
will have a high chance of success, and instability erodes that
confidence.
언론은 논쟁을 좋아하는게, 그것이 좋은 소재이기 때문이다. 하지만, 논쟁
기사는 자금 유치를 시도하는 프로젝트에게는 해가 된다. 이는 불안정한
기운을 형성하게된다. 사람들은 성공할 확률이 높은 일에 자금을
지원하는데, 불안정성은 이를 해치게 된다.
3. 95-5 Rule
Usually it’s the 80-20 rule, but
in open source projects it’s more like the 95-5 rule. Open source projects are usually run by one or
two people doing most of the work. If
you decide to lead an open source project, you must be willing and ready to
accept this. If you want to lead an
open-source project, it helps to be independently wealthy. This allows you to forget about things like a
job and work on the project you want to work on. In hindsight, wouldn’t it have been better to
take a really long vacation instead? Doh!
일반적으로 80-20 규칙을 이야기하지만, 오픈 소스에서는 95-5 규칙이 더
걸맞는다. 오픈 소스 프로젝트는 보통 한명에서 두명정도가 거의 모든 일을
떠맡는다. 만약 오픈 소스 프로젝트를 지휘하려고 마음 먹었다면, 위의
상황을 감내해야한다. 만약에 오픈 소스 프로젝트를 지휘하고자한다면,
독자적으로 경제적 문제를 해결할 수 있는 것이 큰 도움이 된다. 직업등에
대한 생각을 잊고, 프로젝트에 올인할 수 있다. 지나고나서 보니, 정말 긴
휴가를 떠나보는 게 더 낫지않았을까도 생각된다. 훗..
Engineering Lessons
공학적 교훈
1. C/C++ is no longer a viable development language
C/C++은 이제 유용한 개발 언어가 아니다.
This may seem obvious to some
people, and other people may recoil in shock.
어떤 이에게는 당연하고, 어떤 이에게는 충격적으로 다가올 것이다.
In college/grad school we were taught to believe that C/C++/Java, etc
are the best languages in the world, so it was a very difficult transformation
to accept that these languages are not viable development languages for
application level work.
대학 등지에서 C/C++/Java등이 세상에서 가장 좋은 언어라고 믿게끔
배웠으니, 이들 언어가 어플리케이션 레벨에서 그다지 좋은 언어라고 하는
사실은 꽤 어려운 인식의 전환이 아닐 수 없다.
C++ is seen to great for execution speed, static binding, object orientation, templates,
and more. However, it is absolutely lousy development time. Here’s why:
C++은 실행속도, 정적 바인딩, 객체지향, 템플릿등등에 대해서는 훌륭한 듯
보인다. 그렇지만, 절대적인 개발시간이 길어지게된다. 이에 대한 이유는 :
It requires compilation – as your code grows , the wait time to see ifyour code works increases. This delay directly affects how fast your
code is developed.
컴파일하는 시간이 필요하다 - 코드가 증가함에 따라, 대기하는 시간이
증가한다. 이런 지연은 코드 개발 기간에 직접적인 영향을 준다.
It’s really, really, really hard for people to
learn it, and this directly impacts the number of developers you will have on
an open-source project.
이들 언어는 정말, 정말,정말 배우기 힘들다. 또한 오픈 소스 프로젝트에
참가할 개발자의 수에 영향을 미치게된다.
It uses static binding (Isn’t that supposed to
be a good thing?)
정적 바인딩을 사용한다(이게 좋을 것이라고 보는가?)
There are no standard libraries for C++, so
there’s a lot of reinventing the wheel.
(Yeah, there’s the STL and others, but each one has a huge learning
curve associated with it).
C++을 위한 표준 라이브러리가 없다. 따라서 처음부터 모든 라이브러리를
다시 작업해야한다.(STL이나 다른 것이 있지만, 이를 사용하기위해서는
상당히 큰 학습 곡선을 그려야한다.)
Java somewhat fixes
the learning curve and the standard library problem, but still has the other
two problems, and in addition requires the user to download the JRE before you can run any java
program (a 25 MB separate install). One
of my previous jobs had us trying to deploy a client-side Java program to much
failure because of this hurdle.
Server-side programming doesn’t have this problem so Java may not be
such a bad choice for that.
Java는 학습곡선, 표준 라이브러리 문제에 대해 많은 것을 고쳤지만, 다른
두개의 문제(컴파일 시간 및 정적 바인딩)와 사용자가 프로그램을
사용하는데 JRE를 필요로한다는 점(25메가 정도 된다)이 문제이다. 이런
장애로 인해 이전 직장에서 클라이언트용 자바 프로그램을 배포하는데
어려움을 겪었다.
서버쪽 프로그램에서는 이런 점이 큰 문제가 되지는 않기 때문에 나쁜
선택은 아니다.
2. Don’t Use Binary Protocols for Application Development
바이너리 프로토콜을 사용하지 말 것
In grad school we spent a lot of
time analyzing network protocols, network optimization, etc. A binary protocol may be good for core
protocols of the Internet, but they are not a good choice for an application. Once again, this may seem obvious to some,
and others may stop reading at this point in disgust. Here’s why binary protocols were no good for
this project:
학교에서 네트워크 프로토콜을 분석하고, 최적화하는등에 많은 시간을
보냈을 것이다. 바이너르 프로토콜은 인터넷 핵심 프로토콜에는
유용하지만, 어플리케이션에 대해서는 좋다고 보기 어렵다. 다시 한번, 이
점은 어떤 이에게는 매우 당연한 것이고, 다른 이는 이점에 반발해서 읽는
것을 그만둘지도 모르겠다. 이 프로젝트에서 바이너리 프로토콜이 안좋았더
이유를 밝혀준다.
* You
waste too much time figuring out 1’s and 0’s instead of adding
features.
* You
make it very difficult for others to write their own clients
* 기능 추가대신 1혹은 0으로 표기된 내용이 무엇인지 알기위해
시간을 소비하게된다.
* 클라이언트를 위해 다른 프로토콜을 만들기가 어려워진다.
3. Interface is Everything
인터페이스가 전부이다.
This is similar to the #1 project
management lesson. The program should be
fun to work with. There should be
buttons and things that blink. The
interface should be the first thing you do.
프로젝트 관리에서 1번째 교훈과도 유사하다. 프로그램은 사용하기
즐거워야한다. 버튼이나 깜빡이는 요소가 있을 수 있다. 언터페이스는 가장
먼저 손을대야할 첫번째 요소이다.
The interface serves as inspiration and motivation and helps
you to learn how the final product should look.
Yes, it’s going to change a lot.
Yes, it’s going to have to be rewritten multiple times. Yes, it willnever be good enough. Yes, it produces a never-ending list of
additions and features to your already huge TODO list. But when someone downloads your program they
will have something to do. No one likes to
look at command lines.
인터페이스는 최종 제품이 어떻게 나와야하는지에 대한 영감과 동기를
부여한다.
물론, 많이 변경될 수 있다.
물론, 여러번에 걸쳐서 다시 작성할 수도 잇다.
물론, 충분히 유용하지 않을 수 잇다.
물론, 끊임없는 추가사항과, 엄청난 TODO리스트가 생길 수 잇다.
하지만, 당신의 프로그램을 다운받는 누군가가 무엇인가를 해볼 수 있게
해준다. 누구도 커맨드 라인을 보고 싶어하지는 않는다.
These were the main lessons learned in the first two years
of the Peekabooty project. The new roadmap
to the future of Peekabooty will take these lessons into account. That future will be released in the coming
weeks.
Peekabooty 프로젝트를 햇었던 첫 2년간의 주요한 교훈을 적었다. 미래의
Peekabooty에 대한 새로운 로드맵을 준비중이다. 수주안에 새로운 미래를
내놓게 될 것이다.
