開源專案之憾

開源專案之憾

2009年12月29日

我是John Gruber的Markdown的大粉絲。當談及web的人性化標記語言時，我認為不是所有人都像Gruber先生一樣可以搞定它。他的哲學從一開始就很明確：

Markdown的目的是儘可能的易於閱讀、易於編寫。
然而，強調可讀性是高於一切的。Markdown-formatted文章應該是按原樣發表的，以純文字形式，而不包含it’s這種標籤或格式化的指令。 儘管Markdown’s語法受到一些現有的文字到html過濾器的影響，—包括Setext, atx, Textile, reStructuredText, Grutatext,和EtText —，Markdown’s語法的最大靈感源泉是純文字電子郵件格式。

如果是任何形式的ASCII頭，你會立即感覺在Markdown中賓至如歸。對於線上做許多編寫的人，它的設計是如此明顯。因為它模仿我們現在已經使用了幾十年的共同的明文規定。這當然比我選擇的研究更加直觀。

經歷了Stack Overflow的一年半的現實Markdown世界經驗，我們已經很高興了。我想說，Markdown是除了所有其他我嘗試過的標記形式以外最差的。當然，口味不盡相同。 有很多可行的替代方案，但是我毫不猶豫得把Markdown作為最好的人性化標記選項來推廣——就算不是最好的。

提醒一下，Markdown並不是完美的。在暴露於大量受眾之後，Stack Overflow和GitHub各自獨立地發現了三個困惑很多使用者的特性：

1.不通過某種明確的標記，URLs不會是超連結。
2.下劃線 [ _ ]可以用來分割粗體和斜體，也適用於內部詞強調。儘管像"italic"的典型使用是明確的，但是在諸如"some_file_name"和"file_one and file_two"的短語，有令人不安的和意想不到的副作用。
3.這是段落而不是面向行的。Returns不能自動轉化成換行符。相反，由一個或多個空行隔開的段落被檢測為一個或多個連續的行文字。

問題1和2是如此基本、普遍，以至於我認為它們應該得到的Markdown規範本身的改變 。 在意想不到的內部詞強調的地方有如此多的困惑，失敗的自動超連結的URLs。甚至應該在我們出版私人測試版之前，改變這些Markdown規則。問題3，返回到換行符轉換，是較為有爭議。這個問題我還沒有做出決定，但我相信這是一個足以保證顯式的選擇方式。在每一個Markdown實現中它應該是一個標準的可配置選項，你可以根據目標受眾開啟或關閉。

Markdown最初是在2004年推出的，從那時起，它已在web上獲得相當多的關注。 我的意思是， 它沒有MediaWiki （感謝上帝），但它積極使用在網站群上，其中的一些很受歡迎。對於這樣一個受歡迎的標記形式，有點奇怪的是，官方上一次更新的規範和參考實現是在2004年底。

這讓我得出Markdown最大的問題是：John Gruber。

我的意思並不是把它作為個人批評。 John是一個非常棒的作家和Markdown有一個(主要)固體規範,具有強大的願景宣告。但事實上，五年來沒有改善任何規範或參考實現就是一種問題。

在至今的2004年的Markdown 1.0.1 Perl實現中，有一些相當嚴重的缺陷。John在第八個版本1.0.2測試版已經修復的缺陷再沒有復現過。當然，如果你知道正確的Google魔法，你可以挖掘的未發行的的偷偷的在2007年5月上傳的1.0.2b8版的存檔，並且開始嘗試手工修復缺陷。這正是我所要做的，在我們開源的C#實現的Markdown修復缺陷，它自然是基於重大的(僅技術上的)1.0.1發行版。

我還期待一個一些基本的測試套件或輸入/輸出檔案樣本的參考實現，因此我已經正確地實現它了，我就可以確定。沒有這樣的好運氣；來自Gruber網站的官方檔案包括裸Perl檔案連同readme和licence。“test”這個詞並沒有出現。我不得不做更多的大量搜尋，最後發現MDTest 1.1。我不確定這些測試來自哪裡，但是它們似乎由Michel Fortin，主要的PHP Markdown實現的作者，來維護。

但是 John Gruber建立了Markdown。他提出了這個概念和最初的實現。在每一種意義上，他是Markdown之父。Markdown是他的孩子。

作為Markdown的“父親”，帶領他的孩子走向成熟，John有幾個關鍵的責任。即，引領。設定方向。除了2004年的初始推動，他幾乎沒有什麼動作了。John按照Steve Jobs執行蘋果的方式，執行著這個特殊的開源專案——全憑自我的力量。這樣很糟糕。

從那時起，所有我能找到的是關於模糊的郵件列表的零星活動和消極被動的社群互動。

2008年3月15日，02：55，John Gruber寫到：

我鄙視你對Text::Markdown所做的，這或多或少給它取了一個別名MultiMarkdown，幾乎是我不同意的語法補充條款的每一個部分。

哇，那是相當強大的語言。我很高興我正在激起強烈的意見，很高興剪刀你為Markdown的方向做的積極貢獻。

就我個人而言，我其實不喜歡（或使用）MultiMarkdown的擴充套件。列表中幾次所標記的，我不認為我以任何方式所做的事情在它當前的形式下，在技術上/內部上是好的解決方案，正因如此，Markdown.pl仍然是較好的“參考”實現。

不過我覺得有些事很諷刺，你可以批評實際上把Markdown（他已經公開承認目前的缺陷）向前移動的積極的努力。當它比你的努力通過更多的呃測試套件，當自2004年以來，你還沒有被打擾到自己的網站更新的專案，儘管有程式碼更新，在你的網站發現（如果你挖掘）程式碼遠遠晚於此。

我鄙視複製貼上程式碼，並沒有（真正）原因——看到兩個呆板的同一段CPAN程式碼的副本，我很難過。因此我做了一些事情來事先考慮這些情境。也許如果你想把努力維護一個社群，再過去的4年的任何時間中把Markdown.pl向前移動，你不會處於人們拿走“你的孩子”並把它 扭曲到你討厭的境地中。如果從Markdown.pl開始，作為選項的向前進，然後,那將會是我首選的路線——但是，我沒有看到五分之一的perl Markdown實現產生任何價值。

這幾乎是指出，John Gruber，這個為我們帶來Markdown的人，是阻礙Markdown前進和成熟的最大障礙。看到這種粗心大意的開原始碼的父母我非常難過。當你可以使用社群工作的時候，為什麼要抵抗呢？ 它本不是這樣的。也不應該是這樣的。

現在回想起來，我認為Markdown最根本的問題是專案的官網是John網站的一組靜態web頁面。Gruber可以以一種更順從的開源的合作，而非一大堆靜態HTML的方式來主持Markdown專案。我敢肯定SourceForge是在2004年底左右，今天對適當的開源專案託管有許多選擇——GitHub, Google Code, CodePlex等等。什麼阻止他在任何使用Markdown的網站開店，現在，今天？ Markdown是Gruber的孩子，毋庸置疑，但它大於任何一個人。它是開源的。它也屬於社群。

現在我們有兩個世界裡最糟糕的。從上層缺乏領導能力，一群支離破碎、不協調的社群努力推動Markdown，其中沒有一個正式標準。這不僅僅對於那些試圖找到Markdown的準確資訊的人不方便；它實際上危害到了專案的未來。也許這是真的,你不可能殺死一個開源專案，但是糟糕的父母足夠使得其成長遲緩，甚至有點失調。

我並不是不尊重。如果我不在乎，如果我認為這個專案和John Gruber沒有價值，我不會這樣提出來。Markdown是開源組織中小而重要的一部分。這個專案值得更好的管理。然而社群可以一個(許多)開源孤兒程式碼的嬰兒做很多事情，是他們擁有一個比它們父母負責時更加光明的未來。

Jeff Atwood發表

原文標題：Responsible Open Source Code Parenting
連結：http://www.codinghorror.com/blog/2009/12/responsible-open-source-code-parenting.html