# 创建一家 BSD 用户组 少数志同道合的 BSD 用户于 2003 年成立了纽约市 BSD 用户组（NYC\*BUG）。NYC\*BUG 每月举行一次会议，并维护着多个邮件列表，同时为 BSD 项目和其他用户组提供服务。 NYC\*BUG 用户组的发展历程充满了其他技术用户组都会遇到的起伏，因此要总结出有指导意义的经验并非易事。不过，我将尝试回顾 NYC\*BUG 的发展，并为有意成立自己 BSD 用户组（BUG）的人提供一些有用的结论。 2003 年 12 月，我们几位计划在 2004 年 1 月正式启动 NYC\*BUG，地点选在纽约市的最后一次 Linux Expo 上。我们预期可以借此机会接触更广泛的开源社区，并举办一场同好者聚会（BoF），最终在 2 月初举行首次会议。 约有 50 人参加了 BoF，我们早期的会议规模较大且互动热烈。讨论一直持续到凌晨，我们开始看到技术用户组如何将人们聚集起来，并逐渐产生影响。 ## 不友好的委员会 并非当地社区的每个人都对我们的启动感到热情。纽约市一直有各种各样的开源用户组，从受大型企业影响的广泛团体，到接近邪教性质的组织。是的，接近邪教性质。 尤其是当地的 Unix 用户组，他们认为我们在成立 BSD 用户组前应该先征求他们的意见。但我们既不寻求许可，也不求原谅。 更有趣的是，在 BoF 之前，2004 年 1 月 13 日，NetBSD NYC 区域邮件列表上有人发表了如下评论，轻蔑地对待我们： * “我想知道会不会有啤酒？帖子里没有提到。” * “他们只是在做 Linux 用户组做的事……大概还是同一批人。” 最终，这位长期的 BSD 开发者为我们召开了一次会议，并成为我们最大的支持者之一。 ## 从“不想要的事情”开始 回想起来，我们确实曾陷入极度的迷茫之中。但我们对自己不想要的东西非常清楚。 我们中的一些人曾参与过其他技术协会和用户组，这些组织似乎都属于两类之一。 第一类是缺乏实质内容、更多像简历项目的专业协会。各自领域的供应商——比如信息安全——主导了演讲和材料，而被动的参与者几乎只在招聘或解雇时才碰键盘。 第二类是技术用户组，它们因聚集社交上不太擅长的人而名声在外，一个或多个小圈子聚在一起交换一些奇怪的技术文化内容。与专业协会类似，这类组织的演讲仍可能充斥着销售宣传。 我们不希望出现这两种情况。我们想要的是一个松散的组织，专注于生产环境中的 BSD 系统。 ## 关于 Asterisk 的一切 另一个关键原则是对各 BSD 项目保持中立。虽然 NYC\*BUG 的许多人可能偏向某个 BSD，但我们在官方层面保持中立。这并非幼稚想法。我们也会看到偶尔的邮件列表争吵或尖刻的访谈评论，就像世界上其他地方一样。但从根本上说，我们认为各 BSD 项目之间的共同点多于差异。 无论采用哪种简单形式，许可证仍然是最清晰的总体原则。有人可能认为它对开发者、企业或自由特别友好，但我们都能接受这样一个无需几年法学院学习就能理解的许可证。如果明天某个项目崩溃，我们认为剩下的项目很可能为相关开发者和用户提供合理的新归属。 将 BSD 社区与其他开源社区对比，也进一步将各 BSD 项目紧密联系在一起。虽然在 NYC\*BUG 的范围内，各项目之间可能会有批评交流，但这都是开放讨论的精神，并没有在线争吵中常见的恶意。 随着时间推移，定期的线下会议也显现出作用，它减少了网络上“喷子”或对其他 BSD 项目发表无根据评论的环境。在线世界允许一些人幻想自己是王者，但当他们必须面对面与他人交流时，这种虚荣幻想往往会消散。 过去一年的一次会议中，我们对某 BSD 项目进行了概览。会议室中没有来自该项目的其他用户，我们好奇讨论会如何展开。 结果非常有意义。一位长期开发者和 Unix 老手批评该项目缺乏焦点，但方式是建设性的，更可能反映出该开发者自己 BSD 项目中的问题。另一位长期开发者谦虚地谈到他们第三个 BSD 项目遇到的问题，将讲解者的建议视为公开的自我反省。面对面的交流所激发的谦逊，仍然是 NYC\*BUG 的优势之一。所有开源项目都是“玻璃屋”，而在线互动往往掩盖了这一现实。 ## 销售人员免入 另一个很快形成的原则是避免销售人员，甚至在某种程度上暗示不鼓励他们出席。NYC\*BUG 的会议和邮件列表不是宣传某个“颠覆性”新产品的场所，也不是技术招聘人员搜集简历的集散地。是的，NYC\*BUG 会议是免费的、对所有人开放的，但核心原则始终是关注生产环境中的 BSD。 早期有一次具体尝试：我们曾向苹果纽约公司请求一名工程师，讲解 Darwin、BSD 和开源。我们对苹果对 BSD 所作贡献心怀感激，但这位销售人员坚持认为该主题只值 15 分钟演讲，并恳求允许分发销售资料。我们坚持自己的原则，坦率地表示如果技术讲解变成了销售演示，将会终止会议。 那次会议完全以技术为主，50 多人站满会场，在两小时的演讲中，几乎没有人离场。这证实了我们的观点。特别是许多成员都是互联网泡沫时代的老兵，没人会自愿听销售演讲，除非有开放酒水、昂贵赠品，甚至可能还有一块好牛排。我们并不想每月占用自由夜晚。我们希望创造一个环境，使参与者积极参与，会议主题反映他们实际在做的事情。这一直是衡量 NYC\*BUG 成败的标准。 ## 与赞助商的正确关系 在 2004 年的纽约市背景下，应当理解这是一座以 Linux 为主的城市。直到 2008 年金融危机前，纽约的龙头行业是金融业，这些企业经常从 Solaris 迁移到 Linux。纽约确实有一些重要的 BSD 企业，我们的目标是与这些企业建立联系。 更大的趋势同样重要。金融行业采用 Linux 的情况影响了我们的受众。但几年后，Linux 发行版中 systemd 的出现又为我们带来了新的关注群体。苹果在推出 OS X 时对 Unix 的大力支持，也让我们的声音被更多人听到。关注这些大趋势，有助于我们接触到常规受众之外的更广泛群体。 迄今为止，与 BSD 企业建立的最有成效的关系是与 New York Internet（NYI）。他们多年前从 Solaris 迁移到 FreeBSD，并长期被评为最佳公共数据中心之一。虽然他们的 Linux 用户规模不大，但由于我们提供了高质量支持，他们很快就愿意提供帮助。正如一位企业主所说（意译）：“你们看起来是值得相处的好人。”自那时起，NYI 为我们提供了整机机柜以托管数十个项目，并持续作为赞助商。他们还为 NYC 之外的 BSD 社区做出了巨大贡献。FreeBSD 在美国东海岸的基础设施位于他们在新泽西的设施中，BSD 社区和 NYI 都从这种关系中受益。BSD Certification Group、pfSense、BSD.lv、mandoc 等项目，以及众多托管镜像，都从与 NYI 的关系中获益。 关键在于将“值得相处的好人”这一理念与我们对销售演示等活动的态度联系起来。潜在赞助商可能希望在邮件列表、演示甚至会议参与者名单上拥有完全自由，但允许这种行为的用户组，很可能无法吸引赞助商真正想接触的群体。我们可能会让他们有所限制，但如果他们尊重我们的规则，这种努力是非常值得的。 ## 在缺乏资源的情况下进行协调 赞助商问题引出了资金与资产的问题。我们举办过五次会议，并在最近四次取得了盈利。我们在 NYI 维护了一个机柜。但最终，我们没有资产，也不追求资产。会议获得的任何利润都会捐回 BSD 项目。 维持一个非营利实体，甚至只是一个 NYC\*BUG 银行账户，都需要比我们愿意承担的更高的责任和问责。而拥有此类实体意味着潜在冲突的可能性。缺乏资产意味着没有可争之物。参考那本流行的社会学书籍（**译者注**：参见布莱福曼（Ori Brafman）、贝克斯特朗（Rod A. Beckstrom）著，李江波译，《海星式组织：重新定义组织模式》，中信出版集团，精装，2010 年，224 页，ISBN 9787521700312），比喻而言：成为海星比成为蜘蛛更安全。分叉我们，复制我们，但我们太松散，不会断裂。NYC\*BUG 更像黏稠的泥而不是沙堡。切开一只蜘蛛，它会死；切开一只海星，就得到了两只海星。 我们从一开始就保持一定的非正式性。我们努力维持流动的成员制，这意味着我们无法进行任何有意义的投票。谁有资格投票？邮件列表成员？那些一年只参加一次会议的人呢？或者那些几乎每次都参加会议的人呢？只要实施选举所需的形式化程序，会产生太多其他程序性问题。虽然我们早期曾考虑创建非营利组织，但很快意识到风险更高，而保持资产贫乏、尽可能非正式是更好的路径。 六个人走进一家技术导向的纽约市机构会议，该机构希望将我们迁入非营利结构。五人赞成，但最终五人反对创建非营利实体，并满足于继续保持非正式。 除了 NYC\*BUG 管理组履行的一些职责外，没有人被真正强制去做任何事情。有人可能在话题有趣时参加会议，或在相关的邮件列表讨论中参与。但人们的定期出现和再现变得自然而然，而保持这种低门槛的进出氛围改善了整体环境。 那么管理组如何发挥作用呢？管理组的目的很简单。成为管理组成员不是特权。其核心功能是解决 talk@ 邮件列表不适合处理的组织问题。讨论可能围绕机柜的共置问题，或确定即将举行的会议主题。管理组成员由少数人承担协调 NYC\*BUG 活动的角色演变而来，既没有选举，也没有正式任期。 对大多数 BUG 来说，管理组不仅不必要，实际上是危险的障碍。如果五个人定期开会，由其中两人通过单独邮件列表决定组织事务是无用的，只会阻止其他三个人积极参与。 除了永远尝试将技术解决方案引入组织问题外，技术人员也倾向于过度建设组织基础设施，就像在扩展初创公司一样。 一旦管理组运作起来，我们尝试在选择成员时保持挑选性，同时让成员轻松退出而不感到不适。虽然并非总是成功，但总体上，管理组继续运作并提供了相当数量的方向。有时，管理组成员会提出某人可能是不错的新增成员。我们通过共识决定其加入，因为管理组的化学反应至关重要。 有一件值得注意的事件充分体现了管理组的作用。 像更广泛的 BSD 社区一样，NYC\*BUG 面临着明显的多样性不足问题，尤其是在性别方面。我们对此非常关注，并定期进行讨论。我们的一部分措施是明确表明，对女性的性别歧视和居高临下的态度是不可接受的。 在一次事件中，一位 NYC\*BUG talk@ 邮件列表的发帖者在邮件签名中使用了令人反感且带有性别歧视的内容。由于此人之前在其他方面已经造成问题，NYC\*BUG 内部很多人已经将他的帖子直接屏蔽。但当他的签名再次出现时，有几位不在管理组的人发送邮件要求采取行动。 结果，他很快被从邮件列表中移除，并说明了原因。这也显示出，其他不在管理组的 NYC\*BUG 成员能够迅速做出反应，并认为自己有责任共同处理这种情况。 ## 警告：不要在家中尝试 我们经常被问到关于如何创办用户组的建议。第一条建议是：不要试图照抄我们。我们是个特殊的例子，所在的城市充满了技术人才和资源，我们的会议经常会有 Unix 领域的一些“谁是谁”的参与者。如果你位于一个小型大学城或偏远分散的地区，试图照搬 NYC\*BUG 会带来无尽的挫折。 最重要的经验是，我们学会了欣赏自己所处的环境。我们熟悉纽约市的技术圈，了解用户组的现状，明确知道自己不想做什么。最关键的是，我们从可实现的目标开始，目标反映了我们的处境和现有资源。 通常情况下，想要发起 BSD 用户组时，最初只有一个人推动整个工作，其承担了时间、精力和创意。这就带来了第一个问题：不应该只有一个人拥有这个项目。需要至少几个人共同分享愿景，并能负责让用户组正常运作，并长期维持下去。 第一步可以是创建一个邮件列表并进行宣传。启动会议通常会让一两个人被视为组织者，其余参与者则通过参与程度表达支持或不参与。邮件列表是从一开始就让人们积极参与的理想渠道。找到共同兴趣和话题是关键的第一步。 如果你们只有几个人，并且相隔一个小时车程（比如波兰的热舒夫地区），每月开会可能很困难。也许每季度举办一次全天活动更为合理。而且为什么不让每个人都参与组织活动呢？在这种情况下，邮件列表很可能成为团队活动的理想平台。 我们的会议规模可以从十几人到几十人不等。对于其他用户组来说，四五个人也是值得的成果。而且会议主题，比如 Apache，不必由相关 BSD port 维护者来讲解。这是一个常见误区。如果用户组中的人正在使用 BSD，那么就有话题和演讲者可用。依赖“名人”和主题权威会很快耗尽演讲者资源。让实际参与者进行演讲可以保持门槛低，让每个人都能参与。许多在 BSDCon 上首次演讲的人，最初都是在 NYC\*BUG 会议上演讲的。我们创造了一个舒适、互动的环境，最终惠及 NYC 以外的 BSD 社区。 ## 快进来，水温不错！ 另一个 BSD 用户组（BUG）能发挥的作用，是为个人参与 BSD 项目提供“传送带”。人们常常把加入 BSD 项目看作某种虚拟的精英制度，好像优秀的会自然脱颖而出，明天就会出现下一层核心开发者。 实际上情况完全不同。BUG 可以成为面对面接触开发者和其他用户的场所，让那些原本孤立的用户融入 BSD 文化。很多热心的潜在开发者会因此明白，为什么 bash 不是默认 shell，或者为什么即便在冷门架构上测试 ports 也很重要。 虽然 NYC\*BUG 从未声称自己创造了开发者，但确实有不少人从孤立的 BSD 终端用户，转变为在这种环境中活跃的开发者。例如，贡献 ports 就是进入 BSD 贡献的一条相对容易的路径，而我们努力提供易于理解的入门介绍，让更多用户能够上手。从那里开始，那些原本零散的空闲时间很快就会被用在修改 makefile、检查依赖关系等实际开发活动中。 ## 好玩，好玩，还是好玩 我们的黄金法则仍然是早期 USENIX 参与者的一句话：你们玩得开心吗？ 如果不能享受其中，很难有动力去处理各种麻烦事，比如讲师爽约的会议等。要让它有趣。如果会议变成了负担，也许可以改为季度一次，或者只保留邮件列表，或者一个 IRC 频道。 归根结底，用户组不会变成暴利的 IPO，也不会直接催生出惊艳的新技术。它们本质上只是带有目标的社交组织。 ## 用户组很重要 用户组（BUGs）可以为社区提供一个有用的框架，作为企业环境或孤立开发者之外的替代方案。BUGs 能更真实地反映实际用户的行为、需求和困扰。与企业捐赠不同，BUGs 可以提供无附加条件的贡献。最终，更广泛的参与者可以支持项目，从而增强对项目的归属感。 BUGs 能以调查无法做到的方式，提供生产环境中 BSD 使用的真实情况。我们花大量时间确定会议主题和演讲者，有时发现选择不受欢迎，但有时创新主题会激发出意想不到的兴趣。看到纽约及其他地区的用户组复制我们的会议主题和方法，是最令人欣慰的事。 尽管纽约尚不能真正称为“BSD 城市”，但我们树立的旗帜确实推动了这种理念。BSD 社区传统上并不以宣传著称。但如果全世界有几十个 BUGs，能够维护各 BSD 项目的镜像、定期捐赠资金和硬件、与本地 BSD 使用公司建立联系等，整个 BSD 社区的实力将大幅增强。 例如，NYC\*BUG 为对 BSD 感兴趣的人提供了一个入门的场所，让他们“试水”，探索 BSD 如何为自己服务。这种方法同样适用于纽约以外的地区。 *** **GEORGE ROSAMOND** 是纽约市 BSD 用户组（NYC\*BUG）的创始成员。职业上，他是一名系统管理员，同时运营一家面向技术客户的小型托管公司。此外，他还参与多个大型和小型 BSD 项目，尤其专注于隐私增强技术。近两年来，他的核心工作集中于 Tor BSD 多样性项目（），旨在将 BSD 系统的使用扩展到 Tor 公共匿名网络（）。 --- # Agent Instructions: 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: ``` GET https://book.bsdcn.org/qi-kan/ji-wang-jing-xuan/starting-a-bsd-user-group.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.