Apache 基金会创始成员访谈录 ———— 回顾 Apache 20年历程！
Thu Jan 9, 2020 | 8600 Words | 大约需要阅读 18 分钟 | |
引言
刚刚过去的2019年是 Apache 基金会成立的20周年，来自Apache 基金会的 Sally Khudairi搞了一件事，那就是找找当年的创始成员，除了祝贺之外，就是想听听这些人是持什么样的态度。
Sameer Parekh Brenn, Mark Cox, Lars Eilebrecht, Jim Jagielski, Aram Mirzadeh, Bill Stoddard, Randy Terbush, and Dirk-Willem van Gulik,
问题：你第一次参与Apache HTTP 服务是什么时间？做什么？
Mark：
1993年，我还在读博士，当时为 NCSA web 服务撰写一些特性以及修复一些Bug，而且也会做一些安全方面的工作，在1995年四月我收到了 Brian Behlendorf 的邀请，他希望我加入到 Apache 的核心开发团队中，其实大家都是那时候的参与进去的， Apache 开发小组才刚刚成立了几周不到。
Randy：
起先我是遇到了一些均使用 NCSA web 服务的小伙伴们，如果我没有记错的话，在1994年末，我开始和其他人交换一些想法和补丁，从而使得 NCSA web 服务能够满足日益增长的扩展服务。
Dirk:
我本人在 NCSA web 服务的早期阶段就开始参与了，当时我在研究所工作，当时需要一些特定的功能，如希望可以将巨大的卫星图像上较小的地理子集能够作为图像提供，这样的方式对于当时来说还有些新奇的，因为当时正常的做法是：填写表格 -> 发传真过去 -> 等上几个月，直到索大的胶带盒子送到 -> 然后，将需要数周或数月的时间来加载这些磁带并仅提取所需的区域。于是顺其自然的就参与到 Apache中来了。
Jim:
是在1995年，起初是将之移植到 Apple 的旧的Unix 系统、A/UX上，写些补丁、增加些功能、修复bug，也会做些配置和构建工作。
Lars：
时间大约是在1995年前后，我当时还是学生，对 Unix 和互联网，尤其是 Web 服务器产生了浓厚的兴趣，当时我为锡根大学（德国）建立了第一个官方站点，开始的时候，我们并没有采用Apache，但是没有多久，我们就意识到 Apache 才是真正代表未来的web 服务器，于是我开始在各种在线论坛上帮助其他 Apache 用户，大约一年后，一家德国出版公司请我撰写有关Apache HTTP Server的文章，并结集在1998年出版了。
Sameer：
我开始参与的时候，是意识到了开源的 HTTP 服务支持SSL的市场潜力，那时候，其实 Ben Laurie 开发了一个 Apache-SSL ，但是因为专利限制无法在美国境内使用，于是我所在的公司另外开发了一套。
Bill:
那是1997年，我刚刚成为IBM Lotus Domino Go Web(LDGW)服务器的首席程序员。LDGW 有着很强的增强需求，基础代码却很脆弱，而且当时的 HTTP 服务也没有商业利润了，在探索继续进行 LDGW 开发的替代方法后，我们发现 Apache HTTP Server 几乎具备了所需的一切，而且非常稳定。当时对于 IBM 来说，使用开源项目是有着巨大优势的。
Aram:
大约是90年代后期了，我将 Apache HTTPD v1 迁移到了 Linux 和 SCO Unix上，而且还维护了一个教用户如何设置IP虚拟主机的教程站点。
问：您是如何加入到最初的 Apache Group 的？
Dirk：
卫星图片都是非常大的，而我们的科研人员需要的是某一小部分，而在获取的过程中又非常的繁琐，因为考虑到安全的因素。而当时的NCSA服务器或CERN的数据服务器都不满足这些，于是我就另辟蹊径了。
Randy：
对我来讲参与是顺其自然的事情：讨厌 Usenet，希望和同样的人们的一起来挑战它。
Aram：
我曾经为NCSA 发送了一些提交内容，但是被拒绝了，但是我同时听到有部分人离开了 NCSA，要启动一个全新的项目，当然，在移植到Linux和SCO 是有一段被认可的过程的，但是没有关系，我本来的工作就是做这个的。
Sameer：
当我参与到 SSL 方面的内容时，就开始参与其中了。
Lars：
1997年，我出版了关于Apache HTTPD server 的第一本德文书，在为 Apache 撰写文档和测试功能的时候，遇到了一些问题和 bug，然后就向 Apache Group提交了自己修复的问题和补丁。过了一段时间，我想是其他成员厌倦了我频繁的发送错误报告并修复，就邀请我做 Apache Group 的成员……因为这样的话，我就可以自己直接修复了。
Bill：
Apache Group 刚成立的时候，在主页上表明是欢迎商业公司参与到项目中来的，（当然现在也是），这就为时任产品经理的 James Barry 和 一位 IBM STSM：Yin Ping Shan 打开了通道，他们联系了Brian Behlendorf ，并商讨了IBM参与该项目的可能性。不久之后，我有机会和Brian一起聊天了，我被任命为唯一的IBM开发人员，参与到这个开源共同体当中来，我是否提到了IBM对开放源代码的恐惧？这在当时是非常奇怪的事情，我在开发IBM未来的专有软件产品，受雇于IBM，人却在开源共同体工作。
问：您是什么时候第一次与Apache Group的其他成员见面的？感觉如何？
Sameer:
我和 Brian 是 UC Berkeley 的校友，在加入 Apache Group 之前，我们就彼此相识。
Randy:
我第一次和其他成员面对面见面是在 Brian Behlendorf 在旧金山的公寓里，很多人都帮助过我。
Bill:
1998年在旧金山举办的 ApacheCon 会议上。
Jim:
在首次的 ApacheCon 上见到了其他成员。我居住在美国的东海岸（现在也在），而其他成员不是在西海岸，就是靠近西海岸，要么就是远在欧洲。然而最令人陶醉的是，在 ApacheCon 之前我们从来没有见过面，但是在那次会上，我们首次相逢犹如多年的好友，没有丝毫的违和感。
Mark:
IBM于1998年在加利福尼亚赞助了我们的聚会。在那之前，我们仅通过邮件进行交流，面对面的沟通，加深了我们对彼此的了解和兴趣所在，那次见面也为后来成立法律上的实体建立了基础。
[photos attribution (CC BY) Mark Cox. Gallery at https://www.flickr.com/photos/iamamoose/albums/1381277/with/63963566/]
Lars:
1998年首次举办的 ApacheCon 上，那时我刚刚硕士毕业，也是首次来美国，非常荣幸的和Apache 的核心开发人员有一张照片留念。（记得向大家展示哦！）
[photo attribution (CC BY) Mark Cox. Tagged image at https://www.flickr.com/photos/iamamoose/63963722/in/album-1381277/ ; gallery at https://www.flickr.com/photos/iamamoose/albums/1381277]
Drik:
水到渠成的感觉，要知道我们彼此已经打交道好多年了，都是围绕一件事情展开的。几分钟适当的适应下面孔，再花点时间，适应一下英语的口音和发音，毕竟书面上的交流，是看不出对方是否是生活在英语系的国家和地区的。令人蛮惊奇的是，听着他们的口音，也越发觉得他们的邮件里也带着浓重的乡音了，反而面孔则是较为次要的事情了。
Aram:
在我参加 Apache 研讨会之前的某段时间，地点应是在佛罗里达，2000你那之前的事了，匿名（因为我没有任何其他在线个人资料）并被人知道是一种很奇怪的感觉。我把我的名字标签藏在走动的衬衫里，在餐桌会议上，我站在一边，让其他人提问，我并不确定其他人认识我。
问：是什么原因促使 Apache Group 成立为 ASF？这个决定花了多久？
Jim:
随着互联网和 web 技术的日益发展，也日渐稳固，我们都意识到需要较为正式法律给我们提供更多的保护。另外还有一个可能原因，当时，IBM 有意采用 Apache HTTPD 作为其web服务的基石，IBM 对于”江湖“气味颇浓的”Apache Group“是有些担心的，可以说是千载难逢的机会，既有形势的需要，又有如此势力雄厚的盟友助阵，所以，我们没用多久就促成了这次成立基金会的事宜。
Drik:
我们是基于 NCSA 服务的，我们只是在其原有的基础上修修补补，因此，在当 NCSA 的一些核心人物离开小组跑到 Netscape 时，我们需要考虑可能的出路。与此同时，web的市场也开始火爆起来了，Apache 正在形成市场上事实上的主导者，此时微软也杀入了，SSL安全所需的加密实现也引起了监管机构的关注。一些浏览器的供应商无法跟上，我严重怀疑是否有人将专利之类的内容建立在所谓的“自主”之上的，这个时候，IBM的Domino WebServer 正在走下坡路，份额急速下降，他们正在研究开源的可行性，看能否切换到 Apache，但是随着NCSA退出，Apache 尚没有明确的合法所有人。USL与AT＆T的官司对BSD的影响才刚刚开始显现…..所有的这些事情都聚到一起了，当然，对于我一个欧洲的人来说，美国的诉讼习惯实在是太具有侵略性了…..于是，稍作商量，我们便迅速的做出了决定。
Randy:
在决定将 Apache Group 转成为 ASF 之前很多年，我们一直在经营着 Apache HTTPD 服务项目，至于为什么要转，这其中有很多的原因，如果我没有记错的话，其中的一个因素是希望能够为贡献者和公司提供相应的法律保护，另外的一个原因是希望我们能够获得现金和其它捐赠的组织，从而能够让我们进入更加良好的发展。总而言之，我们最终的目的是建立一个组织，从而能够支持日益增长的开源开发的参与，以及大量的被采用。
Bill:
我这里主要的感受还是从IBM的合作上来说起的，合作的决定其实是IBM想参与到项目当中来，Apache Group 拥有非常开放的态度，认证倾听 IBM 的担忧，最终二者通力合作，制定了协作的模式，大家一致认为该模式非常的友好，同时保护了 Apache Group 和参与贡献者的核心利益。我以为该事件，尤其是IBM参与到Apache项目中来，很好的验证了开源的可行性。
Mark:
请移步 Apache 周刊的脚注里了解背景： http://www.apacheweek.com/issues/98-07-10#coremeeting
问： 您贡献了那些Apache项目？
Aram：
HTTPD，HTTPD/2，Java Common ，以及其它一些参与较少的项目。
Drik：
绝大多数是在Web 服务项目上，也为一些 XML 和 Java 的项目做了一些贡献，如 Tomcat。
Randy:
主要是 Apache HTTPD 项目，当然更多的是作为ASF 的董事会成员（不知道算不算项目贡献）。
Jim:
我现在仍然在为 HTTPD 贡献代码，我还为其他几个Apache项目做出了不同程度的贡献，包括Apache Portable Runtime，Apache OpenOffice，Apache Pulsar，Apache Incubator…
Mark:
我参与了 Apache HTTPD 了几年，着力于安全方面的内容，也做过一些发布管理的事情，也是
mod_status模块的作者。在ASF之外，我与另一位核心开发人员 Paul Sutton 一起发起了Apache Week，这是一份每周发布关于Apache 进展的各种情况（1996~2004），我本人的职业也是围绕 Apache 进行的，在欧洲创立了C2Net，基于Stronghold项目——商业版本的Apache版本，加强了安全方面的内容。
Sameer:
只有 HTTP server。
Bill:
Apache HTTP Server 和 Apache Portable Runtime.
Lars:
除了Apache HTTP Server项目之外，我还参与了 ApacheCon 的规划项目，参与 1998年的 ApacheCon 给我留下了非常大的印象，在那次会议上，我不仅遇到了平时协作的伙伴，而且还和Apache的用户交谈了很多，这让我意识到我们需要为用户和开发人员提供定期见面的机会。通过网站，Wiki 和邮件列表可以完成很多工作，但是面对面的交流仍然是不可或缺的。从2000年到2009年，我一直帮助策划ApacheCon活动，并在过去两年中担任会议规划项目的副总裁。
问：目前，您是否仍然和 ASF 有关系？如果有的话，在做些什么工作？
Jim:
我本人仍然在积极的参与 ASF 相关的工作，我很幸运的担任了 ASF 成员多年，也就去年休息了一阵子，我今年仍然提交了提名，兴许我还能继续做总监了，没人能预测结果。但是不变的是，我会一如既往的积极参与基金会和相关项目的工作。
Drik:
比较少的参与了；主要是围绕有关 ASF 的一些事，尤其是安全响应/协调方面的事情。
Randy:
非常遗憾，我已经抽不出时间来为 ASF 做工作了。
Aram:
我是ASF 的名誉会员。大约16年前，我加入了一家不允许向开放源代码做贡献的公司，此后一直处于“养鱼”状态。目前我仍然是邮件列表的狂热阅读者，并试图跟上董事会的动态。不过有一个好消息，在前几个月，公司的法律条款有了变化，新的文件正在生效，那就是允许贡献开源了。
Mark:
作为ASF Security的副总裁，我每周仍致力于帮助项目处理报告给他们的安全问题。同时我也在CVE 编号颁发机构为 Apache 维护者，也是 CVE 的成员。
Sameer:
除了使用许多ASF开源项目外，我对 ASF 已经没有做太多事情了。自从做了三个孩子的父亲以来，能腾出来时间实在有限。
Bill:
身为名誉会员，说明已经不在一线工作了，尽管我仍然订阅和关心邮件列表。
Lars:
没有以前那么的活跃了。自从我儿子于2017年出生以来，尤其的明显。我只能尽可能地与Apache HTTP Server项目、共同体发展以及Apache安全团队保持适当的同步。至于我的日常工作，我作为个体为客户提供咨询服务，主要领域是安全体系架构方面的内容，在伦敦生活了10年后，我目前正在搬到柏林。
问： 可否分享一下ASF 和 Apache 之道对您个人的影响?以及它是否随着时间有所变化？
Drik:
像任何行业/科学共同体/专业协会一样，这是一个让人学习、自我完善、以及社交的好地方，可以改善日常的专业工作。
Jim:
我们非常幸运地可以遵循 Apache 之道，我们很多的决定或“权宜之计”经受住了时间的考验，我以为之所以能够这样，是因为我们所创建的 Apache ，是可以做到让参与的人的才能和技术收到社会的欢迎和奖励，而且能够获得相应的感谢。
Randy：
我参与到 ASF 当中来，进一步巩固了我原有的信念，我们可以更好的解决协作过程中的问题。我是在上世纪80年代末发现了开放源代码的，当一小部分在讨论且公开他们的工作时，就会有更为聪明的同行对其工作进行严格的审核，那么这样的结果就会产生更好的解决办法。能够和 ASF 以及其它的同行评审（Peer Review）成员协作是我视为自豪和荣耀的事情，因为这样可以让我精益求精，这样的环境也让我学会了认真倾听。
Mark:
为 Apache HTTPD Server 所做的工作，不仅让我获得了难能可贵的经验和知识，还让我顺利的获得了第一份工作，而且最神奇的是，我的第一家公司尽管来回易主（被收购），但是我仍然在同一家公司。正因为此，和 Apache 相处的十多年，让我对之充满感激之情，不仅让我的工作有趣，充满挑战，重要的是意义非凡。虽然我已经有相当一段时间没有参与Apache项目的编码了，但是我的专业知识和见解仍然有用，偶尔我还是可以写一些脚本之类的。
Bill:
作为 Apache 小组原创团队成员，也是 Apache HTTPD server 的核心开发者，这些经历彻底改变了我的人生和世界观。尽管我最初参加的时候，是由IBM所“指派”，在Apache 我是通过贡献来获得提交访问权限的，这和我在IBM的工作是完全相反的。尽管有小组成员的反对，但是最终 Apache Group 还是接纳了我，我无法对引导我的人一一致谢，但是我认真倾听、虚心学习，更为了更好的自己，我非常荣幸的亲历并见证了开源运动发生的中心，我要感谢原始Apache Group的所有成员以及IBM的同事为之提供的支持。
问： 您认为 ASF 和 Apache 之道在行业中产生了何等影响？
Drik:
尽管我们在其他领域进行了激烈的竞争，但作为一个行业和ASF，我们共同找到了合作的方式。这种协作对于开放的互联网至关重要。另外互操作性也是关键所在。它使万维网的核心保持相对开放；防止出现某家独大的公司称霸互联网。
Randy:
我以为 ASF 对于业界最大的影响在于其有效地促进了人们参与到开放式开发当中来，ASF 虽然并非是首先发起开放式开发的组织，但是绝对是率先积极寻求公司和个体的组织，很多公司看到了开源所带来的优势，并将这份优势保持在自己的商业解决方案中，在这方面ASF 拥有大量的实践经验，这些公司投入自己的资源到ASF来，从而改进正在开发中的软件项目，这么做同时带来的益处就是还能够进一步获得用户的需求。想当年，我会和这些公司花费大量口舌来解释开源意味着什么，当然最难的部分，仍然是为什么那么多人都愿意将自己的时间投入到不能直接带来营收的工作中来。现在好了，我没有在必要解释了，已经有非常多的公司对于优势已经有了理解，甚至有很多已经是积极的贡献者了。
Aram:
Apache 许可证是路人皆知，有非常多的非 ASF 的项目也在使用和推广。ASF的许多项目都是各自领域/技术的领导者。
Mark:
Apache许可证的创建催生了一代完整的开源软件，使得这些软件遵循 Apache 的理念，即使这些软件项目不一定是由Apache 软件基金会所孵化或创建。例如，在较为早期的 ApacheCon 会议上，几位Apache的核心开发者促成了 OpenSSL 的建立，OpenSSL 尽管不是 ASF 的项目，但是它遵循了 Apache 的理念，采用了 Apache 许可证，且一直没有变，他们也没有打算变。
Lars:
Apache 之道当然是 ASF 的最大输出。它让很多公司在其内部的项目开发中获得启发，以应用 Apache 之道中的原则，ASF 的许多项目在互联网甚至整个IT 行业都有着举足轻重的所用，总体而言，开源软件和 Apache 软件使得许多初创公司能够与大型公司竞争并取得成功。专有软件正在逐渐消失，开放源代码软件在许多公司的长期IT战略中发挥着核心作用。ASF尤其是Apache许可证在此方面发挥了重要作用。
Bill:
ASF、以及许可证模式，在开源的圈子里拥有很多的受众。而 Apache 之道则为有时间和技能的贡献者提供了颇为公平的方式获得认可，而这是Apache 项目成功的关键。
Jim:
在过去的几十年中，ASF 几乎是每一项创新技术进步的摇篮和”魔法锅“。Web、Java、电子邮件、Wiki /博客、数据库、大数据、PubSub、机器学习、人工智能…所有这些技术均能在 Apache的项目和共同体中找到影子。在很多时候，我们定义了某个行业，甚至还引领了多个领域。就目前来说，Apache 之道是公认的很重要软件开发范例，其也是很多公司实行 InnerSource 的基础，换句话说，Apache 之道正在改变企业的 IT 开发。
问： 您对有意加入开源的新人有何建议？为什么说 Apache 是一个值得参与的好的共同体？
Jim:
开源可以很好的培养人们的技能，并发挥天赋，更加重要的是，你所遇到的志趣相投的人，会珍视你的才华和贡献，Apache 是一个根据人的工作进而获得尊敬的地方。去吧，找一个你喜欢并热爱的项目，并且和类似的人分享这种热爱。Apache 就是这样的地方。
Randy:
对于任何想要参与到开放式开发中来的朋友们，我推荐 ASF ，对于新手来说，ASF 有着清晰的组织形式和友好的共同体，非常轻松的上手。在这里可以找到颇为热情的同道中人，现有的共同体成员会非常乐意的帮助新人完成需要的事情，或者循循善诱的让新手自己找到可以开始参与的工作。
Aram:
我一般在 Reddit 上也会回到类似的问题。我的建议是选择一到两个项目，作为用户也罢，订阅者也罢，均可。作为贡献者，是可以在这里看到结果的，我经常会遇到一些在自己的简历上写着某些开源项目，但是仅仅是使用，若问其关于项目本身的开发等情况，大多是一脸茫然，（适兕也经常遇到这样的情景！–译者注）重要的是，不仅要贡献代码，而且要为项目的文化及其方向做出贡献。
Mark:
迄今为止，我还没有发现在开源项目里不需要任何帮助的现象出现，为开源项目做贡献不必是对整体的项目有了解，成为传说的全面手，十多年来，我本身没有为Apache 项目贡献任何的代码，但是我依然为ASF贡献了很多有价值的事情。这么多不同的项目，不同的用户群和不同的编程语言，必然会带来与初次接触的人们的技能和兴趣水平相匹配的内容，所谓之各取所需。
Drik:
代码无法孤立的存在，或者说，不会存在太久，转瞬即逝。代码需要共同体的进化、培育、并确保其朝着正确的方向发展，也会过滤掉那些过于脱离实际而不能长期维护的人，这就是“共同体胜于代码”的缘由。这是一种微妙的平衡艺术，只要你做对了一次，它的发展将超乎你的想象。
Bill:
ASF 是一个非常开放、被广为任何的开源共同体，成员都是非常的优秀。选择一个你感兴趣的项目，潜心观察、学习、聆听，花时间去理解共同体运作的方式，然后去尝试联系共同体的某位成员，问问他们是否愿意为你提供帮助，不要着急，按照自己的节奏，去虚心学习，并尊重共同体的成员以及做事的流程，成功指日可待。
问： 您认为 ASF 在接下来的20年应该在那些方面做些增强？
Drik:
我们的核心推动力之一是（或者曾经是）对互联网的开放性和互操作性的需求，这样的需求驱动了诸如 ASF 之类的具备包容性、探讨性的出现，这使得人们可以在这样一个平台上进行技术上的协作，并很好的让大家进行工作。甚至是这些参与的人的雇主之间是相互竞争的。但是，世界的发展非常的迅速，大型平台参与者在某些领域达成了平衡，并能够将“他们的”技术推向“他们的”未来规划中，而这样的话，他们就没有必要和其它人进行协作。或者是需要贡献回去，与此同时，公司和投资者正在学习如何更好地控制或博弈这些合作；如何创建“付费游戏”开源基金会；以及如何通过金钱来驱动产品的发展方向。这些都打破了 Apache 多年以来所维持的平衡：增长、提高质量、成熟的循环。因此，我们需要学习如何处理这个问题：找到新的正反馈回路和放大器，以弥补我们的损失。
Randy:
我以为，不论哪个开源共同体，均可以通过积极的参与到教育课程当中获得相应的益处。通过参与到K12、以及更多的教学过程，开源共同体不仅可以传播开源的理念，还能获得潜在的贡献者。
Aram:
关于这点真是思绪万千啊… 我认为我们不仅需要更多的交流，而且需要更好的交流方式。作为“技术人员”，我认为我们的交流有时过于技术性。包括我们的采访[🤦♀️]，“ASF” logo 不仅仅是一个品牌，当下就是关于孵化项目及版权所有，展望接下来的5年，10年，20年，ASF 品牌应该代表良好实践，开放式沟通，开放源代码等。并不是说今天没有这些因素，而是说还没有涉足到商业的世界。
Bill:
蛮有意思的问题，“增强”一词是否是应对未来的正确的方式？尚待商榷，我以为“适应”可能会更为妥当一些。相比于过去，人、商业公司参与开源共同体的动机已经获得了充足的发展，而且发展仍然不会停止。ASF，作为公共的慈善组织，想要继续存活下去，或者是想要继续发展，则需要去适应这个不断变化的世界。
Lars：
我们必须继续加大对于“Apache 之道”原则的强调，同时也要保持对于共同体和个体的聚焦。另外我们也要密切观察那些新人参与没多久就离开项目的情况，并寻找原因和解决方法，到底是因为项目本身的问题，还是开放性不足？没有一个良好发展的共同体，谈创新是一种奢望。