点击以下链接收听本期 “大咖访谈” 播客，与大咖面对面：
大咖访谈链接：EP15：林旅强 | AI+开源时代 - 开发者与治理者的机遇与挑战
刘天栋：访谈主持，开源雨林顾问，开源社联合创始人，Apache 软件基金会正式成员
林旅强：访谈嘉宾，开源社联合创始人、前华为云 AI 开发者生态总监、《开发者关系：方法与实践》译者
职业生涯的探索与挑战
请您先简单介绍一下自己
林旅强：大家好，我是 Richard 林旅强，投身在开源开发者领域已有 15 年，最早是在台湾的中央研究院，主要研究开源的知识产权，以及开源治理，后来也从事了社区运营、开源布道的一些工作。2013 年，我在台湾的开源人年会 COSCUP 中，结识了上海 Linux User Group 的 Thomas 姚欣宇，在他邀请之下来到大陆，加入他的创业项目 GitCafe，我在 GitCafe 时结识了许多企业的开源人，包括与 Ted（刘天栋）认识，以及 CSDN 的蒋涛，还有 GNOME.Asia 的朋友，后来我们一起创建了开源社。
2016年，我加入了华为，希望能通过具体的工作，将开源以及开发者生态落实到大型企业之中。在华为我担任过华为开发者社区总监、华为 LiteOS 开源总监，以及华为云 AI 开发者生态总监。今年年中我离开了华为，现在是一名 Freelancer（自由职业者），主要提供开源战略、开发者关系的企业培训与顾问服务，希望贡献更多的力量，让中国开源开发者生态的土壤更加肥沃。
除了以上的介绍外，您同时还是一个翻译者、音乐人，能够分享一下您的职业/自我实现的路径规划吗？
林旅强：大家都说“职业规划”，但我的职业其实没有所谓的“规划”，“规划”这个词我认为是代表能看得到未来——譬如说做一个医生/会计师/律师……这些行业存在非常久，因此是能够被规划出来。而我作为一个最早投身开源开发者领域的老兵，在当时的任何时候往未来看，都看不清楚，因此我的职业选择中真正要做的事情是：发现自己的天赋，验证自己的能力，设定一些项目与挑战，一次一次在这过程中做出一些选择，然后去感知自身能力的边界。举些例子：
在高三毕业那年的暑假，我就开始尝试写网页，当时 2001、02 年是全球互联网的爆发时期，Web 1. 0 的年代，正如我们今天的 AI 。我感觉互联网就是未来，所以就去买些书来自学 html 之类的，我当时其实是个文科生，但我愿意做一些挑战。
我另外一个爱好是 “BBS”（Bulletin Board System，电子布告栏系统），当时台湾最知名的叫做 “PTT”，我曾当过 PTT 某些版块的版主，因此很早就知道如何发帖、回帖、编辑精华区文档、以及组织社区成员一同来进行维护。虽然它并不是一个开源项目，但它完全是以开源之道来运作，这积累了我开源的相关经验。
我大学的专业是法律，当时恰好得知，中央研究院里的开源办公室正在招聘开源相关法务，主要研究知识产权，这非常符合我的一些经历，相较于其他法律系的毕业生，我更了解软件社区，因此顺利入职。坦白说，当年心里非常惶恐，因为当时的我并不是律师（考过律师但没考上 :( ），而且我也不是程序员，那我以后应该做什么工作？懂开源又有何用？总之内心是比较迷茫的，但我就认定一件事：有兴趣那就继续做。直到社会上有需求了，机会就找到了我。
说到入职华为，它同样也不是被规划出来的。2015 年，华为召开了第一届的开发者大会，它的 Keynote 邀请了当时 GitHub 的 CEO 进行演讲，所以我就关注到这家公司，了解到他们开始做开发者生态的业务。同年开源社和 Apache 软件基金会联合举办了 Apache Roadshow - China，在这个大会中，华为的人告诉我有部门正在找开发者社区运营专家，而我当时也正好在寻找新机会，一拍即合，经过快速的面试流程，一个月后我入职华为。所以说这职业是规划出来的吗？我觉得运气成分居多。
而翻译这件事，我并不是英文/翻译专业的，也没有留过洋，在我为开发者关系工作的这些年，却发现中国连一本专门谈开发者关系的书都没有，作为这个领域的人，我认为我需要做些什么，于是我跟人民邮电出版社合作，挑选了《开发者关系：方法与实践》这本书进行翻译。今年这本书出版之后，很多人告诉我，因为这本书，他们对开发者关系理解更为透彻了，这让我为自己的贡献感到值得与满足。所以这并不是职业的发展，而是我知道我做什么事情能够激发我底层需求，正如“马斯洛理论”那样，最终达到自我实现，如果有幸能够找到自我实现的点，且生活还过得去，我认为这是一件很幸运的事。
所以在我的观点里，人生的职业路径不是计划出来的，而是经过不断尝试、有机生产出来的。
AI 与开源
您是如何看待 “AI+开源” 的？它为人类社会带来什么机遇与挑战？
林旅强：AI 是一种能力，但这个能力不单纯只依赖代码，而是会带有一些场景下的智能，它可以替代部分人类的工作；而开源是一种分享、一种共同协作的方式，让更多的人可以通过社区，然后来一起来共建。所以在我看来，“AI+开源” 应该是：我们是否能够通过开源的方法论、开源的社区、开源的模式，让 AI 这件事情变得更好。
如果要开发一款有 AI 能力的产品，你会如何做？要么是调一个 AI 的 API，要么做一个现成的模型。如果是做一个车牌识别，或者人脸识别，目前已有很多现成的 API 可使用，但是 AI 现在最大的问题就是碎片化（这里先不谈 LLM 大语言模型），之前的 AI，例如 CV 类、或者是知识图谱、 NLP 等，没有现成的模型可以用，所以需要优质的数据、充分的算力、以及合适的算法来进行模型的训练，模型训练好了之后，还需要有部署的资源，而且还要迭代，持续优化产品来确保软件的竞争力。
而现在虽然主流的 AI 框架和算法大多都已经开源了，例如 PyTorch ，或者是国内的 Paddle Paddle、MindSpore ……可是其中的数据本身并不开源，训练出来的模型也是私有财产，即使算法是开源的，但微调（fine tuning）也是各个炼丹师的秘方，我们很清楚，这些都不容易要求大家公开出来。
比如说数据，企业认为数据是公司的资产，站在营利的角度，也不应该随便开放出去；另一方面，数据包含个人信息的隐私问题，所以数据开源还真不像代码这样单纯。
同时，如果要共享训练出来的模型，也无法做得与代码一样方便：代码有 Git、DIFF 这样的版本控制方式，而模型太大了，不仅托管成本会高出很多，且不容易做版本控制，因为模型是训练后的成果，就如同源代码经过编译之后的二进制可执行文档，因此我更难想象要如何进行协作。
但在今年，LLM 大语言模型开始风靡全球，提升了 AI 的能力与应用，随着 Meta 的 Llama 2 出台，我们看到了开源大模型未来的机会，虽然 Llama 2 的开源与典型开源定义不太一样，但在我看来，企业在 AI 大模型的开源之路上，运用新的开源模式来进行尝试并无不可，之前我在朋友圈就评论了这件事，我说这个就叫“一个开源，各自表述”——你的是开源，我的也是开源，但是双方意见略有不同。
总而言之，开源的共享、共建、贡献的精神要落地到 AI，中间还有很长的一段路要走，但我认为我们已经在这条路上了，对于这件事我是很乐观的，过去 25 年，开放源代码运动已经证明了开源模式的可行性，而随着各个机构的开发者不断尝试，AI 领域的开源一定能找到解法。
AI时代的开发者关系
“AI+开源” 的时代，企业应该如何看待开发者关系？
林旅强：什么是开发者关系？正如政府关系、公共关系（所谓的公关）、客户关系，甚至投资人关系等等，开发者关系也就是要与开发者建立一定的关系，这是企业制胜的关键。
产品服务本质是提供产品服务给到消费者，而如果在这个过程中有开发者的参与，产品能够有更好的竞争力，例如微信，微信提供 SDK API，让开发者能够在上面做小程序以及各式功能，从而使得微信能更好地提供实时通信和产品服务给用户，由此可见，有了开发者的加入，产品服务能做得更好。
那如何让开发者愿意加入呢？核心点就是开发者体验，这也是开发者关系的核心。围绕开发者体验，做好开发者营销、开发者支持、开发者成功三个模块，在此基础上建立一个强健的开发者社区。
正如前面所述，开发者体验是关键，而 AI 能够让开发者体验变得更好，因此企业应该善用 AI 来提升开发者体验，在提供给开发者的服务/工具当中，把 AI 的能力尽早给加上。举个例子，以前开发者有很多问题时，往往会通过浏览器搜索，或者官方论坛查找来获取答案，现在回头想想，如果之前我在华为负责官方的 AI 开发者社区论坛时，我能够做一个 AI 的 agent，它非常了解华为所有 AI 产品，这时候开发者在上面问一个问题，那可以很快地就能得到答案，虽然回复的人不是一个真人，而是个 AI，但是这个 AI 是为这个社区服务，别人也通过这个 AI 得到更好的服务，那我们就可以把注意力放在如何帮助开发者成功这样的事务上。
另一部分，内容运营。AI 火了之后，很多人认为内容可能就不太重要了，之前看过一张图，说的是 GitHub 的流量发展与 Stack Overflow 的流量发展，很有趣的是，在 ChatGPT 火了之后，GitHub 流量开始往上走，说明越来越多人写代码了，或是越来越多人用 AI 写代码了，而 Stack Overflow 的流量在往下走，大家好像不再需要 Stack Overflow，它的数据被 AI 大模型“吃”进去训练了，因此大家可以直接问 AI，而不需要再筛选模型背后的数据。这对于 Stack Overflow 来说是悲观的，但站在企业的角度，如果企业想要做开发者关系，反而更应该做好内容运营，并且还要想办法把这些内容通过更好的方式做出来：虽然整体社区内容的产量在下降，但 AI 产出的垃圾内容数量在上升，未来几乎各家都在做大模型，一定会用某种方式来吸收优质内容，从而避免给大模型 “喂养” 这些“垃圾”。
总而言之，如果企业能提供开发者更好的工具，让他更省心省事，用更少的力量做出更棒的东西，那他就会加入。所以在开发者关系上面，重点还是产品能力是否结合/善用 AI 的能力。
反过来看，您对开发者未来的技能以及职业发展有何看法？
林旅强：针对开发者个人来讲，在 AIGC 的浪潮之下如何提升自己的能力？
首先第一点：熟悉且善用 AI，而且对它要有“健康的恐惧”。在新的产业浪潮之下，未来如何谁都不知道，所以一定会有恐惧，但不能当一只鸵鸟，封闭自己。
我最近看到一个数据：ChatGPT 在一两个月内就达到了1亿个用户，月活也非常好，但是从今年第二到第三季度，整个流量开始往下走。而在我看来，能够很熟练使用的 ChatGPT 的人，与只是玩两下就不用的人，两者最后的差距是逐渐变大的，因为这一类的 AI 产品现在还在早期阶段，在未来很有可能会进行各种集成，比如 Copilot、Adobe、office……所以我认为未来是一个“超级个体”的年代。
什么叫超级个体？当一个人懂得善用工具的时候，生产力会得到一定的提升，比如我父亲那一辈的人会用电脑的与不会用电脑的，或者我爷爷奶奶那一辈识字的与不识字的，到了我们这一辈，除了会用电脑、会讲英文之外，AI 就成了另一个好的工具，而且 AI 就像一个 bot，我们可以养很多个，一个人背后就可以有千军万马，甚至变成一个超级个体。所以开发者未来的职业发展，首先一定要善用 AI。
第二点：不依赖 AI，而是善用它、超前它，并给予一定指导。不要认为代码只有一行一行写出来的才是好代码，虽然现在有很多烂代码是用 AI 生成的，但这只是现在的五年、十年，而 5 - 10 年之后的未来，我们是否还会像现在这样子呢？
最后一点：在技术方面继续追求高标准。AIGC 的到来降低了开发门槛，开发者越来越多，会有一些非典型开发者，例如产品经理+开发者，或者是艺术家+开发者，甚至是会计师+开发者、律师+开发者等等，开发者的背景与能力的组合将会更加多元。这对典型的开发者来说是件好事，那些非典型开发者无论如何，他们的开发技术也不会比专业的开发者还高，所以最顶尖的技术以及最好的实践经验，才是技术型开发者未来安身立命之道。
人工智能与开源治理
现在欧盟、美国制定了很多人工智能与开源相关的法案，您对欧盟人工智能法案、以及中国的生成式人工智能管理办法和未来发展，有何看法？
林旅强：欧盟的人工智能法案让我想到当年 GDPR 成型之前也是做了各种讨论，欧盟的逻辑很简单，就是以保障人权为第一要求，将各种问题与风险进行分级，这一次的人工智能法案，就是把不可接受的风险和高的风险这两个东西特别提取出来，事前做审查。而欧盟在隐私权法的考虑，GDPR 也一模一样，所以很多企业会认为欧盟的规定很严格。
将欧洲、美国、中国/东方国家三者作比较，美国属于比较放任型的，这可能也与国家的逻辑有关：美国遵从技术先行，关注技术利益，红线是国家安全，当然美国也讲人权，但如果部分有人权疑虑的时候（不是说实质侵犯），会让技术先行。在我看来，美国对技术开放的容忍度是非常高的，欧洲相对较为保守；美国比较强势，会用行业自治的方式来解决问题，而欧盟更喜欢制定一套标准。中国在人工智能治理的未来发展，模式上跟欧盟是相近的，所以我觉得对于技术发展来说，欧盟的逻辑会是一个刹车，对社会适应性会比较好。总而言之，技术是为谁服务？为产业、为股东服务，还是为国家、为国民服务？还是为人类、为全世界服务？这是一个价值衡量的判断，各个国家会有不同的选择，然后各自努力、相互竞争，胜出者赢。
从中国过去的产业结构来看，属于不管理就会乱，严格管理就会萎缩，所以我的建议是现在可以管但不要管的太紧，尤其是 LLM 这类东西，它会产出很多内容，本身中国在内容方面有一定要求与规范，所以我建议是尽量在无伤大雅之处更加的大胆，在绝对红线的地方设警，分清红线，不应有灰色地带。
开源雨林：多元与共生
您对开源雨林有什么建议？接下来期望开源雨林能做哪些事情？
林旅强：我第一次听到开源雨林的时候，我还在华为公司任职。雨林是一个生态的概念，有不同的物种栖息在这里，而我认为开源人的 diversity 也非常高，所以我会期望开源雨林能够让我们这些开源人能够有一些互相连接的可能，甚至我觉得可以有更分布式的一些做法，比如说线下的 Meetup、线上的语音会议等，能够与大家一起互动，我希望能在开源雨林里看到更多不一样的世界、听到更多不一样的声音。
—End—
开源雨林围绕开源通识、开源使用、开源贡献三大方面构建知识体系，愿把长期积累的经验系统化分享给企业，在团队、机制、项目三方面提供合作，推动各企业更高效地使用开源、贡献开源，提升全行业开源技术与应用水平。
开源雨林的内容已开源，并托管在 https://github.com/opensource-rainforest/osr ，欢迎通过 Pull Request 的形式贡献内容，通过 Issue 的形式展开讨论，共同维护开源雨林的内容。
