日月星河，社区长存 | 图尔兹 CEO 致用户书

2018年，我创建了杭州图尔兹，最初的打算是搞搞数据库中间件。在跟客户接触的过程中，发现就数据库操作这个事情，已经不是我当初拿一个单机客户端去 CRUD 这么简单了，这主要体现在：

1. 数据库类型多：我们所处的这个10年估计是数据库类型最多的时代。国外的、国产的、老牌贵族、互联网新贵，夹杂着中美科技战，一众信创此起彼伏，好不热闹。但是我们也看到，数据库工具几乎没有国产的，再引申下，生产力工具也几乎没有国产的。这些国外的工具并不能很好地支持国产数据库。对于用户来说，最好是有个工具能够一锅端都能支持。

2. 桌面客户端不便捷：早10年，IT网络环境没那么复杂，网络安全也不像今天这样倍受重视。桌面客户端连接数据库是一种“直联”，各式各样的数据端口必须保证在网络链路打通。对大部分企业的网络来说，只有 Web(80，443) 是默认的，其它端口的开通都非常麻烦。有人可能会说中国特色的“堡垒机”、“4A”可以解决链路问题，但他们还需要在用户桌面安装插件和客户端（又回到第1点的问题）。我们想把数据库操作都放在 Web 上完成，Web 目前有这个能力，如果变成 Web，就很容易被门户、身份验证等集成，往 SaaS、Cloud 方向天然靠近。

3. 协作已成刚需：传统的客户端是面向“个人”的，但如今 IT 组织的复杂性导致即使数据操作也需要高度协作，比如开发人员、架构师、DBA 和数据工程师经常需要协作，去处理数据过程的不同环节，像设计确认、订正、迁移、转换等。在可预计的将来，IT 在企业的比重将持续加重，协作会愈发紧密。协作能够在提升效率的同时避免个人带来的数据风险。可以说，是否具备协作协同能力，是判断一个数据工具是否现代化的重要标志。

4. 控制势在必行：当前社会企业生产生活都在快速地数据化，绝大部分关键信息都存到了数据库里（包含SQL和NoSQL）；网络的互联互通又导致数据很容易被内/外部的人有意无意地泄露。那么在数据库客户端上根据人员分类进行控制，代价小而精确度高。

基于上面的现实，我们定义 Cloud（oriented）Query（any databases）是一个面向云的、支持多数据源、一体化的数据操作平台。是传统数据库客户端的升级版本。就如同键盘手机升级成大屏手机，可能会丢失一部分传统桌面客户端体验，但同时也会带来更全面、高效、协同、云友好的数据操作体验，我们希望把这个体验送到每一个跟数据打交道的工程师面前。这是一个不小、且很有挑战的事情，做工具对工程师出身的我来说也乐在其中，只要公司和团队还在，我们就会一直做下去。

技术人员如果要做一个面向广泛群体的数据工具产品，首要的困难是需求从何而来，即需要足够多的场景样本。我们不害怕技术挑战，但害怕自己瞎YY，做的东西根本不是用户想要的，所以希望搞一个社区大家一起玩，共创产品。大家花了时间下载、使用和提改进建议，我们承诺永久免费、持续改进，如果有些用户有些特殊需求，我们就赚点钱养活自己，双方以不同的方式为大家带来好产品，好软件。

另外一点是国内缺乏软件市场，虽然最近几年在变好，但软件企业生存仍旧困难重重，软件企业活不下去，好软件不会有，这其中的核心原因我认为是我们暂未形成软件文化，一种尊重产权、精益求精、高效协作的文化。央企国企资金充实，但他们的输出更偏项目化；互联网大厂就像黑洞，容易吞噬一切。面向互联网、倾听广大中小用户的社区协作形态或许是孵化软件文化、建设软件文明的土壤，在我看来值得尝试。

所以做社区，既是我们的根本诉求，也是长远发展的立足点，没打算玩票，早就做好了厮守终身的准备。

可能很多人听说过我们还有一个企业版，尽管我们没有在 CloudQuery 官网上宣传。这里我想对这两个版本的异同点做一些说明。

• 社区版和企业版的目标都是为用户提供可靠的数据工具，其中社区版主要面向中小用户，而企业版主要面向大客户。

• 社区版当前更强调效率，企业版更强调安全。这并不是个常态，未来也会在社区版加入更多安全能力，企业版也会进一步提升操作效率。

• 社区版发版速度更快，企业版倾向于绝对稳定。考虑到社区用户的建议，未来我们也会在社区版加强稳定，相应的发版次数也会减少。

• 社区版会永久免费，企业版会收取一定的费用；社区版只有网络技术支持，企业版还包括上门支持和定制服务。从另外一个角度讲，社区版是爱好，是我们对未来趋势的认同；企业版是当前安身立命的粮草，需要靠它活命。

虽然社区版不赚钱，但并不意味着我们就会边缘化它。从研发管理角度来说，社区版塑造了组织的工程师文化，激活了研发人员的主人翁和进取精神，同时为企业版很多问题的解决提供了有力的支撑。两者当前对我们来说相辅相成，缺一不可。如果未来我们在社区版呈现的价值可以让一部分用户订阅技术支持服务，我们则会进一步加大社区版投入。

从创业的那天起，我认识到中国软件行业的困境：中国的 IT 公司（软件或者集成商）绝大部分为生存苦苦挣扎。做通用软件很难挣到钱，且互联网二十年极大抬高了研发成本，钱花的飞快，我们也没有例外，经历过很长一段时间的懵逼、挣扎，差点难以为继。就像在南泥湾开垦荒地的部队一样，要想持久地去打仗，必须解决生存，解决温饱，于是我们做了一个痛苦的决定：暂停社区版更新一段时间。在暂停的这段时间里我们把有限的资源聚焦在优化产品、提升企业服务上，基本摸清了转化的脉络，更增强了对社区持久投入的底气。

每一次暂停，对社区、对关注 CQ 的用户都是一次伤害，这让我意识到另外一个问题，如果社区要持久发展，产品要持续地服务更多人，我们需要一个更加开放的心态。

过去我们犯了一个错误，就是贪大求全，测试不足，产品不够稳定可靠。对于 CQ 这种定位于数据服务的工具，大家很难接受它不稳定。所以后续 CQ 将会采用新的研发策略：一个稳定可靠的版本+若干创新分支。如果要上生产，选择稳定版本；如果是测试环境或者 CQ 参与者，可以选择某个创新分支，待功能稳定后再合并。

在产品稳定性上，我们将会加大测试资源投入，加强自动化测试，比如单元测试、场景用例测试、SQL覆盖测试，并改进研发环境，扩大回归测试范围。

随着收入的改善，我们将扩大社区版研发队伍，保证每个大模块有一个专一稳定的工程师。

除了改进产品策略，增大研发投入之外，我再分享下产品演进方向。CQ的核心理念是“提升数据效率，增强数据安全”，所以接下来有几个事情是明确无疑的：

1. 增加NoSQL覆盖：过去对 MongoDB 的支持不够，接下来会强化操作体验；Hive 和 Impala 将会被支持；ElasticSearch 也会在后续得到支持。

2. 原厂工具兼容：数据库厂家自带的命令行包含大量的“Command”，比如 mysql 的 source ，sql plus 的 /(commit)，t-sql 的 go 等等。CQ 将会最大化地兼容官方工具导出物，减少人员切换工具带来的不便。

3. 增强管控功能：目前 CQ 对 SQL 操作的管控还比较弱，很多小众语句、命令和存储过程等管控还不支持。此外在管控支持粒度上并不均匀，如 Oracle 支持会完整一些，MongoDB/Postgres 还很不足。后续产品在管控的粒度上会越来越细，并力求各数据库体验一样好。

4. 增强审计：审计主要增强两个维度，一个是审计范围，让审计覆盖所有用户操作；另外是审计的分析和告警，通过数据分析找出所有风险操作。

5. API 支持：目前及未来很长一段时间，我们力求满足用户的每一个需求，但是人员有限，希望一些不是很常见的需求由我们和社区用户一起来完成。我们提供 SDK/API，社区开发者根据这个 API 实现特定功能。目前很多功能社区都有定制需求，比如用户的接入、连接的批量操作、权限分配、审计、日志、甚至监控等等。后续我们将会把越来越多的功能开放出来，最大化满足社区定制需要。

如果有可能，未来我们希望有更多的社区开发者加入进来，源代码将对开发者开放，如果时机成熟，也会开源。我们和你们一起完善 CloudQuery 产品和社区，让这个产品真正成为社区拥有，就可以避免因为公司运营困难，暂停的事情再次发生。

CloudQuery 从诞生到快速发展，离不开广大社区用户的支持。每一次的下载、验证、建议，我们都看在眼里，记在心里，这里借这个机会衷心地表达我的感受：谢谢！甚至在暂停的过程中，还有人在不断为产品筹谋划策，并推荐给其他小伙伴。这些沉甸甸的支持，我们无以为报，只能拿出更稳定、更强大、更尖叫的产品，服务好大家。我们已经做好准备，社区版研发将在12月下旬重启，请继续关注我们，继续一如既往地支持我们，我们需要你！