@FrankHB 就常识来讲，特别是你口中的“外行最常出现的只管拿来用的情况下”，是否符合纯粹的“开源”定义，并没有“许可”本身重要。
关注专利确实不会比版权问题更重要，在你考虑引入 FOSS 的时候，它们是同等重要的。如果你不确定，可以咨你司法务。
专利和 OP 说的内容直接相关，是因为有些许可证涵盖了专利授权，但大多数都没有。所以你在使用可能包含专利的第三方代码的时候，更要小心检查它的许可证。

@FrankHB 我想回答的是“这些常见的 License 是什么，有什么用”，并不关心某个 license 符合不符合 OSD 。
最常见的，在公司里，你去跟你司法务说专利授权不重要试试。
不是只有符合 OSD 的才是好东西，开源归开源，生意是生意。你想用人家的东西，就要遵守人家的 license 。不是说某个 license 不符合开源定义就可以不遵守的。

@ssltest 首先，free 或者说 open source 的软件协议都不会“限制商业使用”。根据 GNU 的哲学，“自由”面对不管是大公司还是个人用户都是平等的。真正限制商业使用的，是商业公司不想让自己的客户获得源代码，和再分发的权力。这个决定是商业公司做的，而不是 license 限制的。
其次，对于 license 最重要的一部分，就是专利授权。你这个完全没说。。。
最后，关于 AGPL 。这个 license 设计的很差，不管对于开源库作者，还是使用者，都是很差的协议。
但就是这样，你的描述也是错的。。
AGPL 的核心在于，认定用户可以与你的系统交互，就认为是你在“分发”。跟你是不是云服务没关系。
AGPL 的问题在于“交互”的认定是很模糊的。对于作者来说，使用者很容易钻空子。对于使用者来说，这种边界界定不清的协议也是垃圾。这也是为什么 MongoDB 把 AGPL 切换成 SSPL 。
看你都挂了推广了，既然想赚这个钱，建议还是专业点。。。

AGPL 的描述也是错的。。。。

@bbbb 我也是。
我基本长直道在自行车道上都是猛蹬，这种路段基本都 25+甚至 30+。直到有次没看到前面有个小路口，有个警车从里面没停直接插出来。
前后刹车捏死了，我整个人直接离开坐垫直接在空中飘着，能深切感到后轮离地差点就飞出去了。
这种状态持续好几秒，感觉我马上就要死了，但是最后还是在警车前面停下了。
从那以后再也不骑快车了。那种你往死里捏刹车，但还是眼睁睁撞上去的，眼看着自己要死却无能为力的感觉，这帖子里天天吹电摩的人肯定是感受不到的。
你就让他们去死就好了。

@matrix67 其它语言倒还好，前端开发这种动不动 node_modules 就上千的，很难挨个看过去的。

@bbbb 骑公路的大佬那都是原地起飞，瞬时 25 摇几下就行了。
可问题是骑到 25+其实很危险，刹车距离很长。城市道路环境复杂的情况下，要么刹不住，要么飞出去。
能骑公路的还都是有一定经验的，给新手一个电动车，加速比大佬摇车还快，随便一拧就上 25 这种确实很危险。
更别说有的人还在车头装个支架一边骑车一边看剧，遇见过几次了，简直离谱。

@dawn009 基本没有竞争力。其实除了买整套解决方案或者设备，设备内置 Linux 的话，一般需要院方协助运维的东西基本都是 Windows 。

如果你要对接的 API 消费者，不只是跟你在同一个地点工作的前端同事，他们的需求也不是你们组定的，那么 GraphQL 可以显著减少沟通成本和你自己的开发成本。
其他情况 RESTful 能遇到的问题，GraphQL 也一样能遇到。并不会省多少事。
但同样的，RESTful 或者瞎写的接口能做到的，GraphQL 也一样可以做。不止 NodeJS ，其他语言，至少我用过的 C#和 Java 的 Client ，功能也都很全。

Bandizip 主要还有个编码转换功能很好用，其它的比较麻烦。

确定一个时间点，比如当前时间，然后把所有 update time 在这之前的数据全拉出来塞到 redis 里。可以想办法跳过序列化和反序列化，直接塞进去。
然后你去查在这时间点以后的 change stream ，按顺序拉到 redis 里。MongoDB 已经给你这功能了，就不要再用 binlog 了。
从此以后用 change stream 同步修改，就可以保证大部分时候都是一致的。

@xmlf 因为狼只想吃你肉，并不想让你加入。
让中国人过上美国人的生活是地球的灾难，这可是前前任头狼自己说的。

还是那句话，开源以前先搞清楚自己选的那个 License 到底是个啥，有什么条件和限制，是不是自己想要的，然后再传代码。
MIT 的唯一限制就是保留 MIT 的 License 声明。我看你已经改了 MIT 里面的作者信息，你可以直接用这点去告他。衡量一下投入产出就是了，而且国内也有几例开源 license 的判例了。
不过如果对方没拿这个赚钱，那你能得到的赔偿就没多少了。

@haython 是，IDEA Ultimate 可以通过插件使用大多数语言特定 IDE 的功能，好像只有 C++和 C#的那俩用不了。

@christin JB 的产品大概可以分为两个系列。
IDEA 系包含各种特定语言的 IDE ，还有 IDEA_U 。
dotUltimate 系列包含 Resharper 和 Rider ，基本上是 C#和 C++的强化工具和 VS 插件。
如果你要用到两种以上 IDEA 系的 IDE ，那就买 IDEA_U 。
如果你要用 C#和任意两种 IDEA 系的 IDE ，那就买全家桶。

健身房，练三休一。周末看情况会额外加一小时有氧。

如果 TeamCity 能满足需求那就 TeamCity ，不然就 Jenkins 。TeamCity 是按 BuildAgent 收费的，如果你们有很多项目，最好还是 Jenkins 。
Jenkins 问题就是插件多数都是第三方个人维护的，很多插件的开发和维护不是很稳定。你要是项目规模大，Jenkins 上项目多，用的插件多，最后就会发现被锁死在某个版本上了。更新的话一堆插件用不了，不更新的话想要的新插件和功能用不上。

这就是架构师的价值了。
说的是正经的架构师，不是那些满口新技术的 PPT 架构师。
软件架构设计和软件需求本身就是互相制约的，什么样的需求就导致会有什么样的架构设计和技术选型，同时这个架构设计又会反过来制约需求的发展。
所以一个好的产品，需要有足够强力和有经验的架构师和 PM 团队来一起界定需求和架构要互相妥协成一个什么样子，然后后续的开发和需求都围绕着这个共识来做。
这就是 DDD 的第一步了。