分享「后台管理系统」开源程序的产品化方案和机会

作者: 唐杰 分类: 奇思妙想 发布时间: 2020-08-27 02:55

在上一篇《杰出产品经理公开课》的文章里,我有提到要搞一个开源社区产品,原本计划基于 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 就行。

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

Lego Admin

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

二级市场开发者:

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

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

外包公司:

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

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


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

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

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

一条评论
  • 唐杰

    2020年8月27日 15:56

    目前技术圈绝大多数人有一个认知误区,因为长期基于「软件包管理系统」开发程序,所以已经丧失了软件设计思维,认为插件或扩展也需要基于「软件包管理系统」的依赖库,所以很难做到「即装即用」的插件机制,甚至像过去那种简易的程序包安装方式也很难实现,因为现在都是命令行了。
    其实这是智力上偷懒,我以 PHP 语言 Laravel 框架举例,国外的 OctoberCMS 就做到了这一点,还有 Flarum 和 Voyager 等等。

发表评论

电子邮件地址不会被公开。 必填项已用*标注