在上一篇《杰出产品经理公开课》的文章里，我有提到要搞一个开源社区产品，原本计划基于 Discuz Q 产品深度定制，但是因为数据结构有很大差异，改动的工作量不比新开发一套轻松多少，权衡之后还是放弃了这条路，于是就要自己重造轮子了。

Web 开源程序是标准化的通用型解决方案，通过一套技术方案为不同业务场景或服务提供支持。既然是固化的标准，又为何能为多元化的场景提供支持呢？这就得益于 Web 技术的 MVC 架构（Model–View–Controller）的灵活性，可以为程序融入主题模板（Theme）机制，程序使用者可以灵活的改变前端界面的内容和交互逻辑，再加上程序设计中又融入了插件机制（Plugin）的软件设计思想，可以在不修改主程序的情况下扩展主程序的功能。

这一切的背景，其实还是离不开标准。开源程序能够玩转起来，也是因为用户使用场景是一个统一的标准化技术（操作系统和浏览器），在统一的标准里，再个性化、再多元的业务场景，总是能够有解决方案。操作系统可以说只有 Windows 一家，而浏览器虽然有好几个渲染引擎，但是至少大家也还是在 HTML、CSS、JavaScript 技术上，无非在前端兼容性上多花点精力，也不是大事。

但是，到了移动互联网时代，一切又被打散了，同一套技术无法满足多端的使用场景，因为用户终端变多了，每一端都有一套互相独立的标准。在 PC 端是浏览器，移动端又分 iOS 和 Android 两种系统，甚至国内还延伸出微信生态（俗称 WeChat OS 生态）。

想要在这样的多端多平台的情况下做通用型开源程序，以一套标准来实现跨端跨平台的使用场景，满足各类业务功能的需求，并且还能保证灵活的扩展性。其实不难，方案有很多种，而我也想到了一种，于是我决定弄一个开源社区产品。一方面是看好，另一方面也是因为「个人站长」出身，对那个时代有情怀。

在我准备要做这个开源社区产品的时候，我首先要解决一个核心功能，那就是插件机制（以及插件之间互相通讯的机制）。于是就延伸出了这篇文章要分享的方案，一套「后台管理系统」的开源方向。而前面讲开源社区则是首尾呼应的铺垫，为的就是拓展其中一个商业化场景。

这是一个面向“普通使用者”的「后台管理系统」，功能特征就是支持「即装即用」的插件机制。普通使用者像互联网早期的开源程序那样，下载程序包，上传到运行环境中，执行安装文件，填写数据库信息，然后完成安装。之后就在后台点点鼠标就能完成插件的安装、配置、更新和卸载等操作。

我称这个全能后台为“乐高后台”，顾名思义就是像乐高一样可以灵活搭配。

默认内置四个功能模块：
1、账号：所有扩展功能或安装的插件，共用一个账户体系。
2、钱包：附属账号体系有一个钱包功能，记录账号的余额和每一笔交易，其他扩展功能或安装的插件，涉及到交易的，统一通过标准从钱包里交易。
3、通知：附属账号体系有一个共用的通知功能，所有涉及通知功能和插件，都基于标准往这个通知内容表里推送内容（从通知模板生成内容），由这个通知处理所有通知消息。
4、附件：所有涉及附件文件的，统一上传标准，后台也可以统一管理和查看。

也就是这套「后台管理系统」的扩展功能不用考虑账号、钱包、通知、附件等功能，以及这些功能的数据表。同时，通过安装相应扩展的插件来丰富这四个内置模块的功能，比如钱包的充值和提现、通知的模板新增和调用。

安装完成后，这只是一个后台，具体应用到什么业务场景，则由使用者安装相应的插件即可，比如 CMS 插件、BBS 插件、商城插件、CRM 插件等等。除了完整业务功能外，也可以有搭配小功能插件，比如邮件或短信营销插件、投票插件、表单插件等等。另外也可以有游戏插件、办公插件等等。

目前国内像这样做的开源程序，以 PHP 语言为例，只有 FastAdmin 一个，而紧跟其后的 DcatAdmin 正在努力往 FastAdmin 方向发展。但是他们都有一个缺点，对普通使用者不够友好，或者说他们的定位就是面向技术人员的，这实际上就局限了程序的潜力。所以 FastAdmin 停止更新了，DcatAdmin 也只是一位个人开发者用爱发电维护着，但方向其实也不明朗。

我为什么要推荐面向“普通使用者”，因为这是直接拿着程序去商业化运营的人群，是更愿意花钱的群体，有人愿意花钱才会激励开发者生态的成长。我所说的普通使用者是一群有具体业务场景的人群，真真切切了解市场、了解用户，甚至有流量资源，现在要的就是一个能用的运营载体，所以不管你是 PHP、Python 还是易语言写出来的代码，能 Run 就行。

做这么一个开源程序，运作的是一个双向驱动的领域，更好的插件生态才能吸引更多的使用者（最关键是使用者愿意花钱，而普通使用者是比技术人员更愿意花钱的），更多的使用者才会促进开发者参与生态建设。运作好了是彼此相辅相成，运作不好就是恶性循环。

讲了这么多，我不可能只是为了让现有技术“支持”普通使用者。而我的方案关键就是，插件机制也有开放生态。如上图所示，有普通使用者、二级市场开发者、外包公司。普通使用者不用再介绍了，接下来就介绍另外两个角色。

二级市场开发者：

比如我开篇介绍的社区产品，也是二级市场，我可以基于这个后台系统开发我的社区业务方向的产品。我将社区功能开发成内置插件，然后打包发布成具体业务的程序包，最终普通使用者下载安装使用。再比如内置商城插件，打包成商城业务的程序包。

二级市场的开发者可以选择是否加入插件市场开放生态，加入后，可以立马为业务程序包集成一个拥有丰富插件的插件市场，为程序包增加竞争优势（因为建一个插件生态不容易，加入开放生态就有现成的）。这个就有点类似于 Android 系统，小米、华为、OPPO、OnePlus 等公司的操作系统是基于 Android 二次开发的，相当于是 Android 的二级市场。

外包公司：

不单纯代指外包公司，也可以是直接业务运营的公司技术员工，或者是个人开发者。只要有业务需求，都可以基于这套系统，快速开发业务功能，无需再从零开发一套基础功能，节省开发时间和成本。目前市场上的开源程序就是这种方向，让后台开发更简单，但是只面向开发者的后端框架，几乎没有任何商业价值。

而我的思路是直接面向业务提供支持，开发者不仅可以将开发的功能内置打包成程序包交付给客户，同时也可以二次利用，发布到插件市场，免费或收费的向一级和二级市场销售。如果是一个完整的功能插件，也可以内置打包成一个独立业务程序包（下次遇到同样需求就不用再从零开发了，也不用担心底层结构会被淘汰），业务程序包也可以单独销售或者开源出去。

文章讲的是产品层面的思路，具体的技术细节就不聊了，毕竟我的读者没几个是程序员。如果实在有人对技术解决方案的可行性和思路感兴趣，可以给我留言，我们可以私下讨论，我也写了技术策划案。

最后再说一下关于插件之间互相通讯的机制，思路有几种，我分享一种思路，叫做“谁触发则由谁解析”。因为要考虑多端跨平台和二级市场，所以插件之间能够通讯是非常关键的条件，这样插件可以交叉使用，扩大使用场景。但是又不能局限了标准，否则就限制了插件的想象空间，所以可以采用开放式通讯，每个插件有自己的通讯数据结构，然后由触发者去解析，我能触发你，自然是认识你，认识你就能解析你的信息，所以插件无需考虑和谁会产生通讯。