大公司开源并非易事，如何用产品思维去做？

作者 | 刘豪

近几年，业内越来越多的人关注和落地微服务架构，Tars作为公司内部经过十年发展的一套稳定可靠的微服务治理框架，服务于腾讯160多个业务（如手机浏览器、应用宝、手机管家、手机QQ等）共计1.6万多台服务器。2017年4月10日，Tars正式对外开源。

一个忐忑不安的起点

Tars是腾讯从2008年到今天一直在使用的后台逻辑层的统一应用框架TAF（Total Application Framework），该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案，帮助一个产品或者服务快速开发、部署、测试、上线。在腾讯内部，各大核心业务都在使用Tars，颇受欢迎，基于该框架部署运行的服务节点规模达到上万个。

但是对于这么一个大而全的框架和平台，开源并非易事。首先是项目本身过于复杂，需要精简和重构，统一代码风格；另外Tars更多面向的是企业用户，这对技术和文档的要求是更高的。

对于我和团队来说，Tars开源是一个忐忑不安的起点，谁都说不准这个在腾讯内部颇具影响力的框架，能否能受到外部开发者的赏识。

4月初，正式开源后4天，Tars的Star数突破一千，并在一个月的时间得到了腾讯开源的置顶推荐。

截止目前，每周活跃交流的用户达140多人，同时能得到50条以上的反馈。在公司外部，腾讯旗下的子公司以及从公司离开的老同事开始使用Tars，也开始有一些企业主动联系我们沟通合作的意向。

在整个过程中，我发现做开源时要尝试用产品经理的思维看问题，除了代码和技术本身的东西之外，还要了解开源用户使用习惯，列计划做运营，并且要保证迭代周期、加强社区建设等等。

这篇文章中，我把遇到的一些问题和走过的弯路分享出来，希望其中的经验和教训，能够启发更多的开源爱好者。

第一印象很重要

有天无意之中，我在知乎里看见，有人对某些开源项目的评论，其中一条让我印象深刻：”竟然采用word写文档，word是什么鬼？”

经常活跃在开源社区的人一般采用markdown来书写文档，它不仅易于文档的阅读，易于文档版本的管理和维护，也易于解析成html。虽然看上去只是文档使用习惯问题，但是这个实际上反应出一定的问题，对社区的人来说，不管你的项目到底怎么样，一旦开源出去，不符合社区的习惯或者规范，就会给人留下不好的第一印象。不好的第一印象将会令项目失去很多用户，后面的发展也将十分困难。

意识到这些，我们决定在开源前，了解公司内部和开源社区在项目管理、代码维护、文档书写等各方面的不同和差异，然后修改这些差异，保证开源后向社区的风格靠齐。比如我们做了下列修改工作：

按照社区的习惯对Tars代码的组织结构进行调整，将内部原来分开维护的各个语言的框架代码统一在git上进行管理，文档全部采用markdown来书写；
对Tars所有代码的编码和注释风格进行规范，让用户阅读代码更加简洁明了；
对Tars所有代码文件、配置文件、db文件的字符集编码采用utf8进行标准化；
对Tars框架编译安装的方式与社区常用的方式对齐，采用符合社区习惯的cmake方式。

一个开源项目更像一个产品

一个项目的开源不仅仅是代码或者技术的开放，它更像一个产品的对外发布，需要事先考虑到其中可能遇到的风险。

举个例子。先前，Tars（漫步在云上的机器人）这个开源项目的名称本来不叫Tars，而是沿用内部的统一应用框架TAF（Total Application Framework）来命名的。但是在公司开源的评审过程中，发现TAF这个名称已经被其它公司注册了商标，这样以TAF名称来开源的话，会有侵权的风险，可能会对公司造成影响，为了防止其中的风险，我们不得不更改项目的名称。

也许有人会说，不就是改不名称么，多简单的事。而实际上，项目名称变后，开源代码里以前统一的命名名称TAF开源后就不好解释了，代码都需要修改，然后重新测试，更大的影响是，如果后续内部基于TAF的项目也想开源，那么也需要修改，带来一连串的问题。

不得不感叹，以产品的思维和视角去做开源项目，提前跟公司相关部门确认其中的问题和风险，十分必要。

初心能告诉你方向

一个项目开源协议的选择，其实很有学问的，这里分享在Tars的开源协议是如何选择的。

社区常用的开源协议有GPL、APACHE、BSD、MIT等，它们有各自的约束和规范。比如：GPL有传染性，由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不太适合。

腾讯内部使用的Tars是一个比较庞大的框架，代码量比较大，涉及到前台、后台等方面的技术。虽然Tars的核心技术都是自己研发的，但是难免会依赖了一些第三方开源软件，而这些第三方的开源软件里有开源协议为GPL、APACHE、BSD、BOOST、MIT等。

我们当时左右为难，如果不想做大的修改，快点让Tars开源出去，那么Tars就得选择GPL开源协议，这样的话很难受到社区用户的认同和有商业化用户的青睐。如果不采用GPL开源协议，Tars的Web管理系统需要重构，这样的话就需要比较长的时间去修改，然后重新验证测试。

回望开源的初心，我们希望Tars这个框架真正的能帮企业或者用户快速构建自己的分布式应用，真正的能让社区一起参与进来一起共建。参考github社区最受欢迎的开源项目，大都不采用GPL开源协议。再加上Tars本身的核心技术都是自己研发的，应该在开源协议上更友好一些。最终我们选择BSD-3-Clause开源协议，决定以核心组件为基础，以不依赖开源协议为GPL的开源软件为目标，对其中的工具或者组件代码重新开发测试，让Tars使用更友好的开源协议。

开源是对项目代码风格、架构、质量的有效检验

Tars开源过程中，我们主要把精力放在了两件事上：

一方面是框架整体代码和文档的规范化和标准化，比如对Tars的所有代码和文档进行修改保证符合公司的规范和社区的习惯等，

另一方面是框架的精简和重构，比如与内部系统相关的框架功能精简和web管理系统的重构。

实际上通过这些事情，我们把Tars优化的甚至比内部使用的更加清晰、合理、简洁。但是细想一下，如果一开始我们就以开源的标准严格要求自己，对日常的文档、代风格和质量都提出规范，，那么真正开源时会减少很多不必要的工作，省时费力，简单容易很多。

开源不是结束，而是开始

一个项目的开源不应该是一个项目的结束，而是一个项目的开始。它需要后续持续的投入，比如：项目的版本规划，构建开发者社区等。这些都是真正把开源项目做好的关键，这块我们也在不断探索。

接下来，我们打算支持更多的语言、进一步完善我们的功能、以及将更多的内部功能开放出去，让大家能更方便的使用Tars。

计划如下：

1.tars多语言开发框架nodejs、php的开源

2.tars新特性之鉴权、调用链、docker化开源

3.tars插件化之名字服务开源