开源与自研的选择

在研发过程中是选择开源技术，还是依靠团队完全自己研发纯手撸这个话题应该讨论由来已久。不同团队在不同阶段有不同的答案，最终结果并无对于错的实质区别，更多是基于团队资源禀赋、团队当前面临的问题与发展过程中各种不可调和的矛盾相互取舍折中的结果。以下就所在团队的经历与过程感受聊一聊个人感受。

先说结论，我所在团队在创业之初选择的是开源与自研相结合的方案。

我们的团队从筹建到最终产品期望投产上线仅有 4-5 个月时间，因此一开始的思路就是一切从简，如何快如何来，快速决策，采取先发展在治理的策略。我们在年中 5 月份开始组建团队，团队没有任何行业大咖，业务、技术均需要自行摸索，且这个时间错过了金三银四，受限于预算，招人异常困难，需量入为出。因此，我们的团队均是行业里的"凡人"，部分人员有一些中大厂的经验或完整上线运营项目经验，这部分人承担团队核心决策人员，结合团队成员画像，类似"草台班子"开始，在技术栈选择上为弥补团队”先天不足“，技术栈选择包容模式，未作统一的严格要求(后端开发语言包括 C++、java、golang、python 等)，当然这也为后来的技术栈统一埋下了不少的雷。

在初始团队与技术栈方向定下后，整个产品涉及移动端、PC 端、联机交易、数据处理等多个领域。在保障项目进度，满足快速交付同时，核心壁垒的构建也并非完全没有要求。因此，在 IaaS、PaaS 层选择使用云厂商能力，应用层中间件等全面拥抱开源，入大数据底层平台、CICD、应用开发脚手架、配置管理发布、日志采集、业务可观测能力等方面均采用了开源解决方案先行推进。在业务系统、内部核心平台能力如 bpm、任务管理、业务网关等与业务应用场景密切领域采用完全自研方式有序推进。

经过几年的实践，目前业务已进入高速发展期，回过头来看，当时的决策应该是成败参半，从快速研发投产支持业务推进来看，先发展在治理，以开源与自研结合的模式并没问题，而且整个产品上线也顺利在几个月完成研发投产，但从技术或治理角度而言，当时的一些决策也存在不少弊端，如技术栈的过渡包容导致了在发展过程中，技能栈无法很好的协同，团队人员之间存在一定程度的冗余无法有效将整体产能最大化，系统运营层面复杂度也相对较高。

于个人而言，满足业务发展需要，支撑业务快速发展，确保有充足的现金流产生，团队能活着对于创业团队而言可能更重要，目前团队以基本渡过了创业发展阶段的生死期，进入快速发展期，这个事后我们开始适当腾出经历进行治理相关的工作，充分印证了一句话”出来混，迟早是要还的“。