|
|
|
多年前决定开源时，我们挺兴奋的：作为典型码农，“用”开源是日常，而全力投入“做”开源，对我们绝大部分人都是头一遭。
我们也曾天真地以为：“开源”能有多难呢？！不就是把代码放出去，大家一起用，一起写嘛。
但是，“开源”这事儿真的是这样子么？还是先看几个灵魂拷问吧：
[list,
[*,目前区块链领域的开源社区处于什么发展阶段？
[*,开源社区的参与者是“用户”（user）为主还是“贡献者”（contributor）为主？
[*,项目的星标数和贡献者数究竟有多重要？
[/list,徐徐几年，众多社区伙伴围绕 FISCO BCOS 开源了诸多项目，覆盖了区块链核心技术、应用开发到运营运维治理的全领域。社区聚集了 4 万多名开发者关注者，2000 多个机构，数以百计的应用已经在生产环境稳定运行，社区和产业生态活跃度在圈子里也获得了诸多好评。
2021 年 3 月，国家“十四五”规划纲要发布，“开源”首次列入其中，指出要支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。
今年 6 月，工业和信息化部、中央网络安全和信息化委员会办公室联合发布的《关于加快推动区块链技术应用和产业发展的指导意见》进一步鼓励开源并指出，要建立开源生态，加快建设区块链开源社区，围绕底层平台、应用开发框架、测试工具等，培育一批高质量开源项目。
我们深受鼓舞，回望过去，在打造良性互动的开源社区新生态方面，我们已进行诸多探索，这其中的酸甜苦辣，仍然历历在目。
直面问题
这几年来，每天早上我醒来的第一件事就是拿起手机，看技术群里有什么问题。工作间隙看、开会间歇看、走在路上也看……活跃的社区群，有时消息犹如刷屏一般。
问题五花八门，从基本概念、安装部署到代码分析，再到从产业层面切入来找案例，或者聊区块链和开源软件，以及开源商业化的……在前沿技术领域，不同个体在不同的阶段总是能碰到新的问题。
我其实挺享受在社区里当“客服”的。在漫长的职业生涯中，我泡过技术论坛，也做过互联网公司的客服系统，开源社区让我找回了和网友打交道的感觉——亲切、有趣、大家都在做有意思的事情。
为啥社区里会涌现出这么多的问题，我们也有一些反思。是因为区块链领域太新了，概念过于晦涩，导致开发者需要迈过的学习门槛较高？还是我们的出品没做好，文档没写清楚，确实难懂难用，BUG 还多呢？
有一说一，2017 年末开源的最初版本，光搭链组网就足有十几个步骤。每一个步骤都有可能因为环境和网络差异，以及软件本身不完善的容错能力而“跪掉”。
在那时候，能把链搭起来已经挺费劲了，运行起来偶尔会有“coredump”（进程崩溃），用户把 core 文件（系统异常堆栈）发给我们以进行详细分析时，看着异常堆栈，我们内心其实是略有苦涩的。
曾有行业专家当面吐槽：“你们代码风格一般呀”。他们本来想引入的，但看了代码风格，觉得还是等等吧。个中滋味，我们懂。
当时，整个行业几乎没有工业级可用的区块链底层平台，我们从 0 到 1 做出的第一个版本， “能用”就是一个小 flag，也确实落地了一些应用，但整体离优秀开源项目的差距还挺明显。
至于文档，大家都知道，程序员写代码很 high，写注释算是义务，但写文档简直比赶鸭子上架还难。奋笔疾书憋出了好长的一个使用文档，但相关的概念原理、异常处理方法不全面，撰文技巧和经验更是欠奉，看起来很“硬”。
在人才方面，几年前，圈子里有个无法证实的说法，“在国内，能徒手撸出一条链的人，不会超过 200 个”。同时放眼整个中国的开源领域，深度参与到开源项目中的开发者，其整体规模也并不大。
区块链行业热潮掀起时，社区开发者们热情都很高，踊跃参与开源项目，积极学习技术和开展应用。其中有不少是在校学生和学术研究人员，以及对企业级或互联网软件研发有一定经验的开发者，还有从非技术角度切入的“文科”人士。总的来说，精通区块链原理、通读区块链项目源代码、能娴熟开发区块链应用的硬核区块链开发者，可遇而不可求。
无论如何，我们不能指望一开始就有海量开发者天降神兵，踩着祥云来共建社区。
我们没有刻意去对比国内外其他区块链项目的状态和经验，别人的模式不完全适用，毕竟开源内容不同、环境和文化不同，发展阶段和发展模式都不同，可资借鉴的经验也寥寥。
大体上，当时国内的区块链开源社区属于“起步”阶段。
化繁为简
那段时间，开源工作组有许多深入的讨论：方向对不对、版本优先级怎么排、能不能让内外上下游都满意……大家非常焦虑，常常讨论到凌晨一两点。
万事不决，还是回到原点：“想让别人满意，首先得让自己满意”。我们不断自问：好用的开源项目应该是什么样子？
想想 Linux/Apache/Mysql/PHP（合起来就是著名的 LAMP）这些成熟的开源软件，是不是下载下来就能安装？安装了就能跑？用这些软件，遇到问题的话，可以读官方文档学习原理和细节；再不行，论坛上问、网上搜，买书看，总能找到答案和案例。
团队有位架构师，人称“楠哥”，他用一句话终止纠结，“如果一个软件用户 15 分钟还用不起来，他们一定会抛弃你！”
于是，码农们掐着秒，数着命令行写代码：下载代码和软件要花多长时间？是不是一行命令就能把链搭起来？配置文件用 json 编辑起来是不是容易误操作，用 ini/toml 格式是不是更简单一些？
“多个进程多个鬼、多个步骤多个鬼。”这是我们的口头禅。极致的简化，把代码中的“玄学”变成确定性。“能用就行”肯定是不行的，还要好用、耐操！我们根据之前的经验，适配各种操作系统和软硬环境，预置默认组网模式和证书文件，让使用者在整个过程中连“踩坑”的机会都没有。万一还是出错，则高亮提示、FAQ 直达，用多种策略自动检测和恢复，应有尽有。
链搭起来了，接着就是打磨控制台、浏览器，让区块链看得见摸得着，用户一旦眼中见图，心里更有数。然后，内置应用模板，乃至压测样例，以使得开发者可以按图索骥，一键构建应用。更进一步，区块链上云，云上资源调配、部署交付、运维运营一站式搞定。
如果开发者有兴趣继续研究细节，我们还有详细的使用手册和技术文档。足足有百万字规模，赶上几本书了，可以慢慢读，还可以搜索直达知识点。
此外，软件的核心能力也没落下。大家都很熟悉的“wheat”，有技术洁癖和质量强迫症，对技术攻关、架构合理性、代码风格和版本时间线毫不妥协，代码必须经过几个人（包括他自己）交叉审核过，而且单元测试覆盖率足够高，才能提交。
让人欣慰的是，2017 年到 2018 年，开源工作组陆续加入了许多老司机和刚毕业的小鲜肉，他们都很生猛，大大地充实了开发力量，并随着项目一起成长。这也是硬核技术创新的奥义：“21 世纪，人才最可贵”。大家一起投入，性能、安全、稳定指标都达到了高水准，同时隐私保护、跨链、新型虚拟机、链治理等多种核心能力也逐步完善。
回首看，2019 年初与社区共同打磨出来的 FISCO BCOS 2.0 版本可以说是一个里程碑，用起来简洁快捷，工具和文档配套齐备，核心能力靠谱，怎么一个“爽”字了得。效果那是立竿见影，能把区块链快速跑起来、用起来的开发者肉眼可见的迅猛增加，社区留存率明显提升，同时社区提交的议题、代码和文档更新也多起来了。
在此之前，社区朋友们可能会礼貌性地夸一下：“开源就是一种精神”、“开源已经是相当有勇气了”……此刻，终于能听到有人真心实意地说：“牛！挺好用！”。
现在我们尝试回答第二个灵魂拷问：如果开源软件没有用户，那么，也大概率不会有什么贡献者。
软件要吸引“用户”，它本身至少要稳定可用，再则使用门槛要低，最好开箱即用，交互手感要如丝般顺滑，无论是代码还是界面都要清晰优雅。唯如此，用户才不会步步惊心，甚至到处踩坑，不会迷失在繁杂的配置文件、天书一样的日志和错误信息里。
众所周知，互联网产品追求“Don’t make me think”。开源项目大抵也如此，若能再有一点极客气质，那就更赞了！
授人以渔
在解决了使用门槛的问题后，我们观察到社区问题在变化。
首先，“简陋、用不起来、运行出错”这些可用性方面的问题明显减少了。
部署搭建等问题增加了，我们分析，这是因为有更多人在实操搭链了。搭建过程中，不免还有一些小的磕磕碰碰，又或者遇到一些概念性和体验感上的问题，需要咨询交流。当然，这也说明软件使用流程，还是文档都还有提升空间。
功能性问题的大幅增长，佐证着我们的技术、组件确实是被更广泛地用起来了。许多人在规划网络拓扑、写合约调接口，在分配权限、分析数据，又或者是在不同的应用场景探索着更多区块链能力。
最令人欣喜的是，大家对区块链原理、架构、算法的探讨更多了、更深了。交流中不时迸发出火花，触发灵感。这对明确后续的优化方向，规划版本，增加特性，以及共同建设都有非常好的参考价值。
社区就像一面镜子，种种变化明晰可见，映出技术的完善，也见证社区的成长。
对于这个阶段，我们也有一些思考：
1、不要指望聊天群能解决所有问题
我们有“社区答疑”排班，如果值班的同学遇到解答不上的难题，将请小组智囊团分析，总之，我们的要求是尽快答复解决，“当日问题当日毕”；尤其是线上产生的问题，要优先跟进。
我曾经花了一个晚上翻看几个月的群记录，算了下我们开源团队每人跟进过的问题数，量还是比较大的（如下是其中一页）。更难能可贵的是，团队成员的态度和积极性都非常到位，每每及时解决问题，并找到了优化点，他们自己也挺开心。
言无不尽地顺畅交流，聚焦解决痛点的社区答疑体系，确实在业内为我们树立了非常不错的口碑。
聊天群的好处在于交流无比便捷，其不足也显而易见，群聊会吸引不少注意力，聊天记录难以被其他人翻查，不利于积累和复用。随着新人的不断加入，不少常见问题的重复率极高。技术论坛应该是不错的互补。当然技术论坛的搭建和维护，也是需要投入的。
而随着社区人数和领域覆盖面爆发式扩张，单凭开源工作组来在线答疑，是否是最佳解呢？我们思考之余，觉得这也算是“幸福的烦恼”吧。
2、不要指望文档解决所有问题
软件质量基本稳定后，每当看到问题，我的第一反应常常是，“是不是文档没写清楚？！”
开源项目文档包括使用手册、开发教程、术语和概念、架构原理、FAQ 等等，可谓“汗牛充栋”。好在线上文档支持关键字检索，基本上能想到的知识点，都可以检索出来。
同时，在公众号、合作媒体上，我们也发布了多角度的文章，尝试跳出技术细节，去澄清区块链思维，科普区块链学习方法，把经验和教训传承起来。我们真心的希望这些文章能给不同阶段的读者一些启发，从技术的“第一性原理”出发，举一反三，直达区块链知识内核。
但我们发现，理想和现实是有差距的：文档怎么写都会挂一漏万；用户的操作路径、思考模式和我们预期的不一样；以及环境不一样，出的问题也会不一样……
此外，受传播渠道、曝光率等诸多原因的影响，文档并没有传播到所有用户；或者因为文档目录结构太深，用户确实没看到特定知识点；即使是看到了文档，面对上百万字的浩瀚篇幅，很多人会表示：“nice，先收藏慢慢看”……种种因素都可能导致文档的有效阅读吸收率并不乐观。
其实，用户根本不太想去看长篇大论，他只想赶紧解决手头上的问题。
总体来看，文档一定要有，还要好。但文档就像宝藏，适合慢慢挖掘，难解燃眉之急。
3、不要指望自己就能解决所有问题
日拱一卒，遇到一个问题解决一个问题，就万事大吉了么？
用户问题确实是最好的方向标，如果一个问题一个星期内出现了两次以上，而且还是由不同的用户问到的，那么可以肯定，是个需要优先解决的问题。
对不同的问题有不同的解法：可以迭代新版本把问题修掉，让它不再出现；也可以是修订文档，并给出显眼的文档入口供参考；甚至可以是跟用户聊聊，对齐了概念和思路，有的问题就消解了。解法很多，但关键是要快、要准、要闭环。
实践也证明，开源工作组不可能包办一切，比如有些用户的需求比较场景化，不适合放到主版本里，由开发者拉分支定制开发更为合理。有些问题跟不同环境、不同业务领域有关。事实上，开源工作组对很多领域也并非专家，只能是根据自己的理解，从技术角度切入和大家交流探讨，期望能互相启发。
本质上，如果只有开源工作组在做单向输出，用户是沉默的大多数，这样的社区势必会变得沉闷、无聊，也很快会遇到天花板。理想的模式是在整个社区形成正循环发展：老手帮助新手，新手成为老手，老手直接上手写代码，分布式解决问题和满足需求。整个过程大家都有贡献、有创新、有积累、有提升。
我们有时候会想，开源工作组是不是要稍微往后退一小步？我们更多的做好服务和布道的角色，以科普引导、激发鼓励为主，给社区小伙伴们更大的舞台，这样效果是不是更好？所以，我们除了写代码，还写文档、写教材，参与国家人才标准编写，组织线上线下的沙龙、培训、黑客松，这都是“授人以鱼，不如授人以渔”。
在行业发展的爬坡期，我们希望帮助更多的人学起来，用起来，让人才多起来。迈过了技术门槛的用户一旦成为娴熟的开发者，那么 BUG 一冒头就会被修正，不同的需求快速得以满足，软件本身也将越来越优秀。
目前社区已经自发形成了诸多 SIG（兴趣小组（Special Interesting Group））。组员们从社区主动加入，根据自己感兴趣和有所长的技术、应用主题，展开分布式合作。下图是其中一位组长（群昵称：李大狗）在小组介绍里的一页。我觉得“有趣、务实、激励、贡献”这几个关键字归纳得非常棒！
开源工作组，社区 SIG 以及不断涌现的开发者群体，构成了立体化社区技术力量。
我们持续聚焦软件质量和提升体验，减少重复问题，并引导和推动社区往自服务阶段走，分工合作，有利于聚焦识别更前瞻性的特性、承担更有挑战性的问题，广大开发者能施展的空间也越来越大。
扬帆航海
逐步成熟的社区将会呈现“网络效应”，良好的口碑是“自来水”，产业人士聚集得越来越多，生态和商业模型自然会长出来。
刚开源的时候，我们全国到处飞，去宣讲理念和技术，邀请大家关注我们的社区。最早的社区群就是这么一个一个人的“拉” 起来的。
我有个朋友一直默默地关注开源社区，把区块链融合到他们的行业产品中去，直到产品成功上线后才告诉我。
我问他：“你们完全不需要支持的么”？
他说：“开源软件就挺好用的，我们自己的技术团队实现业务逻辑，做一下运维配置就可以上线了”。
现在他们已经是“社区认证合作伙伴”，持续地用区块链技术去落地应用，他们的成果也以代码、工具、案例等方式回馈给社区。
这样的社区伙伴还有许多。他们在各自的垂直行业领域里有着深刻造诣，与开源社区形成了互补。在区块链方面，他们只需引入开源技术，而不用重复造轮子，效率大增，成本猛降。同时，他们在行业实践中，持续挖掘出许多非常接地气的需求，贡献了大量技术成果，其落地的实践更是对区块链技术价值的验证，他们的案例已经成为了产业地图上的标杆。
更有意义的是，我们发现不少企业在社区里发掘并招募到自己需要的人才；也有的在社区遇到产业链或技术栈互补、理念又相近的产业伙伴，然后愉快地建立合作关系。总之，社区搭起跨越行业和地域的桥梁，是实现精神物质双收获的平台，自发的形成志同道合、共建共赢的开放联盟。
这里必须介绍下， FISCO BCOS 开源工作组是由“FISCO 金链盟”发起的，金链盟目前已经聚合 150 多家机构，分别来自金融、证券、地方性交易所、科技公司、科研机构等。作为开放的技术社区，聚集的 2000 多家企业，更是覆盖了工业、农业、版权等广泛的行业领域。
值得一提的是，有多个培训机构已经成为社区的“培训合作认证伙伴”。大家共同撰写科普资料，并联合工信部人才交流中心等国家权威机构撰写了多套区块链教材，供全国各地的高等院校和培训机构使用。培训布道工作任重道远，独木难成林，众人浇灌，来日桃李满天下。
在数字化的风口中，各领域的企业犹如一艘艘船，纷纷开辟航道。开源技术就像风帆，能帮助企业顺应风势，带来巨大动力，去探索更大的世界。开源代码本身是否商业化，其实并不那么重要，开源的产业化模式更多是融合服务、拓展边界，推动应用落地。可想而知，如果大量的船只扬帆起航，实体经济来往活跃，整个生态蓬勃发展，所有人都必然得以获益。
大家好，才是真的好。我认为这是开源开放的真谛。
有容乃大
经历过开源的兴奋、焦虑、欣喜，现在我们已经淡定多了。
每天的工作依旧很充实。曾经，刚进入团队的小伙伴们以为来了就是写代码，然后发现并非如此，不但要当“客服”，还要当“写手”，时不时出去当“网红”直播“带货”解析开源技术，或者去当“老师”，站在讲台上一讲就是几个小时。
在不同的角色之间切换，对时间管理和注意力分配确实是一种挑战, 不习惯的时候可能会有一点点“分裂”感。尤其，对普遍有点“社恐”的码农而言，各种“抛头露面”，心理压力有点大。但是换一个视角，从长时间的职业发展来看，经此十八般武艺轮番上阵，技术写作水准、交流陈述能力，以及眼界的广度深度都能得到锻炼；最重要的是，自己写的代码，立刻就会有人用，有人切磋，对自己的技术能力和成就感也有所提升。如此于公于私，都无疑受益匪浅。
在技术团队身旁，我们运营团队还有专业的“社区小助手”，活跃于线上线下沙龙、展会，组织课程，即时推送热点内容，以及和社区开发者互动，协助开发者走上开源之路。在产业合作中穿针引线，如同小蜜蜂穿梭在花丛中。当然，如果群里有人发广告，扰乱技术氛围，也很快就会被小助手请出去的。
小助手也翻过车。记得几年前有一次社区活动，对在 GitHub 给项目点过星标支持的社区小伙伴，小助手会寄送小纪念品。本来是善意的，但被有的开发者误认为是用礼物换星标，并在群里直率地反馈。我们虚心接受并整改，此后自觉避嫌，再也不去做和星标相关的活动。我们非常理解星标是皇冠上的宝石，绝不是用来“兑换”的，应该是由真心支持、喜爱项目的开发者自发自愿的星标。
相应的，对那些为开源项目做出贡献的开发者，社区也会表示感谢，并激励更多开发者持续共建共享，我们会公布项目贡献者列表和季度贡献者榜。他们会获得别致的、值得在朋友圈晒出来的社区纪念品。这主要是精神激励，搞起氛围吧。我们相信带着感恩之心携手同行，可以让我们走得更远。
在开源路上，碰到一些小小的波折、误会和挑战，都很正常。诚如人和人之间，本身也有信任建立的过程。开源社区教会我们要“换位思考”，要有“用户思维”，因为我们已经不是自己在做事了; 我们要时刻保持谦逊，因为任何一点进步，都是来自社区的共同努力；更要保持开放和透明，无论是代码还是运营，都会被社区多方检视、评判和优化，毕竟“talk is cheap，show me the code”（注：code 同时有“代码”和“行为规范”的涵义）。
从这个层面看，开源项目的“星标”重要，但更重要的是大家打星标的理由，以及是否持续有人星标。理想的境界是，大家都是社区的开发者，然后大家点的星标，都是给自己，给共同的社区点赞！
躬身入局
我们再次回顾开篇的三个问题：
[list,
[*,目前区块链领域的开源社区处于什么发展阶段？
[*,开源社区参与者是“用户”（user）为主还是“贡献者”（contributor）为主？
[/list, |
|
发表于 2021-6-17 04:59:27
