> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20161112-bian-cheng-yu-yan/starting-a-bsd-user-group.md). # 创办 BSD 用户组 * 原文：[Starting a BSD User Group](https://freebsdfoundation.org/wp-content/uploads/2016/12/Starting-a-BSD-User-Group.pdf) * 作者：**George Rosamond** 2003 年，几位志同道合的 BSD 用户创办了纽约市 BSD 用户组（NYC*BUG）。NYC*BUG 每月开会，托管多个邮件列表，并为 BSD 项目及其他用户组提供服务。 2003 年 12 月，我们中几人计划在 2004 年 1 月正式亮相，地点选在纽约市最后一届 Linux Expo。我们明白在 Linux Expo 上有机会与更广的开源社区接洽，并举办一场 BoF 会议（Birds of a Feather），最终在 2 月初召开首次会议。 约 50 人参加了那场 BoF，早期会议规模大且热烈。讨论常常持续到凌晨，我们开始见证技术用户组如何把人聚到一起并产生影响。 用户组的历程充满任何技术用户组都会经历的起伏，要总结出有教益的经验并不容易。但我将回顾 NYC\*BUG 的历程，并为有意创办 BSD 用户组（BUG）的人给出一些有用结论。 ## 不友好的“委员会” 并非本地社区所有人都对我们的亮相感到兴奋。NYC 一向有众多开源用户组，从企业影响浓厚的大帐篷到接近邪教地位的都有。是的，邪教地位。 本地 Unix 用户组尤其觉得我们本应在动手前先征求他们的意见。我们既未寻求许可，也未请求原谅。 略带喜感的是，在 BoF 之前，2004 年 1 月 13 日 NetBSD NYC 地区列表上的一条帖子就把我们否了： . > “i wonder if beer is involved? there’s no mention of it in that posting.” > > “they are just doing what the linux group does... probably same ppl too.” 最终，这位资深 BSD 开发者为我们做了场演讲，并成了我们最热心的支持者之一。 ## 从“不想要什么”开始 回想起来，我们确实处于一片混乱中。但我们清楚自己不想要什么。我们中几人参加过其他技术协会与用户组，它们似乎都落入两类之一。 第一类是缺乏实质内容、更像简历素材的专业协会。相应行业的供应商——如信息安全——主导演讲与材料，被动的与会者只在招聘与解雇时才碰键盘。 第二类是技术用户组，当之无愧地招来“社恐聚集地”的名声，一个或几个小圈子凑在一起交换技术文化的边角料。与专业协会一样，演讲仍可能充满推销味。 我们两者都不想要。我们寻求一种松散的组合，专注于生产环境中的 BSD。 ## 一切都围绕星号 另一关键要素是对 BSD 项目保持中立。NYC\*BUG 中许多人可能偏爱某个 BSD 胜过其他，但我们在官方立场上保持中立。这并非天真。我们看到与外界一样的偶尔邮件列表 flame 战或采访中的刻薄评论。但根本上，我们也认为 BSD 之间共同点远多于分歧。 许可证，无论以何种简单形式呈现，始终是最清晰的最高原则。有人视之为对开发者友好、对企业友好或对自由友好，但我们都乐于接受一种不需要几年法学院才能看懂的许可证。如果某个项目明天垮掉，我们认为剩下的项目很可能为相关开发者和用户提供合理的新归宿。 将 BSD 社区与其他开源社区对照，也使 BSD 之间更紧密。在 NYC\*BUG 范围内，项目之间批评可以畅所欲言，但都出于开放讨论的精神，没有网上 flame 战的尖刻。 久而久之也明显了，定期面对面会议削弱了钓鱼或对其他 BSD 项目妄下不当评论的环境。在线世界让虫子也能幻想自己是国王。但当这条虫子必须直视其他虫子的眼睛时，王者幻觉便消散。 过去一年中某次会议上，对某个 BSD 项目做了概览。室内没有该项目的其他用户，我们好奇讨论会如何展开。 结果胜过千言万语。一位资深开发者兼 Unix 老前辈批评该项目缺乏焦点，但其方式更像是在影射他自己所在 BSD 项目的问题。另一位资深开发者谦逊地讲述其第三个 BSD 项目面临的问题，向演讲者当众认错致歉。面对面会议带来的谦逊，仍是 NYC\*BUG 的优势之一。所有开源项目都是玻璃房，而在线互动往往掩盖这一现实。 ## 推销员勿扰 迅速成形的另一原则是避开销售人员，甚至含蓄地不鼓励其出席。NYC*BUG 的会议与邮件列表不是来宣讲某种“颠覆性”新产品的场所，也不是技术招聘者钓简历的池子。是的，NYC*BUG 会议免费对所有人开放，但生产环境中的 BSD 才是最高原则。 早期有过一次考验。我们请纽约的 Apple 企业人员派工程师来谈 Darwin、BSD 与开源。我们感念并深知 Apple 对 BSD 的贡献，但这位销售人员坚称这一话题不过 15 分钟的事，并恳求允许发放销售材料。我们坚持立场，坦白说甚至威胁如果技术演讲变成销售推介就终止会议。 会议是技术性的，会场爆满，50 多人站着听完整整两小时，几乎无人中途离场。这印证了我们的判断。特别是我们中许多是 dot-com 时代的过来人，没有开放酒吧、昂贵赠品，也许还有像样牛排，没人会自愿听销售推介。我们并非想每月占用一个空闲夜晚，而是要营造一种氛围：与会者都是积极参与者，会议主题反映人们实际在做什么。这是衡量 NYC\*BUG 成败的标尺，过去是，现在也是。 ## 与赞助商的正确关系 回到 2004 年的纽约市语境，应理解纽约当时是、现在仍是 Linux 的地盘。直到 2008 年崩盘前，纽约市的龙头行业是金融业，多为从 Solaris 迁来的 Linux 商店。纽约有几家重要的 BSD 商店，我们着手接洽。 大势所趋。金融业采用 Linux 这件事很重要。但多年后，Linux 发行版中 systemd 的兴起为我们带来新受众。Apple 借 OS X 发布高调支持 Unix，也扩大了我们的听众。关注这些更大的议题，有助于触达惯常圈子之外更广的受众。 与 BSD 商店建立的最富成果的关系，大概是与 New York Internet。他们多年前从 Solaris 迁到 FreeBSD，一直被评为最佳公共数据中心之一。我们没有 Linux 那种数量与规模的受众，但他们因我们的质量而迅速提供支持。借用一位老板的话（转述）：“你们看起来是值得交往的人。”此后，NYI 为我们提供满机柜，托管数十个项目，并一直是稳定赞助商。他们对 NYC 之外的社区也贡献良多。FreeBSD 的美国东海岸基础设施就位于其新泽西设施，BSD 社区与 NYI 都因这段关系而更好。BSD 认证集团、pfSense、BSD.lv、mandoc 等项目、众多托管镜像，都因与 NYI 的关系受益。 > “经常有人问我们创办用户组的建议。第一条建议是别试图复制我们。” 把“值得交往的人”这一概念与我们对销售推介等的态度联系起来很重要。潜在赞助商可能希望在邮件列表与演讲中自由使用，乃至拿到会议与会者名单。但允许此类访问的用户组，恐怕也吸引不到赞助商想接触的那类人。是的，我们可能设门槛，但若我们的参数受到尊重，这些努力是值得的。 ## 无资产的协调 赞助问题引出资金与资产议题。我们办过五次会议，后四次都盈利。我们在 NYI 维护机柜。但归根结底，我们没有资产，也不追求资产。会议的任何盈利都捐回 BSD 项目。 维护非营利实体，或哪怕只是一个 NYC*BUG 银行账户，都需要高于我们意愿的责任与问责。拥有此类实体意味着酝酿潜在冲突。“穷”到一无所有意味着无可争。引用那本流行社会学书的话，做海星比做蜘蛛更安全。fork 我们、复制我们，我们都太松散以致无法被打破。NYC*BUG 更像黏稠的泥而非沙堡。把蜘蛛切成两段，它死；把海星切成两段，你得到两条海星。 我们从一开始就保持某种非正式。我们力求成员流动，这意味着无法进行有意义的投票。谁有资格投票？邮件列表成员？一年只来一次会议的人呢？还是几乎从不缺席的人？ 一旦实施选举所需的形式，太多其他程序问题随之而来。我们早期曾探索设立非营利组织，但很快意识到风险会更高，而尽量无资产、尽量非正式是更好的路线。 我们六人走进一家纽约市技术导向机构的会议室，他们兴致勃勃地要把我们改造成非营利结构。我们中五人原本支持。但走出会议室时，五人反对设立非营利，乐于继续无正式结构。 除 NYC\*BUG 行政组承担的几项职责外，没人真的被迫做任何事。也许主题有趣时来一次会议，或主题与工作或兴趣相关时参与邮件列表讨论。但人们自然地反复出现与重现，保持这种低准入（与退出）门槛改善了氛围。 那么行政组如何成为有用的机构？行政组的宗旨很简单。加入行政组不是特权。核心职能是解决不适合在 talk@ 邮件列表讨论的组织问题。讨论可能围绕机柜的托管问题，或确定下几次会议主题。行政组成员由若干承担协调 NYC\*BUG 活动角色的人演变而来，未经选举，也没有正式任期。 对多数 BUG 而言，行政组不仅不必要，还是危险的障碍。如果只有五人定期开会，其中两人在单独邮件列表上决定组织问题毫无意义，只会打消另外三人积极性。技术人员除了总是试图用技术方案解决组织问题外，也倾向于像在创业公司那样过度构建组织基础设施。 行政组一旦启动，我们试图使其在选择成员时有所筛选，同时让成员可轻松离开而不致不适。并非总成功，但总体上行政组持续运转并提供相当方向。偶尔行政组中有人指出某人是不错的补充人选。我们以共识决定其加入，因为行政组的化学反应至关重要。 一个值得一提的事件最能说明行政组的作用。 像 BSD 社区整体一样，NYC\*BUG 面临多样性匮乏的严峻现实，尤其在性别方面。我们对此相当自觉，也是常设议题。我们矫正方式之一是明确表态：性别歧视与对女性居高临下的态度不可接受。 有一次，一位 NYC*BUG talk@ 邮件列表发帖者在邮件签名中使用了令人作呕的性别歧视签名。因此人在其他方面已是麻烦，NYC*BUG 周围许多人早已把他的帖子丢进 **/dev/null**。但当他的签名出现时，几位不在行政组的人发邮件要求采取行动。 他迅速被移出邮件列表，并告知了原因。但这也表明，其他不在行政组的 NYC\*BUG 参与者也迅速作出反应，并认为处理此事也是他们的责任。 ## 警告：请勿在家模仿 我们经常被问及创办用户组的建议。第一条建议是别试图复制我们。我们是不同寻常的例子。我们身处一座充满技术人才与资源的活力全球都市。我们的会议常有 Unix 界“名人录”中的人物。如果你所在的是小镇大学城，或地广人稀的乡村，照搬 NYC\*BUG 只会带来无尽挫败。 最重要的教训是，我们从欣赏自身所处的环境开始。我们了解纽约的技术圈。我们了解用户组圈。我们了解自己不想做什么。更重要的是，我们从与自身处境和手头资源相符的小目标开始。 多数时候，当有人想发起 BSD 用户组时，往往是某个人有时间、精力与想法在推动。这就引出第一个问题：项目不应由一个人独占。至少需要几位志同道合、能共担责任的人来把 BUG 启动并维持下去。 那么，第一步或许是发起一个邮件列表并宣传。召开启动会议通常意味着一两人被视为组织者，其余与会者以参与或不参与被动投票。邮件列表是从一开始就吸引大家主动参与的好载体。寻找共同兴趣与主题是关键的第一步。 如果你们是几位在一小时车程半径内（比如波兰 Rzeszow 周围）的人，每月开会很难。也许每季度一整天的活动更合理。何不让每个人都参与组织？这种情况下，邮件列表很可能是该群体活动的理想平台。 我们的会议与会者从十余人到数十人不等。对其他人来说，四五个就很不错。关于 Apache 的会议也许会引起本地 LAMP-stack 群组的兴趣，哪怕他们不跑 BSD。不如只保留邮件列表，或者一个 IRC 频道。归根结底，用户组不会变成大获成功的 IPO，也不会催生出色的新技术。它们实际上只是有目标的社会组织。 ## BUG 的意义 BUG 可为社区提供有用的框架，作为扎根企业世界或孤立开发者之外的另一种选择。BUG 能更好地反映实际用户在做什么，他们的需求、愿望和挫折。与企业的捐赠不同，BUG 能提供不带附加条件的贡献。最终，更广泛的人群可以支持这些项目，这反过来也让人对项目有更深的主人翁感。 BUG 能以调查永远无法做到的方式，提供生产环境中 BSD 使用情况的有用且接地气的画面。我们花大量时间确定会议主题和演讲者，有时发现我们的选择反响平平。另一些时候，我们发现创造性地选择会议主题会激发没人意识到的兴趣。没有什么比看着纽约及其他地方的用户组复制我们的会议主题和做法更令人受宠若惊的了。 纽约仍然不能真正算作“BSD 之城”，但我们插下的旗帜确实促进了这一概念。 BSD 社区传统上不以倡导闻名。但如果我们有这样一个世界——几十个 BUG 为每个 BSD 项目维护镜像，定期捐赠资金和硬件，与所在地区的 BSD 使用企业建立联系等等——整个 BSD 社区将强大得多。 例如，NYC\*BUG 创造了一个让对 BSD 好奇的人可以试探水温的地方，也许还能探索 BSD 如何为他们所用。这种方法同样适用于远超纽约市范围的其他地方。 *** **George Rosamond** 是纽约市 BSD 用户组的创始成员。本职是系统管理员，George 为技术客户维护一家小型托管公司，此外还为大小各异的众多 BSD 项目做贡献，尤其专注于隐私增强技术。近两年来，他的核心工作是 Tor BSD 多样性项目（`https://torbsd.github.io/`），致力于将 BSD 的使用扩展到 Tor 公共匿名网络（`https://www.torproject.org/`）。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/20161112-bian-cheng-yu-yan/starting-a-bsd-user-group.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.