才看到 PHP 协程扩展 Swoole 去年的时候发生的分支事故

[cwcc]

https://github.com/swoole/swoole-src/issues/4434

具体原因好像是因为核心开发者添加了一个可以 RCE 的 Dashboard ，然后被覆盖关闭，此外又和另一个核心开发者起了权限的冲突，最后导致一位成员成立分支 openswoole ，现在两个仓库滚动的版本号都不一致了，而且某些代码从使用上来说不再相互兼容。

出现这种情况感觉挺悲哀的，本来 PHP 生态就进展缓慢，现在好不容易有一个强心针 swoole ，结果也因为开发者的原因导致了分家的情况。

我作为一个 Swoole 框架的开发者和 PHP 部分生态的依赖者，看完这次虽然不是很影响我的进程，但是很影响我对 PHP 社区未来的看法。虽然我已经给 PHP Foundation 捐款，但现在也没看到什么巨大的成效。还有 PHP 大会说是 2022 在 RU 举行，估计现在也没法开了。

[terranboy]

看那作者 应该是可以约见的事

[terranboy]

@terranboy 预见

[Stevenv]

这个框架故事太多

[BruceHong]

没有必要，换 Go 就行，时代在发展，该淘汰还是要淘汰。

[panlatent]

在我的印象里都好像是老早之前的事了。PHP 怎么说呢，实用为主，你说的这个事跟 PHP 其实关系不大，类似这种库发展起来还是相对有限，生态方面不是一个 Swoole 的问题。历史包袱，领域受限，早年的设计问题
... 但所有老语言为了保持兼容也都有各种历史包袱，推陈出新也不奇怪。

以社区驱动的 PHP 还是在不断的变好的，但也很难在其他赛道超车了。我也是 PHP 基金会的捐助者，PHp 基金会最直接的目的是为了帮助 PHP 内核开发者，短期肯定是见不到啥成效，未来 ... 未来可期吧

[jhdxr]

At this stage, all the member's releases have to use matyhtf's PECL account which is ridiculous for a project contributed by a group of people.

我很震惊难道在此之前是几乎没有（以 21 年 18 次的发布次数来看，我心中的几乎没有指的是一次或更少）其他成员去执行发布这个操作吗？如果有的话，居然没有人提出过异议吗？还是说只是也被忽略了？（但哪怕没人提过，我也认为作为唯一的 lead ，韩应该意识到这是个问题并且给自己找一个 backup （于是我去翻了翻 contributor ，更震惊的发现了如果我是韩，我也选不出一个 backup 来））


再回到这次事情的起因上，我也是强烈反对在 core 里边加上一个对外部网站的依赖，无论那个网站是否是商业性质的（而且刚才试了试 business.swoole.com 这个域名还直接因为没备案给 block 了？）。然后 Bruce 指责韩尽管承诺解决，但直到 fork 前都没有实质行动，那个总结的 comment 中并没有提及 introduce 这个 change 的 commit ，所以我去挖了一下，https://github.com/swoole/swoole-src/commit/73372ad07720f3f024d8b86b50d2e96dc9b6c1de 。从 8 号提交，到 14 号（冲突后）删除，其实只有 6 天，尽管是 master 分支，但考虑到没 release 其实我觉得这个时间并不算久。但还是有两个我觉得有问题的点，第一个是刚才发的这个引入这段代码的 commit ，commit message （ Added tests, improved server stats_file, fix core-tests ）中完全没有提及这一点，甚至可以说是将本应是好几个 commit 的文件放到了一个里来提交，至少让我觉得有点想浑水摸鱼。第二个是在 14 号就直接 release 了新版，我也很好奇如果这场撕逼不发生，这段代码是不是就顺势 release 了？


至于对 php 未来的看法，船大难掉头吧。现在的新版更多的是各种语法糖和小修小补，大的一些变更（比如异步 IO ）之类的应该是有生之年都没希望了（这种大的变更 php-internal 时不时都会冒出来相关的讨论，但有一些特性我已经成功地被说服成不要添加那一派了）。web 开发基本上也是小的网站用啥都行，大的也轮不到动态语言。php 应付中小型的网站已经绰绰有余了。

[cwcc]

@jhdxr 感觉就是发布版本时候没有利用 review 机制监督，再加上发布 pecl 帐号共用的事情，感觉管理得不是很好，Swoole 本来应该做得更好的。

[mxalbert1996]

@jhdxr 这句话是说其他成员发布的时候都需要用 matyhtf 的帐号

[ericgui]

这是好事啊

[ToBeHacker]

异步可不是加上 libuv 就兴趣，所有的 IO 操作都需要支持，目前也就 golang 做得还行了

[jhdxr]

@mxalbert1996 是啊，我就是这么理解的（我说的什么话让你误解为理解成别的意思了？）


@cwcc 我觉得不仅是『不是很好』，而是『是很不好』。之前在商业化的过程中韩已经不止一次有被批评过激的行为了，但看了 contributor 的统计后我也不奇怪了。因为韩的代码量的确是压倒性的。

[Alan1978]

Swoole 娱乐圈

[JaguarJack]

只能说 swoole 作者功利心太强

[pangpre]

在用 webman 代码不用改 直接翻几倍的性能，性能测试比 go 还牛。 这算 php 唯一的清流和希望了。

swoole 吃相有点难看了，php 半死不活的，有一半原因是他们瞎搞……swoole_cli 如果还这样 就彻底放弃他们了

[towser]

应用容器用 workman 就行，性能好，功能全。另一个项目频出公关事故，不适合用于长期项目。

[cwcc]

我个人使用过 Workerman ，感觉性能是很强，但是里面的东西非常不组件化，想要改些东西只能重写一整个文件，而且还不是 PSR 规格的。Swoole 做得还算可以，有啥用啥，但是作者搞的每次操作非常迷。
@towser

[liuxu]

行走在荒野之上的 rustman 路过

[cszchen]

PHP 是我主要使用的语言，但是我不建议用 swoole ，需要它的场景都能用 go 或者 node 替代，如果需要跟 PHP 互动，就暴露 Api

[sagaxu]

赚钱不寒碜，但是藏的不够深，被发现了

1. 尝试过推 swoole 收费版，性能更强，被吐槽了，说是拿商业版做小白鼠测试，稳定了 merge 进开源版。
2. 韩天峰撇清，称郭新华的商业公司行为，结果一看股权结构，韩天峰是绝对控股的大股东。
3. 官方推荐 hyperf 时，存在明显对其它基于 swoole 的框架不公的情况，接着撕逼。
4. php fibers 投票的时候，拉拢中国有投票权的人投反对票，实名投的票，藏不住。
5. Dashboard 事件，震惊社区，这么偷偷塞 RCE 进去真的合适吗？

[cwcc]

@sagaxu

1. Swoole 收费版确实非常需要吐槽，这很明显想赚钱想多了。
2. 商业关系内部人士，外面都显得很明显了也不多说。
3. 部分其他 Swoole 框架也存在生态建设排挤的情况，不是少数，不仅限 hyperf 。
4. Fibers 投票应该是立场不同，因为抛开 Swoole 作者立场，Swoole 本身和 PHP Fibers 理念会有冲突，是两个派的做法（ Swoole 和 swow 是 hook 派，官方对 Hook 底层的操作应该比较排斥，所以主推了 Amphp 系的 fibers ）。
5. Dashboard 事件没掀起大的波澜，但是我现在至少知道使用第三方非并入主线的扩展，包括 Composer 依赖，也并不比 npm 被投毒的概率小。

[lap510200]

@cwcc 吹 swoole 的那帮人就是带节奏的，就没看到多少公司项目在用，有这成本的为了生态全使用方便干嘛不上 java. 喜欢折腾追新干嘛不搞 go

[liuyibao]

@cszchen 赞一个

[cszchen]

@lap510200 还真有公司用，面试的时候考我。还有用 swoole 的嘲讽我，我说太初级搞不懂协程，才回想着用 Go 去解决，因为 Go 门槛低。。。

[lap510200]

@cszchen 如果是小公司那估计就是装了。小公司哪有那么牛逼的 To c 项目, 而大公司用 hyperf 还不如 spring 直接搞微服务, java 生态更好，现成的轮子和解决方案多，招到对应的人更容易