mpvue开源后就很少更新了

[SuHeran]

今天看了Taro1.0正式发布，他们开源3个月以后每天都提交几十次，并且还在持续更新完善中，相比较mpvue在这方面真的差太多了，基本处于一个停滞不前的状态，我开始学react了
发这issue的目的是希望mpvue能够活跃起来，有时间多维护一下mpvue生态，毕竟我觉得这对熟悉vue的开发者来说，是非常好的一个框架，不希望就此落寞下去

[imgss]

现在有种骑虎难下的感觉:sweat:

[youngluo]

哎

[TonyLuo]

已经三个月没有版本发布了，准备弃坑，转taro

[nyrf]

#140 (comment) 这个问题N久了，还是个大问题，就是没任何动静，我也发现，同意AibiTi ，但凡vue相关的开源的最后都有点不怎么活跃了，

[insist-dream]

想着进坑呢，看完怎么犹豫了

[XavierShi]

本来前端时间对比之后想学mpvue的，结果发现不怎么活跃了。这点我也是挺奇怪的，好多高星vue项目比如mint-ui、mpvue最后都不维护或者不活跃，倒是react的开源后来比较活跃一点。

[SuHeran]

@nyrf 我在#140 (comment) 问题提交了自己的方案，你看是否能够满足你们项目需求，就是普通的H5方式

[DreamPWJ]

哎 坑

[JasinYip]

我也是 mpvue 的使用者，同时也曾经和 mpvue 项目组在同一个组里面，所以这个问题的出现是完全可以理解的，无论是用户们还是项目组。我试着来解释一下吧，反正我现在也不在美团了，可以来瞎扯了（逃

要讨论这个问题，我们需要先回到「开源」这个事情本身来说。「开源」的初心是为了将好的代码分享给全世界，让全世界的程序员可以减少重复造轮子，让这个世界的程序更稳定高质，让写程序的过程有更高的效率和更好的体验。所以，「开源」本来就是一件分享的事情，作为使用者其实没有权要求更多，维护团队也没有义务去持续维护。我们不能让分享饼干给我们的人要一直无条件地给我们分享饼干。

再者，一旦一个项目开源出来，只要开源协议许可，往往意味着这份代码属于了全世界。为了自己用这个工具的项目也好，为了全世界所有使用这个工具的人也好，我们本身就有义务去帮助这个工具运行得更好。比如很多人会去写教程写文章让更多的人学习使用这个库，也比如有一些人会来提 issue 报 bug，又或者是发 PR 贡献代码。大家共同为这个工具注入价值，影响自己的同时也影响所有别的使用者，这才是双赢。

项目发起方是一家商业公司的一支团队，商业公司是趋利的，投入产出比低的东西只能从别的项目的时间中挤出来做，但国内现实是，别的项目不加班都算好的了。所以只要满足了公司的需求，往往不会给资源去做更多的事。所以，项目组的同学和大家一样，都只能抽出自己的业余时间帮忙维护的。

我们要面对现实。

我的建议是，大家要有 owner 精神，一起去为这个项目思考未来还有什么出路，发起 issue 去讨论，讨论怎么迭代怎么实现，有结论后发起 PR（或者干脆自己 fork 一版更好的），而不是过来抱怨。

[DreamPWJ]

@JasinYip 你说的我理解 但是不认同 如果没有义务去持续维护 你这不是坑人？ 人家京东taro 阿里的项目怎么维护特别频繁？国庆还在更新 人家不工作？ 我们虽然没法要求太多 但是mpuve维护太不给力而已 其他的都是借口 先把明显bug解决 才是王道 已经准备弃用mpvue 用更靠谱更高质量的taro了 这里我只是建议

[JasinYip]

@JasinYip 你说的我理解 但是不认同 如果没有义务去持续维护 你这不是坑人？ 人家京东taro 阿里的项目怎么维护特别频繁？国庆还在更新 人家不工作？ 我们虽然没法要求太多 但是mpuve维护太不给力而已 其他的都是借口 先把明显bug解决 才是王道 已经准备弃用mpvue 用更靠谱更高质量的taro了 这里我只是建议

你没有权利要求要更多。

[DreamPWJ]

@JasinYip 我当然没有权利 我只是建议 你们只是给自己找借口而已

[DreamPWJ]

我一直都是很尊重开源贡献者的 但是如果不听建议 给自己找借口不维护的话 只是可悲

[JasinYip]

@JasinYip 我当然没有权利 我只是建议 你们只是给自己找借口而已

你甚至连我在这个话题下的身份是什么都没弄明白，也就是说你连上面我写的都没看。我只能用中本聪的话来回复你了：如果你没有理解我说的话，我没有时间说服你。

[DreamPWJ]

@JasinYip 阿里的项目大部分都没有KPI 维护很频繁 借口留给自己 行动证明一切

[nyrf]

@JasinYip 其实还好，我们并不是要求多少，我只是觉得，pr有人提了，但并没人理，或者把这个项目放给社区维护，这些都可以，主要现在这个项目还是美团的人管理的，但却不接pr，也不看issue，可以看看，#140 像这样一个大问题，这么久了，没一个人跟进。的确，开源是好，也理解开源的辛苦，但如果开源让很多人入坑了，然后不维护，也不能让社区共同维护，这就是坑了，

[JasinYip]

@JasinYip 其实还好，我们并不是要求多少，我只是觉得，pr有人提了，但并没人理，或者把这个项目放给社区维护，这些都可以，主要现在这个项目还是美团的人管理的，但却不接pr，也不看issue，可以看看，#140 像这样一个大问题，这么久了，没一个人跟进。的确，开源是好，也理解开源的辛苦，但如果开源让很多人入坑了，然后不维护，也不能让社区共同维护，这就是坑了，

看 PR 本身也要花不少精力，我觉得要不然就 fork 出去一份用就好了。#140 那个问题我看过，要动的刀很大，不太好搞，收益也低，反正凑合能用用，估计他们就没动力改了。毕竟 ROI 低公司又不会给资源做。

[nyrf]

@JasinYip 其实还好，我们并不是要求多少，我只是觉得，pr有人提了，但并没人理，或者把这个项目放给社区维护，这些都可以，主要现在这个项目还是美团的人管理的，但却不接pr，也不看issue，可以看看，#140 像这样一个大问题，这么久了，没一个人跟进。的确，开源是好，也理解开源的辛苦，但如果开源让很多人入坑了，然后不维护，也不能让社区共同维护，这就是坑了，

看 PR 本身也要花不少精力，我觉得要不然就 fork 出去一份用就好了。#140 那个问题我看过，要动的刀很大，不太好搞，收益也低，反正凑合能用用，估计他们就没动力改了。毕竟 ROI 低公司又不会给资源做。

所以我说，如果真的公司没精力维护，或者觉得成本高不划算，不如学阿里，自己不维护的丢给社区，毕竟人多力量大，否则最后真是要烂手里，自己没人维护，别人又提交审核不了代码，这是个死循环。

[JasinYip]

@JasinYip 其实还好，我们并不是要求多少，我只是觉得，pr有人提了，但并没人理，或者把这个项目放给社区维护，这些都可以，主要现在这个项目还是美团的人管理的，但却不接pr，也不看issue，可以看看，#140 像这样一个大问题，这么久了，没一个人跟进。的确，开源是好，也理解开源的辛苦，但如果开源让很多人入坑了，然后不维护，也不能让社区共同维护，这就是坑了，

看 PR 本身也要花不少精力，我觉得要不然就 fork 出去一份用就好了。#140 那个问题我看过，要动的刀很大，不太好搞，收益也低，反正凑合能用用，估计他们就没动力改了。毕竟 ROI 低公司又不会给资源做。

所以我说，如果真的公司没精力维护，或者觉得成本高不划算，不如学阿里，自己不维护的丢给社区，毕竟人多力量大，否则最后真是要烂手里，自己没人维护，别人又提交审核不了代码，这是个死循环。

社区想维护其实都可以 fork 出去一份去维护的，开源社区有不少这样的例子，不一定要在原仓库里改，这也是 git 原本的设计。

[DreamPWJ]

别争了 强东说的对 一切的不行都归咎于人的不行

[DreamPWJ]

想留下的留下 不想留下的走人 再争 人家也是不维护白搭

[TonyLuo]

要是不投入资源去维护了，最起码要发一个声明吧？

[westudiodev]

有闲工夫扯淡，还不如老老实实学习小程序开发。毕竟mpvue也好，Taro也好都只是工具。能用则用。要怪就要怪微信为何不用vue框架。

[nyrf]

@JasinYip 其实还好，我们并不是要求多少，我只是觉得，pr有人提了，但并没人理，或者把这个项目放给社区维护，这些都可以，主要现在这个项目还是美团的人管理的，但却不接pr，也不看issue，可以看看，#140 像这样一个大问题，这么久了，没一个人跟进。的确，开源是好，也理解开源的辛苦，但如果开源让很多人入坑了，然后不维护，也不能让社区共同维护，这就是坑了，

看 PR 本身也要花不少精力，我觉得要不然就 fork 出去一份用就好了。#140 那个问题我看过，要动的刀很大，不太好搞，收益也低，反正凑合能用用，估计他们就没动力改了。毕竟 ROI 低公司又不会给资源做。

所以我说，如果真的公司没精力维护，或者觉得成本高不划算，不如学阿里，自己不维护的丢给社区，毕竟人多力量大，否则最后真是要烂手里，自己没人维护，别人又提交审核不了代码，这是个死循环。

社区想维护其实都可以 fork 出去一份去维护的，开源社区有不少这样的例子，不一定要在原仓库里改，这也是 git 原本的设计。

嗯，你说的对，说到这份上，也应该看的出来是以后不维护了，至少曾经用的挺不错的，还是感谢下。

[JasinYip]

嗯，你说的对，说到这份上，也应该看的出来是以后不维护了，至少曾经用的挺不错的，还是感谢下。

我的话不代表项目组哈

[netbuffer]

希望开发团队能表个态

[hucq]

感谢 @JasinYip 建议以及给社区传达我们的项目组日常。Jasin 的建议可以给到有技术工程能力和时间的团队或个人，但对更多的使用者不具有普遍意义，日常维护还是会继续由 mpvue 项目组承担。

所有参与讨论的同学的期望我们能体会到，mpvue 没有变的足够快足够好，响应不及时，维护不足是我们的责任，我们接受建议和批评。所幸目前 mpvue 依然能提供常规的使用，多数问题虽然不是最优解，但也有社区的各种优化建议，在此一并感谢。

过去的一个季度，我们的工作状态不足以提供有质量和规模的迭代更新，整个项目团队在其它项目中的投入超出常规，我们梳理出的计划也没有持续展开。社区的声音我们一直在主动关注，在我们拿出方案之前没有主动表态。最近我们已经大体协调完成，接下来会从 mpvue 在社区遗留问题和更多平台支持方面入手，把 mpvue 继续推进。

感谢大家的关注，未来的半年，mpvue 是我的主要工作，请耐心期待我们的后续更新！
这里也算是正式回复一下大家：mpvue 项目将加大投入继续更新！

纠正一下：https://github.com/mpvue 这个group里有我们更多的依赖项目迭代，并不是如有的同学说的，我们三个月都没有更新。

[nyrf]

感谢 @JasinYip 建议以及给社区传达我们的项目组日常。Jasin 的建议可以给到有技术工程能力和时间的团队或个人，但对更多的使用者不具有普遍意义，日常维护还是会继续由 mpvue 项目组承担。

所有参与讨论的同学的期望我们能体会到，mpvue 没有变的足够快足够好，响应不及时，维护不足是我们的责任，我们接受建议和批评。所幸目前 mpvue 依然能提供常规的使用，多数问题虽然不是最优解，但也有社区的各种优化建议，在此一并感谢。

过去的一个季度，我们的工作状态不足以提供有质量和规模的迭代更新，整个项目团队在其它项目中的投入超出常规，我们梳理出的计划也没有持续展开。社区的声音我们一直在主动关注，在我们拿出方案之前没有主动表态。最近我们已经大体协调完成，接下来会从 mpvue 在社区遗留问题和更多平台支持方面入手，把 mpvue 继续推进。

感谢大家的关注，未来的半年，mpvue 是我的主要工作，请耐心期待我们的后续更新！
这里也算是正式回复一下大家：mpvue 项目将加大投入继续更新！

纠正一下：https://github.com/mpvue 这个group里有我们更多的依赖项目迭代，并不是如有的同学说的，我们三个月都没有更新。

首先感谢你们的付出，希望mpvue可以更好，毕竟vue是用习惯了，期待接下来的更新

[SuHeran]

感谢 @JasinYip 建议以及给社区传达我们的项目组日常。Jasin 的建议可以给到有技术工程能力和时间的团队或个人，但对更多的使用者不具有普遍意义，日常维护还是会继续由 mpvue 项目组承担。

所有参与讨论的同学的期望我们能体会到，mpvue 没有变的足够快足够好，响应不及时，维护不足是我们的责任，我们接受建议和批评。所幸目前 mpvue 依然能提供常规的使用，多数问题虽然不是最优解，但也有社区的各种优化建议，在此一并感谢。

过去的一个季度，我们的工作状态不足以提供有质量和规模的迭代更新，整个项目团队在其它项目中的投入超出常规，我们梳理出的计划也没有持续展开。社区的声音我们一直在主动关注，在我们拿出方案之前没有主动表态。最近我们已经大体协调完成，接下来会从 mpvue 在社区遗留问题和更多平台支持方面入手，把 mpvue 继续推进。

感谢大家的关注，未来的半年，mpvue 是我的主要工作，请耐心期待我们的后续更新！
这里也算是正式回复一下大家：mpvue 项目将加大投入继续更新！

纠正一下：https://github.com/mpvue 这个group里有我们更多的依赖项目迭代，并不是如有的同学说的，我们三个月都没有更新。

作为mpvue的受益者，听到你这样的回复非常高兴，也非常感谢贵团队能够开源mpvue供所有开发者使用，辛苦各位了

[keyuanupup]

感谢 @JasinYip 建议以及给社区传达我们的项目组日常。Jasin 的建议可以给到有技术工程能力和时间的团队或个人，但对更多的使用者不具有普遍意义，日常维护还是会继续由 mpvue 项目组承担。

所有参与讨论的同学的期望我们能体会到，mpvue 没有变的足够快足够好，响应不及时，维护不足是我们的责任，我们接受建议和批评。所幸目前 mpvue 依然能提供常规的使用，多数问题虽然不是最优解，但也有社区的各种优化建议，在此一并感谢。

过去的一个季度，我们的工作状态不足以提供有质量和规模的迭代更新，整个项目团队在其它项目中的投入超出常规，我们梳理出的计划也没有持续展开。社区的声音我们一直在主动关注，在我们拿出方案之前没有主动表态。最近我们已经大体协调完成，接下来会从 mpvue 在社区遗留问题和更多平台支持方面入手，把 mpvue 继续推进。

感谢大家的关注，未来的半年，mpvue 是我的主要工作，请耐心期待我们的后续更新！
这里也算是正式回复一下大家：mpvue 项目将加大投入继续更新！

纠正一下：https://github.com/mpvue 这个group里有我们更多的依赖项目迭代，并不是如有的同学说的，我们三个月都没有更新。

加油，支持！

[marsprince]

我也是 mpvue 的使用者，同时也曾经和 mpvue 项目组在同一个组里面，所以这个问题的出现是完全可以理解的，无论是用户们还是项目组。我试着来解释一下吧，反正我现在也不在美团了，可以来瞎扯了（逃

要讨论这个问题，我们需要先回到「开源」这个事情本身来说。「开源」的初心是为了将好的代码分享给全世界，让全世界的程序员可以减少重复造轮子，让这个世界的程序更稳定高质，让写程序的过程有更高的效率和更好的体验。所以，「开源」本来就是一件分享的事情，作为使用者其实没有权要求更多，维护团队也没有义务去持续维护。我们不能让分享饼干给我们的人要一直无条件地给我们分享饼干。

再者，一旦一个项目开源出来，只要开源协议许可，往往意味着这份代码属于了全世界。为了自己用这个工具的项目也好，为了全世界所有使用这个工具的人也好，我们本身就有义务去帮助这个工具运行得更好。比如很多人会去写教程写文章让更多的人学习使用这个库，也比如有一些人会来提 issue 报 bug，又或者是发 PR 贡献代码。大家共同为这个工具注入价值，影响自己的同时也影响所有别的使用者，这才是双赢。

项目发起方是一家商业公司的一支团队，商业公司是趋利的，投入产出比低的东西只能从别的项目的时间中挤出来做，但国内现实是，别的项目不加班都算好的了。所以只要满足了公司的需求，往往不会给资源去做更多的事。所以，项目组的同学和大家一样，都只能抽出自己的业余时间帮忙维护的。

我们要面对现实。

我的建议是，大家要有 owner 精神，一起去为这个项目思考未来还有什么出路，发起 issue 去讨论，讨论怎么迭代怎么实现，有结论后发起 PR（或者干脆自己 fork 一版更好的），而不是过来抱怨。

俊星不在美团了吗，基础服务平台还是很优秀的组，曾经接触过，希望以后有机会共事

[JasinYip]

俊星不在美团了吗，基础服务平台还是很优秀的组，曾经接触过，希望以后有机会共事

嗯，去高德了，不过与本题无关哈😄来来来给我投简历一起共事（逃

[marsprince]

俊星不在美团了吗，基础服务平台还是很优秀的组，曾经接触过，希望以后有机会共事

嗯，去高德了，不过与本题无关哈😄来来来给我投简历一起共事（逃

那我得好好准备一下简历😄

[zxzhgk]

我也认为开源项目，人家是没有责任来给你提供饼干的。很感谢美团项目团队开源出这么优秀的工具。想要项目好得大家一起出力去维护，有能力的提PR或者自己修改。在这里责怪就不对了，比较人家没拿你给的工资

[nyrf]

我也认为开源项目，人家是没有责任来给你提供饼干的。很感谢美团项目团队开源出这么优秀的工具。想要项目好得大家一起出力去维护，有能力的提PR或者自己修改。在这里责怪就不对了，比较人家没拿你给的工资

你可以看清我们上面讨论的，我们只是问如果不维护了，提的pr有用么，谁去审核合并代码？自己去看看请多人提了多少pr都没有一个解决的，我们只是建议如果真不维护，让社区大家一起维护，这样bug也可以快速修复。而且现在美团的人员也说了，暂时没考虑让社区来维护，还是美团来维护的，所以至少我们讨论也知道了官方还会维护。再一个，开源是要感谢，但有问题总不能不讨论吧？

[JasinYip]

你可以看清我们上面讨论的，我们只是问如果不维护了，提的pr有用么，谁去审核合并代码？自己去看看请多人提了多少pr都没有一个解决的，我们只是建议如果真不维护，让社区大家一起维护，这样bug也可以快速修复。而且现在美团的人员也说了，暂时没考虑让社区来维护，还是美团来维护的，所以至少我们讨论也知道了官方还会维护。再一个，开源是要感谢，但有问题总不能不讨论吧？

没觉得他说的话有什么问题，你要注意这些人就是在责怪维护团队，还美其名称之为「建议」。如果你无法理解开源精神，可以再多思考一下，不要总说什么不交给社区维护来指责，现在没有人禁止你 fork 出去维护。

[JasinYip]

当年 CoffeeScript 的作者也是长时间没有维护，当时大家提的 issue 是「CoffeeScript 的未来在哪里」，一起讨论如何继续发展，而不是「CoffeeScript 是不是不维护了，不维护就交给社区维护」，这就是你们和他们的区别。

[DreamPWJ]

当年 CoffeeScript 的作者也是长时间没有维护，当时大家提的 issue 是「CoffeeScript 的未来在哪里」，一起讨论如何继续发展，而不是「CoffeeScript 是不是不维护了，不维护就交给社区维护」，这就是你们和他们的区别。

所以CoffeeScript 未来已被TypeScript代替，还有建议关闭评论 ，不想看撕逼和圣人婊说辞

[JasinYip]

所以CoffeeScript 未来已被TypeScript代替，还有建议关闭评论 ，不想看撕逼和圣人婊说辞

一点逻辑思维一点理解能力都没有，还来戴帽子人身攻击，真是没有教养。

[muzi131313]

确实建议关闭issue， @SuHeran ，mpvue团队也给出会投入更多精力维护、迭代的回复了。应该是完美结局了吧！一直觉得mpvue团队做的工作很赞，后续公司的新项目会入坑 ~ 加油~

[nyrf]

你可以看清我们上面讨论的，我们只是问如果不维护了，提的pr有用么，谁去审核合并代码？自己去看看请多人提了多少pr都没有一个解决的，我们只是建议如果真不维护，让社区大家一起维护，这样bug也可以快速修复。而且现在美团的人员也说了，暂时没考虑让社区来维护，还是美团来维护的，所以至少我们讨论也知道了官方还会维护。再一个，开源是要感谢，但有问题总不能不讨论吧？

没觉得他说的话有什么问题，你要注意这些人就是在责怪维护团队，还美其名称之为「建议」。如果你无法理解开源精神，可以再多思考一下，不要总说什么不交给社区维护来指责，现在没有人禁止你 fork 出去维护。
这个上面其实讨论过，最早的讨论是因为公司要做小程序，评估风险，然后我发了个问下还维护不？后来几天后团队的人说后面会维护，如果说，这个都算责怪，那不好意思，我道歉。也不想再讨论了，用一句俗的话说，至少曾经 爱过，

[SuHeran]

确实建议关闭issue， @SuHeran ，mpvue团队也给出会投入更多精力维护、迭代的回复了。应该是完美结局了吧！一直觉得mpvue团队做的工作很赞，后续公司的新项目会入坑 ~ 加油~

我没有权限关闭

[7obe]

哈哈，别人就是问一下还维护不维护，有必要这样撕逼吗？感谢项目组的同学

[Amorites]

首先感谢项目组，mpvue 对我的工作产生了很大的帮助，让我们可以用更有趣的方法来写小程序。

然后现在的关键问题是：有很多有能力、有精力的同学，想给项目做贡献但是受限于日常维护资源不足而无法投入。 我们希望mpvue能够更好地利用社区的力量发展。

提一些可以操作的建议：

1. 建一个「志愿者群」，招募有能力、有精力的人帮忙维护。志愿者:

• 面对feature request虽然不能决定一个功能要不要做，但可以初步分析判断，两边联系
• 虽然不能快速定位bug，给反馈，但是可以向内部寻求初步帮助，根据提示的文件/代码位置去找
• 虽然不能合入一个PR，但可以指出一些常见问题、分配reviewer
• 可以从简单需求开始，根据自身优先级承担编码任务

2. 人力多一些之后，公布一些相关制度来增强社区用户信心，如：

• 建立issue回复制度，规定24小时之内一定有回复之类的保证，同时对issue质量作出要求，不合规范的直接关闭。
• pr处理制度
• 志愿者流动制度

希望能继续讨论下去，祝社区越来越好。

[DreamPWJ]

@achellies 说实话人家是没有时间去维护 也不愿意给社区 所以就一直这样

[hucq]

@achellies 说实话人家是没有时间去维护 也不愿意给社区 所以就一直这样

如果你有关注过我们的提交记录，应该能看到我们的迭代。github 和 npmjs 都有的。
你说这些毫无意义，不如提点建设性意见。

[DreamPWJ]

@hucq 看看你们的PR审核不完善 有迭代的都是其他人做的核心PR 你们项目组我看到的只是代码风格处理和readme更新而已 恕我直言 莫怪 我提建议不是最重要的 重要的是你们先处理完正式版的明显bug 谢谢

[imyellow]

建议放个捐款途径，作为使用用户，工作上提供的帮助很多，相信大家都愿意给项目组一些更实际的感谢作为支持，换框架成本太高，还是希望可以持续更新维护，捐款表达一下谢意也是很应该，@hucq 不用太過客气

[Lingouzi]

。。。所以更新频率是多少啊，要是以后维护频率太低，就不能选着这个了。