# 市場營銷
雖然大多數開源開發者不愿意承認,但市場推廣確實有用。好的營銷活動*可以*為開源產品創造良好的氛圍,即使此時頑固的編碼者因為一些無法說明的原因,對于軟件還沒有清晰肯定的思路。這里我不會討論一般意義的市場營銷的軍備競賽動力學。所有參與到自由軟件的公司最終都會發現自己需要考慮如何營銷自己、軟件或他們與軟件的關系。下面是在進行這種努力時如何避免落入陷阱的建議;請看[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “公開性”](# "公開性")。
### 記住你正在被注視著
為了讓志愿開發者社區一直站在你一邊,*非常*重要的一點是不要說任何不能確定正確的事情。作出任何聲明前要仔細審核,并要為公眾提供獨立檢查該聲明的方法。獨立事實檢查是開源項目的主要組成部分,它不僅僅適用于代碼。
很自然,沒有人會建議公司作出未驗證的聲明。但是在開源活動中,通常會有不可思議的大量擁有專業技能的人去驗證聲明—這些人也都有高速的寬帶接入和足夠的社會聯系,可以用一種危險方法發布他們的發現,他們一定會這么干。當Global Megacorp化工的工廠污染了河流,只有經過訓練的科學家可以驗證,他們也會受到Global Megacorp科學家的反駁,讓公眾抓耳撓腮而不知如何考慮。而另一方面,你在開源世界中的行為不僅是可見的和可記錄的;也很容易被許多人獨立的檢查,得出他們自己的結論,并口頭傳播這些結論。這種交流網絡一直都在;那是開源操作的本質,他們可以用來傳播任何信息。如果不是不可能,反駁通常很困難,特別是當某人所說的是正確的。
例如,如果你們確實這么做了,可以稱你的組織“資助了項目X”。但是,如果大多數代碼是外人寫的,不要稱自己為“X的制造者”。相反地,如果任何人都可以看到版本庫只有少量代碼變更來自于組織之外,不要聲明已經有了一個深入參與的開發者社區。
不久之前,我看到一個知名計算機公司的一次聲明,說明他們以開源許可證發布了一個重要的軟件包。當最初的聲明發出之后,我看了一下他們的公共版本控制版本庫,發現其中只有三次修訂。換句話說,他們只是做了一次代碼的初始化導入,之后沒做什么事情。此事本身沒有什么好擔心的—畢竟,他們只是做了聲明。沒有理由期待會立刻發生大量開發活動。
不久之后,他們作出另一次聲明。下面是將名稱和數字替換后聲明:
> *我們很高興的宣布經過Singer社區嚴格的測試,Linux和Windows版本的Singer?5已經做好生產使用的準備。*
很想知道是什么社區進行的“嚴格測試”,我回到版本庫去看最近的變更歷史。項目還在修訂3,很明顯,他們沒有發現*任何一個*值得在發布前修訂的bug。考慮到社區測試一定是記錄到了其他地方,接著我檢查了bug跟蹤系統。發現剛好有6個開放的問題,其中四個已經打開了幾個月。
當然,這是乞丐的信仰(不可信)。當測試者在一個大型和復雜的軟件上認真推敲一段時間,他們一定會發現bug。即使bug的修正不會進入即將到來的版本,人們還是希望有一些版本控制活動會作為測試過程的結果出現,或至少是一些新的問題。很顯然,在開源許可證聲明和第一次開源發布聲明之間沒有發生任何事情。
重點不是說這個公司在社區測試問題上說了謊。我不知道他們到底做了沒有。但是他們很明顯*像*是在欺騙。因為,無論是版本控制版本庫還是問題跟蹤系統,都沒有任何跡象來說明所謂的嚴格測試曾經發生過,這個公司要么不要過早的聲明,要么提供一些測試結果的明確鏈接(“我們發現了278個bug;點擊此處看詳細內容”)。后一種方法可以讓任何人迅速掌握社區活動的級別。就像前面說的,我只有了幾分鐘就確定了這個社區測試的真相,它沒有在任何常見的地方留下痕跡。那樣不會花費太多力氣,我確信我不是唯一保持疑惑的人。
當然,透明性和可驗證性也是準確信用的重要部分。關于這些內容可以看[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")的[the section called “榮譽”](# "榮譽")。
### 不要痛擊競爭開源產品
要忍住不要發表關于競爭開源軟件的負面意見。可以做的是提供負面的*事實*—也就是通常在一些好的比較圖表上可以輕易確定的斷言。但是最好避免不太嚴格的本性的負面特征,有兩個原因。首先,這樣會點燃論戰而脫離有建設意義的討論。其次,更重要的,在*你的*項目的一些志愿開發者會轉向為競爭項目工作。開始并不是很明顯:項目都在同一個領域(這也是為什么他們會競爭),擁有專業技能的開發者會在任何可以發揮專業才能的地方作出貢獻。即使沒有直接的開發者重疊,也很可能你的項目的開發者會與關聯項目的開發者相識。他們維護建設性的個人關系的能力會被負面營銷信息所束縛。
在開源世界中,痛毆閉源產品中的競爭者是可以廣泛接受的,特別是如果這些產品是微軟制造。個人來講,我為這種趨勢感到悲哀(雖然如此,這種直接基于事實的比較沒有任何錯誤),不僅僅是因為這樣很粗魯,也因為這樣很危險,讓一個項目開始相信它自己的夸夸其談,并忽視競爭者實際上可能更加優越的方式。通常情況下,可以仔細觀察市場聲明的效果,因為這也會發生在你自己的開發社區。人們可能因為市場美元的支持而喪失客觀性,無法看清自己軟件的真正力量和弱點。一個很可能出現的情形,某個公司的開發者會公開展示自己對于某個市場聲明的無辜,甚至是直接在公共論壇。很明顯,他們不應當直接跳出來否決市場營銷信息(除非它事實上是錯誤的,盡管人們希望此類事情能夠盡早被捕獲)。但是他們可能會一次次的取笑這種行為,這也是將開發社區的其余部分帶回地球的一個方法。
- 前言
- 為什么寫這本書?
- 誰應該讀本書?
- 資料來源
- 致謝
- 免責聲明
- 1. 介紹
- 歷史
- 現狀
- 2. 起步
- 從你擁有的開始
- 選擇許可證并應用
- 設置風格
- 通告
- 3. 技術基礎設施
- 一個項目需要什么
- 郵件列表
- 版本控制
- Bug跟蹤
- IRC / 實時聊天系統
- RSS供稿
- Wikis
- 網站
- 4. 社會和政治的基礎架構
- 慈善獨裁者
- 共識為基礎的民主(Consensus-based Democracy)
- 寫下所有的內容
- 5. 金錢
- 參與的類型
- 長期雇傭
- 作為一些個體出現,而不是一個整體
- 公開你的動機
- 錢不能讓你可愛
- 契約
- 資助非編程活動
- 市場營銷
- 6. 交流
- 人如其文
- 避免常見的陷阱
- 刺兒頭
- 處理成長
- Bug跟蹤系統中無對話
- 公開性
- 7. 打包、發布和日常開發
- 版本號
- 發布分支
- 穩定發布版本
- 打包
- 測試和發布
- 維護多發布線
- 發布和日常開發
- 8. 管理志愿者
- 從志愿者中獲取最多
- 像分擔技術任務一樣分擔管理任務
- 轉化
- 提交者
- 榮譽
- 分叉
- 9. 許可證,版權和專利
- 術語
- 許可證的方面
- GPL和許可證兼容性
- 選擇一個許可證
- 版權分配和所有權
- 雙許可證模式
- 專利
- 深入資源
- A. 自由版本控制系統
- B. 自由Bug跟蹤系統
- C. 為什么我要關注車棚的顏色?
- D. 報告bug的樣例指導
- E. 版權