# 公開你的動機 盡可能公開你的組織的目標，不要因此而讓商業秘密妥協。如果你希望項目能夠獲得某個特定的特性，例如你的客戶要求這個特性，那么就應該在郵件列表中坦率的說出來。如果客戶希望保持匿名，實踐中這種情況很多，至少要詢問一下客戶是否愿意以未命名的方式使用他們的實例。開發社區對于你為什么這樣做的*原因*了解越多，就會對你提議的事情越感到舒服。 這與直覺背道而馳—得到容易甩掉難—知識就是力量，你的目標別人知道的越多，他們就越有可能超越你的控制能力。但是那種直覺在這里并沒有錯。通過公開支持這個特性（或是bug修正或其他任何東西），你*已經*亮出了底牌。現在唯一的問題是你能否成功的引導社區來分享你的目標。如果你僅僅是表明你需要它，而不能提供任何表明原因的切實例子，你的論點就會很脆弱，而人們會開始猜疑其隱藏的動機。但是如果你能夠提供現實的場景來展示為什么提議的特性是重要的，就可以有力的影響辯論的效果。 為了看清楚這樣做為什么有效，考慮另外一種選擇。關于新特性或新方向的討論會非常耗時和煩人。人們提出的論點經常會變成“我個人希望X，”或曾經流行的“根據我多年作為軟件設計師的經驗，對用戶來說，X是極端重要的/一個無用的花邊功能不會讓任何人滿意。”可以預料到，現實用例的缺乏不僅不會縮短或緩和這種辯論，而會扯得離實際用戶體驗越來越遠。如果沒有一些增補的力量，那么最終的結果很可能需要由口才最好、堅持最久或地位最高的人決定。 對于有許多客戶數據的組織，你有機會提供這種增補的力量。你可以作為無法達到開發者社區的數據的信息管道。不必因為那些支持你愿望的信息事實而感到窘迫。大多數開發者個人沒有他們所寫軟件如何使用的廣泛經驗。每個開發者都會按照自己的怪異方式使用軟件；只要有其他的使用模式，她就會憑直覺并臆斷之，而且事實上，她們知道這一點。通過提供包含可觀用戶數量的可信數據，你就象為整個公共開發社區提供了氧氣。只要你提供的例子是正確的，他們就會狂熱的歡迎它，就會推動事情往你希望的方向發展。 關鍵是提供正確的例子。不要因為你要應付大量需要某特性（或以為他們需要）的用戶，就堅決要求你的特性，也就是你的解決方案必須實現。相反，你必須將你最初的帖子關注于問題，而不是一個特定的解決方案。詳細描述你的客戶遇到問題的細節，盡可能提供你已經完成的分析，以及你能想到的可行性方案。當人們開始考慮不同方案的效果時，你可以繼續通過提供數據來支持或反對她們的意見。你在心里可以有一個特定的解決方案，但是不要在開始單獨提出來以期望獲得特殊的考慮。這不是欺騙，這只是標準的“誠實代理人”的行為。畢竟，你的真正目標是解決問題；一個解決方案只是達到目標的一種方法。如果你選中的解決方案確實更好，其他開發者最終會識別出來—她們會出于自愿的跟進，肯定比你通過威逼她們實現更好。 （當然，也有可能她們找到了更好的方案。） 這不是說你不能說出你看好某個方案。但是你必須耐心的查看你所做的分析反復成為公共開發列表的中心。不要在列表中說“是的，我們試過這種方式，但是因為原因A、B和C，它是行不通的。當你徹底了解它后，解決它的唯一辦法是...”問題不是它聽起來很傲慢，而是讓人覺得你對此問題*已經*研究了許多未知的（但是，人們會假設有很多）分析資源，只是一切都在門后面。它讓人覺投入的精力白費了，或許已經做出了決定，而公眾都不是有利害關系的人，這是招致怨恨的好方法。 自然，*你*知道你自己在某個問題上所投入的力量，而這些知識從某種意義上來說是一種劣勢。它讓你的開發者處于和郵件列表中的其他人些許不同的心理空間，減弱了開發者從那些普通人的視角看待這個問題的能力，這些普通人沒有像開發者那樣考慮過這個問題。你越早能夠讓所有人用與你相同的術語考慮問題，這種差距就會越小。這種邏輯不僅適于個人技術情形，而且適用于更廣泛的讓你的目標盡可能清晰的授權。未知總比已知的更不穩定。如果人們理解了為什么你希望你所希望的，即使他們不認可，在與你交談時也會感到舒服些。如果他們不能指出何事讓他們憤怒，他們會假定最壞的情況，至少有時候。 你不能宣傳所有的事情，當然，人們也不會期望你如此。所有的組織都有秘密；或許會因為利益，但是沒有利益也會如此。如果你必須發起這樣一個過程，而無法揭示任何原因，那就提供你在這種不利條件下最好的論點，并接受你將不會在討論中獲得你期望影響力的后果。這是讓你不必為開發社區支付薪水的一個折衷手段。