# Appendix E. 版权 ~~~ 本作品按照创作共用署名-相同方式共享 3.0 Unported许可证发布，完整的许可证 可以访问http://creativecommons.org/licenses/by-sa/3.0/deed.zh，或者发送 信件到Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA。许可证的摘要如下，之后是完整的法律文本，如果您希望使用其他许可证发布 本作品部分或全部内容，请联系作者Karl Fogel<kfogel@red-bean.com>。 -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- 您可以自由： * 分享 – 复制、发行、展览、表演、放映、广播或通过信息网络传播本作品 * 重新修改 – 创作演绎作品 惟须遵守下列条件： * 署名 – 您必须按照作者或者许可人指定的方式对作品进行署名。 * 相同方式共享 — 如果您改变、转换本作品或者以本作品为基础进行创作， 您只能采用与本协议相同的许可协议发布基于本作品的演绎作品。 * 对于本作品的任何复用或分发，必须清晰说明本作品的许可证条款，最佳 的方法是提供本文的链接。 * 如果得到版权所有者的许可，以上所有条件可以免除。 * 本许可证未有任何内容损害或限制作者的道德权利。 -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- Creative Commons Legal Code: Attribution-ShareAlike 3.0 Unported CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. License: THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. 1. Definitions a. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License. b. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined below) for the purposes of this License. c. "Creative Commons Compatible License" means a license that is listed at http://creativecommons.org/compatiblelicenses that has been approved by Creative Commons as being essentially equivalent to this License, including, at a minimum, because that license: (i) contains terms that have the same purpose, meaning and effect as the License Elements of this License; and, (ii) explicitly permits the relicensing of adaptations of works made available under that license under this License or a Creative Commons jurisdiction license with the same License Elements as this License. d. "Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership. e. "License Elements" means the following high-level license attributes as selected by Licensor and indicated in the title of this License: Attribution, ShareAlike. f. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License. g. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast. h. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work. i. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation. j. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images. k. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium. 2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws. 3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below: a. to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections; b. to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified."; c. to Distribute and Publicly Perform the Work including as incorporated in Collections; and, d. to Distribute and Publicly Perform Adaptations. e. For the avoidance of doubt: i. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; ii. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and, iii. Voluntary License Schemes. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License. The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved. 4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions: a. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(c), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(c), as requested. b. You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. If you license the Adaptation under one of the licenses mentioned in (iv), you must comply with the terms of that license. If you license the Adaptation under the terms of any of the licenses mentioned in (i), (ii) or (iii) (the "Applicable License"), you must comply with the terms of the Applicable License generally and the following provisions: (I) You must include a copy of, or the URI for, the Applicable License with every copy of each Adaptation You Distribute or Publicly Perform; (II) You may not offer or impose any terms on the Adaptation that restrict the terms of the Applicable License or the ability of the recipient of the Adaptation to exercise the rights granted to that recipient under the terms of the Applicable License; (III) You must keep intact all notices that refer to the Applicable License and to the disclaimer of warranties with every copy of the Work as included in the Adaptation You Distribute or Publicly Perform; (IV) when You Distribute or Publicly Perform the Adaptation, You may not impose any effective technological measures on the Adaptation that restrict the ability of a recipient of the Adaptation from You to exercise the rights granted to that recipient under the terms of the Applicable License. This Section 4(b) applies to the Adaptation as incorporated in a Collection, but this does not require the Collection apart from the Adaptation itself to be made subject to the terms of the Applicable License. c. If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Ssection 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties. d. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise. 5. Representations, Warranties and Disclaimer UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. 6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 7. Termination a. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above. 8. Miscellaneous a. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. b. Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License. c. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. d. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. e. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You. f. The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law. Creative Commons Notice Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor. Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, Creative Commons does not authorize the use by either party of the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. For the avoidance of doubt, this trademark restriction does not form part of the License. Creative Commons may be contacted at http://creativecommons.org/. ~~~

# Appendix D. 报告bug的样例指导 这是Subversion项目针对新用户如何报告bug的在线指导的少许修改版本。为什么项目有一个这样的指导的重要性请见[Chapter 8, *管理志愿者*](# "Chapter 8. 管理志愿者")的[the section called “将每个用户当作潜在的志愿者”](# "将每个用户当作潜在的志愿者")。原始的文档位于[http://svn.collab.net/repos/svn/trunk/www/bugs.html](http://svn.collab.net/repos/svn/trunk/www/bugs.html)。 ~~~ Subversion中如何报告Bug 该文档说明了如何以及在何处报告Bug。（这里不是所有现存Bug的列表 - 您可以 在这里得到。） 何处报告Bug --------------------- * 如果是Subversion本身的Bug，可以发送邮件到users@subversion.tigris.org。 如果确认是bug，或许您可以将其输入问题跟踪系统。（或者如果您对Bug 非常确定，可以直接在我们的开发列表dev@subversion.tigris.org发布。 但是，如果您不能确定，最好首先在users@提交；某人会告诉您您所遇到的 情况是否与预期一致。） * 如果是APR库的Bug，请同时在以下列表中报告： dev@apr.apache.org，dev@subversion.tigris.org * 如果是Neon HTTP库的Bug，请同时在以下列表中报告： neon@webdav.org，dev@subversion.tigris.org * 如果是Apache HTTPD 2.0的Bug，请同时在以下列表中报告： dev@httpd.apache.org，dev@subversion.tigris.org。Apache httpd 开发者邮件列表流量较大，您的报告可能会被错过。您也可以在 http://httpd.apache.org/bug_report.html发起一个bug。 * 如果您的毯子有bug，请给他一个拥抱让它保持温暖。 如何报告一个Bug ------------------- 首先，请确保它是一个bug。如果Subversion无法按照您的预期工作，请检查 文档和邮件列表，确保它确实应该按照您的预期工作。当然，如果是常识， 例如Subversion破坏了您的数据并导致您的显示器冒烟，您可以相信自己的 判断。但是如果并不确定，请继续在用户邮件列表users@subversion.tigris.org 中询问，或者在IRC的irc.freenode.net中的频道#svn中询问。 一旦您确定是一个bug，最重要的事情得到一个简单的描述和重现步骤。例如， 如果您发现的bug，只会发生在5个文件的10次提交中，请设法使之在单个文件 的单个提交中发生。重现步骤越简单，开发者越有可能重现bug并修正它。 当您写下重现步骤时，不要仅仅写下使bug发生的散文描述，而应当给出一个 您所运行命令的一系列文本脚本，及其输出。请使用复制粘贴，如果与文件 有关，请包含文件名，如果您觉得与内容有关，也请提供文件内容。最好是能 提供打包的重现步骤脚本，那会使我们获益良多。 快速健全性检查：您正在运行Subversion最近的版本，对吧？:-)或许bug已经 修正；请对最新的Subversion开发树运行重现步骤进行测试。 除了重现步骤，我们也需要重现Bug的完整环境描述。包括： * 您的操作系统 * Subversion的发布版本和修订版本 * 构建Subversion的编译器和配置选项 * 您对Subversion的私下修改 * 运行Subversion的Berkeley DB版本，如果使用的话 * 所有其他可能相关的事情，宁肯信息多一点也不要少一点。 一旦完成了这些，您就准备好了编写报告了。从对Bug的简短描述开始，也就是 您对Subversion的预期行为方式，与之对应的实际行为方式。虽然Bug对 你是显而易见的，但对其他人可能并不是这么明显，所以最好可以避免猜谜游 戏。然后是环境描述，以及重现步骤。如果您希望也可以包含对于原因的猜测， 甚至是修正bug的补丁，那样就太棒了 - 关于发送补丁的指导请看 http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches。 将所有信息发送到dev@subversion.tigris.org，或者如果您已经在此询问并被 要求发起一个问题，可以根据这里的指导进入问题跟踪系统。 谢谢。我们知道要发起一个有效的bug报告还有很多事情要做，但是一个好的报告 可以为开发者节省大量时间，会让bug更有可能被修正。 ~~~

# Appendix C. 为什么我要关注车棚的颜色？ 你不应当；这并没有什么意义，你有更多值得花时间的事情。 Poul-Henning Kamp著名的“车棚”论述（这个[Chapter 6, *交流*](# "Chapter 6. 交流")的节选）是一份关于项目讨论容易陷入误区的雄辩论文。经过允许在这里重新打印，原始的地址是[http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers](http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers)。 ~~~ Subject: 更绿的草坪上的车棚（任何颜色都可以）... 发自: Poul-Henning Kamp <phk@freebsd.org> 日期: 1999年10月2日 星期六 16:14:10 +0200 Message-ID: <18238.938873650@critter.freebsd.dk> 发送人: phk@critter.freebsd.dk 抄送: Blind Distribution List: ; MIME-Version: 1.0 [暗送到committers, hackers] 我的上一份小册子已经接收的差不多了，我不太需要再发送一份，今天我 有时间愿意这样做。 我对此类事务的正确决定有一些困难，这一次是密送committers和hackers， 这是我能做的最好的事情了，我不太会订阅hackers，但是之后我订阅的更 多了。 这次触发我的事情是“sleep(1)应当有小数部分”的讨论，这已经困扰我们很长 时间了，已经过了好几周了，我甚至懒得去检查。 如果你错过了这个讨论：那就太恭喜了。 有人认为如果给sleep(1)一个非整形的参数会让这个函数很脏，这点燃了 丛林山火。除此以外我不会再多说，因为与他的讨论长度相比，这确实 是一件太小的事情，于此同时我们还有许多真正的问题。 sleep(1)的传奇是我们在FreddBSD中自行车棚讨论的最吵闹案例。这些 建议已经经过充分思考，我们能够获得与OpenBSD和NetBSD，以及所有已经 编写代码的兼容性。 然而出现和启动了这样多的反对、建议和变更，我们只好以为这些变更 会把瑞士奶酪的空都插满，或者是改变可口可乐的口味等等等等。 “关于自行车棚是什么？”你们中的某些人问过我。 这是一个很长很长的故事，或者说一个很老的故事，但实际上也很短，叫做 “帕金森定律”，包含了管理动态性的深入见地。 你可以在亚马逊找到，也可能在爸爸的书架上找到，它物超所值，也值得花 时间去读，如果你喜欢呆伯特，那一定会喜欢帕金森。 有些人最近告诉我阅读之后发现只有50%可以应用到现如今，我只能说真的 够好了，大多数现代管理书籍的命中率远低于此，要知道这本书已经超过35 年了。 与自行车棚相关的特定例子中，另一个至关重要的部分是核电站，我猜这透 漏了书的年龄。 帕金森展示了如何进入主管委员会并获得建造价值几百万甚至几十亿美元的 核电站，但是当你希望建造自行车棚时，却会陷入无尽的讨论中。 帕金森解释了这是因为核电站是这样巨大，这样昂贵，这样复杂，没有人能 够掌握，甚至只是尝试，他们只是假设某个其他人已经检查了所有细节。 Richard P. Feynmann在他的书中给了许多关于洛斯阿拉莫斯（美国原子弹生 产中心）的有趣而且到位的案例。 另一方面是自行车棚。任何人可以在周末建一个，还能剩下时间看电视比赛。 所以无论如何准备，无论你的建议如何的合理，总会有人展示自己的存在， 他就在这里。 在丹麦，我们称之为“留下指纹”。它是关于个人骄傲和声望，关于能够指向 某个方向，然后说“在这里，我做的。”这是政治家的一个强烈特色，但是如 果有机会，大多数人会试试。想想我们在湿水泥上留下的足迹吧。 我只能低头向最初的建议者表示敬意，因为他将枪口从地毯处转向了剧场的 最高后座，而且这个改变就在我们现在的讨论树中。我会折返回去，来到该 线索中不太顺手的消息中。 而这些告诉我，就像我之前许诺的，我为什么不订阅hackers： 几年之前我就取消订阅了hackers，因为我无法承受紧跟邮件的压力。同样的原 因，我也取消了其他一些列表。 但我还是收到很多邮件。许多直接由过滤器转向到/dev/null：人们喜欢[遗漏的] 永远不会来到我的屏幕，例如用我不理解的语言提交到文档，以及提交到ports。 所有的事情都在没有我的时候发生，甚至我都不知道。 虽然我的邮箱有这些尖利的牙齿，我还是得到太多邮件。 这是更绿的草丛进入视野的地方： 我希望能够减少我们列表中噪音的量，我希望可以让每人经常建造一个车棚， 我真的对他们喷什么颜色并不关心。 第一个愿望是关于公民的，敏感和智能的使用我们的邮件。 如果我可以简明精确的定义一组标准，规定何时某人可以回复，何时不可以 回复邮件，这样任何人都可以认可和遵守它，我会成为一个快乐的人，但我 是太明智了，甚至不会去尝试。 但是先让我建议一些我希望邮件程序可以在人们发送或回复邮件列表时能够 提供的弹出窗口： +------------------------------------------------------------+ | 您的邮件会发送给成百上千的人，他们需要花费10秒钟来阅读才能 | | 决定是否有兴趣，阅读您的邮件至少会花费两个人周会。许多接收 | | 者会需要为下载邮件而产生花费。 | | | | 您是否绝对确定该邮件的重要程度值得打扰所有其他人？ | | | | | | [是] [修订] [取消] | +------------------------------------------------------------+ +------------------------------------------------------------+ | 警告：您还没有阅读讨论中的所有邮件，其他人已经说了您在回复 | | 中所说的内容。在回复任何邮件时，请阅读整个讨论。 | | | | | | [取消] | +------------------------------------------------------------+ +------------------------------------------------------------+ | 警告：您的邮件程序未能为您展示所有的信息。逻辑上讲您不可能 | | 阅读了整个邮件，并且理解了其内容。 | | | | 在没有全部阅读和认真思考前就发送邮件是不礼貌的。 | | | | 一个降温定时器会在一个小时内防止您回复该线索 | | | | [取消] | +------------------------------------------------------------+ +------------------------------------------------------------+ | 您编写这个邮件超过了N.NN字符/秒，不太可能以超过A.AA字符/秒 | | 的速度思考和输入，因而您的回复可能不够连贯，思考不充分且过 | | 于感情化。 | | | | 一个降温定时器会在一个小时内防止您发送任何邮件。 | | | | [取消] | +------------------------------------------------------------+ 我的愿望的第二部分更加感情化。很明显，在sleep(1)线索中我们可以操纵的 不友好火焰，尽管已经在项目中存在多年，从来没有对其有足够的关心，所以 为什么有这么多人被许多年轻人激怒？ 我希望我知道。 我知道推理对停止这种“保守主义”无能为力。可能是因为这些人对于之后提供 有形贡献的缺乏，亦或是这些人认为“我们年老还古怪，我们知道年轻人的所作 所为”。 任何一种方式对于项目都是低生产率的，但我对如何停止它没有任何办法。 我只能建议忍住不要给潜伏在邮件列表的怪兽添油加醋：直接忽略他们，不要 回答，忘记他们的存在。 我希望我们可以在FreeBSD得到一个强大且广泛的志愿者基础，而且希望我们 能够团结起来通过吞噬、分化和驱散古怪的老家伙和[漏掉的]，防范他们有 任何立足之地。 对于已经潜藏下来，由于参与这些怪人而驱散的人：我只能说不好意思，并 鼓励您无论如何继续尝试，我不希望环境成为这样。 Poul-Henning ~~~

# Appendix B. 自由Bug跟踪系统 无论项目使用哪个bug跟踪系统，某些开发者总会有些抱怨。在这一点上bug跟踪系统比其他标准开发工具更具代表性。我想这是因为bug跟踪系统是这样可视化和可交互，可以轻松的想象出一个人可以做的改进（如果某人有时间），并说出这些改进的描述。把这些不可避免的抱怨当作可信也可疑的吧—下面说的跟踪系统都已经足够好了。 在这个列表中，”问题（issue）“用于代表跟踪系统跟踪的条目。但是请牢记每个系统都会有自己的属于，对应的术语包括”制品（artifact）“或”bug“或其它。 ### **Bugzilla** — [http://www.bugzilla.org/](http://www.bugzilla.org/) Bugzilla非常流行，活跃的维护中，看起来让它的用户都很快乐。我曾经有四年在工作中使用了一个修改的变种，很喜欢它。它并不能高度的自定义，而是以一种可以看作其特性的古怪方式：Bugzilla看起来和它创建时差不多，意味着许多开发者已经习惯了它的界面，而且感觉它位于熟悉的版图。 ### **GNATS** — [http://www.gnu.org/software/gnats/](http://www.gnu.org/software/gnats/) GNU GNATS是最古老的开源bug跟踪系统之一，被广泛使用。它最大的长处是界面的多样性（可以仅仅通过浏览器，也可以通过邮件或命令行工具），以及纯文本问题存储。所有问题数据以文本文件存放在磁盘上这一事实，使我们可以轻松的编写自定义工具获取并解析数据（例如，生成统计报告）。GNATS也可以用多种方法自动吸收邮件，并根据邮件头的模式将其加入到合适的问题中，使得对于用户/开发者的对话的记录非常简单。 ### **RequestTracker (RT)** — [http://www.bestpractical.com/rt/](http://www.bestpractical.com/rt/) RT的网站说”RT是一个企业级问题系统，可以让一组人智能和有效的管理任务、问题和一个团队的用户提交的请求，以及所有的汇总。“RT有一个相对优美的web界面，也有相当广泛的安装基础。界面在视觉上有些复杂，但当你熟悉后就不会觉得那么乱了。RT的许可证是GNU GPL（出于某些原因，他们的web站点说的并不是那么清楚）。 ### **Trac** — [http://trac.edgewall.com/](http://trac.edgewall.com/) Trac不仅仅是一个bug跟踪系统了，它也是一个集成wiki的bug跟踪系统。它使用wiki链接来关联问题、文件和版本控制变更集和wiki页面。它也很易于设置，并与Subversion集成（见[Appendix A, *自由版本控制系统*](# "Appendix A. 自由版本控制系统")）。 ### **Roundup** — [http://roundup.sourceforge.net/](http://roundup.sourceforge.net/) Roundup相对来说很易于安装（只需要Python 2.1或更高版本），而且很简单。它包括web，email和命令行接口。问题数据模板、web接口和部分状态转换逻辑是可以自定义的。 ### **Mantis** — [http://www.mantisbt.org/](http://www.mantisbt.org/) Mantis是一个基于web的bug跟踪系统，由PHP编写，并使用MySQL数据库作为存储。它拥有你所期望的特性。个人来见，我觉得web界面非常干净、本能，看起来很简单。 ### **Flyspray** — [http://www.flyspray.org/](http://www.flyspray.org/) Flyspray是一个使用PHP编写的基于web的bug跟踪系统。它的网页将其描述为“非复杂的”，特性列表包括：支持多种数据库（目前支持MySQL和PGSQL）；多项目；‘关注’任务，包括发生变更时提醒（通过email或Jabber）；复杂的任务历史；CSS主题；文件附件；高级搜索特性（简单易用）；RSS/Atom供稿；wiki和纯文本输入；表决；依赖图表。 ### **Scarab** — [http://scarab.tigris.org/](http://scarab.tigris.org/) Scarab是一个高度可自定义的，完全特性的bug跟踪系统，提供了其他bug跟踪系统所支持的特性的组合：数据条目、查询、报告、相关方通知、评论的交互式累加和依赖跟踪。 它是通过管理web网页实现的。在单个Scarab安装中你可以有多个“模块”（项目）。在给定模块中，你可以创建新的问题类型（缺陷、改进、任务和支持请求等）。并可以增加任意属性，以满足你的项目特定需求。 2004末，Scarab已经接近于1.0发布版本。 ### **Debian Bug跟踪系统（DBTS）** — [http://www.chiark.greenend.org.uk/~ian/debbugs/](http://www.chiark.greenend.org.uk/~ian/debbugs/) Debian Bug跟踪系统的不寻常之处在于所有问题的输入和处理都是通过邮件完成：每个问题都有自己的专用邮件地址。DBTS的扩展性很好：例如[http://bugs.debian.org/](http://bugs.debian.org/)有277,741个问题。 因为交互是通过普通的邮件客户端，这个大多数人都熟悉并可以轻松访问的工具完成的，DBTS非常适合处理需要快速分类和响应的大规模数据。当然也有缺点。开发者需要花费时间学习邮件命令系统，用户必须在没有引导他们选择编写信息的web表单的情况下编写bug报告。也有工具可以帮助用户发送更好的bug报告，例如命令行。**reportbug**程序或Emacs的包`debbugs-el`。但大多数用户不会使用这个工具；他们只会手工编写邮件，他们可能有，也可能没有遵循你的项目所发布的bug报告指南。 DBTS有一个只读的web界面，用于查看和查询问题。 ### **Trouble-Ticket Trackers** 这更像是一个面向服务台的问题跟踪系统，而不是软件bug跟踪。你或许可以在普通的bug跟踪中正常工作，但是因为完整性这里要列出，因为可以理解某个非同一般的项目可能更需要一个trouble-ticket系统，而不是传统的bug跟踪。 - **WebCall** — [http://myrapid.com/webcall/](http://myrapid.com/webcall/) - **Teacup** — [http://www.altara.org/teacup.html](http://www.altara.org/teacup.html) （Teacup好像已经不再继续开发了，但是还有下载。请注意它同时拥有web和邮件界面。） ### **Bluetail Ticket Tracker (BTT)** — [http://btt.sourceforge.net/](http://btt.sourceforge.net/) BTT算是处于标准trouble-ticket tracker和bug跟踪之间。它提供了隐私特性，这在开源bug跟踪中并不常见：系统的用户被分为Staff、Friend、Customer或Anonymous，取决于不同的类别，会有或多或少的数据。它提供了一些邮件集成，一个命令行界面和将邮件转化为问题的机制。它也提供了一种维护与特定问题不相关信息的特性，例如内部文档或FAQ。

# Appendix A. 自由版本控制系统 这些是在2007年中段我所知的所有开源版本控制系统。我日常唯一使用的是Subversion。除了Subversion和CVS，我对大多数系统仅有很少，甚至没有任何经验；这里的信息取自他们的网站。也请看[http://en.wikipedia.org/wiki/List_of_revision_control_software](http://en.wikipedia.org/wiki/List_of_revision_control_software)。 ### **CVS** — [http://www.nongnu.org/cvs/](http://www.nongnu.org/cvs/) CVS已经有很长的历史了，许多程序员已经非常熟悉。它曾经是革命性的：它是第一个开源版本控制系统，在网络上被开发者广泛使用（在我所知的范围内），也是第一个提供匿名只读检出的系统，可以让心开发者轻松的开始参与项目。CVS只能版本化文件，但不包括目录；它能提供分支、标签和优良的客户端性能，但不能很好的处理大文件和二进制文件。它也不支持原子提交。*[免责声明：在开始替代CVS的Subversion项目前，我也在CVS开发上活跃了大约5年。]* ### **Subversion** — [http://subversion.tigris.org/](http://subversion.tigris.org/) Subversion是最早也是最重要的CVS替代者—也就是以与CVS近似的方法实现版本控制，但没有经常困扰CVS用户的一些问题和特性缺失。Subversion的一个目标就是使已经习惯CVS的用户能够平滑的过渡到Subversion。这里没有空间详细描述Subversion的特性；相关信息请看它的网站*[免责声明：我参与了Subversion开发，也是在日常中唯一使用的系统。]* ### **SVK** — [http://svk.elixus.org/](http://svk.elixus.org/) 尽管SVK建立在Subversion之上，但它更类似于下面说的一些非集中式的系统，而不是Subversion。SVK支持分布式开发、本地提交、精密的变更合并和从非SVK版本控制系统镜像目录树的能力。详细信息可以看它的网站。 ### **Mercurial** — [http://www.selenic.com/mercurial/](http://www.selenic.com/mercurial/) Mercurial是一个分布式版本控制系统，提供“完整的文件和变更集的跨索引；有效率的带宽和CPU下的HTTP和SSH同步协议；开发者分支间的任意合并；集成独立的web界面；UNIX、MacOS X和Windows跨平台能力”以及更多（前面的特性列表来自Mercurial网站）。 ### **GIT** — [http://git.or.cz/](http://git.or.cz/) GIT是Linus Torvalds开启的一个用于管理Linux kernel源代码的项目。一开始GIT仅仅限于满足kernel开发的需要，但不久就超出了这个范围，被用于Linux kernel之外的项目中。它的主页上说“...设计用于快速有效的处理非常大的项目；主要用于各种开源项目，最引人注目的是Linux kernel。 Git属于分布式源代码管理工具，类似于GNU Arch或Monotone（或私有世界的BitKeeper）。每个Git工作目录是一个完整的版本库，包含了完整的修订跟踪能力，不依赖于网络访问或中央服务器。” ### **Bazaar** — [http://bazaar.canonical.com/](http://bazaar.canonical.com/) Bazaar还处于开发中。它是GNU Arch协议的一个实现，并依然随着演进的GNU Arch协议保持兼容，而且与GNU Arch社区中对于需要用户友好的任何协议变更的进程进行配合，。 ### **Bazaar-NG** — [http://bazaar-ng.org/](http://bazaar-ng.org/) Bazaar-NG（或bzr）目前由Canonical（[http://canonical.com/](http://canonical.com/)）开发。它提供了一种在单个项目中结合集中式和非集中式工作的选择。例如，当在办公室中，你可以在一个共享的中央分支上工作；对于实验性变更或离线工作，你可以在笔记本上建立一个分支，并在之后合并回去。 ### **Darcs** — [http://abridgegame.org/darcs/](http://abridgegame.org/darcs/) “David的高级修订控制系统（Advanced Revision Control System）是另一个CVS的替代者。它由Haskell编写，已经用于Linux、MacOS X、FreeBSD、OpenBSD和Microsoft Windows。Darcs包含一个可以查看版本库内容的cgi脚本。” ### **Arch** — [http://www.gnu.org/software/gnu-arch/](http://www.gnu.org/software/gnu-arch/) GNU Arch同时支持分布式和集中式的开发。开发者将变更提交到一个可以是位于本地的”归档（archive）“，而管理员可以根据情况将变更推和拉到其他归档。这个方法学暗示了Arch提供比CVS更精密的合并。Arch也允许一个人轻松的为没有提交权限的人建立归档的分支。这里只是简短的描述；更多细节请看Arch网页。 ### **monotone** — [http://www.venge.net/monotone/](http://www.venge.net/monotone/) ”monotone是自由分布式版本控制工具。它提供了一个简单，单个文件事务的版本存储，包含完全无连接的操作，以及有效率的端到端同步协议。它理解历史敏感的合并，轻量级的分支、集成代码评审和第三方测试。它使用加密的命名和客户端的RSA凭证。它也有不错的国际化支持，没有外部依赖，可以按照GNU GPL运行在linux、solaris、OSX和windows上。“ ### **Codeville** — [http://codeville.org/](http://codeville.org/) ”为什么需要另一种版本控制系统？所有其他版本控制系统需要你小心跟踪分支间的关系，这样你才能不会重复合并同一个冲突。Codeville更加自由。它允许你随时更新或提交到任意版本库，而无需担心重复合并。“ ”Codeville为每个完成的变更创建一个标识符，并记住每个文件已经已经应用的变更列表。如果有冲突，它会检查某一方是否已经应用到另一方，如果是这样，则使另一方自动获胜。如果确实有非自动的可合并的版本冲突，codeville则与CVS的工作方式相同。“ ### **Vesta** — [http://www.vestasys.org/](http://www.vestasys.org/) ”Vesta是一个可移植的SCM[软件配置管理]系统，旨在支持任意规模的，从相对较小（小于10000行源代码）到非常巨大（10000000行）的软件系统的开发。“ ”Vesta是一个成熟的系统。它是Compaq/Digital系统研究中心10年研究和开发的成果，它是Compaq的Alpha微处理器团队两年半的时间里生产使用的系统。Alpha团队有超过150个活跃开发者位于距离几千英里的两地，分别在美国的西海岸和东海岸。该团队使用Vesta管理编译超过130MB的源数据，会产生1.5GB的衍生数据。东部的构建每天会产生10到15GB的衍生数据，全部由Vesta管理。尽管Vesta主要关注的是软件开发，但Vesta Alpha团队设法使系统可以用于硬件开发，将它们的硬件描述语言检入到Vesta的源代码控制用具中，并使用Vesta构建器构建模拟器和其他衍生的对象。前Alpha团队的成员，现在是Intel的一部分，在新的微处理器项目中还是继续使用Vesta。“ ### **Aegis** — [http://aegis.sourceforge.net/](http://aegis.sourceforge.net/) ”Aegis是一个基于事务的软件配置管理系统。它提供了一个框架，在其中一个团队的开发者可以独立的为程序的多个变更工作，而Aegis协调将这些变更集成到程序的主源中，并尽可能减少中断。“ ### **CVSNT** — [http://cvsnt.org/](http://cvsnt.org/) ”CVSNT一个高级跨平台的版本控制系统。与行业的标准CVS协议相比，添加了许多附加特性。 ... CVSNT是开源，使用GNU GPL许可证的自由软件。“它的特性列表包括通过CVS协议的认证，以及Windows特定的SSPI和活动目录。支持安全传输，通过sserver或加密的SSPI；跨平台性（可以运行于Windows或Unix环境）；NT版本与Win32系统完全集成；MergePoint处理的含义是没有更多的标签和合并；处于活跃开发中。 ### **META-CVS** — [http://users.footprints.net/~kaz/mcvs.html](http://users.footprints.net/~kaz/mcvs.html) ”Meta-CVS是一个建立在CVS周边的版本控制系统。尽管它保留了CVS的大多数特征，包括所有的网络支持，它比CVS能干，更易于使用。“META-CVS的站点包括的特性列表：目录结构版本化，改进的文件类型处理，类似和更用户友好的分支和合并，支持符号链接，附加属性列表的版本化数据，改进的第三方数据导入，以及易于从CVS升级。 ### **OpenCM** — [http://www.opencm.org/](http://www.opencm.org/) ”OpenCM设计为一个安全的，CVS的高完整性替代产品。关键特性列表可以在特性页面找到。虽然不像CVS那样‘特性丰富’，但它提供了一些CVS缺乏的特性。简要来说，OpenCM提供了第一流的重命名、配置、加密认证和访问控制和第一流的分支。“ ### **Stellation** — [http://www.eclipse.org/stellation/](http://www.eclipse.org/stellation/) ”Stellation是一个高级，可扩展的软件配置管理系统，最初由IBM研究院开发。虽然Stellation提供了任何SCM系统提供的所有标准功能，但它也提供了许多高级特性，例如面向任务的变更管理，一致的项目版权化和轻量级的分支，目的是简化由松散结合的开发者组成的大规模团队开发软件系统的难度。“ ### **PRCS** — [http://prcs.sourceforge.net/](http://prcs.sourceforge.net/) ”PRCS，项目修订控制系统是一系列工具（如CVS）的前端，提供了一种以一个整体管理一组文件和目录的方法，保存了整个集合的一致版本。 ... 它的目的类似于SCCS、RCS和CVS，但是（至少根据其作者称）与这些工具相比更加简单。“ ### **ArX** — [http://www.nongnu.org/arx/](http://www.nongnu.org/arx/) ArX是一个分布式修订控制系统，提供了分支和合并特征，加密数据完整性验证和将归档轻松发布到任意HTTP服务器的能力。 ### **SourceJammer** — [http://sourcejammer.org/](http://sourcejammer.org/) ”SourceJammer是一个使用Java编写的源代码控制和版本化系统。它由服务器端维护文件和版本历史，处理检入、检出等功能的组件，以及客户端向服务器发起请求并管理客户端文件系统的组件组成。 “ ### **FastCST** — [http://www.zedshaw.com/projects/fastcst/index.html](http://www.zedshaw.com/projects/fastcst/index.html) ”一个使用文件修订变更集，并且分布式而非集中控制的‘现代’系统。只要你有一个邮件帐号，你就可以使用FastCST。对于较大的分发，只需要一个FTP服务器和一个HTTP服务器，或使用内置的‘serve’命令来直接提供服务。所有的变更集都是全局唯一，并且有大量元数据，这样你可以拒绝任何未经测试的东西。合并是通过比较合并的变更集和当前的目录内容完成的，而不是试图将其与另一个变更集合并。“ ### **Superversion** — [http://www.superversion.org/](http://www.superversion.org/) ”Superversion是一个基于变更集的多用户分布式版本控制系统。它的目标是成为一个行业力量，商业解决方案的开源选择，提供相同（或更简单）的易用性和类似的强大。实际上，从一开始，直觉和可用的效率就处于Superversion开发的最高优先级之一。 “

# 深入资源 本章仅仅是对自由软件许可证问题的一个介绍。尽管我希望包含能够让你开始自己的开源项目的足够信息，但对于许可证问题的任何深入研究都会迅速耗尽本书所能提供的。下面的列表是一些关于开源许可证的深入材料： - *Understanding Open Source and Free            Software Licensing*作者Andrew M. St. Laurent. O'Reilly媒体出版，第一版2004年8月， ISBN: 0-596-00581-4. 这是一整本关于开源许可证的书，包含许多本章省略的主题。更多细节见[http://www.oreilly.com/catalog/osfreesoft/](http://www.oreilly.com/catalog/osfreesoft/)。 - *Make Your Open Source Software GPL-Compatible. Or Else.*作者David A. Wheeler，网站 [http://www.dwheeler.com/essays/gpl-compatible.html](http://www.dwheeler.com/essays/gpl-compatible.html). 这是一篇非常详细和优秀的文件，论述了为什么要使用GPL兼容的许可证，即使你不使用GPL本身。该文章也涉及了其他许可证问题，有高密度的优秀链接。 - [http://creativecommons.org/](http://creativecommons.org/) 创作共用是一个旨在提升比传统版权实践所提倡的更灵活和自由的版权的组织。他们不仅仅提供软件的许可证，也包括文字、艺术和音乐、以及所有用户友好的许可证可以访问的；有一些许可证是copyleft，也有一些是非copyleft但是仍然免费，另外则是一些传统的版权，但限制略有放松。创作共用站点对此有着非常清楚的解释。如果我必须描述自由软件运动更广的哲学含义，这就是一个例子。

# 专利 软件专利现在是自由软件运动中的一个避雷针问题，因为他们设置了自由软件无法防御的真正威胁。版权和商标问题一直可以绕开。如果你的部分代码看起来侵害了某人的版权，你只需要重写该部分。如果某人拥有你的项目名称的商标，最坏也就是将项目改名。尽管改名是一种暂时的不便，但长期来讲问题不大，因为代码依然发挥着应有的作用。 但是专利则是针对实现特定思想的完全禁令。无论谁编写的代码，无论使用了什么编程语言。一旦某人指控某个自由软件项目侵害了专利，这个项目必须停止实现某个特定特性，或者面对昂贵和费时的法律诉讼。因为这种法律诉讼的教唆者通常都是有大把钞票的公司—拥有抢先获得专利的资源和倾向—大多数自由软件项目不能负担后一种可能，只能立刻认输，即使他们认为在法庭上该专利很有可能无法强制执行。为了预先避免这种情形，自由软件项目必须防御性的开发编码，预先避免有专利的算法，即使知道那是针对某个编程问题的最佳，甚至是唯一可用的方法。[[31](#)] 民意调查和其他证据显示，不仅仅是开源程序员的绝大多数，也包括*大多数*程序员认为应当完全废止软件专利。[[32](#)]开源程序员容易对此有更强的感受，也许会拒绝在与软件专利的集合或强制过于接近的项目中工作。如果你的组织收集软件专利，请以公开和不可更改的方式明确，这些专利不会强加到开源项目上，他们仅用于防御某些其他组织针对你的组织的侵害事件。这不仅仅是做正确的事情，也事关开源公共关系。[[33](#)] 不幸的是，因防御目的收集专利是一项有理性的行动。当前的专利系统，至少在美国，本质上是一场军备竞赛：如果你的竞争者获得了大量专利，那么你最好的防御是也获取大量专利，这样如果你遇到了专利侵害诉讼，你可以使用类似的威胁—然后双方通常会坐下来并取得跨许可证交易，这样双方都无需支付费用，当然，不包括他们的知识产权律师。 然而，软件专利对于自由软件的危害不仅仅是对代码开发的威胁。软件专利鼓励了固件设计师中的私密气氛，他们理所当然的担心如果公布他们接口的细节，就是为其的竞争对手提供了技术帮助，使他们可以使用专利侵害诉讼进行打击。这不仅仅是理论上的危险，例如，很明显在显卡工业这存在了很长时间。许多显卡制造商很不情愿发布详细的可以为他们的显卡产出高性能开源驱动的编码规范，因而使自由操作系统无法发挥这些显卡的全部潜力。为什么生产商这样做？这与他们*反对*软件支持无关；毕竟，兼容的操作系统越多，就会有越多的显卡出售。但是那样做的结果，设计室的门后，这些厂商全部违反了他人的专利，有时是已知，有些则纯属巧合。专利是在如此的不可预测和漫无边际，没有哪个显卡厂商可以确信安全，即使经过了专利搜索。因而，制造商不敢发布他们的所有接口规范，因为这样可以使他们的竞争者可以轻易的指出是否有专利受到了侵害。（当然，这种情形的本性决定了不会从主要来源获得书面承认；我是通过个人交流获得这些信息。 ） 一些自由软件许可证有一些与软件专利斗争，或至少不鼓励软件专利的条款。例如GNU GPL包含这些语言： ~~~ 7. 若法院判决、专利侵权主张或者其他任何理由（不限于专 利争议）的结果，使得加诸于您的条件（无论是由法院命令 、协议书或其他方式造成）与本授权规定有所冲突，他们并 不免除您对于本授权规定的遵守。若您无法同时符合依本授 权所生义务及其他相关义务而进行发布，那么其结果便是您 不得发布该程序。例如，若专利授权不允许其他人直接或间 接取得复制物，通过您以免付权利金的方式再发布该程序， 您唯一能同时滿足该义务及本授权的方式就是徹底避免进行 该程序的发布。 [...] 本条的目的并不在诱使您侵害专利或其他財产权的权利主张 ，或就此类主张的有效性加以争执；本条的唯一目的，是在 保障藉由公共授权惯例所执行自由软件发布系统的完整性。 许多人信赖该系统一贯使用的应用程序，而对经由此系统发 布的大量软件有相当多的贡献；作者／贡献者有权决定他或 她是否希望经由其他的系统发布软件，而被授权人则无该种 选择权。 ~~~ Apache许可证，版本2.0（[http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0)）也包含了反专利的要求。首先，它规定在该许可证分发代码的任何人，隐含包括了一个可能他们持有并可以应用于这些代码的专利的免专利费许可证。其次，更贤明的，通过在主张做出时自动终止他们的隐含专利许可证，它惩罚了任何对代码主张专利侵害的人。 ~~~ 3.专利许可证的授予。 根据本许可证的条款，每个贡献者授予用户永久性的、全球 性的、非专有性的、免费的、无版权费的、不可撤销的(除在 本部分进行说明)专利许可证对作品进行制作、让人制作、使 用、提供销售、销售、进口和其它转让，且这样的许可证仅 适用于在所递交作品的贡献中因可由单一的或多个这样的贡 献者授予而必须侵犯的申请专利。如果用户对任何实体针对 作品或作品中所涉及贡献提出因直接性或贡献性专利侵权而 提起专利法律诉讼(包括交互诉讼请求或反索赔)，那么根据 本许可证，授予用户针对作品的任何专利许可证将在提起上 述诉讼之日起终止。 ~~~ 尽管这很有用，不管是法律还是政治，以这种方式将专利防御构建到了自由软件许可证当中，但最终这些步骤不足以形成对于自由软件的专利诉讼威胁的寒翅效用。只有国际版权法的主旨或解释可以解决这个问题。关于此问题的更多信息，以及相关的斗争，请看[http://www.nosoftwarepatents.com/](http://www.nosoftwarepatents.com/)。维基百科文章[http://en.wikipedia.org/wiki/Software_patent](http://en.wikipedia.org/wiki/Software_patent)也有许多软件专利的有用信息。我也写过一篇总结软件专利争论的blog，位于[http://www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad-idea/](http://www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad-idea/)。 [[31](#)] Sun Microsystems和IBM针对此问题也做出了完全相反的姿态，他们解放了大量软件专利—分别为1600和500—用于自由软件社区。我不是一个律师，因而无法评估这些授予的真实功用，但是即使全部是重要的专利，而且授予的条款确实能够真正的自由用于开源项目的，这也仅仅是沧海一粟。 [[32](#)] 这里有一个相关的民意调查[http://lpf.ai.mit.edu/Whatsnew/survey.html](http://lpf.ai.mit.edu/Whatsnew/survey.html)。 [[33](#)] 例如，RedHat保证它的专利对开源项目是安全的，见[http://www.redhat.com/legal/patent_policy.html](http://www.redhat.com/legal/patent_policy.html)。

# 双许可证模式 一些项目希望通过双许可证模式资助自己，也就是私有衍生作品向所有者支付使用代码的版权，但代码对于开源软件依然免费。很自然，代码库比独立应用更适合这种方式。精确的条款各不相同。通常其属于自由的许可证为GNU GPL，因为它已经禁止了他人在未经版权持有者允许前，将覆盖的代码组合到他们的私有产品中，但是有时一些自定义许可证起到相同的效果。前者的一个例子是MySQL许可证，这里有描述[http://www.mysql.com/company/legal/licensing/](http://www.mysql.com/company/legal/licensing/)；后者的例子是Sleepycat软件许可证策略，描述在[http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html](http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html)。 你或许有些疑惑：为什么明明GNU的GPL规定代码必须在较少约束的条款下发布，而版权持有者还可以提供私有许可证。答案是GPL的条款是版权持有者为所有其他人设置的；而所有者可以自由的决定*是否*对其本身应用这些条款。对此，一个好的理解方法是想象版权所有者在桶里有无数份软件的拷贝。每次它从桶中取出一个发送到世界上时，它可以决定是采用GPL，私有或其他许可证。这并不是仅仅与GPL或其他任何开源许可证相关，它仅仅是版权法所赋予的权利。 双许可证的吸引力在于，为自由软件项目提供了一种可靠的收入来源。不幸的是，它也可能干扰开源项目本身的一般动力性。问题是任何为代码作出贡献的志愿者现在开始为两个不同的实体贡献：代码的自由版本和私有版本。当然，贡献者会乐于贡献自有版本，因为这是开源项目的标准，如果是为他人的半私有收入贡献，她会感到可笑。由于双许可证的这一事实加剧了这种尴尬，版权所有者确实需要从所有贡献者收集正式的，签署的版权授权，从而才能保护自身之后不会受到不满的贡献者对于从私有收入中获取自己份额的指控。收集这种授权文件的过程意味着贡献者要严酷的面对这一事实，他们在为别人赚钱而工作。 不是所有的志愿者会因此而困扰；毕竟他们的贡献也进入了开源版本，这是他们的兴趣所在。虽然如此，双许可证是版权持有者赋予自己，而项目中的其他人所没有的特权的一个例子，而且一定程度上会引起一些紧张，至少对某一些志愿者。 在实践中，我们看到许多基于双许可证软件的公司确实没有真正平等的开发社区。他们只能从外部获得很小规模的bug修正和清理补丁，而通过内部源做大量艰苦的工作。例如，Zack Urloker，MySQL的副主管告诉我，公司通常最终会雇佣最活跃的志愿者。因而，尽管产品本身是开源的，使用GPL许可证，它的开发还是或多或少受到公司的控制，虽然也可能有人确实不满意这个公司把持着这个软件而分叉这个项目。一定程度上，这种威胁迫使公司政策的内容，但在也有一定几率，MySQL没有发现在开源世界或之外存在着接受的问题。

# 版权分配和所有权 有三种处理自由代码和文档版权所有权的方法，许多人为此做出了贡献。第一种是完全无视版权的问题（我不建议如此）。第二种方法是从项目中工作的每个人那里收集一个*贡献者许可证协议*（*CLA*），明确项目对使用个人贡献的权利。这通常对大多数项目已经足够了，更好的是在一些司法权中，CLA是可以通过email发送的。第三种方法是从贡献者那里获得真正的版权协议，这样项目（例如一些法律实体，通常是非盈利）就是所有东西的版权所有者。这通常是无懈可击的方法，但也是贡献者的负担；只有少数项目坚持如此。 请注意，即使在集中式的版权所有权时，代码[[30](#)]还是自由的，因为开源许可证并没有给版权持有者可以将所有代码的拷贝收回所有的权利。所以即使作为法律实体的项目突然转向开始将所有的代码使用限制许可证发布，也不会给公共社区带来什么问题。其他开发者可以简单的根据最新的代码拷贝开始一个分叉，并当作没发生任何事情一样继续。因为他们知道他们可以这样做，大多数被问及签署CLA或版权协议时会非常合作。 ### 无为而治 大多数项目从来没有从他们的贡献者那里收集过CLA或版权协议。相反，只要代码是合理清除，而且贡献者愿意将其组合进项目，他们就会接受代码。 在通常情况下，这是正常的。但是偶尔会有人决定因版权侵害而诉讼，声称他们是问题代码的所有者，而且他们从没有同意这些代码由项目使用开源许可证分发。例如，SCO团队向Linux团队这样做的，细节见[http://en.wikipedia.org/wiki/SCO-Linux_controversies](http://en.wikipedia.org/wiki/SCO-Linux_controversies)。当这些发生时，项目没有文档说明贡献者正式的赋予使用这些代码的权利，可能会导致一些法律辩护。 ### 贡献者许可证协议 CLA可能是在安全性和便利性之间提供了最好的折衷。一个CLA通常是一个发送给开发者填写并发回项目的电子表格。在大多数司法中，邮件提交已经足够。或许需要安全电子签名；可以咨询律师找出对你的项目最合适的方法。 大多数项目使用两个些许不同的CLA，一个针对个人，一个针对公司贡献者。但是在两种类型中，核心的语言是相同的：贡献者赋予项目*"...永久的、全世界的、非独占的、免费的、特许自有、不能取消的版权许可证，可以用于重新制作、准备衍生作品、公开显示、公开操作、发放从属证书和分发这些贡献和此类衍生作品。"*再次强调，你应当有一个律师确认CLA，但是如果你能了解所有这些程序，那样会很好。 当你从贡献者那里请求CLA时，请确认强调你*不是*要求真正的版权授予。实际上，许多CLA使用这些语句来提醒读者： > *这仅仅是一个许可证协议；它不会转移版权所有权，也不会改变因任何目的使用自己贡献的权利。* 下面是一些例子： - 个人贡献者CLA： - [http://apache.org/licenses/icla.txt](http://apache.org/licenses/icla.txt) - [http://code.google.com/legal/individual-cla-v1.0.html](http://code.google.com/legal/individual-cla-v1.0.html) - 公司贡献者CLA： - [http://apache.org/licenses/cla-corporate.txt](http://apache.org/licenses/cla-corporate.txt) - [http://code.google.com/legal/corporate-cla-v1.0.html](http://code.google.com/legal/corporate-cla-v1.0.html) ### 版权转移 版权转移的含义是贡献者将自己的贡献赋予给项目版权所有权。理想情况下，需要书面完成并传真或邮寄给项目。 一些项目坚持完全的协议，因为如果开源许可证的条款需要强制时，一个单独的法律实体拥有整个代码基的版权会非常有用。如果没有单个实体有这样的权利，所有贡献者需要合作，但问题发生时可能某人没有时间或无法找到。 不同的组织对于收集授权的严苛程度不同。有一些仅仅是某个贡献者在公共邮件列表中的简单非正式陈述—类似“我这里将我的在该项目的代码授权，使用其余代码相同的许可证条款。 ”至少有一个我交流过的律师认为这样已经足够，大体推测，可能是因为它发生在一个版权授权已经非常普通和预期的方式，而且因为它代表了项目一方对于确保开发者真正意图的*诚意*努力。另一方面，自由软件基金会则进入对立的极端：他们要求贡献者物理上签署并邮寄一份文件，包含版权授权的正式描述，有时仅针对一份贡献，有时针对当前和未来的贡献。如果开发者被雇佣，FSF也会要求雇员签署这个东西。 FSF的偏执狂可理解的。如果某人违反了GPL关于将他们的软件组合到私有程序的条款，FSF会需要与之在法庭上斗争，他们希望他们的版权在这种情况发生时可以无懈可击。因为FSF是许多流行软件的持有者，他们认为这是真实可能的。无论你的组织是否有只有你所决定的需要类似的小心谨慎，请咨询律师。通常情况下，除非一些特别的原因需要你的项目拥有完全的版权授权，你可以直接采用CLA；他们对每个人都很简单。 [[30](#)] 之后我使用的“代码”指的是代码和文档。

# 选择一个许可证 当选择为项目应用一个许可证时，如果可能，请尽量选择一个而不是建一个新的。选择已有的许可证有两个原因： - 熟悉度。如果你使用最流行的三，四个许可证之一，人们会感到在使用代码前不需要阅读这些法律条款，因为他们之前已经阅读过了。 - 质量。除非你有一个可以支配的律师团队，否则你很难得到一个法律坚实的许可证。这里说的许可证时大量思想和经验的产品；除非你的项目确实有不同寻常的需要，你不太可能做的更好。 关于应用这些许可证的某个到你的项目，见[Chapter 2, *起步*](# "Chapter 2. 起步")的[the section called “如何为你的软件应用许可证”](# "如何为你的软件应用许可证")。 ### MIT / X Window System License 如果你的目标是希望代码能被最大可能数量的开发者和衍生作品使用，而且你对这些代码用于私有程序不太在意，选择MIT / XWindow System许可证（这样命名是因为它是麻省理工学院发布的X Window System代码的许可证）。该许可证的基本信息是“你可以任意的自由使用这些代码。”它与GNU GPL兼容，而且简短、简单和易于理解： ~~~ Copyright（c） <年份> <版权所有者> 现授予的权限，免费向任何人索取该软件和相关的文档文件 （“软件”），以处理软件，没有任何限制，包括但不限 于使用权，复制，修改，合并，出版，发行，授权，和/或销 售软件的副本，并允许的人提供的软件是这样做，但须符合 下列条件： 上述版权声明和本许可声明中应包括所有副本或实质性部分 的软件。 该软件是“按原样”提供，不做任何保证，明示或暗示，包 括但不限于适销性，针对特定用途的适用性和非侵权的。在 任何情况下，作者或版权持有人对任何索赔，损害赔偿或其 他责任，无论是在一项行动的合同，侵权或其他因出于或有 关的软件或利用等交易必须软件。 ~~~ （取自[http://www.opensource.org/licenses/mit-license.php](http://www.opensource.org/licenses/mit-license.php)。） ### GNU General Public License 如果你不希望你的项目代码用于私有程序，或者如果你对代码是否用于私有程序毫无在意，请选择GNU GPL（[http://www.fsf.org/licensing/licenses/gpl.html](http://www.fsf.org/licensing/licenses/gpl.html)）。GPL可能当今世界上是最广泛使用的自由软件许可证；这种快速的识别性本身就是GPL的主要优点。 当编写代码库时，也就是说代码主要被用于其他程序，请考虑清楚GPL设置的这个限制是否与你的项目目标一致。在某些情况下—例如，当你试图取代另一个完成同样功能的竞争私有库时—如果以可以将其混入私有程序的许可证方式分发代码会有一些战略意义，即使你并不想这样做。自由软件基金会甚至为这种情况设计了一种替代GPL：*GNU Library GPL*，不久之后更名为*GNU LesserGPL*（大多数人一直使用首字母缩写*LGPL*）。LGPL比GPL有更宽松的限制，可以与其他非自由代码轻松的混合。然而，它也有一些复杂，需要花一些时间理解，所以如果你不会继续使用GPL，我建议你使用MIT/X样式的许可证。 ### GPL是自由还是不自由？ 选择GPL的一个后果就是会有—小的，但不是无限小—的可能卷入GPL是否为真正“自由”的争论中，考虑到它为你如何处置代码设置了一些限制—也就是代码不能以其他任何许可证分发。对于某些人，这些限制的含义是GPL比诸如MIT/X的宽松许可证有“较少的自由”。这种争论会一直在继续，当然，因为“更多的自由”比“较少的自由”更好（毕竟，谁不喜欢自由？），下面是这些比GPL更好的许可证。 这种争论是另一场圣战（见[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “避免圣战”](# "避免圣战")）。避免参与，至少不要在项目论坛。不要试图证明GPL更自由或是更不自由，或者比其他许可证更自由。相反，强调你的项目选择GPL的原因。如果许可证的可识别性是一个原因，说出来。如果是为了强制衍生作品的自由许可证，也说出来，但是拒绝陷入这是否会使代码更自由的讨论。自由是一个复杂的主题，如果术语继续用于作为事实的掩饰，这种讨论毫无意义。 因为这是一本书，而不是邮件列表讨论，然而，我必须承认我从没有理解“GPL是不自由的”论据。GPL设置的唯一限制是防止人们设置*进一步*限制。说这样不自由对我来说就像是在说失去法律保护的奴隶制减少了自由，因为它防止了某些人拥有奴隶。 （噢，如果你陷入了这样一场争论，不要使用激烈的类比来提升自己的证据。） ### 那BSD许可证呢？ 有大量开源软件使用*BSD许可证*（或者有时*BSD样式的许可证*）分发。原始的BSD许可证用于Berkeley软件分发版本，是加利福尼亚大学分发的Unix实现的重要部分。该许可证（完整的文本在[http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6](http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6)的2.2.2）与MIT/X许可证有相似的精神，除了这个条款： > *所有提及该软件特性或使用的宣传材料必须包含如下致谢：该产品包含加州大学Lawrence Berkeley实验室的软件。* 这个条款的出现不仅使得最初的BSD许可证不兼容，也设置了一个危险的先例：其他组织也在*他们的*自由软件中设置了类似的广告条款—用他们自己组织的名称代替“加州大学，Lawrence Berkeley实验室”—软件分发商面对了一个日益增长需要显示什么的负担。幸运的是，许多使用这种许可证的项目注意到了这个问题，并删除了这个广告条款。在1999年，甚至加州大学也放弃了这个条款。 结果是修订的BSD许可证，仅仅是删除广告条款的原始BSD许可证。然而，这个历史使得“BSD许可证”有一些暧昧：它指的是原始的还是修订的版本？这就是我倾向于MIT/X许可证的原因，本质上是相同的，但不会面对这种不明确。然而，也有一个选择修订的BSD许可证而不是MIT/X许可证的原因，也就是BSD有这个条款： > *在经过特定的预先书面许可之前，<组织>的名称和贡献者的名称都不可以用于支持或提升此软件衍生的产品。* 不清楚如果没有这个条款，软件的接受者是否拥有使用许可者的名称的权利，但这个条款清除了这个可能的疑问。对于担心商标控制的组织，修订的BSD许可证可能比MIT/X更好。大体来说，一个自由主义的版权许可证并没有暗含了接受者可以使用或削弱您的商标的权利—版权法和商标法是两个不同的东西。 如果你希望使用修订的BSD许可证，这里有一个模板[http://www.opensource.org/licenses/bsd-license.php](http://www.opensource.org/licenses/bsd-license.php)。

# GPL和许可证兼容性 私有不兼容与私有兼容许可证的最尖锐区别，也就是GNU GPL与其他许可证的区别。因为GPL作者的主要目标是提升自由软件，他们故意使它们的许可证不可能让GPL代码混入私有程序。具体说来，在GPL的要求中（见[http://www.fsf.org/licensing/licenses/gpl.html](http://www.fsf.org/licensing/licenses/gpl.html)的全文）有这样两点： 1. 所有衍生作品—也就是任何包含非琐碎量GPL代码的作品—也必须在GPL下分发。 1. 对于原始作品或衍生作品的分发没有其他附加的限制。（另一种表达是：“你不可以为接受者设置一些超过这里列出的进一步限制。 ”） 通过这些条件，GPL成功的让自由传播。一旦某个程序在GPL下设置版权，它的再次发布条款会像*病毒*—传播到与之组合的代码中，有效的使GPL化的代码无法用于闭源程序中。然而，同样的条款也使GPL与其他自由许可证无法兼容。一个常见的方式是其他许可证设置了一个需求—例如，需要以某种方式提及原始作者的荣誉条款—与GPL中“不得设置进一步的限制不兼容...”。从自由软件基金会的角度，这种二阶的后果是理想的，至少没有值得后悔的。GPL不仅仅保持你的软件的自由，也有效的推动*其他*软件强制自由。 这是否是提升自由软件地位的好方法这个问题是互联网上一场持久的圣战（见[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “避免圣战”](# "避免圣战")），我们不做深入分析。重要的是GPL兼容性是我们选择许可证时的一个重要问题。GPL是最流行的开源许可证；在[http://freshmeat.net/stats/#license](http://freshmeat.net/stats/#license)大约是68%的份额，而第二高的许可证则只有6%。如果你希望你的代码可以自由的与GPL的代码混合—这里有大量GPL的代码—然后你必须选择一种GPL兼容的许可证。大多数GPL兼容的开源许可证也是私有兼容：也就是说，在该许可证下的代码可以用于GPL程序，也可以用于私有程序。当然，混合的*结果*不会互相兼容，因为一种是GPL，另一种则是闭源作品。但是真正相关的是衍生的作品，而不是你一开始分发的代码。 幸运的是，自由软件基金会维护了一个与GPL兼容或不兼容的许可证列表，位于[http://www.gnu.org/licenses/license-list.html](http://www.gnu.org/licenses/license-list.html)。本章讨论的许可证都会展现在这个列表中，兼容的和不兼容的。

# 许可证的方面 尽管有许多不同的自由软件许可证，但在许多重要的方面所说的是同一件事：任何人可以修改代码，也就是任何人可以再次分发其原始和修改的形式，而版权所有者和作者不做任何保障（考虑到人们会在不知情的情况下运行修改的版本，免责非常重要）。不同许可证的区别经常出现在这些问题上： 私有许可证的兼容性 有一些自由许可证允许覆盖的代码用于私有软件。这不会影响私有程序的许可证条款：它还是私有软件，它仅仅是包含了一些非私有的源。Apache许可证、X Consortium许可证、BSD样式的许可证以及MIT样式的许可证都是私有兼容的许可证。 与其他自由许可证的兼容性 大多数自由许可证与其他兼容，意味着某个许可证下的代码可以与其他的代码合并，使用任意一种许可证分发也不会违反另外一种许可证的条款。主要的例外是GNU GPL，它要求使用GPL化的代码则必须按照GPL分发，并不得增加任何GPL所要求的更多限制。GPL只与某些自由许可证兼容。本章后面的[the section called “GPL和许可证兼容性”](# "GPL和许可证兼容性")将会详细讨论这些细节。 荣誉的强制性 一些自由许可证强制对于所覆盖代码的任意使用，必须伴随一个已指明了放置和显示方式的提示，给予代码的作者或版权拥有者荣誉。这些许可证仍然是私有兼容的：他们并不要求衍生的作品是自由的，仅仅要求给予自由代码一份荣誉。 商标保护 强制荣誉的一个变种。商标保护许可证指明在未经预先书面许可前，原始软件的名称（或者其版权所有者，或他们的机构等等）*不能*被用于衍生的作品中。尽管荣誉强制坚持使用特定的名字，而商标保护保证其不被使用，但他们只是相同目的不同表达方式：原始代码的名声必须保存和传递，但不要因为关联而玷污。 "艺术完整性"保护 有一些许可证（例如著名的Perl编程语言实现所使用的艺术许可证，以及Donald Knuth的TeX许可证）要求分发时必须明确区分代码的原始版本和所有的修改。他们与其他自由许可证在实质上允许同样的自由，但是提出了特定要求，可以轻松的确认原始代码的完整。除了制作这些许可证的特定程序，并没有太多这类许可证的使用，所以将不会在本章讨论；它们的出现仅出于完全性的考虑。 大多数这类强制不是互斥的，某些许可证会包含多个。他们之间相同的线索是在接受者那里设置要求，交换接受者使用和/或发布代码的权利。例如，一些项目希望他们的名称和名声能够随着代码传播，并且也值得放置额外的荣誉或商标条款；取决于其难度，这种负担会导致某些用户选择较少要求的包。

# 术语 在开源许可证的任何讨论中，最明显的是首先要看到有许多不同的单词指的是同一件事：*自由软件*、*开源*、*FOSS*、*F/OSS*和*FLOSS*。首先从列出这些开始，然后引出一些其他的术语。 *自由软件* 可以自由分享和修改的软件，包含源代码格式。该术语首先由Richard Stallman创造，他在GNUGeneral Public License (GPL)中编写了这个词，并创建了自由软件基金会（[http://www.fsf.org/](http://www.fsf.org/)）来发扬这个概念。 尽管“自由软件”几乎覆盖了几乎“开源”软件的同一个范围，FSF还是倾向于前一个术语，因为它强调了自由的理念，自由分发软件的概念主要是一种社会的而不是技术的运动。FSF承认这个术语的不明确性—它可以是“0费用”的“free”，而不是“自由”的“free”—但还是认为这是最好的术语，其他可能性在英语中还是有自己的混淆。（在本书中，“free”取“自由”之意，而非“0费用”之意。） *开源软件* 自由软件的另一个名字。但是不同的名字反映了重要的哲学差异：开源促进会（Open Source Initiative [http://www.opensource.org/](http://www.opensource.org/)）创造了“开源软件”一词，作为“自由软件”的可替换词，他们试图通过以开发方法学而不是政治运动的方式进行展示，努力使此类软件成为公司更可口的选择。他们也期望消除另一个污点：任何“免费的”一定是低质量的。 所有的许可证是自由的则也是开源的，反之亦然（除了少许的例外），人们倾向于选择一个并保持不变。概括说来，喜欢“自由软件”的更有可能喜欢在这个问题上保持一个哲学或道德姿态，而喜欢“开源”的则或许是不认为自由十分重要，亦或者不希望极力宣扬他们所做的。关于这次分裂的历史请看[Chapter 1, *介绍*](# "Chapter 1. 介绍")的[the section called ““自由”还是“开源””](# "“自由”还是“开源”")。 对于这两个术语，自由软件基金会有一个非凡的—完全不可反对的，但是微妙而公平的—解释，位于[http://www.fsf.org/licensing/essays/free-software-for-freedom.html](http://www.fsf.org/licensing/essays/free-software-for-freedom.html)。开源软件研究院通过这两个页面传播：[http://www.opensource.org/advocacy/case_for_hackers.php#marketing](http://www.opensource.org/advocacy/case_for_hackers.php#marketing)和[http://www.opensource.org/advocacy/free-notfree.php](http://www.opensource.org/advocacy/free-notfree.php)。 *FOSS*, *F/OSS*, *FLOSS* 开始是两件事，不久后就变成三件，这确实是自由软件中术语所发生的事情。学术世界或许更希望精确和内涵，而不是优雅，所以设置FOSS或有时F/OSS来代表“Free / Open Source Software”。另一个变种是FLOSS，代表了“Free / Libre Open Source Software”（*libre*在许多语言中也是被人所熟悉的，并且没有“free”的模糊含义；更多信息请见[http://en.wikipedia.org/wiki/FLOSS](http://en.wikipedia.org/wiki/FLOSS)）。 所有这些术语实质上是同一件事：任何人可以修改并分发的软件，有时—并不一直是—要求衍生的作品必须按照同样的条款自由的分发。 *DFSG-符合* 符合Debian自由软件方针（[http://www.debian.org/social_contract#guidelines](http://www.debian.org/social_contract#guidelines)）。这是一个许可证是否为真的开源软件（free、*libre*等等）的广泛使用的测试。Debian项目的目标是维护整个自由软件操作系统，这样人们安装之后就无需担心自己是否有权限修改和分发系统的任意部分。Debian自由软件方针是软件包许可证进入Debian所必需达到的要求。因为Debian项目花费了大量时间考虑如何构建这样一个测试，所以得出的方针被证明是非常健壮（[http://en.wikipedia.org/wiki/DFSG](http://en.wikipedia.org/wiki/DFSG)）的，并且至少以我看来，无论是自由软件基金会还是开源研究院都没有提出严重的反对。如果你知道一个许可证是DFSG-符合的，你就知道它保证了支持开源项目动态性的重要自由行（例如甚至违背最初作者意愿的可分叉性）。本章讨论的许可证都是DFSG-符合的。 *OSI-确认* 经由开源研究院确认。这是另外一个广泛采用的确定许可证是否执行所有必要自由的测试。OSI对开源软件的定义基于Debian自由软件方针，只要符合其中一个定义就几乎可以符合另一个定义。这几年有了一些例外，但是只包括niche licenses，与这里毫无关系。不像Debian项目，OSI维护了一个所有已经经过确认的许可证列表，位于[http://www.opensource.org/licenses/](http://www.opensource.org/licenses/)，所以被“OSI-确认”是一个毫不含糊的状态：许可证是否在这个列表中。 自由软件基金会在[http://www.fsf.org/licensing/licenses/license-list.html](http://www.fsf.org/licensing/licenses/license-list.html)维护了一个许可证的列表。FSF不仅仅根据是否自由来分类许可证，而是根据其是否与GNU的GPL兼容分类。GPL兼容是一个重要的主题，将会在本章后面的[the section called “GPL和许可证兼容性”](# "GPL和许可证兼容性")介绍。 *私有*, *闭源* “自由”或“开源”的对立面。这意味着软件按照传统的、基于授权的许可条款分发，用户需要为每一份拷贝支付，亦或者按照其他足够限制开源动态性操作的条款分发。即使软件可以不支付的情况下分发也可以是私有软件，只要它的许可证禁止自由分发和修改。 通常来说“私有”和“闭源”是同义词。然而“闭源”有甚至看不到源代码的附加含义。因为大多数私有软件看不到源代码，所以这经常是一个没有差别的区别。然而，偶然情况下，有一些人会使用允许其他人查看代码的许可证发布私有软件。令人混淆的是，他们有时称之为“开源”或“近似开源”等等，但确实是误导。源代码的*可见性*确实不是问题所在；重要的问题是你能对此做什么。因而，私有和闭源的区别几乎毫不相关，二者可以被当作同义词。 有时会使用*商业*作为“私有”的同义词，但是严格说来，二者并不是一回事。自由软件也可以是商业软件。毕竟，自由软件可以出售，只要购买者没有被限制为禁止放出他们自己的拷贝。在其他方面也可以是商业的，例如出售支持、服务和认证。现在有许多数百万美元的公司是建立在自由软件之上的，所有没有什么固有的反商业和反公司。另一方面，*其*反私有则是本性，这是其区别与传统每拷贝许可证模型的关键方式。 *公共域* 没有版权所有者，也就是说没有人拥有可以限制复制这些作品的权利。进入公共域中与没有作者并不相同。任何事物都有一个作者，即使某个作品的作者选择将作品放到公共域，这改变不了他们编写的事实。 当一个作品进入公共域，由其组成的材料可以变成有版权的作品，之后该材料的*拷贝*与整个作品处于同一个版权下。但是这不会影响原始作品的存在性，它还是会保存在公共域。因而，在公共域发布一些东西从技术讲就是根据大多数自由软件认证组织的方针，使之“自由”。然而，通常有许多原因促使我们使用一些许可证，而不仅仅是简单的发布到公共域：即使对于自由软件，特定的限制也是非常有用的，这不仅仅是对于版权的所有者，也是对其他接受者，下个小节会澄清这个问题。 *copyleft* 使用版权法取得反对传统版权的结果的许可证。取决于你所问的人，这个许可证可能是允许这里讨论的自由，也可能是更窄一些，并非允许这些自由，而是通过契约保证必须在作品中履行自由，*强制*它们的许可证。自由软件基金会排他的使用第二种定义；其他情况下则只是匆忙上马：许多人像FSF一样使用这个术语，但是其他人—包括那些为主流媒体写作的人—倾向于第一种定义。不太清楚使用这个术语的人是否意识到了需要做一些区分。 一个本地的例子更加狭窄，一个更严格的定义是GNU GPL，强制所有衍生的作品也必须使用GPL许可证；更多信息请见本章后面的[the section called “GPL和许可证兼容性”](# "GPL和许可证兼容性")。

# Chapter 9. 许可证，版权和专利 只要是开源许可证，你选择的许可证可能不会是影响采用项目的主要因素。用户通常根据质量和特性选择软件，而不是许可证的细节。虽然如此，你还是需要对自由软件许可问题有基本的了解，一方面确保项目的许可证与其目标一致，另一方面可以与其他人讨论许可证决策。请注意，我不是律师，本章的内容不应当作为正式的法律建议。对于法律事务，你需要雇佣一个律师或自己是律师。

# 分叉 在[Chapter 4, *社会和政治的基础架构*](# "Chapter 4. 社会和政治的基础架构")的[the section called “分叉能力（forkability）”](# "分叉能力（forkability）")，我们说了*潜在的*分叉能力对于项目管理的重要影响。但是当分叉确实发生时，我们应该怎么做？你应该如何处理，会发生怎样的情况？与之对应，何时你应当*开始*一个分叉。 答案取决于你选择的分叉类型。有一些分叉源于对于项目方向的友善但不可调和的异议；也有一些由于技术分歧和个人冲突。当然，很难说清楚二者之间的区别，因为技术争论也会包含个人元素。所有分叉的共同之处是有一队开发者（有时仅仅是一个开发者）认为与某些人或所有其他人一起工作的成本已经大于收益。 一旦项目分叉，对于分叉与“原”项目谁是谁非，没有明确的答案。人们会通俗的说分叉F来自于项目P，好像P继续沿着自然路径保持不变，而F则进入新的领域，但这实际上是一个观察者的声明。但这纯属个人感觉：当足够高百分比的观察者认可，这个断言便成为真。并不是说一开始就有一个客观事实，而只是一开始的一个不太完美的感觉。此外，感觉*是*客观事实，因为最终一个项目—或一个分叉—仅仅是存在于人们思想中的一个实体。 如果开始分叉的人们感觉自己是在建立主项目的一个分支，则感知问题可以立刻轻易的解决。每个人，开发者和用户会将分叉视为新的项目，有新的名称（或许基于旧有的名称，但容易与之区分），一个单独的网页以及单独的哲学或目标。当双方都认为自己是原项目遗产的守卫者，理所当然继续使用原来的名称时，事情会变的复杂。如果某个组织拥有这个名称的商标权，或对于域名或网页有法律控制，通常可以平滑的解决这个问题：这个组织可以决定谁是这个项目，谁是分叉，因为它拥有公共关系战争中的所有卡片。很自然，一般不会如此过分：因为每个人都知道权利动力学，他们会避免一场结局已定的战斗，会直接跳到结局。 幸运的是，大多数情况下可以轻松的区分哪个是项目，哪个是分叉，因为分叉从本质上是一个自信的投票。如果过半的开发者倾向于采纳分叉的过程，通常意味着没有必要分叉—这个项目可以自己走这条路，除非它有一个顽固的独裁者，按照独裁方式运行。另一方面，如果支持者少于一半，则分叉则明显是少数派的反叛，根据礼貌和常识，它应当认为自己是分叉，而不是主线。 ### 处理分叉 如果某人在项目中威胁进行分叉，请保持冷静并牢记你的长期目标。分叉的*存在*不是对项目的伤害，而是开发者和用户的损失。你真正的目标，不是为了镇压分叉，而是最小化其损害。也许你会生气，你或许感到分叉是不公正和不请自来的，但如果这样公开表示则是对未决定用户的疏远。相反，不要强制人们做出唯一的选择，要与分叉实行可行的合作。首先，不要因为某人决定在分叉上工作，而删除其在你的项目中的提交权限。在分叉上工作并不意味着他立刻失去了在原项目工作的资格；之前的提交者之后还是提交者。此外，你应当展示与分叉保持兼容的愿望，并表达你希望开发者能够在二者之间搬运合适的变更。如果你对项目服务器有管理权限，一开始就公开提供分叉的基础架构帮助。例如，如果他们无法通过其他方法获得，可以为他们提供一个完整的，版本控制库的深度历史副本，这样他们就不必以无历史数据作为开始（必要性取决于版本控制系统）。询问他们是否有其他的需要，并尽你所能提供。这种支持表明了你不会阻挠他们，而且希望该分叉以自己价值成功或者失败，仅此而已。 这样做—以及公开这样做的—原因实际上并不会帮助分叉，但是通过尽可能的展示非报复心态，会使开发者相信你这边是安全带。战争中有时强制人们选择一边非常有意义（战略意义，而不是人的感觉），但是自由软件几乎从不这样做。实际上，分叉后一些开发者会公开的在两个项目同时工作，并尽可能保持二者兼容。这些开发者保持了分叉之后的交流。他们允许您的项目从分叉中有趣的新特征中获益（是的，分支也有你想要的），另外也会增长在未来合并的可能。 有时，某个分支变得异常成功，即使他最初的煽动者也认为他们开始于一次分叉，但成为人人都喜欢的版本，最终由于其流行性取代了最初的版本。一个著名的实例是GCC/EGCS分叉，*GNU Compiler Collection*（*GCC*，以前称为*GNU CCompiler*）是最著名的开源本代码编译器，也是世界上最便于移植的编译器。源于对GCC官方维护者和Cygnus软件的分歧。[[29](#)]GCC的一个最活跃的开发团队，Cygnus创建了一个GCC的分叉，称为*EGCS*。该分叉谨慎保持非敌对位置：从任何角度看，EGCS开发者从没有试图把他们版本的GCC描绘成新的官方版本。相反，他们集中精力使EGCS尽可能的好，比官方的GCC维护者以更快的频率整合补丁。EGCS受到了欢迎，最终一些主流的操作系统发布商决定将EGCS而不是GCC作为打包产品的默认编译器。此刻，对于GCC的维护者很清楚，坚持“GCC”的名称，而让所有人切换到EGCS分叉上需要每个人承受毫无必要的名称修改负担，对防止切换毫无意义。所以GCC采用了EGCS的代码基，再一次只有一个GCC，但因为分叉获得了极大的改进。 这个例子向我们展示了为什么不能单纯的将分叉视为一件坏事。分叉时可能充满痛苦和不受欢迎，但你不能必然知道它是否会成功。因而，你和项目的余下部分要一直留意它，不仅仅要准备好吸收可能的特性和代码，在极端情况下，如果分叉获得了项目的精神占有率，甚至需要加入分叉。当然，通过观察谁加入了分叉你也能预测到其成功的可能性。如果分叉由项目最大的抱怨者开启，并有少数不满的看起来起不到建设作用的开发者加入，他们将无法通过分叉解决问题，你也无须担心分叉会将原项目的动力带走。但是如果你看到有影响和令人尊敬的开发者支持这个分叉，你必须问自己这是为什么。或许整个项目被限制了，最好的方案是在主线项目采纳一些分叉打算的行动—从本质上，通过变成它而避免分叉。 ### 初始一个分叉 这里的所有建议假设你将分叉作为最后的依靠。初始分叉前耗尽了所有的可能性。分叉总是意味着丢失开发者，只留下一个不确定的在以后获得新产品的承诺。它也意味着开始了对用户注意力的竞赛：每个下载这个软件的人都会问自己：“哦，这个还是那个？ ” 无论你是哪个，情况也是肮脏的，因为出现了原本不存在的问题。一些维护分叉的人们会维护软件的整体生态系统的健康，通过标准的自然选择论点：适者生存，意味着最终每个人得到更好的软件。从生态学的角度这或许是正确的，但对于单个项目来说则并不正确。大多数分叉并不成功，大多数项目不喜欢被分叉。 一个推论就是不要使用分叉的威胁作为极端的辩论技巧—“按照我的方式，否则我要将项目分叉！ ”—因为每个人都会意识到如果是无法吸引开发者离开原项目的分叉，不太可能长久存活。所有的观察者—不仅是开发者，还有用户和操作系统打包者—会对选择哪一方做出自己的判断。你不必表现出极端不情愿分叉，这样如果你最终这样做了，你可以光荣的宣布这是最后一条路。 在评估你的分叉成功可能性时，不要忽视*所有的*因素。例如，如果项目的许多开发者都有同一个雇主，那么即使他们不满且私下里倾向于分叉，也不太会大声说出他们的雇主是赞成还是反对。许多自由软件程序员以为如果代码有自由许可证，那么没有哪个公司可以控制开发。许可证确实如此，是一种终极意识，自由的保障—如果其他人强烈的希望分叉项目，并有足够的资源，它可以这样做。但是在实践中，一些项目开发团队大多由一个实体资助，没有证据说明这些实体的支持无关紧要。如果他们反对分叉，他们的开发者不会离开，即使私下里希望如此。 如果你还是确认必须分叉，最好首先私下联络好支持，然后使用不含敌意的语调宣布分叉。即使你对当前的维护者感到愤怒，或者失望，不要在这些信息中写出来。只需要不露声色的陈述导致你决定分叉的动机，以及你对所分叉原项目并无敌意。假定你考虑一次分叉（相对于对原项目的紧急保存），强调你分叉的是代码而不是名称，并选择一个与原项目不会冲突的名称。你可以使用一个包含或引用原名称的名称，只要不会造成识别上的混淆。当然，在分叉的主页上也可以突出解释其来自的原始程序，甚至对于替代它的期望。但是不要迫使用户解开识别争议，给他们带来额外的麻烦。 最终，通过为原项目的所有提交者，包括那些公开反对分叉的提交者赋予提交权限，就可以自动让事情开始运转。即使他们不会访问，但你的信息是明确的：这里存在争议，但是没有敌人，你欢迎来自所有竞争源的代码贡献。 [[29](#)] 现在是RedHat（[http://www.redhat.com/](http://www.redhat.com/)）的一部分。

# 荣誉 荣誉是自由软件世界的主要货币。无论人们怎样说他参与项目的动机，我不知道有哪个开发者会乐于匿名，或以其他人的名义的做这些事。有一些有形的原因：一个人在一个项目的名声大体上决定了他的影响力，参与一个开源项目也会间接的带来金钱，因为某些雇主希望寻找简历。也有一些无形的原因，或许更加强大：人们只希望被赏识，本能的寻找被别人识别的标志。荣誉的希望是项目一个最重要的动机。当小的贡献被认可，人们会返回作出更多。 协作开发软件的一项重要特性是（见[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")）保持何人何时做了何事的精确记录。如果存在，请尽可能使用现有的机制确保荣誉精确的分配，要根据贡献的本性特别处理。不要仅仅写下"感谢J. Random <jrandom@example.com>"，作为替代可以在日志信息中写为"感谢J. Random jrandom@example.com>的bug报告以及对于重现bug的描述"。 在Subversion中，对于bug报告者的荣誉，我们有一个非正式的但是一致的政策，如果有发起的问题，则在问题中记录，如果没有发起问题，则在修正该bug的提交日志信息中记录。对于提交编号14525之前的Subversion日志进行了一个快速调查，发现10%的提交包含了某人名字和邮件地址的荣誉信息，通常是报告或分析该提交的bug修正的人。请注意，这些人与实际作出提交的开发者不同，这些开发者的名字已经自动记录到了版本控制系统。在目前Subversion的80位完全和部分提交者中，有55位在他们成为提交者之前，曾经在提交日志（通常多次）中被记录过荣誉。当然这并不是说，被记录荣誉是继续参与的一个因素，但至少给了人们知道自己的贡献如何被认可的氛围。 很重要的一点是区分常规的感谢和特别感谢。当讨论特定代码片段或其它某人的贡献时，最好能够感谢他们的工作。例如，假设“Daniel最近对于增量代码的变更意味着我们现在可以实现特性X”，需要同时帮助人们识别你所谈论的变更并感谢Daniel的工作。另一方面，仅仅单独感谢Daniel对于增量代码的变更无法达到即刻的实践目的。它不会增加任何信息，因为版本控制系统和其他机制已经记录了他所做的变更。感谢所有人的所有工作则会分散最终的信息，因为感谢的内容是他与所有默认的、背景的评论级别相比的突出程度。当然这并不意味着你不需要感谢大家。只需要确保不会陷入荣誉通货膨胀。遵循下面的指导会有所帮助： - 这个论坛越是短暂，越应该对在这里自由表达感谢感到自由。例如， 在IRC对话中感谢某人传来的bug修正很好，在邮件中旁敲侧隐也很不错。但是最好不要单独发一个感谢某人的邮件，除非是真的不同寻常的壮举。很有可能，不要因为表达感激弄乱项目的网页。一旦你开始这样做，便会永远无法清理，也无法停止。而且*绝不要*将感谢置于代码的注释之中；这将会分散注释主要目的的注意力，注释本来的作用是帮助读者理解代码。 - 一个人参与项目越少，就更应该对她的所作所为提出感谢。这似乎与直觉并不一致，但是表示感谢的态度适用与某人作出的贡献，超出了你对他的预期。因此，一直感谢常规贡献者的日常工作表现了对他们所做工作的较低的预期。如果说有效果，可能是反效果！ 这个规则有一些偶尔的例外。如果感谢某人完成了预期角色，而这个角色反复包含了许多临时的、紧张的努力，则这是可以接受的。一个标准的例子是发布管理员，他在每次发布时都会投入紧张的工作，但其他时间则陷入休眠（作为发布管理员休眠，在有些情况下—它还可以是活跃的开发者，但那是另外一回事了）。 - 就像批评和荣誉，感谢必须是特定的。不要因为伟大而感谢，即使确实如此。要为他们所做的超出寻常的事情表示感谢，如果能恰当的说出他们的伟大之处也能额外加分。 通常情况下，在确保某个人的贡献已经被识别出来，和确保整个项目是一个团队，而不是一些荣耀的个体时，总会有些紧张。只要意识到这种紧张，并且强调表现团队，以及未能掌握的事物。

# 提交者 作为所有开源项目中唯一正式的明确阶层，需要对提交者格外关注。提交者是系统中不可避免的对鉴别的让步，而其他角色则是尽可能的非鉴别。但是“鉴别”这里绝无轻视的含义。提交者发挥的功能是绝不可少的，我不相信一个项目会在没有这个角色的情况下取得成功。我们需要质量控制，是的，控制。总会有许多人觉得自己具备对某个程序修改的能力，但实际上只有少数人确实具备。项目不能依赖人们自己的判断，必须设置标准并为达到标准的人赋予提交权限[[28](#)]。 另一方面，要让可以直接提交变更的人与不能设置明显权利变化的人一起工作。这种变化必须是受管理的，这样才不会损害项目。 在[Chapter 4, *社会和政治的基础架构*](# "Chapter 4. 社会和政治的基础架构")的[the section called “谁进行表决？”](# "谁进行表决？")，我们已经讨论考虑过新提交者的机制。这里我们会讨论潜在的新志愿者必须被判断的标准，以及在一个大的社区中如何展示这个过程。 ### 选择提交者 在Subversion项目，我们主要根据希波克拉底原理选择提交者：*首先，不要伤害*。我们的主要标准不是技术技巧或对代码的认识，仅仅是提交者展示出好的判断。判断仅意味着知道不要做什么。一个人可以只发布小的补丁，修正代码中的小问题；但只要这个补丁能够干净的应用，不会带来新的bug，能够最大程度的符合项目的日志信息和代码习惯，而且有足够多的补丁可以展示明显的模式，则现有的提交者通常会提议为该人赋予提交权限。如果至少三个人赞成，且没有人反对，则提议通过。诚然，也许我们没有证据证明这个人有能力解决代码基所有部分的复杂问题，但这并不重要：他所做的已经证明他至少能对自己的能力有正确的判断。技术技巧可以习得（和讲授），但无法获得最重要的判断。然而，在赋予一个人提交权限之前，这是你需要确保某人所具备的能力。 当一个新的提交者提议引起了讨论，通常不会是关于技术能力，而是关于该人在邮件列表或IRC中的行为方式。有时，某人展示了技术能力和按照项目正式方针工作的能力，以及在公共论坛中一致的好战或不合作性。这需要认真的关注；如果即使经过了回复的提示，这个人也一直未能改变，我们不会将其添加为提交者，无论其技巧怎样高。在一个志愿者团队中，社会技巧，或者说在“沙盒中玩耍的”能力，与原始的技术能力同样重要。因为任何东西都会进入版本控制，添加一个不该添加的提交者不会在代码层面带来太多的问题（评审可以迅速定位这些问题），但那样会导致最终强制项目收回该人的提交权限—这绝不是一项让人愉快的行为，有时会让人失望。 许多项目坚持潜在的提交者展示了特定级别的技术专业技能和持久性，通过提交一定数量的非琐碎补丁—也就是项目不仅仅希望知道他不会伤害项目，而且希望知道他会使项目在代码基上获益。这样很好，但是要小心，不要将提交权变为一个排他俱乐部的身份。每个人的脑子中都应该有一个问题：“怎样做才会为代码带来最好的结果？”而不是“认可这个人是否会降低提交权关联的社会状态的价值？”如果您有100个提交者，10个进行常规的较大的变更，而其他90个则仅仅是每年修正几个拼写和小的bug，依然比只有10个提交者更好。 ### 收回提交权限 关于收回提交权限首先要做到：尝试不要一开始就进入这种情况。取决于谁的权限将会被收回，以及收回的原因，相关的讨论将会显著不同。即使没有不同，这也将会是有效率工作的一项费时的分心的工作。 然而，如果您必须如此，一定要确保讨论必须处于将会为该人*赋予*权限进行投票的人之间，无论他们拥有怎样的投票风味。一定不要包含本人。这似乎否定了针对保密性的禁令，但在这种情况下这是必要的。首先，没有人能够以别的方式自由言论。其次，如果行动失败，你不会希望让此人知道这被考虑过，因为这会带来一些问题（“谁站在我这边？ 谁反对我？”），会导致最坏类型的党派主义。在一些罕见的情形下，团队会希望某人知道收回提交权限的过程正在进行中，作为警告提示，但一定要确保这种公开是团队决策的结果。任何人不应当擅自行动，将别人认为是秘密的讨论信息和表决透漏出去。 一旦收回了某人的权限，结果必然要公开（见本章后面的[the section called “避免神秘”](# "避免神秘")），你需要尝试尽可能谨慎的公布于众。 ### 部分提交权限 有些项目提供细粒度的提交权限。例如，有些贡献者的提交权限限于文档，而不能是代码。常见的部分提交权限包括文档、翻译、其他语言的绑定代码，打包的特定文件（例如RedHat RPM规范文件等等），以及其他即使发生错误也不会导致核心项目问题的地方。 因为提交权限不仅仅关于提交，而且事关选举资格（见[Chapter 4, *社会和政治的基础架构*](# "Chapter 4. 社会和政治的基础架构")的[the section called “谁进行表决？”](# "谁进行表决？")），自然回带来另一个问题：部分提交者能够为何投票？没有一个正确的答案；这取决于你的项目有何种部分提交领域。在Subversion中，我们尽可能让事情简单：一个部分提交者只可以参加提交者领域的部分投票，其他地方则不行。更重要的，我们有一个可以覆盖建议投票的机制（其实质在于，表决时提交者可以写"+0"或"+1 （非绑定）"，而不仅仅是"+1"）。...................... 完全提交者可以为任何事情投票，就像他们可以任意提交一样，只有完全提交者可以为添加所有类型的提交者投票。在实践中，通常这种添加新部分提交者的能力通常会被代理：任意完全提交者可以“发起”一个新的部分提交者，而且某个领域的部分提交者通常会为同一领域选择新的提交者（这在保证翻译工作正常运行时特别有益）。 你的项目可能有些许不同的安排，这取决于你所作工作的特性，但相同的原理适用于所有的项目。每个提交者必须能为她提交权限相关的事物进行投票，不相关的则不能，而且程序上的问题默认由完全提交者表决，除非有原因（要由完全提交者决定）来扩大投票范围。 关于部分提交权限的强制性：最好*不要*让版本控制系统约束提交领域，即使技术上可行。原因请见[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")的[the section called “授权”](# "授权")。 ### 休眠提交者 一些项目会在提交者在一定时间（例如一年）内未能提交任何东西时，自动删除其提交权限。我认为这样没有太大帮助，甚至有不良的后果，有以下两个原因。 首先，这会诱使人们提交可接受但不必要的变更，仅仅为了保住将要过期的提交权限。其次，这样没有意义。如果赋予提交权限的主要标准是判断力，为何仅仅因为他离开了项目就认为其判断力的下降？即使他完全的消失了几年，没有看任何代码或跟踪开发讨论，但当他重新出现时，他会*知道*他已经多久未从联系，并以此行动。你原来相信他的判断，为何不永远相信他？如果高校的文凭不会过期，那么提交权限也不应该。 有时，一个提交者会要求将其删除，或在提交者列表中明确的标记为休眠状态（关于该列表的更多信息见后面的[the section called “避免神秘”](# "避免神秘")）。在这种情况下，项目当然必须答应个人的意愿。 ### 避免神秘 尽管围绕添加特定新提交者的讨论必须保持机密，其规则和步骤本身不应该保密。实际上，最好公开，这样人们可以意识到提交者并不是什么神秘的秘密法庭，也不是凡人免进，而是任何人可以参与，仅需要发布一些好的补丁，并指导如何在社区中交流。在Subversion项目中，我们将信息放在开发指南文档中，因为那些希望为项目贡献代码的人们对如何赋予提交权限最有兴趣。 除了发布步骤，也要发布提交者*列表*。该文件的传统位置是项目代码树顶级目录中叫做`MAINTAINERS`或`COMMITTERS`的文件。它首先必须列出所有的提交者，紧跟是多个部分提交域以及其中的提交者。要列出每个人的名字，如果该人愿意，也包括邮件地址，地址可以为防止垃圾邮件进行编码（见[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")的[the section called “归档中的地址隐藏”](# "归档中的地址隐藏")）。 因为完全提交者和部分提交者访问权限有着明显的区别，也做出了明确的定义，所以这个列表也应该列出这种区别。除此以外，该列表不应当试图表明项目中不可避免会出现的非正式的区别，例如谁更具影响力。它是公共记录，不是致谢文件。请使用字母顺序或其出现顺序列出提交者。 [[28](#)] 请注意，在非集中式的版本控制系统中，提交权限的含义有些区别，在非集中式系统中，任何人可以建立与项目关联的版本库，并为自己设置到该库的访问权限。然而，提交权限的*概念*依然适用：“提交权限”是“改变软件下一次发布中输送代码的权利”的缩写。在集中式版本控制系统中，这意味着直接的提交权限；在非集中式系统中，这表示了将某人的变更默认拖入主发布。其实是相同的含义；其实现的机制并不重要。

# 转化 一次又一次，某个位置上承担责任的志愿者（例如补丁管理员，翻译管理员等）无法执行该位置的责任。这可能是因为出现了超出他预期的工作，或者完全因为是许多外部因素：结婚、孩子出世、新的老板等等之类的。 当一个志愿者陷入这种境地，他通常不会立刻注意到。可能以很小的程度发生着变化，而且没有一个时刻可以自觉的认识到他已经无法完成这个角色的任务。相反，项目中的其他部分只是发现有一段时间未能听到他的消息了。然后他们会会立刻匆忙行动，而他则觉得长时间对项目的怠慢是有愧的，并立刻连夜赶工。然后就有更长的一段时间你无法听到他的消息，然后可能是或可能不是另一场慌乱。但是，很少有主动提出的正式辞职。志愿者用自己的业余时间工作，辞职意味着公开承认他的业余时间被永久的减少了。人们通常不愿意这样做。 因而，需要你和项目中的其他人发现发生的事情—或者说发现没有发生—，并能够询问哪个志愿者可以继续。这种询问必须是友好和100%无内疚的。你的目的只是找出真相，而不是让人难过。通常情况下，这个询问应当对项目的其他人可见，但是如果你知道一些必须私下进行的原因，也没有问题。公开进行的主要原因是如果志愿者回复说无法完成工作时，就可以为你的*下一次*公开发布提供一个上下文环境：请求一个新的志愿者完成该角色。 有时，一个志愿者无法完成其接受的工作，但是没有意识到或不希望承认这个事实。当然，任何人在一开始都会遇到困难，特别是当责任很复杂时。然而，如果某人不努力完成他接受的任务，即使所有人都给出全部的帮助和建议，最后唯一的解决方法只能是他放弃并让其他人来尝试。而且如果这个人没能看到这一点，需要有人告诉他。基本上来讲，我认为只有一种处理方法，但是需要一个多步骤的过程，每个步骤都很重要。 首先，确保你自己没有发疯。在私下与项目的其他人讨论，看看他们是不是和你一样认为问题很严重。即使你们已经肯定，这样也实现了让其他人知晓你们正考虑让这个人退出的目的。通常不会有人反对—他们会很高兴你肩负这个尴尬的任务，这样他们就不必动手了！ 下一步，*私下*联系有问题的志愿者并友好和直接的告知他，你所发现的问题。为了效果，要尽可能提供多的实例。确保能够指出人们是如何不愿继续帮助的，而问题一直存在得不到改善。请确保花较长的时间编写该邮件，对于此类邮件，如果你无法支持你所说的，最好就什么都不要说。要说明你会找一个新的志愿者充当这个角色，但也要指出有许多方法可以支持这个项目。在这个阶段，不要说你已经为此与其他人进行了谈话；没有人希望被告知有人在准备接替他。 之后，可以有许多其他不同的方法。最可能的反应是他们可能会认可你，或者在某种程度上会争论，并愿意退出。如果是这个情况，建议他自己作出声明，然后你可以跟从他的文章寻找一个替代者。 或者，他可能认可自己的问题，但是请求多一点的时间（或者再多一次机会，例如离散任务角色的发布管理员）。如何响应这个情况需要您的判断，但是无论您如何做，不要仅仅因为感到无法拒绝这种请求而表示同意。这样会延续痛苦，但不会有所减轻。这通常是拒绝这种请求的好原因，换句话说就是已经给了足够多的机会，而现在就是得到的结果。这是我告知某人无法肩负发布管理员角色的邮件： ~~~ >如果您希望别人替代我，我会有好的将这个角色交给下个人。我有个 >不情之请。我希望再尝试一次发布来证明我。 > 我完全能够体会您的想法，但是在这种情况下 ，我们无法“再试一次”。 这不是第一次或第二次发布，而是第6或第7次... 我知道你也对结果 不够满意（因为我们之前已经讨论过）。所以我们已经有效的完成了 再次尝试的程序。最终，总有一次是最后一次... 我认为[上一次发布]就是 了。 ~~~ 在最坏的情况下，志愿者可能完全不同意。然后你需要接受事情变得尴尬并预先准备。现在是与其他人讨论此事了（但在得到他们的允许前，还是不能说是谁，因为这些对话是机密的）的时候了，也是你认为项目不应该这样继续下去的时候了。坚持，但不要威胁。请注意，大多数角色的转换可能始于某个新人已经开始了它的工作，而*不是*老人结束了他的工作。例如，如果争论事关角色，譬如说问题管理员，在任何时刻你和其他有影响的人可以请求一个新的问题管理员。可以不必是之前做这些事的人停止了工作，只要他没有妨害（故意或其他原因）新志愿者的努力。 有一个充满诱惑力的想法：为何不去尝试不必告知人们辞职，而仅仅是为他寻找一些帮助？为什么不可以有两个问题管理员、补丁管理员或任何角色？ 尽管理论上听起来很不错，但通常不是一个好方法。是什么让管理员角色可以工作—是什么使之发挥作用，实际上—应该是非集中化。能够以非集中式完成的工作通常已经这样做了。有两个人肩负管理员角色会带来两个人的交流负担，也可能会带来不可靠的互相依赖（“我以为你带了急救箱！” “我？我以为*你*带了急救箱”）。当然，也有例外。有时两个人可以配合的极好，或者任务本身就可以轻松的分散给多个人。但当你见到某人挣扎于某个他不适合的角色时，通常并不会起太大作用。如果他一开始就能够重视这些问题，之前就会寻求此类帮助。在任何情况下，让一个人持续做一件不会让人关注的事情都是失礼的。 让某个人隐退的重要因素是隐私：给他空间作出决定，而不要让他感觉大家都在关注和等待。我曾经犯过这种错误—非常明显的错误，回想起来—也就是同时向所有的三方当事人发送邮件，征求Subversion发布管理员，接替另外两个志愿者。我已经与两个人私下有所交流，也知道他们希望肩负这个责任。所以我认为，有些天真有些迟钝，通过向他们同时发送邮件开始了转换过程，省去了时间和争辩。我设想现在的发布管理员已经完全意识到了问题，也会立刻理解我的用意。 我错了。当前的发布管理员被冒犯了，完完全全的冒犯了。被人要求交出工作是一回事，而在*大庭广众*之下被要求交出工作则是另外一回事。当我意识到我的行为有些冒犯，我做出了道歉。他最终有礼貌的退出，并继续参与这个项目。但是他的感情受到了伤害，无需再说，对新志愿者来说也不是一个吉利的开始。

# 像分担技术任务一样分担管理任务 运行项目时要像分担技术负担那样分担管理负担。随着项目的成长，就会有更多关于管理人员和信息流程的工作。没有道理不分担这些负担，这并不一定需要一种自顶向下的阶级组织—实践中更多是同级的网络拓扑结构，而不是军队式的命令结构。 有时管理角色是正式的，有时则是自然发生的。在Subversion项目中，我们有一个补丁管理员，一个翻译管理员，文档管理员和问题管理员（尽管是非正式的）以及一个发布管理员。有时这些角色是经过认真考虑才开始的，而有些则完全是自发的；随着项目的成长，我相信会增加更多的角色。下面我们会详细审视这些角色，以及一些其他的角色（除了在本章前面的[the section called “发布经理”](# "发布经理")和[the section called “发布所有者独裁”](# "发布所有者独裁")中介绍的发布管理员）。 就像你看到的角色描述，请注意没有人独占控制其所在领域。问题管理员并没有防止其他人在问题数据库中做出修改，FAQ管理员也不必是编辑FAQ的唯一人选。他们的角色都是非垄断的责任。每个领域管理员所作工作的重要组成部分是提醒在该领域工作的人，训练他们按照管理员的方式工作，这样多种力量就可以互相加强，而不是发生冲突。领域管理员必须记录他们工作的过程，这样当他们离开时，别人就可以立刻接班。 有时会发生一种冲突：两个或更多的人希望同一个角色。现在没有人处理这件事。你可以建议每个志愿者写一个计划（一个“申请”），让所有的提交者选出最佳。不过这样有些笨拙，而且可能有些尴尬。我发现最好的方法只是告诉多个候选者自己处理。他们通常能够，也会更满意自己得出的结果，而不是别人施加的结果。 ### 补丁管理员 在一个接收许多补丁的自由软件项目，跟踪到达的补丁以及所做的决定会成为一场噩梦，特别当通过非集中方式完成时。大多数补丁是以邮件的形式出现在项目开发列表（尽管可能有些最早出现在问题跟踪系统，或外部站点）的，在补丁到达时有许多不同的处理补丁的例程可以选择。 有时，某人评审了补丁，发现了问题，然后踢回给原作者整理。这通常会导致一个交互过程—都在邮件列表中可见—原始的作者一直发布修正的补丁版本，直到评审者无法找到更多的问题。有时很难说清楚这个过程已经结束：如果评审者提交了补丁，则可以说整个周期已经结束。但是如果她没有，或许仅仅因为她没有时间，或者没有提交权限，而且无法拉其他开发者做这件事。 另一个对补丁的常见回应是轻快的讨论，不必是针对补丁本身，而是关于补丁之后的概念。例如，补丁可能修正了一个bug，但项目希望用另一种方式修正这个bug，作为解决一个更普通类型问题的一部分。通常一开始这都是未知的，只是补丁激发了探索。 偶然情况下，发布的补丁可能会遇到完全的沉默。通常是因为没有开发者有时间*在那个时刻*去评审这个补丁，都希望其他人能去做这件事。因为每个人等待其他人捡起这个球的时间并不一定，而其他优先的事情不断出现，很容易会造成补丁被漏掉的情况，但这是任何人都不会希望发生的事情。项目可能以这种方式错误可用的的补丁，也有其他有害的副作用：会打击作者，他为补丁做了许多工作，让他觉得整个项目难以靠近，特别是对于其他考虑编写补丁的人。 补丁管理员的工作就是确保补丁不会漏掉。这是通过跟踪每个补丁的稳定状态实现的。补丁管理员观察邮件列表中每个由提出补丁引发的线索。如果最终以补丁的提交完成，他不需要做任何事。如果进入了评审/修正迭代，以补丁的最终版本结束，但是没有提交，他发起一个指向最终版本以及相关邮件列表的问题，这样之后跟进的所有开发者都有了一个永久的记录。如果补丁定位了一个现有的问题，他会将相关信息注释到该问题，而不会开一个新事物。 如果某个补丁没有回应，补丁管理员应该等待几天，然后询问是否有人会去评审它。通常会有响应：某个开发者会解释她认为该补丁不必应用，然后给出原因，或者她会去评审它，。如果还是没有回应，补丁管理员可以发起，也可以不发起一个补丁的问题，要根据他自己的判断，但至少最初的提交者得到了*一些*回应。 拥有一个补丁管理员为Subversion开发团队节省了大量时间和心力。如果没有指定的人负责，每个开发者需要一直担心“如果我没有时间现在回应补丁，我能指望别人做吗？我是否要一直盯着？ 但如果有别人盯着，同样的原因，这样是否是没必要的重复。” 每个开发者在第一次看到这个补丁的时候都要做这样的决定。如果她希望跟进评审，她就可以这样做—补丁管理员会根据情况调整他的行为方式。如果她希望完全忽略这个补丁，也没问题；补丁管理员会确保它没有被遗忘。 因为这个系统只有在补丁管理员不发生失误的情况下才能运作正常，所以这个角色必须正式任命。在Subversion，我们在开发和用户邮件列表中广而告之，得到了许多志愿者，并选了第一个回复的。当那个人请辞后（本章后面的[the section called “转化”](# "转化")），我们重复了这个步骤。我们一直没有试图让多个人分担这个角色，因为他们之间会需要交流的负担；但是如果补丁提交的规模更大，则一个多头的补丁管理员就会有意义。 ### 翻译管理员 在软件项目中，“翻译”可能指的是两件完全不同的事。它可能指的是将软件文档翻译为其他语言，或者指的是翻译软件本身—也就是让程序使用用户选中的语言显示错误和帮助信息。两者都是复杂的任务，不过一旦建立了正确的基础架构，则可以很大程度上与其他开发分离。因为这些任务非常类似，所以设置一个单独的翻译管理员处理两部分任务就非常有意义（取决于你的项目），亦或者更好的方式是设置两个不同的管理员。 在Subversion项目，我们有一个处理两部分的翻译管理员。他自己并不编写翻译，当然—他可以帮助一两个，但是在写这些话时，如果他希望与他们所有人一起工作，他需要讲10种语言（12种方言）。因而，他管理志愿翻译者：他帮助他们互相协调，以及他们团队与项目其余部分的协调。 设置翻译管理员的一个原因是翻译者是与开发者不同的人。他们有时只有有限的甚至没有任何在版本控制版本库中工作的经验，也没有与分布式志愿团队一起工作的经验。但在另一方面，他们通常是最好的一类志愿者：拥有特定领域知识，可以看到需求，选择参与进来。他们也通常愿意学习，对工作充满热情。所需要只是有人告诉他们如何做。翻译管理员确保翻译不会没必要的干扰日常的开发。每当开发者必须被告知需要为支持翻译工作提供技术变更时，他也要作为翻译者作为一个统一整体的代表。 因此，这个位置最重要的技能是外交能力，而不是技术能力。例如，在Subversion我们有一个政策，每种语言的翻译都必须至少有两个人正在参与，否则，就没有人可以检查文本。譬如说，有新的志愿者请求提供Subversion马达加斯加语翻译时，翻译管理员必须提示他去与六个月前某个表达过马达加斯加语翻译意向的人建立联系，或者有礼貌的询问志愿者去寻找*另一个*马达加斯加翻译者与其搭档工作。当有了足够的人手，管理员就可以为他们设置正确的提交访问权限，告知他们项目的惯例（例如如何编写日志文件），然后紧盯他们是否遵循了这些惯例。 翻译管理员和开发者之间，以及翻译管理和翻译团队之间的对话通常使用项目原先的语言—也就是所以翻译的源语言。对于大多数自由软件项目，就是英语，但是是什么语言并不重要，只要项目认可即可。（对于希望吸引广泛国际开发社区的项目，英语可能是最好的语言。） 在特定翻译小组*中的*对话通常使用它们共享的语言，然而翻译管理员的另一个任务就是为了每个团队设定一个专门的邮件列表。通过这种方式，翻译者可以自由的讨论他们的工作，而不会打扰项目邮件列表中的人，他们可能根本不理解他们的翻译语言。 **国际化还是本地化** *国际化*(*I18N*)和*本地化*(*L10N*)都指的是采用非原软件编写的语言和环境使用程序的过程。这两个术语通常是可以互相替换的，但是实际上他们并不是同一回事。就像[http://en.wikipedia.org/wiki/G11n](http://en.wikipedia.org/wiki/G11n)所说的： > 它们之间的区别是微小的，但是非常重要：国际化指的是为*潜在的*用于所有地方的产品改造，而本地化是为用于*特定*地域的特别特性附加。 例如，将您的软件修改为实现对Unicode([http://en.wikipedia.org/wiki/Unicode](http://en.wikipedia.org/wiki/Unicode))文本编码无损处理是一种国际化行动，因为它并不是关于特定的语言，而是关于接受来自任意数量语言的文本。另一方面，当检测到软件是运行于斯洛文尼亚语环境时，便以斯洛文尼亚语打印错误信息，则是本地化的行动。 因此，翻译管理员的任务从原理上是关于本地化的，而不是国际化。 ### 文档管理员 保持软件文档的实效性是一项无法结束的任务。每个进入代码的新特性或改进都可能会导致文档的变更。另外，一旦项目文档达到了一定级别的完整性，就会发现许多人发来的补丁是针对文档的，而不是代码。这是因为许多人是在文章中修正了bug，而不是在代码中：所有的用户都是读者，但仅有少数是程序员。 文档补丁通常比代码补丁更易于检查和应用。仅需要少许或无需测试，而且可以快速的通过检查评价变更的质量。因为数量很多，但是检查的负担相对较低，文档补丁中有效工作的管理负担比率远比代码补丁高。此外，大多数补丁需要一些调整，才能保持文档中作者语气的一致性。在大多数情况下，补丁通常会覆盖或影响其他补丁，在提交之前需要根据之间的关系进行调整。 出于处理文档补丁的紧迫性，以及需要持续监控代码基以便保持文档的实效性，有必要让某个人或一个小组专门从事这项任务。他们需要精确的保存文档在何处滞后于软件的记录，而且他们可以用一种整体方式的实践步骤来处理大量的补丁。 当然，这样不会阻碍项目中的其他人在工作中应用文档补丁，特别是时间允许时一些小的补丁。同一个补丁管理员（见本章前面提到的[the section called “补丁管理员”](# "补丁管理员")）可以同时跟踪代码和文档补丁，当开发和文档团队希望时完成它们。（如果补丁的总数已经超出了单个人可以跟踪的容量，最好的一个步骤可能就是将补丁管理员分为代码和文档。）文档团队的关键是使人们把保持文档组织性、实效性和一致性当作自己的责任。在实践中，这意味着对于文档的熟悉，关注*其他人*提交给文档的变更，关注到来的文档补丁，并使用所有这些信息源完成保持文档健康的所有必要工作。 ### 问题管理员 项目bug跟踪系统中问题的数量是随着使用产品的人数同比例增加的。因而，即使你在一个快速成长的健壮程序中修正bug并装运，您还是会看到大量开放的问题漫无边际的产生。重复问题，以及不完整或描述糟糕的问题也会频繁发生。 问题管理员通过关注进入数据库的信息，定期的清除特定问题有助于缓和这种问题。他们的大多数常见行为可以修正进入的问题，一方面因为报告者未能正确的处理部分字段，另一方面也因为问题与数据库中的一个问题已经重复。很明显，问题管理员对项目bug数据库越熟悉，他就越能有效率的检测到重复问题—这也是设置一小部分人专门关注bug数据库，而不是让每个人都*特别*参与其中的原因。当团队试图按照非集中式的方式完成这项任务时，就不会有任何一个人具备对于数据库内容的深入专业知识。 问题管理员可以帮助我们映射问题和个别开发者。当有大量bug报告进入时，不是每个开发者会以平等的态度读取问题通知邮件列表。然而，如果某人知道开发团队紧盯着所有进入的问题，她可以将注意力放到特定合适的bug上。当然，这需要对项目所有开发的事情，接受者期望和性情都很敏感。因而，问题管理员最好也是开发者的一分子。 取决于你的项目如何使用问题跟踪系统，问题管理员也可以调整该数据库以反映项目的优先级。例如，在Subversion我们将问题排入未来的特定发布，这样每当有人询问“某个bug X何时可以修复时？”我们可以说“之后的两个发布，”即使我们不能说出确切的日期。这个发布在问题跟踪系统中以目标里程碑的形式展示，也就是IssueZilla中的一个字段。[[27](#)]作为一个规则，每个Subversion发布都有一个新的特性和一组特定的bug修正。我们为该发布的所有问题赋予一个合适的目标里程碑（包括新特性—它也会得到一个问题），这样人们就可以通过发布计划查看bug数据库。这些目标很少情况下会保持静止。随着新bug的到来，等级会发生切换，而且有些bug必须移到另一个里程碑，以保证每个发布的可管理性。再次，最好由对项目数据库的内容以及问题之间的关系有着整体意识的人完成。 问题管理员的另一项值得关注的任务是管理废弃的问题。有时，某个bug会因为软件一个不相关变更而意外的修正，或者有时项目对于特定行为是否为bug的意见发生改变。寻找废弃的问题并不简单：唯一的系统方法是清理数据库中的所有问题。随着问题数量的增长，完全的清理会变得越来越不可行。在达到某个点时，保持数据库健康的唯一方法就是分而治之：根据进入数据库的情况将问题分类，并直接分配给合适的开发者或团队。然后接受者负责问题余下的工作，根据需要决定是解决还是废弃。如果数据库足够大，问题管理员的工作就更倾向于协调，将会花费较少的时间用于自己查找问题，而是花更多的时间使之到达正确的人手中。 ### FAQ管理员 FAQ维护是一项出人意料的困难工作。项目中其他文档的内容都是由作者预先计划得到的，而FAQ则完全是被动的文档（见[维护FAQ](# "维护FAQ")）。无论它变得如何巨大，你永远不知道何时会再一次添加。而且因为它总是零零散散的添加，它很容易变得不够一致并缺乏组织，甚至会包含重复的或半重复的条目。即使它没有任何此类的明显问题，项目之间也通常会有不引人注目的互相依赖—必须有链接，但是没有—因为与关联的项目添加的时间相差一年。 FAQ管理员的角色是双重的。首先，通过至少对所有问题的标题保持熟悉，她维护了FAQ的整体质量，这样每当有人添加的新条目与原来的条目重复或者相关，可以作出合适的调整。其次，她关注着项目的邮件列表和其他论坛中重复发生的问题或疑问，并根据这些输入编写新的FAQ条目。后一项工作可能非常复杂：必须能紧跟线索，识别出其中的核心问题，发表一个提议FAQ条目，组合来自其他人的评论（因为FAQ管理员不可能是FAQ包含的所有主题的专家），并感知何时结束这个过程并将其添加到FAQ。 FAQ管理员通常也会成为FAQ格式的默认专家。有许多保持FAQ结构的小细节（见[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “将所有的资源视为归档”](# "将所有的资源视为归档")）；当某人编辑了FAQ，他们可能会忘记这些细节。但只要FAQ管理员能够在之后查漏补缺，这样便没有任何问题。 许多自由软件可以用于辅助维护FAQ的过程。只要能够保证FAQ的质量，就可以选一个来使用，但是要避免过度自动化。一些项目试图完全自动化FAQ维护的过程，使用类似wiki的模式允许每个人贡献和编辑FAQ条目（见[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")的[the section called “Wikis”](# "Wikis")）。我曾经遇到过在Faq-O-Matic上发生的这种情况（[http://faqomatic.sourceforge.net/](http://faqomatic.sourceforge.net/)），尽管我看到原因仅仅是对Faq-O-Matic超出本来目的的滥用。在任何情况下，虽然完全的分布式FAQ维护可以减少项目的负担，但也会导致较差的FAQ。没有人具备整个FAQ的广泛视野，没有人注意到了哪个条目需要更新或变得完全不可用，每个人看到的都是孤立的条目。结果是FAQ经常会无法为用户提供他们所需要查找的东西，甚至会误导他们。您可以使用任何必须的工具维护项目FAQ，但是不要因为工具便利性的诱惑而损害FAQ的质量。 见Sean Michael Kerner在[http://osdir.com/Article1722.phtml](http://osdir.com/Article1722.phtml)的文章*The FAQs onFAQs*，描述和评估了开源FAQ维护工具。 [[27](#)] IssueZilla就是我们使用的问题跟踪系统；它是BugZilla的后继。

# 从志愿者中获取最多 志愿者为什么要为自由软件项目工作？[[24](#)] 当被询问时，许多人声称自己只是因为希望制作好软件，或希望自己修复所需要的bug。但是这些原因并不是完整的故事。毕竟，你能想象如果没有人欣赏他的工作或倾听他的讨论，这个志愿者还会呆在这个项目吗？当然不会。很明显，人们在自由软件上花费时间的原因不仅仅是单纯的对生产良好代码的渴望。理解志愿者的真实动机将会帮助你能够合理的安排，以确保吸引和保持他们。对生产优秀软件的渴望、在复杂问题上获取的挑战和学习价值也许都是动机。但是人们有与其他人一起工作的内在期望，并在合作活动中提供和获取尊重。从事合作活动的团队必须进化出行为的标准，能够通过帮助团队的活动获取并保持那种地位。 这些标准并不总能自己出现。例如，在一些项目中—资深的开源开发者可以从顶级人员中去除几个人—人们明确的感觉到是通过频繁并详细的发布取得的这种地位。他们并不是偶然得到这个结论；这是因为他们曾经因进行长时间的，复杂的辩论中而得到尊重的回报，即使对项目没有实际的帮助。下面是一些创建氛围的技术，可以让获取地位的活动与建设性活动一致起来。 ### 委派 委派并不仅仅是将工作分散的方法；它也是政治和社会工具。考虑你要求某人做什么事情的所有效应。最明显的效应是如果他接受，就是他完成任务不是你。但是另一个效应则是他意识到你信任他能够处理这个任务。此外，如果你是在公共论坛发起这样的请求，那么他也知道团队中的其他人也表明了对他的信任。他也能感受到需要接受一些压力，这意味着你询问时要使用一种允许他拒绝的方式，如果他确实不想做这个工作的话。如果这个任务需要在项目中协调，你这样做可以有效的提议他更深入的参与进来，形成其他方式无法形成的契约，而且也有可能成为项目某个子领域权威的起源。增加的参与或许令人畏惧，也或者会导致他以其他方式参与进来，例如对于整体承诺的更多感觉。 因为所有这些效应，所以即使你认为你可以完成的更好更快，让其他人来完成也很有意义。当然，也有一个严谨的经济学效率作为论据：或许你自己完成的机会成本太高—在同一时间里你可以完成许多更重要的事情。但即使机会成本的论据并不适应，你*还是*会希望其他人完成这个任务，因为从长期来看你希望人们更深入的参与到项目当中，即使一开始需要花费更多的时间关注他们。相反的技术也适应：如果你偶然志愿完成其他人不喜欢或没时间完成的工作，你会得到他的友好关系和尊敬。委派和代理并不仅仅是要完成单个任务；他们也是将人们引入到项目核心的方法。 ### 明确区分调查和指派 有时可以很明确的期待某人会接受特定的任务。例如，如果某人编写的代码带来了bug，或者提交的代码明显未能符合项目的指导方针，那么直接指出问题，那么之后你可以认为他会小心避免此类问题。但是在一些情况下，没有明确的方法可以确保你获得期望的行动。这个人可以听你的，也可以不听。因为没有人喜欢被熟视无睹，你需要敏感的察觉到这两种情形的区别，并以此为依据调整你的请求。 你让某人做某事，如果你采用的方式让人感觉这是他理所当然的责任，而实际上他并不是这么想的时，几乎一定会立刻让他们感到非常的厌恶。例如，分配的问题可能会带来很多讨厌的事。项目的参与者通常知道谁是某个领域的专家，所以当出现了bug报告，通常会有大家都知道的一两个人可以立刻快速的修正它。然而，如果你没有得到先前的许可就将问题分配给她，她会感觉自己处于一个不舒服的地位。她会感受到这种被期望的压力，而且感觉她是由于其专业技能而被惩罚了。毕竟，获取技能的方法就是通过修正bug，所以某人会接受这个问题！（请注意，在问题跟踪系统中根据bug报告的信息自动分配的问题通常并不太冒犯，因为每个人知道分配是自动的过程，并不代表人们的预期。） 虽然应该尽可能将负担均匀的分配，但有时你需要鼓励能够以最快速度修正bug的 人。考虑到你可能无法承受为每个这种分配进行这种交流的负担（“你愿意看一下这个bug吗？” “可以。” “好的，一会儿吧这个问题分配给你。” “好的。”），你应当以询问的形式进行分配，不要传递出任何压力。事实上所有的问题跟踪系统都允许为任务分配的问题作出评论。在那个评论中，你可以这样说： > 把这个分配给你，jrandom，因为你可能是最熟悉这些代码的。如果没时间，尽管踢回来。（如果你想在以后接受这中请求，请让我们知道。） *请求*完成工作与某人*接受*工作有明显的区别。在这里观众不仅仅是被分配工作的，而是所有人：整个团队可以看到被安排工作的人的专业技能得到了公开的确认，但是这些信息也明确的表明他可以自由的接受或者拒绝这种责任。 ### 指派后要继续跟踪 当你要求某人做一些事情时，请牢记所做的，并无论如何要继续跟踪他。大多数请求是在公共论坛中做出的，形式大体上类似“你能处理一下X吗？我们只是要获知；如果你不行，那么没问题，我们只需要知道。 ”不一定会得到回应。如果你得到的回应是负面的，则环路可以关闭—你需要尝试其他的策略来处理X。如果有正面的回应，那就需要继续关注这个问题的进展，并为可见和不可见的进展作出评论（当知道其他人会欣赏他的作品时，每个人都会做的更好）。如果几天内没有回应，可以再次询问，或者发表文章说明你没有得到回应，希望找其他人做这件事。或者直接自己完成，但也要说明最初的询问未能获得回应。 公开提示缺乏回应的目的并*不是*要羞辱任何人，你的评论一定不要造成这种效果。目的仅仅是说明你还在跟踪自己征求的问题，而且你已经注意到了一些反应。这样做可以增大人们在下一次说同意的机会，因为他们会知道（即使只是无意的）你会注意到他们所做的任何工作，包括许多不太起眼的，人们会忽略的事件。 ### 通知感兴趣的人 另一件可以让人们高兴的事情就是通知他们所感兴趣的事情—通常情况下，你注意到并记住某人的个性方面越多，他会越觉得舒适，他也就越会希望参与你的团队一起工作。 例如，在Subversion项目有一个非常有明显区别的划分，期望达到决定性的1.0发布的人，和那些主要希望添加新特性，并完成感兴趣的问题，但对1.0并不太关心的人。两者的地位相当；他们只是不同类型的开发者，都在项目中完成了大量工作。但是很快认识到我们绝*不能*假设所有的人都是由1.0发布的喜悦所驱动的。电子媒介可能很有迷惑性：在你感觉到共同目标的氛围中，实际上只是你与谈过话的人有共同的目标，而其他人则有完全不同的优先级。 你对人们对于项目的期望了解越多，你就越能有效发出请求。即使仅仅是描述一下他们所期望目标的理解，甚至不必发出任何相关的请求，也非常有用，这样可以确保所有人不仅仅是无差别群众中的粒子。 ### 赞扬和批评 赞扬和批评并不矛盾；在大多数情况下，是类似的。都是关注的形式，越是明确就越有效。二者必须在牢记实在目标的情况下实施。两者都有可能因为夸大而削弱：赞扬过多或太频繁会使赞扬贬值；对批评也是同样，尽管在实践中，批评通常会有反作用，因而更加不容易贬值。 一个重要的技术文化特性是将详细的，不带偏见的批评当作一种赞扬（正如在[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “识别无礼”](# "识别无礼")中所讨论的），因为这隐含了接收者的工作值得花时间去分析。然而，两种条件—*详细的*和*不带偏见的*—必须同时满足。例如，如果某人对代码做了些马虎的修改，如果只是说“很马虎”是毫无用处（而且通常是有害的）的。马虎最终是*人*的一种特性，而不是作品的，应该将反应集中到作品上。更有效的方法是描述变更中所有错误的地方，巧妙而无恶意。如果这是某人连续第3，或者第4次作出疏忽的修改，则可以再说一次这些事—不必发怒—批评的最后，要清楚的说明同样的模式早已经被注意到了。 如果某人对于批评不做任何改进，解决办法不应该是更多或更强的批评。对于团队来说，解决方法是将这个人从不能胜任的位置删除，并尽可能使用一种不会造成情绪伤害的方法；见[the section called “转化”](# "转化")本章后面的例子。但实际上，这种情况通常很少发生。大多数人可以很好的回应批评，当然批评必须要特定，详细并有明确的（即使没有说出来）改进预期。 赞扬不会伤害任何人的感情，但并不意味着使用时可以不像批评那样小心。赞扬是一种工具：在使用之前，要问自己*为什么*你希望使用它。作为一条戒律，不应该因为人们经常做的事情，或正常的和参与到团队中应当要做的行动赞扬他。如果你这样做，估计就停不下来了：你因为普通的事情而赞扬*每个人*？毕竟，如果你漏掉了某人，他们会问为什么。如果能珍惜你的赞扬和感激会更好，要针对不寻常或意料之外的努力，以鼓励此类努力为目的。当某个参与者永久的进入了更高生产力的状态，要根据此人调整赞扬的阀值。对普通的行为进行反复的赞扬会变得毫无意义。相反，这个人也应该感觉到自己较高的生产力水平已经是正常和自然的，只有超出这个范围的才会被特别关注。 当然，这并不是说不应该感谢某人的贡献。但是请牢记，如果项目设置正确，这个人做的任何事情都会看到，所以这个团队会知道（这个人也会知道团队中的其他人所知道的）所有她所做的。除了直接的赞扬，我们也有其他的方法感谢某人的工作。你也可以采用曲折战术，在讨论相关主题时，她已经给定领域做了许多工作，成为了领域专家；你可以公开的向她咨询代码的问题；或者更有效的，你可以大张旗鼓的进一步利用她的工作，这样她就会为别人依赖于她的工作结果而感到舒服。通常不必在这些问题上精打细算。那些有规律的为项目作出贡献的人知道自己会自然的得到有影响的地位。通常没有必要为此采取明确的步骤，除非你感觉到无论出于什么原因，贡献者都无法得到正确的评价时。 ### 防止割据 请留意那些试图在项目中独占某一领域，或希望完成某一领域所有工作的参与者。此类行为已开始看起来很健康。毕竟，在表面上似乎是某人在肩负更多的责任，并展示在特定领域增长的活动。但从长期来看，则并没有建设性。当人们感觉到“禁止入内”的标志时，他们就会离开。这种结果会减少这个领域的检查，会使之更加脆弱，因为孤单的开发者成为失败的单独一点。更严重的，它会削弱项目的合作，平等精神。理论上应该欢迎任何开发者在任何时间帮助完成任何任务。当然，在实践中会有些不同：人们在不同领域的影响总有差别，非专家通常与项目特定领域的专家不同。但关键是这都是自愿的：非正式的权威是根据竞争性和证明的判断能力赋予的，而不可以主动的*获取到*。即使某人期望的权威是能够胜任的，仍然需要她非正式的保持权威，通过团队的共识和那种永远不会将其他人排除在该领域之外的权威。 当然，因为技术原因反对或编辑某人的工作则是完全另外一回事。决策因素是工作的内容，而不应该是谁恰好是守门人。也许也是同一个人完成恰好完成了最多的工作，但只要他没有阻止其他人完成这个工作，就没有问题。 为了对抗地方主义的萌芽，许多项目采用禁止在源代码文件中包含作者名或维护者签名的方法。我完全认可这种实践：我们在Subversion项目中也遵循这个方法，这也算是Apache基金会的一种正式政策。ASF成员Sander Striker是这样做的： > *在Apache软件基金会中我们不鼓励在源代码中使用作者标签。除了法律分歧以外，还有多方面的原因。协作开发是以一个团队一起工作，将整个项目看作一个团队。给予信誉非常好，必须有人这么做，但是必须使用不会允许错误归因的方式，即使是通过暗示的方式。何时添加或删除作者标签没有明确的标准。在你修改注释后添加你的名字？或者是添加了一行的修正？在你重构了代码，改变了95%时就可以删除其他作者的标签？当人们去接触每一个文件，修改足够多的内容以达到名字标签的限额，这样他们的名字就会出现在每个地方时，你会怎么做？* > *提供信誉可以有更好的办法，我们推荐这些。从技术观点上讲，作者标签并不是必需的；如果你希望知道哪个人写了某段代码，版本控制工具可以提供。作者标签也经常失去时效性。你希望被私下咨询5年前编写，而且已经希望遗忘的代码？* 软件项目的源代码文件时身份的核心。必须要反映整个开发社区为此负责，而不仅仅是简单的各自的封地。 人们有时会为源代码中作者或维护者标签的风格而争论，他们认为这些东西是所做工作的可见信誉。这种论点有两个问题。首先，不可避免的要面对多少工作量才可以进入这个列表的尴尬问题。其次，这样会将信誉的问题与权威合并了：过去曾经完成了工作并不意味着对于曾经工作区域的所有权，但是如果单个人的名字出现在源文件的顶部，想避免这种暗示就变得几乎不可能。在任何情况下，信誉信息都可以从版本控制日志和其他诸如邮件列表归档等外带机制中获取，所以在源代码文件中禁止其出现不会损失任何信息。[[25](#)] 如果你的项目禁止在源代码文件中包含姓名，请务必不要过分执着。例如，许多项目会有一个保存小工具和辅助脚本的`contrib/`区域，通常由与本项目不相关的人编写。这些文件可以包含作者姓名，因为他们完全不是由项目维护的。另一方面，如果贡献的工具被项目的其他人修改了，最终你希望将其从孤立的位置移出，如果原始作者许可，就可以删除作者名称，这样代码就像其他社区维护的资源一样了。如果作者对此有些敏感，折衷的方案也是可以接受的，例如： ~~~ # indexclean.py: 从Scanley索引删除旧数据。 # # 原始作者: K. Maru <kobayashi@yetanotheremailservice.com> # 现在维护者: Scanley项目组<http://www.scanley.org/> # 和K. Maru。 # # ... ~~~ 但是最好避免此类折衷，如果可能，大多数作者会被说服，因为他们都会乐于自己的贡献更紧密的成为项目的一部分。 重要的是请牢记项目的核心和外围是一个连续体。项目的主要源代码文件显然是核心部分，会被认为应当是由社区维护的。在另一方面，伙伴工具或一些文档则可能是单独某个人的作品，始终独自维护，即使这些作品是与项目关联，甚至是与项目一起分发的。没有必要应用一个适用于所有文件的规则，只要坚持社区维护的资源不允许成为个人领土的原理就可以了。 ### 自动化率 努力不让人做机器可以做的事情。作为一种经验法则，将一项工作自动化花费的工作量即使十倍于手工执行也是值得的。对于非常频繁或复杂的任务，这个比率可以轻松的达到20倍或更高。 将自己想象为“项目管理员”，而不仅仅是开发者，可能是一个有效的态度。有时，单个开发者会过于沉溺于较底层次的工作，而无法看到全局图并意识到每个人都在手工执行自动化任务上浪费了大量精力。即使那些意识到的人也可能不会花时间解决问题：因为每个个体都不会感觉此类任务是一个巨大的负担，没有人已经厌烦到要为此做些什么。使自动化如此引人注目的是每个很小的负担需要乘上每个开发者执行的次数，然后还要乘上开发者的*数量*。 这里，我广泛的使用的术语“自动化”，并不仅仅是重复每次只需要修改1到2个变量的动作，而且包括任何辅助人们的技术基础架构。最低标准的自动化需要按照[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")中描述的方式运行一个现在的项目，但是每个项目也都有自己的特殊问题。例如，一组编写文档的人会希望有一个网站能够在任何时间都显示最新版本的文档。因为文档通常由如XML的标记语言编写，会有一个编译步骤，通常非常复杂，包括创建可显示或可下载的文档。组织这种会在每次提交时进行此类编译的网站可能会有点复杂和花费时间—但是这样很值得，即使这要花费你一天或更多的时间。拥有最新网页的整体收益是巨大的，即使*没有*的代价仅仅是每个开发者需要每次多一些很小的烦恼。 进行这种步骤不仅仅可以消除时间的浪费，也可以确保消除在执行手工操作时步骤出错（不可避免的会发生）时的痛苦和沮丧。多步的，确定的操作恰好是发明计算机的目的；将人们拯救出来可以做更有意义的事情。 ### 自动测试 自动测试对任何软件项目都有用，特别是开源软件项目，因为自动测试（特别是回归测试）可以让开发者舒服的修改自己不熟悉的代码，因而鼓励了探索性的开发。因为手工检测损坏是这样困难—需要从本质上猜测可能损坏的事情，而且必须尝试多种实验证明其没有损坏—通过自动化方法检测这种损坏为项目节省了*大量*时间。它也可以让人们可以更放松的大幅度重构代码，从而对软件的长期可维护性贡献良多。 **回归测试** *回归测试*指的是判断已修正bug是否重新出现的测试。回归测试的目的是减少代码变更以不可预料的方式破坏软件的机会。随着软件项目的增大和复杂，这种不可预料的副作用会急剧增长。好的设计可以减少随着变更增长带来的这种比率，但是不能完全消除这种问题。 结果就是许多项目都有了一个*测试套*，一个单独的可以按照过去模仿bug发生的方式进行调用的程序。如果测试套成功的使某个bug出现，这被称作*回归*，意味着某人的变更意外的将以前修正的bug又修正回来了。 请看[http://en.wikipedia.org/wiki/Regression_testing](http://en.wikipedia.org/wiki/Regression_testing)。 回归测试并不是万能药。首先，它非常适于批量样式界面的程序。对于主要使用图形用户界面操作的软件很难程序化驱动。回归测试的另一个问题是测试套框架本身可能非常复杂，自己有一定的学习曲线和维护负担。减少这种复杂性是你可以做的一件非常有用的事，即使这需要花费相当多的时间。将新测试添加到测试套越简单，就会有越多的开发者这样做，发布中漏网的bug也就会越少。在使测试更简单上的努力将会在项目的生命周期中得到成倍的回报。 许多项目有一个*“不要破坏构建！”*的规则，意思是：不要提交会使软件不能编译或运行的变更。成为破坏构建的人通常会导致温和的窘迫和取笑。拥有回归测试套的项目通常有一个推论的规则：不要提交会导致测试失败的任何变更。如果整个测试套会自动每夜运行，随着结果发送到开发列表或专门的测试套列表，这类失败可以轻松定位；这是自动化价值所在的另一个实例。 大多数志愿开发者会愿意用额外的时间编写回归测试，只要测试系统是可理解的并易于使用。变更搭配测试可以理解为一种责任，也是协作的一种简单的机会：通常要由两个开发者分担bug修正的工作，其中一个编写修正本身，另外一个编写测试。后一个开发者通常要以更多的工作结束任务，因为编写测试并没有实际的修正那样让人愉悦，测试套不应当使测试体验超出本来应有的痛苦。 一些项目走的更远，*每个*bug修正或新特性都要伴随新的测试。这是否是个好主意取决于许多因素：软件的特性，开发团队的组成和编写新测试的难度。CVS（[http://www.cvshome.org/](http://www.cvshome.org/)）团队一直有这样一个规则。在理论上这是一个好政策，因为CVS是版本控制软件，所以非常希望规避处理或误处理用户数据可能性的风险。问题是在实践中CVS的回归测试套是一个单独的巨大shell脚本（好笑的是叫做`sanity.sh`），难于阅读，也难于修改或扩展。增加新测试的难度，以及对于新增补丁必须包含测试的要求，决定了CVS有效的阻碍了补丁。当我在CVS上工作时，我见过有人着手，甚至完成了一个CVS自己代码的补丁，但是当被告知需要在`sanity.sh`增加新测试时则放弃了。 编写新的回归测试比修正原来的bug花费更多的时间非常正常。但是CVS将这种现象发挥到了极致：一个人需要花费数小时才能正确的设计自己的测试，但仍然得到错误的结果，因为修改这样一个35000行的Bourne shell脚本有太多不可预测的复杂情况。即使是长期的CVS开发者也会为增加新测试而感到郁闷。 这种情况源于我们对于自动化比率考虑的失败。转换到一个真正的测试框架—无论是自定义的还是成品的—都会成为一种主要的动力。[[26](#)]随着时间的推移，这种忽视给项目带来更多的代价。有多少bug修正和新特性*未能*进入现在的CVS，仅仅因为这尴尬的测试套的阻碍？我们不知道精确的数量，但是一定远大于开发者为了开发新测试系统（或集成一个成品的系统）而会放弃的bug修正或新特性数量。这个任务只会耗费有限的时间，但如果无动于衷，则使用现有测试套的惩罚将会永远持续下去。 重点不在于强制编写测试是错误的，也不是说编写Bourne shell脚本的测试系统必然是不好的。它可能工作的很好，这取决于你的设计和测试的需要。重点仅仅是说当测试系统成为开发的明显障碍时，必须要有行动。同样的道理适用于所有成为障碍或瓶颈的常规过程。 ### 将每个用户当作潜在的志愿者 与用户的每次交流都是发展新志愿者的好机会。当一个用户花时间在项目邮件列表上发表文章或报告bug时，他已经认为自己比大多数用户（那些项目永远听不到回音的人）有更大参与的可能。紧跟这种潜力：如果他描述了一个bug，感谢他的报告，并询问他是否有兴趣自己修正它。如果他说FAQ中漏掉了一项重要问题，或者程序的文档有些不足，请坦率的承认问题（假定确实存在），并询问他是否有兴趣自己编写遗失的材料。很自然，大多数时候这个用户不会同意。但是多问一句也不累，而且只要你每次都这么问，也会提醒论坛中的其他听众参与到项目当中是每个人都可以做的。 不要将你的目标限制在新开发者和文档编写者上。例如从长期来看，即使训练人们编写优秀的bug报告也是值得的，如果你没有在每个人身上花费*太*多时间，而且如果在将来继续提交更多的bug—如果第一次报告时能获得建设性的互动，以后更有可能这么做。建设性的互动不必是对于bug的修正，尽管那样是理想的；它可以仅仅是一种要求更多信息的恳请，或仅仅是那种行为*是*bug的确认。人们希望被倾听。其次，他们希望自己的bug被修正。你可能无法一直及时的给予后者，但你（或者说整个团队）可以给他们前者。 一个推论就是开发者不能向出于好意提出含糊bug报告的人们表现出愤怒。这是我个人很气恼的事情。我在许多不同的开源邮件列表中看到许多开发者一直这样做，危害是显而易见的。一些倒霉的新手会发布无用的报告： > 嗨，我没法运行Scanley。每当我启动它，就会报错。有人遇到过这个问题吗？ 一些开发者—可能已经遇到此类报告几千次了，但丝毫不考虑这个新手从未遇到过—会这样回复： > 这么点信息我们能怎么做？天呐。请给点细节，例如Scanley的版本、你的操作系统和错误信息。 开发者无法从用户的角度看待事物，也未能考虑到这种反应对于观看这种交互的*其他*人的效果。很自然，对于没有编程经验的用户，之前没有报告bug的经验，当然不知道如何编写bug报告。对于这种人该怎样正确处理呢？教育他们！要使用会促使他们回来获取更多信息的方式： > 很遗憾你遇到了困难。我们需要更多信息才能找出发生的问题。请告诉我们Scanley的版本，您的操作系统和错误的精确文本。最好能提供一份你所运行命令的脚本，以及对应的输出。更多信息请看http://www.scanley.org/how_to_report_a_bug.html。 这种从用户那里榨取信息的响应方法远谈不上有效率，因为它是从用户的角度编写的。首先，它展示了同情：*你遇到了问题；我们也感到痛*。（即使在bug报告回应中也不是必须的；这取决于问题的严重程度以及感觉到的用户的伤心程度。）其次，没有对她不知如何报告bug表示轻视，而是告诉她如何，以及怎样的详细程度才会实际有效—例如，许多用户并不理解“请给些细节”的意思是“展示错误的精确文本”，不要遗漏或删节。当你第一次与这样一个用户工作时，你需要说明这些。最后，应该提供到更加详细和完整的报告bug指导的链接。如果你成功的让用户感觉在为她考虑，她通常会花时间阅读该文档并按照你所说的去做。当然，这通常意味着你需要预先就准备好文档。必须说清楚哪种类型的信息是开发团队在每个bug报告中希望看到的。理想情况下，可能需要通过回应多个这样的用户，逐渐的查漏补缺，使之更好地为项目服务。 Subversion项目的bug报告指导可以说是这类形式的标准案例（见[Appendix D, *报告bug的样例指导*](# "Appendix D. 报告bug的样例指导")）。请注意他们是如何以请求提供一个bug的补丁或修正结束的。这不是因为这种请求将会导致更高的补丁。报告率—大多数能够修正bug的用户都知道如果能提供补丁会受到欢迎，无需告知他们。请求的真实目的是为了向所有读者，特别是刚来到项目，或者刚来到自由软件的人强调，这个项目是通过志愿者的贡献运营的。这是许多新用户通常不熟悉的一个关键点。一旦他们意识到这一点，他们就更有可能在发生时帮助完成修正，即使不能提供代码，也会提供更完整的重现步骤，甚至是为其他人发布的内容测试修正。目标是让每个用户认识到他们和为项目工作的人没有*天生*的区别—问题只是他们能投入多少时间和力量，而不在于是谁。 对于愤怒回应的告诫不能适用于粗暴的用户。偶尔会有一些人会发送毫无信息量的bug报告或投诉，表现对项目某些失误的蔑视。通常此类人会在轻蔑与谄媚之间转换，例如Subversion邮件列表的这个人： > 为什么几乎6天了还没有Windows平台的二进制程序？！？每次都是同样的故事，确实让人灰心。为什么这类工作就不能自动化，可以立刻出现。？？当你发布“RC”构建时，我想你们的意思的是让用户测试构建，但是你们没为此事做任何事。如果你们没提供测试方法，又何必搞一个浸润期？？ 对于这种激动文章的最初回应是令人吃惊的克制：人们指出该项目有自己的发布政策，不会提供官方的二进制文件，并告诉他如果要改变恼人的程度，他应该志愿自己编译代码，如果真的对他很重要的话。相信与否，这段话属于他的下一次发布： > 首先，我要说我认为Subversion很彪悍，很感谢每个参与者的努力。 [...] ...然后他*再次*继续为项目没有提供二进制，现在仍然没有志愿者做这件事而斥责项目。之后，大约50人跳了出来，我必须说我确实注意到这一点了。在[Chapter 2, *起步*](# "Chapter 2. 起步")的[the section called “防无礼于未然”](# "防无礼于未然")提出的，针对粗鲁行为的“零容忍”政策，已经潜移默化的应用到每个人的交互中。但是，当人们认清他一开始就要当一个喷子时，没人能给他好脸色。 很幸运，这些情形非常罕见，很少需要被项目特别关注，并投入力量去保持用户建设性的和有礼貌的交互。 [[24](#)] 这个问题已经被详细研究，Karim Lakhani和Robert G. Wolf的一篇论文有非常有趣的结果，题目为*Why Hackers Do What They Do: UnderstandingMotivation and Effort in Free/Open Source SoftwareProjects*。见[http://freesoftware.mit.edu/papers/lakhaniwolf.pdf](http://freesoftware.mit.edu/papers/lakhaniwolf.pdf)。 [[25](#)] 但是邮件列表中链接为[http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee](http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee)的*“having authors names in .py files”*的这篇文章是一个很好的抗辩，作者是William Stein。我认为关键在于许多作者来自一种将信誉直接取自源代码视为标准并高度评价的文化。在那种环境中，可能有必要将作者的名字置于源代码中，并精确的描述每个作者的贡献，因而大多数潜在的贡献者会希望有这种样式的承认。 [[26](#)] 请注意，没有必要将所有已存在的测试转化到新框架；二者可以和平共处，只需要转化需要改变的测试。