BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Esty的开源项目运营经验

| 作者 曹知渊 关注 1 他的粉丝 发布于 2015年8月4日. 估计阅读时间: 7 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

在Etsy(译者注:一家以交易手工制品和旧物品为主的P2P电商),我们是开源的忠实粉丝。在互联网上,无数的人解决了无数个问题,并使用开源许可证发布了他们的代码,没有这些人,就没有Etsy。我们在Linux上运行Apache网页服务器,来保持etsy.com的运作,我们服务端的代码多数是用PHP写的,我们使用MySQL来保存数据。为了保持与时俱进,我们使用GangliaGraphite生成的可视化数据来度量我们的系统状态,同时使用Nagios来监视系统的稳定性。当然这只是一些主要的例子,我们技术栈里面的每个边边角角,你都能发现开源代码的身影。

在Etsy,“慷慨精神(Generosity of Spirit)”是每个人工作的一部分,它的意思是要给行业以回馈。对工程师来说,这意味着至少每年一次,或努力在某个会议上做一次演讲,或在本博客上写一篇文章,或给开源项目做点贡献。当我们解决了一个问题时,如果我们觉得解决方案或许对他人有用,我们很乐意把它回馈给开源社区。

维护与分化

这个问题一直困扰着我们公司的很多开源项目,因为源源不断的贡献同时来自于我们的工程师和开源社区。我们从不羞于开源我们技术栈的核心部分。我们一直在公开开发我们的部署系统统计数据收集器团队即时管理工具以及代码搜索工具。我们甚至开源了我们的原子部署系统的关键部分。开源确实很有好处,我们广泛地收到来自社区的新功能和bug修复,我们的软件变得越来越成熟和稳定。

我们开源的项目越来越多,当我们想快速搞定某些新功能的时候,显然很有理由为项目创建一个内部的分支。这些建立内部分支的项目,很快就和它们的开源版本发生了分化。这意味着,维护好这些项目的工作量会翻倍。内部的任何修复或者新功能,都要在开源版本中重新做一遍,反之亦然。在一个商业公司中,内部版本的优先级往往高于开源版本。看看我们的GitHub主页,很难搞清楚哪些项目还在频繁维护中的,甚至我们自己的工程师也搞不清楚。

所以我们的结局就是,手上捂着一大堆“年久失修”的项目。开源社区的人花时间报告了一个bug,却等不到任何答复,有时候甚至几年都等不到,这使潜在的开源用户心寒。没人能说得清楚,某个开源项目是一个持续维护的软件,还是仅仅是验证完某个想法后就被丢弃了。

向前走

我们想把开源社区建设得更好,因为我们从现有的开源软件中受益良多。为了使我们的开源项目的状态更清晰,我们对此来了一次“春季大扫除”。我们的开源项目将会被清晰地标注为:维护中、停止维护、已归档。

维护中

维护中是默认的状态,所以不会特别标注。维护中,说明我们要么内部就在使用开源版本,要么正在把内部版本的修改同步到开源版本中。我们已经对我们的部署工具完成了这项工作。我们正在处理所有维护中的项目:对pull request进行合并或给出我们的看法,答复问题报告,以及添加新功能。

停止维护

我们也有一些项目已经几年没有公开更新过了。通常这是因为虽然我们想在内部也使用开源版本,但我们不能拖慢开发周期,我们难以找到两全的办法。但是,代码还是在那儿,依然可以视作是对某种创意的展示,诠释我们如何解决某个问题。或者,这原本是一个研究项目,但我们放弃了它,因为长久以来它都无法解决我们的问题,但是我们仍然希望展示我们曾经做过的尝试。那些项目就保持原样放在那儿,很有可能不会再有更新。我们会关闭问题报告,不再接受pull request,并且会在README中清楚地说明此项目仅作展示之用。

已归档

我们开源的项目中也有一批是我们在特定时期用过的,但是目前已经不再使用。很可能我们对某个问题找到了更好的解决方案,或者是老方案从长期来看并不能真正解决问题。在此类情况下,我们会往主分支上提交一个commit来删除所有的代码,仅留下README用于描述项目及其状态。README会指向源代码删除前的最后一个commit。这样代码不会真正消失,但项目的状态却明白无误。此类项目同样会关闭问题报告和pull request。

除了这些归档的项目外,我们也在某些时间fork了别人项目,里面有些我们也不再维护,我们也在着手清理这些项目。

结束语

在过去几年中,我们在维护开源项目方面学到了很多。我们想分享的最大教训就是,一定要在内部直接使用软件的开源版本,这很重要,有可能其他开源开发者也想使用此软件,这可以给他们带来更好的体验。我们一直在努力学习,力求把每件事情做得更好。如果你在等我们对某个问题做出回应,或合入某个pull request,希望本文能帮助你深入理解当下在发生什么,为什么等个回复这么久,并且我们希望新的项目分类方式能帮你梳理清楚我们开源项目的状态。我们希望成为开源世界的典范,我们希望以一种众人受益的方式来给予回馈。给项目做一次春季大扫除总是一件好事,即便当下已是夏季。

你可以在Twitter上关注JaredDaniel

https://codeascraft.com/2015/07/09/open-source-spring-cleaning/

本文由作者Daniel Schauenberg发表在codeascraft.com上:Open Source Spring Cleaning。经授权,在InfoQ中文站翻译共享。本文在Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License许可证下发布。


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT