The Cathedral and the Bazaar (2)——The Mail Must Get Through 郵件必須接通

flong19900501

http://blog.sina.com.cn/s/blog_746638070100tf47.html


Since 1993 I'd been running the technical side of a small free-access Internet service provider called Chester County InterLink (CCIL) in West Chester, Pennsylvania. I co-founded CCIL and wrote our unique multiuser bulletin-board software— you can check it out by telnetting to locke.ccil.org. Today it supports almost three thousand users on thirty lines. The job allowed me 24-hour-a-day access to the net through CCIL's 56K line—in fact, the job practically demanded it!



從1993年以來我一直負責位于 West Chester, Pennsylvania的一家名叫CCIL（Chester County InterLink）的一家免費網(wǎng)絡服務供應商的技術工作。我吸住建立了CCIL并且寫了我們自己的多用戶電子留言版軟件——你可以通過telnet連接到locke.ccil.org嘗試一下。今天這個軟件服務于大約30條線路上的3000個用戶。這項工作允許我通過CCIL的56K的網(wǎng)線24小時接入網(wǎng)絡——事實上，這項工作需要這樣。

I had gotten quite used to instant Internet email. I found having to periodically telnet over to locke to check my mail annoying. What I wanted was for my mail to be delivered on snark (my home system) so that I would be notified when it arrived and could handle it using all my local tools.

我已經(jīng)很習慣于遠程的網(wǎng)絡電子郵件。我發(fā)覺定期的通過telnet連接到locke來查收電子郵件是很討厭的事情。我想要的是郵件發(fā)送到snark（我的本地系統(tǒng)），這樣就可以在有新郵件的時候提醒我，并且我可以使用本地的軟件來處理他們了。

The Internet's native mail forwarding protocol, SMTP (Simple Mail Transfer Protocol), wouldn't suit, because it works best when machines are connected full-time, while my personal machine isn't always on the Internet, and doesn't have a static IP address. What I needed was a program that would reach out over my intermittent dialup connection and pull across my mail to be delivered locally. I knew such things existed, and that most of them used a simple application protocol called POP (Post Office
Protocol). POP is now widely supported by most common mail clients, but at the time, it wasn't built in to the mail reader I was using.

因特網(wǎng)本身的電子郵件傳輸協(xié)議SMPT（Simple Mail Transfer Protocol）并不適合，因為它最適合于機器一直連接的情況，而我的跟人計算機并不總是在線，并且沒有一個靜態(tài)的IP。我所需要的是一個程序能夠通過我斷斷續(xù)續(xù)的比好連接來拉取我的郵件到本地。我知道有這類東西，大多數(shù)這樣的軟件使用一種叫做POP的簡單的應用程序協(xié)議。現(xiàn)在POP（Post Office Protocal）被大多數(shù)的郵件客戶端廣泛支持。但是那個時候，我使用的郵件閱讀工具并沒有支持。

I needed a POP3 client. So I went out on the Internet and found one. Actually, I found three or four. I used one of them for a while, but it was missing what seemed an obvious feature, the ability to hack the addresses on fetched mail so replies would work properly.

我需要一個POP3的客戶端。于是我在網(wǎng)上搜索找到了一個。確切的說是我找到了三四個。我使用了其中一個一段時間，但是發(fā)現(xiàn)它似乎地缺少了一個很明顯的功能——截取取回的郵件的地址以便于回信。



The problem was this: suppose someone named `joe' on locke sent me mail. If I fetched the mail to snark and then tried to reply to it, my mailer would cheerfully try to ship it to a nonexistent `joe' on snark. Hand-editing reply addresses to tack on “ <@ccil.org> quickly got to be a serious pain.

問題就在這里：假設locke上一個叫joe的人給我發(fā)了一封郵件。如果我取回郵件到snark 并且試著回復。我的郵件軟件將會很高興的把回復發(fā)送到snark上一個不存在的joe上。而手動的附加<@ccil.org>將很快讓你覺得那是件很痛苦的事情。

This was clearly something the computer ought to be doing for me. But none of the existing POP clients knew how! And this brings us to the first lesson:

這很顯然是電腦應該幫我做的事情。但是現(xiàn)在沒有一個POP的客戶端知道如何去做。這帶給我們第一條啟示。

1.Every good work of software starts by scratching a developer's personal itch. Perhaps this should have been obvious (it's long been proverbial that ``Necessity is the mother of invention'') but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world —which may explain why the average quality of software originated in the Linux community is so high.

每一個好的軟件的誕生都是因為撓到了開發(fā)者的癢處�；蛟S這是個一直以來都很明顯的道理（一直有這樣的諺語：需求是發(fā)明之母），但是太多的軟件開發(fā)者花費大量的時間去鉆研是為了報酬，而他們并不喜歡或者需要。但在linux的世界里面不是這個樣子的——這在一定程度上或許能解釋為什么從linux社區(qū)里起源的軟件的質量往往很高。

So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself ``Which one is closest to what I want?'' Because:


于是，我應不應該立刻開始 瘋狂地嘗試編寫一個新版本的POP3客戶端來跟已經(jīng)有的競爭？開玩笑！我仔細的看了看我手里的POP軟件，尋找哪一個是最接近我的需求的，因為：

2.Good programmers know what to write. Great ones know what to rewrite (and reuse).

好的程序員知道去編寫什么。偉大的程序員知道如復用些什么。

While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all.

當然我不是在說自己是個偉大的程序員，只是在嘗試模仿。偉大程序員一個很重要的特征就是構建的懶惰性。他們明白得到一個A不是為了努力而是為了結果，并且從一個很好的部分性解決方案開始總是比從頭開始容易的多。

Linus Torvalds, for example, didn't actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten—but while it was there, it provided scaffolding for the infant that would eventually become Linux.


Linus Torvalds就是個很好的例子，他世界上沒有從最開始編寫Linux。而是從復用Minix的代碼和思想開始，Minix是一個小的用于PC的類Unix操作系統(tǒng)。最終所有的Minix代碼被去掉和重寫——但是還存在的時候，它為后來成為幼兒期的Linux提供了一個腳手架。


In the same spirit, I went looking for an existing POP utility that was reasonably well coded, to use as a development base. The source-sharing tradition of the Unix world has always been friendly to code reuse (this is why the GNU project chose Unix as a base OS, in spite of serious reservations about the OS itself). The Linux world has taken this tradition nearly to its technological limit; it has terabytes of open sources generally available. So spending time looking for some else's almost-good- enough is more likely to give you good results in the Linux world than anywhere else.

運用同樣的想法，我開始尋找一個已經(jīng)存在的相當不錯的POP軟件，作為開發(fā)的基礎。Unix世界代碼分享的傳統(tǒng)一直以來都是很有利于代碼復用的（這就是為什么GNU計劃選擇Unix作為基礎系統(tǒng)，雖然對于系統(tǒng)本身存在一些嚴肅的保留意見）。Linux世界已經(jīng)把這項傳統(tǒng)發(fā)揮到了技術的極限；這里有數(shù)以萬計字節(jié)的開源資源可以獲得。因此在Linux世界里花些時間去尋找別人“很不錯的軟件”比在別的地方更有可能讓你有好的收獲。

And it did for me. With those I'd found earlier, my second search made up a total of nine candidates—fetchpop, PopTart, get- mail, gwpop, pimp, pop-perl, popc, popmail and upop. The one I first settled on was `fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release.

對我來說那是很有效的。加上先前找到的那些，我的第二次搜索一共找到了9個候選對象——fetchpop,PopTart,get-mail,gwpop,pimp,pop-perl,pope,popc,popmail和upop。我第一個選中的是Seung-Hong編寫的fetchpop。我把我的頭部重寫特性加到里面，并且做了一些其他的改進，作者接受并且把這些加進了1.9版。

A few weeks later, though, I stumbled across the code for popclient by Carl Harris, and found I had a problem. Though fetchpop had some good original ideas in it (such as its background-daemon mode), it could only handle POP3 and was rather amateurishly coded (Seung-Hong was at that time a bright but inexperienced programmer, and both traits showed). Carl's code was better, quite professional and solid, but his program lacked several important and rather tricky-to-implement fetchpop features (including those I'd coded myself).

然而，幾周之后，我無意間發(fā)現(xiàn)了Carl Harris編寫的 popclient 代碼，并且我縣我面臨一個問題。雖然fetchpop有很多很好的原始創(chuàng)意（例如他的后臺守護模式），但是它只能處理POP3協(xié)議，并且代碼編寫比較業(yè)余（當時Seung-Hong是一個很聰明但是缺少經(jīng)驗的程序員，并且兩種特點都呈現(xiàn)了出來）。Cail的代碼要好的多，相當?shù)膶�業(yè)和穩(wěn)定，但是他的程序缺少幾個重要并且難以實現(xiàn)的fetchpop的功能（包括我、編寫的那些）。

Stay or switch? If I switched, I'd be throwing away the coding I'd already done in exchange for a better development base.


堅持還是改變？如果我改變，我將會拋棄掉我已經(jīng)編寫的代碼，來換取一個好一些的開發(fā)基礎。

A practical motive to switch was the presence of multiple- protocol support. POP3 is the most commonly used of the post- office server protocols, but not the only one. Fetchpop and the other competition didn't do POP2, RPOP, or APOP, and I was already having vague thoughts of perhaps adding IMAP (Internet Message Access Protocol, the most recently designed and most powerful post-office protocol) just for fun.



選擇改變的一個很實際的動機是對多協(xié)議的支持。POP3是運用最廣泛的POP服務器協(xié)議，但并不是唯一的。fetchpop和其他的幾個軟件都不支持POP2，RPOP或者APOP，而我已經(jīng)有一個模糊的想法：也許可以為了好玩增加IMAP協(xié)議（Internet Message Access Protocol 最近開發(fā)設計的并且很有發(fā)展?jié)摿Φ腜OP協(xié)議）。


But I had a more theoretical reason to think switching might be as good an idea as well, something I learned long before Linux.

但是，有一個更理論的原因讓我覺得改變也許是個好主意。這是我在linux之前很久發(fā)現(xiàn)的。

3.``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)

“計劃扔掉一個，無論如何你要扔掉一個”（Fred Brooks 《人月神話》11章）

Or, to put it another way, you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you
want to get it right, be ready to start over at least once [JB].

換句話說，直到你真正第一次實施了一個解決方案之前你往往不能真正明白一個問題。第二次，也許你能足夠明晰如何如正確的做。因此如果你想要把事情做對的話，準備好至少重來一次。

Well (I told myself) the changes to fetchpop had been my first try. So I switched.

好吧（對我自己來說）對于fetchpop的改變是我的第一次嘗試，所以我選擇了改變。

After I sent my first set of popclient patches to Carl Harris on 25 June 1996, I found out that he had basically lost interest in popclient some time before. The code was a bit dusty, with minor bugs hanging out. I had many changes to make, and we quickly agreed that the logical thing for me to do was take over the program.


當我在1996年6月25日發(fā)給Cail Harris第一個補丁的時候，發(fā)現(xiàn)他在很久之前就基本上對popclient失去了興趣。這些代碼有點陳舊，有些小的bug。有許多改進要我去做，我們很快達成了一致，接受這個項目成為理所當然的事情。

Without my actually noticing, the project had escalated. No longer was I just contemplating minor patches to an existing POP client. I took on maintaining an entire one, and there were ideas bubbling in my head that I knew would probably lead to major changes.

我沒有什么覺察，這個計劃已經(jīng)升級了。我不再僅僅給POP客戶端做一些小補丁。我負責起了整個程序的維護，同時有些想法在我腦子里面出現(xiàn)了，我認為這些想法也許能夠實現(xiàn)一些大的變動。

In a software culture that encourages code-sharing, this is a natural way for a project to evolve. I was acting out this principle:

在一個倡導分享的軟件文化里面，這是一個項目進化的最自然的方式。我正在實踐這條法則：

4.If you have the right attitude, interesting problems will find you.

如果你有正確的態(tài)度，有趣的問題就會找上門來。

But Carl Harris's attitude was even more important. He understood that 。

但是Cail Harris的態(tài)度甚至更為重要，他明白:

5.When you lose interest in a program, your last duty to it is to hand it off to a competent successor.


當你對一個程序失去興趣的時候，你最后的責任就是把它交給一個能夠勝任的繼承者。

Without ever having to discuss it, Carl and I knew we had a common goal of having the best solution out there. The only question for either of us was whether I could establish that I was a safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will do as well when it comes my turn.

甚至不用什么討論，Carl和我都明白我們有一個共同的目標：找到最好的解決方式。對于我們兩個人來說，唯一的問題就是我是否能夠證明我的可靠性。一旦我做到了，他就會優(yōu)雅快速的那樣去做。我希望當有一天輪到我的時候，我也能那樣去做。