transcript.md

Slide 1

• 闲置

Slide 2

• 大家下午好，我是来自安同开源社区（AOSC）的白铭骢，我是黎民雍。安同开源社区简称 AOSC，一个由学生建立的开源社区。目前社区成员也仍然主要由在校学生组成，当然也有相当数量的社会人士。社区一直以来的工作都围绕着 AOSC OS 这个 Linux 发行版项目进行。
• 今天在学生开源年会，我们想和同为学生的大家来分享下我们社区的历史、现状和一些人生的经验。

Slide 3

• 今天我们叫“开源社区”，但追溯到 2011 年安同的起源，我们实际上并不曾是个“开源社区”。最开始的时候，安同不过是一个由三名初三学生在 Steve Jobs 去世之际，阅读了《乔布斯传》之后，以他曾经创立的 NeXT 为灵感，想要创造的一个操作系统。
• 最开始这个系统叫做 Creator.K（创造者内核），这是一个基于 DOS 的 x86 单任务系统，“让人专注工作”是它的“根本设计原则”。当然，这在今天听起来非常好笑；对没有什么理论基础的初三学生来讲，也是块硬骨头。自然，开发并不是很顺利。
• 这之后，三位初创成员又偶然找到了 SUSE Studio（RIP），发现这个平台可以基于 openSUSE“创造”一个新的 Linux 发行版。于是，他们给这个项目取了另外一个名字：Anthon。之后，纠结再三，他们把 Anthon 译作“安同”，取义“安于同学合作”；这便是 AOSC 名字的来源。
• 于是，三位初创成员开始着手这一项目，在不断寻找“自创操作系统”的可能性的同时，也开始在互联网和学校里进行宣传。但是少年们总是容易受外部影响的，安同的初创成员和安同本身便不免受到了些政治教科书的影响。

Slide 4

• 当时在初中无形中受政治课影响最大的一点就是对中国“制造”和“创造”的理解，乔布斯自传中的“创举”恰好和这个观点相符。
• 可是，年少轻狂，总是想着作为学生（尤其初中生）做点什么，能在同学之中脱颖而出，能有什么公众关注。从一开始就缺少一种踏实的态度，仗着自己对计算机软件有限的理解，首先去关注了如何能让别人知道自己的想法，却没有想过制作一个 Linux 发行版所需要投入的技术、人力和精力成本。“成名心切且自命不凡”的态度决定了我们在这个时期所做的和所说的。现在回看确实有点让自己脸红，不过真正的黑历史还在后面。
• 经历过这段，我认为“中二病”确实是个现实中存在的一种心理状态，一是对自己特殊性的过度重视，二是对一些“程序”和“仪式”特殊的癖好。下面要简要说的安同开发团队的短暂历史，也和这点密不可分。

Slide 5

• 于是三名初创成员在 2012 年初建立了“安同开发团队”。和传统的开发团队相同，三名初创成员拉拢了一些（潜在的）开发者之后，将大家组织成一个紧密联合的团体（建了个群），然后照旧是：上层负责设计，并指派任务到下层，让开发者实现。我相信在大家深入接触开源社区之前，都会觉得这样的想法十分自然。明显地，这一“开发团队”的工作效率，无论是在管理者还是众开发者看来，都是十分“低下”的。
• 究其原因，首要的一点是当时的成员缺乏对社区和开放参与的理解。虽然大家都知道任何人都可以修改 Linux 内核的源代码，因为它是开源的，但是对于项目带头人，怎么组织这些志愿者参与 Anthon OS 的开发，三位初创成员却没有一个很好的概念。所以就有这样一种景象，开发者“申请”进入团队，团队“领导”面试一番，然后被安排一些工作。（我就是那个时候加入“开发团队”的）
• 其次是程序多于实务。在当时的我们看，初中生组成的 95 后开发团队，简直就是狂拽酷帅 dió 炸天啊，大家快来看，我们是初中生开发者诶！还设计了不同样式的队旗，好让整个项目显得高大上。（核心、周边、硬件）还是中二病。
• 再者，那时的我们并没有认识到，由学生组成的团体并不能和全职开发团体比效率。安同 OS 对于所有参与者来说，不过是业余爱好项目。各开发者参与到项目的时间零散不一。在一个“靠爱发电”的项目上，再被任务分配一番，开发者在他不预期接受压力的项目上感觉到了压力，积极性自然就会下降，任务分配的效率就会变得非常低下。

Slide 6

• 开发团队本身的组织也越来越复杂，什么“决策组”，“周边组”，“宣传组”里面往往只有一个人，而到底来说团队里可能就一两个人在做事，而剩下的也便是“挂名”。
• 开发团队的“工作”就这样进行了一年，到这个时候，无论是我本人还是团队中的许多人都已经意识到自己像是在一个传销团伙里面工作了一年，叫着响亮的口号，却不见得做了多少实际的事情。
• 到 2012 年底，团队中的人际矛盾也开始显现出来，争吵也时常发生，一是迷惑于为什么在一个团队里并没有几个人能真正指派到工作，二是质疑这个团队的意义是否在于抬举其中几个成员，只是一个“个人宣传计划”。
• 而后团队中的一名成员（网名“小鸡”）提出建立社区的想法，这个时候，开发团队的成员们才第一次接触到“开源社区”的概念：开放的边界，不再有什么所谓的“加入申请”和从上到下的管理结构，以共同的目标和兴趣来确定社区本身的“边界”；社区内的每个人也能根据这个共同目标和兴趣以及自己的能力来建立或自己的项目或加入其他社区项目，以便充分利用每个人的才能。当然这个概念也和很多老牌社区例如 Debian 社区不同，考虑到当时的人数制约和作为学生有限的理解（当然这不是在假设所有学生都缺乏这方面充分的认识，在这几年来也认识了相当多的低龄“社区人”，到现在都让我羞愧于与其比较）。不过回到原来的话题，这个社区定义更类似于一个缺少“社长”和管理结构的校园社团。“安同开源社区”（AOSC）就这样在 2012 年 12 月 1 日建立了，每年到这个日子是我们社区的周年庆祝日。
• 但是建立社区不是我们对“社区”建设探索的终点，社区只是个概念，尽管实现了也只是个框架。一个社区的内容，它的文化、共识以及内外形象都是需要经历相当长的时间才能建成并具体化的。这个时候的 AOSC 也没能完全抛弃之前开发团队阶段的一些痼疾。

Slide 7

• 于是，从“开发团队”转制到“开源社区”之后，曾经的管理者也变成了社区的成员之一，但他们仍然是社区的精神领袖（当然，现在还是）。无论是事实上仍然起到带头作用的精神领袖们还是刚从开发团队被带到开源社区的不知所措的参与者们，都没有搞清楚开源社区到底是什么东西，它应该有有怎么样的形象，怎么样的文化内涵，成员们需要达成怎样的共识。在这个节骨眼上，不少的成员因为对氛围的不满，离开了 AOSC（退群了）。
• 留下的成员继续进行 Linux 发行版“安同 OS”以及一些周边项目的开发。然而和在开发团队里时一样，社区成员仍然非常看重自己“学生”的身份，社区的心态依然是“扭曲”的。有时社区的成员会在其它 Linux 社群，比如百度 Linux 吧，上提到安同 OS，并鼓吹一番；然后当大家问起 AOSC 是什么的时候，大家都会很自豪地说“是完全由学生组成的开源社区噢”。
• 加上当时社会开始重视并鼓励计算机软件上的国产创新，特别是操作系统上国产系统与 Microsoft Windows (XP) 的对比，大家“为中国创造”的梦想似乎又一次得到了实现的机会。比如说，那时的我们会追求系统启动上的“中国速度”，用户界面设计上的“中国设计”。我们甚至规划了特别的中国定制版本。
• 社区当时存在的问题还有一点，就是为了尽可能地招来新的开发者，我们在对新人描述社区的时候倾向于将社区描述地非常厉害，甚至可能不惜以夸张的手法来使得新人误以为 AOSC 的技术能力非常上乘。而实际上，当时的 AOSC 并没有什么实际的技术能力。我们一会儿就会详细谈一谈这个。

Slide 8

• AOSC 的历史中总是充满了教训，或细微而温柔，或显著而无情。而当今的 AOSC 社区的面貌，尤其在对待其对外交流和技术手法方面，很大程度上说，其基础是由 2013 年初一次与百度 Linux 吧成员的一次冲突建立的。
• 前面谈到过许多社区初期保留的一些痼疾，到了这个时候最显著的还是对自身社会角色的认识以及技术与政治混杂的问题。但是，到这个时候，AOSC 的开发活动基本上已经恢复，“安同 OS”也转入基于 Debian 做衍生版本的阶段。当时主要工作有几个：一是改善中文翻译（初步开始参与上游工作），二是对界面进行定制和美化，三是基于 Debian 对 KDE 4 的最新版本进行追赶适配。
• 当时的社区中成员对能做一点实际的工作还是感受到了一定的成就感，但是爱高调宣传的毛病战胜了埋头踏实做事的念头，还是看着自己是个高中生，还是觉得自己在为中国创造作了贡献——便从 2012 年底开始在 Linux 吧和 Ubuntu 中文论坛进行了大规模的宣传攻势：什么“为中国用户和新手优化”，什么“飞快启动”，都是当时的口号——但是到头来只是小规模的本地化工作以及换用 systemd 并关闭部分服务造成的必然的启动速度改善。宣传心切，也不知天高地厚，到了 Linux 吧自然是被四处嘲讽和怀疑，到头来，开发者自己也清楚这么一个“发行版”也只是比其他人对自己电脑上的 Linux 发行版做了点外观修饰多了那么点，更何况这还是个“社区产品”。
• 当时肯定的声音也不是没有，但是对待褒奖和批评也是社区当时缺乏的一点基本技能。将褒奖的人作为自己的伙伴，而将批评的人作为敌人，甚至上纲上线地标记他人为“崇洋媚外”和“美分”，总觉得“在做事情”的自己在正义的一方，在历史的正确面上。
• 当时贴吧上一用户叫“大地精”，也便成为了社区的头号敌人，一旦出现，便叫上社区成员与其打群架——论战。而到 OS1（当时已经将一开始基于 SUSE Studio 做的“概念”版本定为 OS0.5）快到 RC 阶段的时候，与其冲突变得尤为尖锐。“大地精”自己动手安装了安同 OS 并且一路嘲讽，像是否定了我们“社区化”一年来所有的努力。
• 而我本人也是“义愤填膺”，总感觉对方否定了我们作为学生的任何一点尝试和努力，总觉得自己像是什么韩国天团 cough ，便“代表”社区写了一封“给 Linux 吧的一封公开信”，信中描述社区的努力和“年轻成员”可能感受到什么“伤害”，请求对方能够稍微放缓批评而多去“理解和鼓励”。
• 而互联网是个公平而无情的地方，这篇“公开信”明显的矫揉造作不仅造成了更大反弹，还导致了社区中再次出现数次激烈争执并直接造成了 OS1 再没有完成其开发计划。当时有对安同 OS 这个“操作系统”的意义和未来价值的怀疑，对社区一直以来抱有政治色彩和对学生身份过度重视的批评，更重要的还有对社区一直缺乏诚信、夸大其辞的宣传方式逐渐强烈的抵制。
• 这段历史在社区中少有被提及过，而我本人也是第一次鼓起勇气在这里描述这段黑历史。在此先对当时自己幼稚的做法对社区成员和贴吧相关人士诚恳地道个歉，也对在此之后持续参与到社区活动的各位表示感激。

Slide 9

• 贴吧事件”风波过去之后，AOSC 停止了所有的对外宣传，社区成员也选择几乎不再对外提及我们的作品。但是，安同 OS 的开发并没有停止。这段沉寂的时间里，我们开始尝试探寻开源社区真正的意义。
• 与此同时，我们开始践行“少说话，多做事”，将所有的时间投入到技术改进上。可能也是受了一口气的原因，那时的我们终于认识到，社会并不会因为开发者是学生就对作品赞誉有加；用户实际使用一个产品的时候，他们关心的是自己的体验，不是开发者是怎样开发的。换句话说，市场不看过程，只会看结果。因此，社区的开发者们决定先发展技术基础，有足够的能力之后再去考虑怎么做 Propaganda。所以对社区开发者而言，唯一能作伴的就是对技术的激情和兴趣。
• 就这样，沉闷的五年过去了，直到今天我们再次鼓起勇气，站到学生开源年会的讲台上来。这五年来社区的参与者来来往往，但人数不断增加，不仅作为社区主业的 AOSC OS 的开发者数量越来越多，其用户数量也越来越多。
• 这是一件再好不过的事情了：实际上，我们也见证了许多年轻的（年轻人组建的）开发团队、操作系统团队。他们中有的以 30 天自制操作系统为蓝图，有的与我们一样基于其它 Linux 发行版组建自己的发行版，还有的从头开始撰写了自己的操作系统，包括内核、驱动、用户空间，能力不亚于一个计算机科学的研究生（而他们甚至刚上初中）。这些项目有的刚发布就夭折了，有的轰轰烈烈开发了一阵子，由于主要开发者失去耐心，渐渐黯淡下去了。所以，我们是这么多圈子里比较幸运的一个，这主要是开发者们没有失去对项目和社区的兴趣。五年闷声对我们来说到底是麻药呢还是解药呢？我们到底有没有发大财呢？我只能说，当局者迷，旁观者清。

Slide 10

• 如今的 AOSC 是个一切以其项目为指导而相互组织协作的社区，可以说是一个因为其项目才得以存在的社区。无论是其文化，其成员之间的友谊，都是因为这些项目的存在才得以实现的。在社区后来的历史中，项目数量曾有过多次的膨胀，社区也一直认为其存在是为了给其众多项目的开发者提供共同的平台，而不只是简单地保障单一项目——安同 OS 的开发组织。
• 关于项目的介绍，我们还是得从我们一直以来参与人数最多且工作投入最大的项目，AOSC OS。AOSC OS 的历史说来话长，不过简要地说，2014 年 AOSC OS 在我们社区成员郑兴达的指导下转入了独立构建。她从初中生时期就已开始独立制作一个叫“Heartl”的 Linux 发行版，基于 LFS 或 Linux From Scratch 的指引衍生并引入了包管理。
• 但是，安同 OS（到 2014 年夏季重启并完成了 OS1 正式版本且进行了第一次代号公投，并不可避免地投出了个 Doge）一直以来是一个针对 64 位 x86 处理器制作的发行版，而 Heartl 坚持只提供 32 位 x86 支持，外加当时刚刚立项的 CentralPoint 版本，基于 Debian 并针对 64 位 x86 服务器。后两者一直没有在社区里面得到太大关注，不过遵循社区中允许多项目并行的基本属性便造就了一个社区三个发行版的混乱现象。
• 不过回到刚刚的故事，我当时作为安同 OS 的主要开发者，提出了 The :Next Project，Next 左边有个冒号，用于表达在前面加入不同的项目，意味着社区众多项目进入走进新的阶段，或者像安同 OS 一样进行开发重启。一个暑假之后，OS2，第一个独立构建发行版的尝试就这样成型了。
• 而后几年，CentralPoint 和 Heartl 项目都先后终止，而安同 OS 也从一个针对桌面的发行版转变为了合三者为一体的 AOSC OS，通用于多种设备和多种架构。而 AOSC OS 本身也发生了许多变化，从 OS3 开始不再针对 KDE 4 一个桌面而是开始引入多样化的用户体验，并与此同时放弃对系统本身进行大范围定制；而在 OS3 正式版出现之后，系统转入了 Core + OS 的两层结构，前者保留核心运行时、工具链并提供一个抽象的“版本号”如 4.1 和 5.2.1 之类来识别发行版本身的“代系”，而后者提供其余的应用程序和链接库，进行滚动更新；而从去年暑假开始的 Core 5 周期开始，我们又引入了测试 + 稳定双线的更新模型，并且到今年年初将系统的架构支持范围扩大到了 8 个。我们会在后面几页继续深入描述这些当前的特性。

Slide 11

• AOSC OS 在我们的历史上一直是最重要的项目，是人力的最主要集中点。AOSC OS 代表着我们这个群体近七年来不断的思考和实践。
• 现今的 AOSC 社区中众多的工作都是围绕着 AOSC OS 进行的，无论是对系统本身的开发、维护和测试工作，还是针对其开发工具的项目以及社区的本地化工作，大多是以持续改善 AOSC OS 的可用性和质量为最终目标的。一会儿我们会对 AOSC OS 和社区的本地化工作进行详细的介绍。

Slide 12

• 在 AOSC OS 的自身定义方面，我们采用了非常传统的“Linux 发行版”概念，也就是我们作为发行商，基于 Linux 内核提供最基本的软硬件支持，并甄选软件提供给用户。AOSC OS 不是严格意义上的“操作系统”，更不是类似 Windows 或 macOS 这样一个定型的产品，AOSC OS 允许用户和发行商自由组合定制以适应不同使用场景。
• 我们也一直坚信用户选择 AOSC OS 时选择的是一个自认为适合自己的工具平台，而我们的责任在于维持这个平台的可用性，不少于也不多于这点。

Slide 13

• 也正因如此，我们在维护系统定制自由度的同时，试图对发行版做出一些微小的创新设计。
• 前面提到 OS1 到 OS2 最大的变化就在于系统从基于 Debian 的衍生发行版变成了基于 LFS 的独立发行版。这样一来我们对发行版的定制自由度就得到了保障，不仅限于定制用户界面。
• AOSC OS 所做的第一个设计就是简化了软件包的组织形式。简单来讲，相对于同样使用 dpkg 的 Debian 以及 Ubuntu 的细粒度软件包拆分，AOSC OS 坚持以空间换时间的策略，除非分包带来的便利更多或非分不可，对一份完整的软件来讲，AOSC OS 能不分包则不分包。
• AOSC OS 注重开箱体验。为了让以中文为母语的用户在安装完系统的第一时间就能上手，我们对软件本地化十分重视。与此同时 AOSC OS 也针对其他语言的潜在用户预先进行字体适配，以我们有限的知识保证他们的使用体验。一会儿我们会详细谈社区的本地化工作。
• 和众多发行版一样，AOSC OS 针对数个不同的处理器架构做了移植，除了 x86_64 处理器架构外，AOSC OS 还有 armv7、aarch64、mips32 和 mips64 小端序、以及针对稍老 Macintosh 电脑适配的大端序 PowerPC 32 及 64 位处理器的移植，最近还新增了 RISC-V RV64GC 架构的移植。AOSC OS 在不同处理器架构上都有一套独立的优化方案，比如在 x86_64 处理器架构上，AOSC OS 全局打开 SSE3 的编译器优化；在 ARM 和 MIPS 平台上，AOSC OS 要求使用硬件浮点数处理器；而在 PowerPC Macintosh 唯一一代支持 64 位的 G5 上，我们打开了 AltiVec 指令集支持。尽管如此，我们希望在总体用户体验上，追求跨处理器架构的一致性。我们这次带来了运行着 AOSC OS 的 Pinebook，感兴趣的话可以来我们的社区摊位体验。
• AOSC OS 由用户参与并由用户驱动。一些问题和功能性改进开发者往往不能顾全，因此 AOSC OS 的进步很大程度上靠的是用户的持续反馈。如果用户希望在 AOSC OS 上使用某些源里没有的软件或者发现有未更新的软件包，用户可以通过在 GitHub 上开 Issue 或使用社区交流群里的机器人，申请软件包增添或升级（我们把这两个过程分别称作 pakreq 和 updreq）。AOSC OS 从去年暑期引入的测试 + 稳定双线的更新模型也允许任何人选择参与到测试分支里来测试下一个月度周期要发布的软件包的稳定性（就像 Windows Insider 一样，但 AOSC 的反应一般要快一点 :-) ）
• AOSC OS 坚持可用性为先，“不扰民” 的原则。AOSC OS 里，除了最基本的 os-release，没有什么 Branding，因为我们认为时刻提醒用户“你正在使用 AOSC OS”是完全没有必要的事情；我们认为操作系统不过是用户日常使用的工具之一。因此我们把之前设计、开发“关于操作系统”的精力迁移到了系统本身的开发和创新上。

Slide 14

• 从 OS3 后，AOSC OS 引入了 Core + OS 概念。这是是目前 AOSC OS 最基本的更新方式。Core 一开始的思路不仅仅是给 AOSC OS 提供一个应用和核心的分隔，而是给 AOSC OS 本身及可能存在的基于 AOSC OS Core 衍生的发行版提供一个共同的“兼容定义”，保持同样的工具链和核心库版本和配置，而 Core 外的任何东西都属于发行版本身的设计，互不干涉。当然，到今天我们也没能看见这个“衍生发行版”的出现（笑）。
• Core 本身包含不到 30 个软件包/组件，但是定义了最基本的 C 和 C++ ABI 兼容性并提供了最基本的编译器和库。Core 相对于其外的部分，更新相对保守，在每个大周期——也就是 x.y.z 版本格式中的 x——中尽可能少地去引入新特性，只修复已知 bug、安全漏洞和兼容性问题。每次大周期（大约是一年），Core 才会大幅度更新其内容，以并引入新的技术特性。
• 而到去年暑期开始的 Core 5 周期之前，AOSC OS Core 外的部分是完全滚动更新的，频繁的更新带来了最新的软件包，但是对测试周期的忽视也将很多上游和 AOSC OS 打包者造成的问题转换成了用户的困扰。而从 Core 5 开始，我们开始引入了一个基于时间周期的测试—更新模型以保证用户能及时且相对自信地接收和安装更新，而喜欢走在风口浪尖的用户也能选择打开 testing 源来接收最新的更新和功能修改。
• 但是与此同时暴露的也是我们社区依然存在的人力问题。一开始的计划是一个月内完成一次更新周期，或 Monthly Wave，但是一个月内可能更新的软件包往往要接近 1000 个，这给我们目前依然相当依赖手动操作的打包工作带来了相当大的压力。到现在，我们基本稳定在一个基于季度的更新周期，或 Seasonal Wave。
• 这个模型的另一部分是引入安全更新频道和安全公告这两个发行版设施，安全更新和可用性修复一样，是这个 Wave 系统的两个特例，这些软件包会经过第一时间打包和开发者测试后直接推送到稳定源给用户获取。而安全公告就是一个相当传统的机制，我们叫 AOSA（或 AOSC OS Security Advisories），根据年份分类并编号，并在我们的 GitHub 页面上发布，每半个月也会在邮件列表上公布。
• 不过由此看来还是可以得到一个结论，AOSC OS 依然在进行许多的实验和实践，目的就是给用户们提供一个便利且稳定的工作平台，符合这个原则的事情我们会作为基本的“哲学”来坚持，而不符合的，便作为问题案例进行讨论并改进或丢弃。这就是 AOSC OS 的目前现状。

Slide 15

• 如果你对尝试 AOSC OS 或参与到其开发工作感兴趣，可以考虑访问这个 Wiki 页面，或在这个 talk 之后到我们社区的摊位找我们切磋切磋。

Slide 16

• 我们社区另一个重要的参与点就是上游的本地化工作，尤其是针对大陆简体中文的本地化工作——当然，这是我们社区目前的人员特征决定的。
• 我们认为，社区的主要项目 AOSC OS 是同时作为上游和下游的存在。我们作为一个发行版，是给用户提供工作平台和其他各类维护操作的上游；但是与此同时我们也是一个接收其他开源和商业项目产品及其更新的下游。尤其对于各个组成我们发行版的开源和自由软件项目，我们认为回馈这些项目是我们的责任，而作为一个特定地域语言的使用者，最直观的贡献方法除了反馈问题、提交补丁以外，就是为其本地化项目贡献翻译。
• 中国大陆地区对上游开源及自由软件本地化工作的贡献可以追溯到 2000 年之前，可以说是国内多代开发者和社区共同贡献过的方面了。但是一直以来这方面工作一直的志愿性质也导致简体中文本地化工作一直不完全或水平不一的问题。
• 我本人是 AOSC 中众多成员中第一个参与到本地化工作的，我当时翻译了 KDE 4 时期的 Homerun 启动器，而后鼓励了其他成员也参与到这个工作中。
• 曾经在社区中活跃的 A2 同学捡起了之前 Aron Xu 编撰的《大陆简中自由软件本地化工作指南》并且加入更多项目的本地化工作指引和新的标点规范等等，并尝试反馈给各简中本地化工作组请求意见并推荐其遵守。
• 从 2014 年底开始，我们给众多上游项目作出了简中本地化贡献，或大或小，或长期或短期。最主要的几个例子有 GNOME，MATE Desktop，Audacious，FreeDesktop.org 等等，其中 Wine，Octave，LMMS 等等的本地化工作主要是由我们社区的成员组织完成的。
• 本地化工作成为了我们在沉默时期和外界沟通最重要的通道之一，社区通过实际的上游工作得到了一定个人和社区的肯定，为我们社区扩展了人脉网；与此同时，也教给许多社区成员（包括我本人）很多和上游沟通的技巧和不成文规则，从长久来说改善了我们社区和上游沟通的效率和方式。

Slide 17

• AOSC 也有许多各具特色的的周边项目，有些和 AOSC OS 紧密相关，有些却完全没有关系。
• 这些项目大多都是社区成员一时兴起挖的坑。安同开源社区对各路项目的态度是“无为而治”，即以兴趣为本，开发者志愿参与。
• 这样一来当然也就有很多人挖坑不填，然而这实际上不是我们的基本策略（笑）

Slide 18

• 所以社区实际上是有过很多项目的，在此我们永远怀念这些已经没有继续开发的项目。不过我倒是想和大家分享一下其中的几个项目，虽然它们都已经停止了开发或维护，但是它们可能有一些我们认为到今天还很有意义的思想或存在，说不定我们哪天就会复活某些项目。
• 18.1: Anthon/BSD, MobiAnthon, CentralPoint, Heartl
  • 是在有 AOSC OS2 之前四个不同的操作系统项目。其中 Anthon/BSD 是针对内存小于 128MB 的低端设备开发的基于 BSD 的发行版，MobiAnthon 是为移动设备开发的操作系统。这两个项目都是只提出了概念，画了个 Logo，就没了。
  • CentralPoint 和 Heartl 则是我们之前提到的在社区化之后与 AOSC OS1 同时存在的两个独立发行版。
    • 其中 CentralPoint 是强调开箱即用用户体验的 x86_64 Linux 发行版，项目的目标是简化服务器配置，为自建服务器的新手提供 Turn-Key（也就是“转钥匙”）的配置体验和简单轻量的图形界面。
    • Heartl 则是坚持只提供 32 位版本的 x86 桌面发行版，以轻量快速为特色，基于 LFS 独立构建；而同时期的 Anthon OS 基于 Debian。Heartl 的开发者后来深入参与到了 Anthon OS 的开发之中，这才为 AOSC OS2 基于 LFS 构建打下了基础。
• 18.2: Anthon Starter
  • 安同开始程序是一个在 Windows 下运行的 Linux 安装程序，或者严格地说是一个 Linux Bootstrap Helper，为了让使用 Windows 的用户更方便地切换到 Linux 上。安同开始程序一开始是设计给 AOSC OS 用的，后来开始重新设计成一个通用的 Linux Bootstrap Helper。这个项目和当时流行的 unetbootin 是类似的，不过它的设计比较激进，那就是直接修改计算机的引导记录，达到连空白 U 盘都不需要的效果，更接近安装软件的效果。与 Ubuntu 的 wubi 相比，它则支持更多的发行版。这个项目是我在 2012 年以 Magic Linux 的 mgc_win 为灵感和原型提出并设计开发的，从我一开始用在竞赛里学到的 Pascal 加上 Delphi 开发，到使用 Windows CMD 批处理处理整套流程，到用 C 语言重写，直到我 15 年准备高考，这个项目因为无人维护而搁置。16 年到 17 年我还有断断续续的写一些代码验证 EFI 平台的可用性，但是现在明显是一个我挖的的坑了（笑）。
• 18.3: LinkC 是一款设计为完全去中心化的 P2P 聊天软件。
  • LinkC 项目作者认为自由不受约束限制的通讯应该是存在的，加上当时 Linux 用户对 IM 软件的呼声较高，因此 LinkC 作为一种代替 QQ 的客户端出现了。伴随着这个项目的是它所搭载的新一代通讯协议 Gurgle。Gurgle 类似于 XMPP 可以跨域聊天，并基于全新设计的二进制 JSON 格式 JKSN，能以更小的数据体积传输数据。然而实际情况是，LinkC 的理论基础不成熟，其作者认为完全的去中心化并不现实，加上 Gurgle 项目最终认为 Protobuf 还是比较好用，这两个项目就停止开发了。LinkC 和 Gurgle 可能是 AOSC 代码量最高的项目之一。
• 18.4: Auch 的全称是 AOSC Unified Configuration Helper，它要解决的是应用容器化的问题。
  • 简单来讲，类似于 macOS，软件包会被分成 App。每个 App 在运行的时候，Auch 驱动会给它提供一个虚拟的根目录（rootfs）。这样，每个程序启动之后它看见的文件系统就是由它和它的依赖组成的一个虚拟的文件系统。不过 Auch 的设计不止于此。Auch 不是要在 App 启动时真的去创建这些目录和文件，而是根据 App 来查询它需要哪些文件。而这个发行版本身是没有真正的根文件系统的，对系统来说，所谓的 Root 不过放着一个装着应用需要什么的数据库和 Auch 的守护进程而已。总得来讲，Everything is virtual。

Slide 19

• （如果有人对上面项目感兴趣的话我们还是很欢迎大家参与的）
• 那么接下来我们想谈一谈我们在这次学生开源年会想要说的最主要的话题，就是社区文化以及我们对开源社区文化的一些微小的见解。
• 社区不只是个网上聊天群组或论坛，当然也不仅限于一个群组，我们认为它应该有更多的属于它自己的含义。
• 五年来我们有意无意地思考这样一个问题：组建这样一个开源社区的意义是什么？对社区成员来说，社区首先是一个兴趣空间，其次是一个实验空间，再者是一个学习空间。所有的参与者首先因为兴趣或围观打酱油，或参与到社区的日常事务中来。其次，社区成员可能希望改进社区的现有项目或借助社区资源进行新项目的研发，那么这部分就会进而发展出实验项目。再者，开源社区聚集了不少行业先进的技术和人才，成员还可以借助社区这个平台接触不同方向的开发者，相互学习。
• 尽管如此，和一般的编程交流群不同，社区本身需要立足于一个集体共有且共同承认的文化，因为它本身承载了一定的使命，它是围绕一个或多个实际项目组建起来的开发者聚集体，是先有的实际项目，才有的社区。对于开源社区而言，这一点尤其显而易见。
• 安同开源社区随着时间推移，当然也发展了一套属于自己的文化。稍后我们会提到我们自己的文化要素。

Slide 20

• 我们两个作为 AOSC 相当长时间的社区成员，从主观角度上也对我们社区的文化和特征有一定的理解。在下面几页谈到的事情很多都是根据我们个人及许多社区新老成员交流中得到的几点概括，就在这里介绍一下。
• 首先，作为一个开源社区，我们致力于用自己的技术能力和兴趣来改善开源及自由软件在个人计算机的日常使用中的可用性和质量。本着这样的一个基本目标，我们社区尊崇以技术为先，以能力说话，而且相当重视技术工作上的行为道德，这包括：技术讨论基于准确和科学的信息，参与社区项目时保全许可和版权所有权，最后，社区技术不与政治和其他无关基准挂钩。
• 其次，我们重视社区本身的性质，这主要体现在“以友好为先”及“以兴趣为本”两点上。
• AOSC 的历史上，我们对社区成员之间的关系一直追求这两个原则。社区成员之间互相的尊重只是基础。我们追求的是，社区成员们能通过多元的社区参与方式建立友谊，并且可以在技术工作内外形成信任和互助。我认为这是 AOSC 能以纯粹的社区形式存在接近一载的一点重要特性，我们不仅保证了技术工作，我们还在这个过程中成为了朋友，在社区中真正找到了归属感，无论工作还是闲时，都能在这个互联网上的群体中找到快乐。
• 至于“兴趣”，这更多体现在我们的“运营”模式上，“运营”这词可能不合适，不过实在词穷（笑）。我们在社区“运营”及参与上有两个“零”的原则，那就是零报酬和零经费。我们认为，参与 AOSC 的最大目的是找到一个有共同目标和看法的群体，而不是从中获取什么实际的物质利益。作为一个通过业余时间参与组织起来的社区，我们认为金钱和物质的追求将破坏我们的团结性且不必要地将社区生活复杂化。零经费方面的思路是类似的，我们承认社区不可能不依靠金钱生存，但是我们也反对让社区成为一个基于资本运作的群体。根据这个原则，AOSC 接受实际的服务赞助（如网站服务器、域名及证书等）、硬件捐助，但是我们不接受任何实际的金钱捐助——我们没有具体的财政管理细则，也不会去追求这样的一个细则。
• 如此原则的弊端也是明显的，这最明显地体现在我们每年的社区聚会，AOSCC 上。首先，线下聚会需要实际的场所，而在这个原则下我们必须借助高校的支持来得到场地，任何纪念品（比如我们社区内比较出名的 AOSCC 贴纸集，包含各种社区圈内梗和笑话）也需要自费去定做和购买。但是总的来说我们认为，社区额外活动和纪念品等同于志愿性的社区参与，应当借助于志愿的支持，这样才能从各方面以均等的方式来保证社区生活的简洁和最大化的透明度。
• 社区虽然定义上是一个自由参与的团体，但是毕竟有定义就有边界，我们社区也遵循“有限包容”的原则。综上所述，我们首要接纳的是对针对开源及/或自由软件的技术学习和应用有兴趣的人群。而从社区文化上，我们鼓励辩证且实用地看待各种类型的软件，包括开源、自由、专有、商用等类型的软件，而不是一味地以一个政治团体一般的身份来拒绝承认各种软件的利弊和纯粹的优劣之分——我们认为合适使用的软件就是应该鼓励使用的软件，但是我们的兴趣依然驱使我们去改善自由和开源软件。
• 但是在社区的边界内我们也对一些特定话题和行为有制约和禁止。我们社区，至少在技术工作范围内禁止一切的政治讨论，也禁止对我们社区和其代表的形象进行政治定性——这包括对社区的国籍进行定义或以社区名义发表任何的政治信息，无论是已知的通识内容还是观点。在社区的水群及其他休闲地点，我们也只允许了对政治话题的讨论和辩论，其他行为依然是明令禁止的。
• 当然，我们社区的文化不只是在这些方面体现的，我们社区的很多其他共同观点和特殊活动也进一步形成了 AOSC 这个社区的形象和我们作为社区成员的自我辨识。在接下来几页我们还会进一步讨论。

Slide 21

• 在总结一些基本的社区文化和组织原则的同时，我们的社区也时有对其他所谓“一般开源社区”进行观察并总结其经验和教训。我们社区也在这个过程中对开源社区组织和运行的某些方面总结了自己的一些观点，我们在此简要介绍几点。
• 相当数量的开源或自由软件都会在自己的许可文本或程序警告中显示 ABSOLUTELY NO WARRANTY，即不提供任何担保。我们虽然能认可这种行为，但是我们认为开发者作为社区一员，考虑到他们对社区成员的服务性质，我们认为社区应当鼓励开发者在力所能及之处负责任地维护和解决用户遇到的问题。这个我们会在稍后详细解释。
• 从 AOSC OS 本身看，社区也应该保障软件的使用和选择自由。相当多的发行版由于哲学或法律原因会尽可能去选用自由软件来满足系统的各种功能，这无可厚非。但是我们认为一味地拒绝不自由的开源软件或专有甚至商业软件破坏了用户的选择自由，我们希望给用户提供尽可能完善的工具集并尽可能地发挥他们所持有设备的功能性，而尽可能宽容地去看待和合乎许可地引入软件是达到这个目标的重要途径。
• 最后一个例子是社区和上游项目或社区的交互。上面提到过我们社区对上游作出本地化贡献，这点我们不再赘述，简单说就是我们作为下游社区，贡献上游应作为我们的责任和道德需求；而对于我们的用户，贡献上游并改善上游项目是我们进一步改善用户体验和支持的基础。

Slide 22

• 和许多其他开源社区一样，AOSC 的开发者同时是社区成员。可能和社区近几年来的外联方式有关系，许多来到社区的成员多少有一定的技术基础且对参与到社区项目有兴趣。贡献和参与的方式多种多样，从报告问题，创建项目，Pull Requests 再到参与到忙碌的 AOSC OS 日常维护中——其中 AOSC OS 的例子可以说是相当幽默和无奈，社区中常有的一个梗是这么说的，“AOSC OS 的用户同时处于开发者和用户的叠加态，只要在遇到问题的时候就会坍缩成其中一种形态”。用户没有开发者多，自然保证了用户能及时得到支持，这当然是个问题，但是也不失为一个有趣的现象。总的来说，我们社区最幸运的是有一群相当积极的成员在志愿维持社区的项目。
• 我们社区的开发者以志愿者身份参与工作，自然也能免于服务用户及承担各种损失责任的义务。但是我们认为单纯以这个原则来处理社区中的开发者和用户角色将不可避免地造成两者之间的隔阂。
• 我们认为在一些开源社区中开发者的的基本责任心可能被过度淡化，其结果就是用户觉得总是找不到开发者，或者说找开发者并不能解决问题，而开发者似乎也以用户的报告为负担或者消极对待，形成一个恶性循环。许多开源及自由软件项目总有一个问题存在多年却无人着手解决的问题，这也包括 AOSC，这是我们需要努力解决的问题。
• 所以从社区角度，我们鼓励开发者在自己的时间和精力允许范围内保障用户能正常使用并受益于社区项目，而开发者也应认识到用户选择社区项目的过程（尤其在 AOSC OS 的例子中）实际上是用户在牺牲自己的时间来适应一个新的工具——简单说，鼓励开发者与用户互相尊重对方的时间和精力，是这个观点的基础。

Slide 23

• 因此，我们更多地认为，社区是一个多元而无统一责任划分的群体。我们认为，社区成员知道他们要做什么。一名社区成员可以是一名开发者，那么他自然对对应的项目有维护的责任。但是如果一名开发者突然感到累了，不想做了，那么他不需要理由来退出开发的工作，然后他可以选择成为用户或以其他方式参与到社区生活中。但是如果这个用户哪天发现了项目可以改进的地方，那么他不需要理由来重新加入开发工作；他既可以向现有的开发者提出问题，开 Issue，也可以直接向对应代码仓库发 Pull Request，或者重新成为一名活跃开发者。对于社区来说，谁来开发不重要，重要的是开发的人对项目有兴趣。我们觉得社区成员至少不应该在他们的兴趣空间中受到束缚。
• 在安同开源社区，我们相信社区可为其成员所用，也就是说社区作为一个承载项目和开发者的平台应该充分鼓励成员之间的交流和自由活动。社区也不仅仅是一个工作和使用交流的平台，正如我们刚才提到的，它可以是聚集并提供开发灵感或者其它灵感的来源，它可以是大家施展身手的平台，它也可以是一个接触新技术、接触行业的地方。因此，社区同时也应是一个值得其成员信赖和喜爱的活动空间。这些都是我们一贯认为的开源社区的文化方针。

Slide 24

• 标题中我们提到了“大社团”这么一个词，在这里简短讨论一下。我们认为 AOSC 作为一个社区应当更多去尊重一个开放和自由的氛围，而不是一味以民主原则为保障社区组织和文化的单一途径。具体说，那就是社区应当以开放的态度对待其新老成员和项目，并充分保障各种点子和观点思路的自由传播，让社区的大门敞开，并让新加入的成员能感受到包容的氛围，并敢于提出自己的想法。这样一来，社区提供了类似于无权力结构的校园社团的平台，这样一个“大社团”里的各位成员能够提出自己的想法并自主地组织活动，体现为不同的项目和短期目标等等，这是我们社区组织的宗旨之一。
• 而至于“议会”，社区日常活动中不可避免地需要进行讨论和决策这两种活动。这个时候社区需要营造一种类似传统双边议会的氛围，鼓励正反两方的观点交流和辩论。但注意以相互尊重为原则，以专业态度去对待和发表议论。在我们社区，激烈的争论时有发生，但是我们社区的成员们往往保持住上述两点原则，不仅激发了社区的参与和思维活性，利用了成员的不同技能和专长，而且在大多数情况下争论的结果往往是和平且具有建设性的，这对社区整体来说属于一种激发生产力的活动。

Slide 25

• 撇开严肃的开发相关的话题，聚集在一起的大家不免想要交流和开发无关的事情，也就是大家常说的“水群”了。安同开源社区除了注重社区参与，也希望大家能愉快地分享自己生活的乐趣。从这样一个机制同时保障了社区成员工作和娱乐的需求，也从此形成了两个子文化，一个是上述社区组织和工作的文化，而另一个是社区成员之间一种幽默和轻松的文化。
• 当然了，在安同开源社区，大家最熟悉的就是各种各样的“梗”，也就是段子了。安同开源社区有着深厚的梗文化和对此的认同感，任何人在任何时间都在产生段子，大家随意调侃的话都会成为大家津津乐道的语录。
• 如果大家访问安同开源社区的主页 aosc.io，在 Banner 上就有一个滚动的梗栏目。我们还有一个专门的 Telegram 频道记录社区频道里大家无意说出的梗。当然了，对于初识安同开源社区的新人来说，碰到这么多的梗未免感觉被水淹没，因为梗都是基于一定的情况和知识发展而来的，比如说这篇 Unix 新说：……这是社区一名成员对 systemd 的评价，它当然是要吐嘈 systemd 的大一统，但是 systemd 仍然成为了 Linux 发行版中的主流，这就很耐人寻味了。

Slide 26

• 最后在这里卖个广告，欢迎大家来 AOSC 转转，也许我们就会这样成为社区中的伙伴。AOSC 时刻欢迎你们的参与和贡献。
• 上面列出的几个玩笑，多是在概括社区的几个文化特征。如果各位对这里任何一条感到好奇，欢迎来到我们的社区摊位交流——如果你昨天来访过我们的摊位，你大概已经对这几条有所了解。我们的社区总是包容而原则分明，认真专业却不失乐趣，这也是我们社区在这几年来虽然面对诸多挑战和变数却能保持至今的原因。大家乐于参与社区活动，这是我们社区最耐用和高效的燃料。

Slide 27

• 我们的社区组织大多基于线上活动，欢迎各位通过我们社区的诸多设施和渠道来认识些新伙伴。
• 除此之外，我们社区每年都会尝试组织一个名为 AOSCC 或 AOSC Conference 的线下聚会活动，一般于七月中旬在国内某个投票决定的城市中院校举行，历时三天，不需门票，还有免费的 AOSCC 贴纸集可供获取。我们在社区摊位准备了一些去年 AOSCC 派发的贴纸集，欢迎领取。
• 可惜的是，由于不可抗因素，各院校对外校活动审批严格，我们也无法在原来投票决定的武汉举行这次聚会。明年的聚会地点和 AOSCC 的其他活动和讨论将在我们的社区 Telegram/IRC 群组进行，欢迎参与。

Slide 28

• 如果各位有任何疑问和异议，请尽情提出来。Ask Me Anything.
• 如果各位有谁没能及时发言，欢迎来到我们的摊位或考虑在后面十分钟的休息时间和我们继续讨论。
• 本次演讲的幻灯片和我们的讲稿原文可以通过 aosc.io/soscon 获取，欢迎对我们本次自我介绍提出意见和批评，感谢大家能到来捧场。