晚间，我们在准备 TBtools-II 的讲演报告内容，于是聊起来一个不时被我们想起，又不时放下的问题，即是“为什么是我们开发了TBtools？”
这是一个好问题，我一直在思考，本质上，我们这是在一条非主流的道路上渐行渐远。说得好听一点，那么是「副业做得不错」；说得难听一点，那么是「旁门左道搞太多」。不同人，不同视角，会有不同看法。当然，让我们感到开心的是，绝大多数人，属于前者，甚至更多人认为，TBtools开发是我们主业，而不是副业。到底还是当一个工作得到更多关注的时候，往往其他方面会被忽略不计。当然是好事，只是这个时候还是回到一个问题，「为什么是我们开发了TBtools」？
或许可以简单小结一下。
我们有需求
这个很直接，因为我们有需求，事实上我们是在做园艺植物的生物信息学数据分析，其中有各种组学数据，包括转录组，小RNA，ChIPseq，DAP-seq，重测序，基因组组装等等。在做深度生物学问题挖掘时，我们需要频繁使用各种软件工具，甚至有一些特殊的，其他软件所不具备的功能，这让我们非常头痛。找不到能用的软件，所以我们只能自己开发；找不到好用的软件，所以我们需要自己开发；用起来不舒服，不能良好满足我们需要，所以我们想自己开发。
目前来说，TBtools 有很多很多小功能，每一个小功能，逻辑上都是对应了一个数据分析需求。我们有需求所以开发出来，开发出来，所以可以满足需求。
没人愿意做
当一个事情看起来就是「很普通」，「没啥用」的时候，很多人都不会愿意去做；当一个事情看起来就是「很难」，「很复杂」的时候，很多人就完全没有做的想法，甚至宁愿忍受一些低效率工具的机械重复使用。
前者很正常。事实上，做生物信息学软件开发的人有太多，每天仅 Bioinformatics 期刊出版的软件就超过3个，每年超过1000个软件。不可否认，有很多生物信息学的问题都等着更多人去解决。而一个能解决实际数据分析需求的软件，可能对于有生信数据分析技能的人来说，或许是一行命令？或者是调用某一个软件？或许是使用某一个R语言包，python模块，就可以解决。因为看起来就是很简单，那又有什么开发必要？没有错，换做是我，我也不会去针对这个开发。
至于后者，明明有需要，但确实很难去实现一个鲁班性高的软件。这个很好理解，因为经验有限，时间有限。事实上，即使写出来软件，那么也非常难以写出来运行稳定，可用性高的软件。这个并非能力问题，而是时间和经验的问题。
为何不交叉
没错，这个时候，交叉看起来就是一个最好的解法。为什么你不让一群做计算的人和一群做生物的人坐在一起，开发出来一个非常好用的软件？一方面又鲁棒，一方面又功能丰富。当然可以，但是当然不可以。做计算的很难对生信下游数据分析感兴趣，即使感兴趣，也很难理解生物学问题，和实际需求。大家思维真的不一样，思维的磨合是一个痛苦的过程。TBtools 之前肯定出现过类似的软件，那为什么没有类似的传播度？因为做生物学问题的人会说这个真的不好用。
做一个能用的软件，甚至做一个看起来就是高大上的软件，其实真的不容易，但是很容易就进入了真的不好用的状态。
做生物的描述出来生物学问题，具体数据分析的需求；而做计算的无法理解这些需求，这样就很难实现出能用的软件。
实现出来能用的软件后，真正用软件的人是做生物的，那么结果就是后者用起来很不舒服，甚至很痛苦。
说得过分一点，最近我们开发了一个GSAman软件，在这个软件之前有一个软件已经打遍天下无敌手了，Apollo。Apollo是一个非常优秀的软件，但很明显，是一个做计算的团队开发出来的。只要体验过的朋友都清楚，你会选择 GSAman。因为功能相近，但是无法衡量的使用体验差别太大。
我们是做生物学故事的，甚至说基本就是做分子生物学，走园艺方向，软件开发出来第一时间不是给用户来使用，是给我们自己使用，觉得挺好用了，就分享出去。这个是比较奇怪的。因为我们失去了目的性。
忘了目的性
为什么是我们开发了 TBtools？事实上，最大的原因是，我们足够走运！没有错，我们运气足够好。从一开始就没有想着写这个软件，然后来发表，或者来结题，或者来干嘛。我们只是为了满足自己的课题需要，甚至只是觉得某个功能会比较好玩，所以写出来，没有多余的追求，所以能做纯粹的事情。
很多时候，我们做课题是这样的，先写好，我要做BLABLABLA课题，然后一个技术路线，然后就规划，然后就开始做。最后就是整理成论文发表。因为不发表能成吗？不能啊。于是从一开始，目的就是发表。发表之后呢？发表之后软件就 Archive 了，再也不提了。诚然有很多优秀的软件开发者，写出来的软件，根本不需要再update一次。但是做数据分析的都很清楚，更多软件发表即巅峰，自此不更新。这些软件并不是活着的软件，但不得不说他们已经完成了使命，达成了目的。
有目的，所以有达成，有达成，所以有结束。
TBtools 开发没有目的，我们说的「降低生物数据分析门槛」这个事情不是一个目的，我们只是提出来一个事情，正在做的事情，他根本就没有一个终点，比如降低到什么程度？所以完全无法考核。这个工作本身就游离在主流考评体系之外。你说他好他就好，你说他不行，我也没办法。所以我们设立了一个 TBtools 奖学金，奖励无法满足主流考评体系的优秀研究生。
我们能坚持
坚持，这个真的很难。前述提到，做生物的即使写出来软件，也很难让很多人使用。这是一个事实，因为 TBtools 一开始也是这样，可以说一开始就是求着别人使用。别人为什么要用你的软件？用了你的软件，发表了引用靠谱吗？这些都是问题。早前我做过一批贴纸，结果送不出去....因为真的没有用户，我身边也没多少用 TBtools 的。怎么办？当然是靠坚持。
那时候跟 TBtools 类似功能的软件几乎没有，各大云平台甚至还没起步，所以我们只坚持下来，可以积累到初始用户群体。这个还是得感谢用户，实际上是用户成就了TBtools，而不是TBtools帮助了用户。尽管很多人跟我们说的是后半句。近三四年，尤其在 TBtools 发表前后，越来越多与 TBtools 类似功能或者模式的软件发表。这是一个大好事，甚至我都支持。而且我必须提出的是，但凡跟 TBtools 类似属性的软件到我手上来审稿，我都给最多大修，甚至还有小修。但是很遗憾，这接近10来个软件，几乎全部没落，停更，或者并没有得到很好的应用。
我开始在想，到底是有人写，所以有人用？还是反过来，有人用，所以有人写。当然这个必然是相互的。要么就是越多人用就越值得写，越坚持写，就越多人用。
有一些不同
尽管有很多与 TBtools 类似的软件出现，但并不会影响到 TBtools 的传播和应用。简单来说，TBtools 还是有一些不同：
- 我们有自研的绘图引擎 - JIGplot，这个绘图引擎是从零开发，所以 TBtools 的数据可视化可以非常灵活和丰富，同时还支持交互。相比之下，几乎所有类似软件，无一不调用 python 或者 R包。自然后者可以实现非常多漂亮图稿，但是可视化和可视化分析，并不相通。要实现可视化分析，依赖于R包，那么最好还是coding。只凭这一点，TBtools就可以做出很好的用户体验，让更多人轻松简单，且灵活自由的完成数据可视化。如果是一心做好可视化，那么强大的 TBtools 用户群体，对于 TBtools-II 来说，用户完全可以开发成 TBtools 插件，使用起来更自由和方便。同时不存在网络问题，即插即用，不要可以删掉。
- 持续增长的用户群体，TBtools 目前装机数目已过50w，每天会有超过3000人使用 TBtools 进行数据分析。软件就是这样，用户越多，越能暴漏出软件问题，这样就只需要把开发人员搞崩溃，软件就会变得更稳健。软件更稳健，就更多用户。持续的反馈循环，所以使得 TBtools 越来越好用，功能也丰富。
不变中求变
不变的是 TBtools，变得是需求和功能。TBtools 与用户是共成长的，起始于开发人员的硕士研究生阶段，稳定于博士研究生阶段，成熟于教职人员阶段。其中功能不断在完善。TBtools 几乎每天都在更新，要么是优化已有功能，要么是开发出来新功能。尽管我必须承认，这一两年 TBtools 的更新速度减缓的。但实际上并不 TBtools 不更新了，而是 TBtools-II 来了。
为了解决更多的需求，所以 TBtools 需要转变，从软件转变为平台。让那个更多真正有一线科研需求的朋友参与到开发中来。
TBtools 是一款本地软件，一旦分发，就无法收回。这跟网页软件完全不同，从这个角度来说，TBtools 并不是初始开发者的，而是用户的，因为他就在电脑上，想用就用。类似的，TBtools 的开发工作，也是用户的。在 TBtools-I 中开发者是用户；在 TBtools-II 中用户就是开发者。
我们不会停步，一直前进。
所以，「为什么是你们开发了TBtools？」其实不是，问题应该是「为什么是用户开发了TBtools？」而这个问题本身就是答案。