我为何在不知不觉间做上了开源

2次阅读

共计 1212 个字符,预计需要花费 4 分钟才能阅读完成。

做了几年的 php,无聊之余、突然很想记录一下,自己是如何走上开源这条不归路。。。

接触 Swoole

第一次接触 swoole, 那个时候的 swoole,还是 1.6.7 版本。为了实现比 php 自带的 curlMulti 更加精准且可控制的爬虫,我把关注点放到了 swoole 身上。在初步的技术评审后,发现 swoole 可以满足我在不改变技术栈的情况下,实现我想要的东西,而且效率比我之前的 fpm 模式高出了很多,因此开始慢慢的试着去使用 swoole。

开始造轮子

说实话,1.6.7 时代的 swoole,生态非常的欠缺,以至于我想找个靠谱的框架都没有(ps: 其实反过来想是哪个时候我比较菜鸡,韩总写的 swoole framework 我又觉得太繁琐),经过一段时间的摸索,写了一个比较简陋的框架,我把它叫 easyPHP-Swoole(其实这么叫的原因在于我觉得 swoole 对于我来说,很难,好不容易才从 fpm 思维转到常驻内存模式,后面在韩总的建议下才改为 easyswoole),并把他开源了。其实那个时候,就仅仅是为了好玩,也觉得不应该再让大家重复造轮子,而且万一要是火了,那也许我也就出名了。

王婆卖瓜

其实 v1 版本的 easyswoole 非常简陋,甚至不支持 composer 包管理,现在反过头来看,真的是漏洞百出。但得益于长年喜欢装逼混迹于各种 php 群内,和我那非常厚的脸皮,我竟然真的忽悠到了几个初始用户。那个时候的我,不容许有任何人说 Easyswoole 的不好,就好比你问我 php 是不是世界上最好的语言,当有人问我什么框架最好最牛逼的时候,我也会肯定的告诉你,那就是我的 Easyswoole。

不得不维护

随着慢慢的被我忽悠的人把 Easyswoole v1 投入生产,他们也开始逐渐的反馈问题和不足,怎么办,修呗,为了自己曾经吹出去的牛逼,含着泪也要把 bug 修完。修完 bug 后,又有人提出,缺少这个功能,或者是 swoole 出协程版本了,怎么不适配(v1 版本是要求同步版本的 swoole),文档这边写的不好,怎么不完善一下等诸多问题。。。我发现,做个开源怎么这么麻烦,问题越来越多,而且吃力不讨好,连文档服务器都是自己掏腰包的。甚至有一段时间,其实很想删库,但是又觉得那样很不负责,毕竟,人家是用了我的代码,那就是信任,如果我出问题我不负责,那其实就是耍流氓。在这样的恶性循环下,出了 v2, 和现在的 v3 版本。

争议不断

后来,随着用户的增多,Easyswoole 有了一个 599 vip 群,专门为基础差或者是不爱看文档的人做解答的付费群。随之而来,就骂声一片了,什么开源还收费,或者是见钱眼开之类。。。其实关于这个问题,我不想解释,也不想说太多,只想告诉那些人,开源不易,且行且珍惜。

不忘初心

其实,我确实曾经考虑过把 Easyswoole 商业化,现在也在考虑,但反观现在的市场和用户量,对于我来说,我还是专心先做好开源,等哪天,用的人多了,我也就真的装逼成功了,也就有钱了。

正文完
 0