【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”
XpmJS 是一个小程序云端增强 SDK,它为微信小程序提供了云端能力,降低开发门槛,提升小程序的开发效率。作为长期在云计算领域耕耘的开发者,当初开发 XpmJS 的初衷什么呢?又是如何把小程序和云计算结合起来的, XpmJS 以后的发展方向如何?本期开源访谈邀请到了团队猫创始人王伟平老师,和大家分享他在做小程序后端开发工作中的思考和实践,以及在互联网从业以来的一些经历。
【本期嘉宾】
王伟平,团队猫创始人兼 CEO,微信小程序云端增强 SDK - XpmJS 开源项目发起人。十年以上互联网从业经历,连续创业者,曾供职于九城集团、新浪云,在云计算、互联网+、企业软件和 SaaS 服务领域有着丰富的实战经验。
【访谈实录】
1. 嘉宾自我介绍(技术背景、工作经历和学习经历等)
大家好,我叫王伟平,之前是在新浪云计算的 SAE 工作,当时主要负责 SAE 的运营,所以基本上是跟着 SAE 一起去研究云计算而逐渐成长起来的。刚毕业的时候,在新浪做工程师,后来出来创业,当时算是创办了中国最早的音乐分享网站,和虾米类似。因为没找到商业模式,也没能融资成功,就放弃了这个项目,选择了回去工作。
在 SAE 工作的时候,开始真正接触云计算, 刚加入SAE的时候,SAE 上大概只有两三千的开发者,到我离开的时候, 差不多有近百万的开发者了。 SAE 是一个 PaaS 平台,所以,相对来说我对于云计算了解会更多一点。
从 SAE 出来之后,我做了一个项目叫 “点云”,因为当时 Docker 十分火热,所以在刚火起来的时候,我发现 Docker特别适合用来做云端软件的交付。
比如说 Ghost 博客系统,当时很多开发者不能成功安装 Ghost,因为他们不了解这背后的技术栈,所以安装起来比较费劲,还有很多 Python语言好的开源项目也不能成功安装。所以我就想是不是可以做一个云服务,让完全不懂技术的人点几下鼠标就能成功安装一个开源的产品并使用。这件事就相当于说可以把很多优秀的开源项目拿过来直接给大家使用,所以当初就凭着这个想法做了 “点云”。
但后来发现了两个问题,让我决定放弃这个项目:
- 一方面是很难找到那么多的优秀开源项目,毕竟大家也都了解,大部分开源的产品都是处于 60 分刚刚及格这样的水平,其实能做到 60 分都比较少见。所以第一个问题就是缺少软件。
- 另一个方面就是市场的原因了,这个市场虽然也有,但还是比较小众的。
2. 团队猫这个产品是怎样诞生的?
之前做的产品受众群体是个人,后来转型面向企业之后,我们发现交付这件事情并不是企业的痛点。
因为我们去跟一些大型企业沟通的时候,发现他们完全不关心软件交付这件事,他们更愿意把这件事委托给第三方,让第三方完成,也不关心是如何完成的。而且对于 ERP 等一些类似的大型项目,当真正去部署,去做实施的时候,会发现背后十分复杂,也很难做到一键安装,就算能做到一键安装,也许对于 A 企业有效,但对于 B 企业就无效了,毕竟业务场景不一样,所以当时我就意识到这件事不能再继续做下去了。
因为看见很多网站都是用 WordPress 搭建的,原因是它的可扩展性强,插件也特别多,有各种各样的插件可以把 WordPress 变成一个电商网站或者其他东西。
但我发现所有人都会吐槽 WordPress 一件事,就是它太难用了。因为它背后的接口,包括它的性能和程序都写得相当复杂,刚好我当时在 SAE 工作的时候有过这方面的经验,我就想,能不能把这些基础的资源服务化,比如说,假如要操作一个基础设施资源,例如内存,我们可以提供简单的内存增删改查接口。甚至能做到让用户可以不用查看文档,直接看到代码就能想到 get 是读取,set 是写入,所以当时就做了这样的一个服务库。
因为我们团队刚好也会跟一些大型的企业有合作,他们偶尔会有项目给我们做,所以我们就把这套结构应用在上面了。
后来发现 WordPress 还有一个特点,刚刚说到了它的插件特别多,所以就设计了一个叫 “应用引擎” 的东西,实际上是一个请求的代理,可以把一个请求转发到应用上。所有的后台功能也都是一个个独立的应用组合的,都是模块化的,这些模块也支持热插拔。所以如果客户需要一个文章管理的模块,就安装这个模块,如果需要一个活动管理模块,也把它安装上去。而另外一个客户只需要文章管理不需要活动管理,就只需要安装一个文章管理的模块,但其实最后大家使用的是同一个东西。
因此,最后我们内部交付的都是一个个的应用,而且这些应用模块是非常小的,因为这是功能模块而不是 API 模块,随着我们内部的模块越来越多,后来接受了一些项目之后,把模块稍加拼合就能组合出一个产品了。
这件事,我觉得挺有意思的,当时在找相关的开源实现也没有特别好的产品,所以就有了这样的一个想法,接着就做了团队猫这个产品。
3. 是什么原因促使您开发了 XpmJS?
主要的原因还是像我分享时候说的,项目急着上线。当时只有一个前端工程师可以参与这个项目,我就非常着急,因为页面特别多,如果后端写一遍逻辑,前端再写一遍逻辑肯定不能完成。后来想了想,把团队猫拿过来修改一下也可以,因为也是一个个的接口,接着就做了一个自动化的建表,把数据库改成增删改查通用的。
这个项目大概花了两周的时间,因为后端是现成的,我们就把现成的拿过来稍加修改,而且它本身有一个应用热插拔的机制,拿过来也刚好适用,毕竟不可能提供所有功能,所以一定要支持应用热插拔。
所以就是这样机缘巧合的情况下做了 XpmJS。这个产品我们自己也在用,现在做的一些小程序项目也会用到,用起来确实很方便,因为后端不需要写任何代码,直接调用就可以。
XpmJS还有一个好处,它不会跟任何一个云绑定。这个其实很重要,现在我们正在实现这样的功能,让 XpmJS 后端从 A 云迁移到 B 云只需要几分钟,使用者只需点击一个按钮,或者运行一条指令就可以直接迁移过去,这个实现起来很简单,最终的目的是让大家用得放心。
4. XpmJS 目前怎么推广,在业界的应用情况如何?
因为目前没有融资,所以我就面临着一个最大的问题,要养活团队。
坦率地讲 2D 这件事很难赚钱,所以现在做的更多的推广不是 2D(面向开发者)。目前做得更多的是面向大型企业和中小型企业去推我们的解决方案。
在开发者受众中,使用者目前不是很多,毕竟也是刚刚推出不久,大家接受这个东西也需要一段时间。我也了解到,其实大部分中国的开发者不太愿意用中国人的东西。甚至连我自己开源这个产品的时候,也想着要不要把所有的东西翻译成英文的,后来一想还是算了,反正你做小程序,别人一看就知道是中国的了,没必要弄这个。
另外,XpmJS这个产品对于大家来说,技术含量不是特别高,但它确实可以给大家提供一个方便。所以,大家愿意用就拿去用,如果能改进的话,大家一起改进。万一哪天以开源的方式就成功了呢,因为我本身特别喜欢做开源项目,从大学开始研究 Linux,一直到现在工作,也特别喜欢开源相关的事情。
5. 目前参与开发/维护 XpmJS 的人员有多少?开发/维护过程中遇到最大的难题是什么?
目前做这个项目全职的人员有两个,当然也会有一些兼职的同事来维护、改进代码,一般是远程的合作。但毕竟因为目前的使用者不是特别多,所以参与维护、开发的人也不是很多。
去年在做这个产品的时候,我们的引擎本身会有很多的问题,例如出现错误没有报出来,所以调试起来很麻烦。但是现在陆陆续续的,很多问题都被解决了,已经成熟很多了。
6. XpmJS 将来的发展方向是什么?
XpmJS 是一座 “云桥”,可以链接任何云端资源,为小程序、移动应用和网页提供云资源通道和后端能力。 有人和我纠结说你这个产品到到底是 BaaS、PaaS 还是别的什么。我一般会回答说是 FaaS(Fuck-as-a-Service)。其实是什么真的不用太在意,重要的是提供的服务是不是你需要的。
XpmJS 做的是将用户的产品跟某一个云计算提供商或者服务商连接起来,可以选择用它,也可以选择用别的提供商,我们只是提供一个通道,用户的数据是存储在自己的数据库里面的。比如说开发者写了一个腾讯云的所有 API 作为一个模块,然后放在腾讯云上,别人也写了一个阿里云的模块,使用者需要哪个提供商的,可以直接拿过去安装上就能使用。
我们最终的目标是提供这样的一个产品,像桥一样,愿意用就拿去用,不愿意用可以用自己的。没必要用产品和服务去绑架用户,而应该是用户和开发者主动的拿去用。需要这个东西就拿去用,不需要了就把它放下,等需要的时候再拿过去。所以它应该就是作为一个工具服务,这才是正常的状态。我们所做的就是为开发者提供便利。
我并不是反对商业上的东西,只是觉得这才是一个好的产品应该有的特性。因此最主要的一个定位是把它作为一个开源的,大家都可以使用的产品,无论用户把它当做自己的中间件也好、服务也好。
个人认为,这会是一个趋势,因为在 XpmJS 中,像刚才提到的 Server 中的很多东西,是可以把应用开源出来放到码云上的。可以借助开源的力量,共同推动这件事儿,鼓励大家开发各种云端模块。模块越多的话,产品就会越成熟,大家使用起来就越方便。最后或许会发现,这个东西什么都可以做,开发者拿来用也很方便,提升了开发的效率。
当然这是我的一个愿景,未来还有很长的一段路要走。
7. 你所理解的 “开源精神” 是怎样的?
对于开源这件事,我经历了很多也看了很多,其实唱衰的也有不少。尤其是中国现在的这种环境,大家也都不用太避讳去讲。就像有人说的,没人会看你源代码,也没人给你贡献代码,你开源干嘛?别人都是拿过去就用,然后稍加修改就成了自己的。
我觉得不应该这样去看待这个问题,其实我觉得,尤其是现在互联网发展这么好,我也有很多异地办公的兼职同事,这些同事之间基本靠 “代码交流”,完全不需要坐办公室。从这个角度看,我认为开源也是一种不错的工作方式。我本身也算是工程师,现在转来做商业运营,觉得挺繁琐的,我最开心的时候是写代码的时候。
开源的一个理想的状态应该是这样的: 开发者去做一个开源项目,有另一拨人去经营这个开源项目,去赚钱,然后把赚到的钱分给大家,大家都能通过这件事赚到钱。有了稳定的收入,开发者愿意在哪写代码就在哪写代码,今天高兴了在深圳写代码,明天不高兴了在泰国写代码,而且对于开发者来讲,只需要专注把代码写好就行了。这样更容易把一个产品做到 120 分。这是我心目中理想的开源,也愿意为这个理想去做些具体的事情。
开源中国有强大的商业运作能力,可以帮助开源项目作者发掘开源项目的商业价值(毕竟靠捐赠这件事不靠谱),能给开发者带来价值,并推动开源项目商业化,给客户带来价值。如果某一天,开发者通过开源项目获得的收益能够超过工资的时候(当然这会是一小部分),整个开源的生态也就形成了。
也许真是这样吧。也许还有一个原因是很多中国人的项目对中国人不友好,文档注释都是英文的。对于学习和使用来说,既然都是英文的,那么也就无所谓是国人的还是洋人的了。
其实大部分中国的开发者不太愿意用中国人的东西
这个真的很赞同
一个宅男说的话,P。
等有了家有了孩子,能做到小扎那样就不错了。