第一，你忽略了开源本身对软件的进步作用。维护大型项目本身是一件很耗资源的事情，而且边际效应明显，一定程度上开源可以缓解这种情况，最典型的就是用户痛点，当项目规模大到一定程度，光靠付费用户反馈你是想把售后累死还是想把用户累死？所以 ‘运营能力不足’ 正确，‘去争取比他们还差的人’ 错误
第二，你忽视了学术圈。不开源谁拿你做实验？谁靠你发 paper ？难道我灌个水还得给你商业付费？最典型的例子就是 LLVM 。LLVM 现在的地位少说一半是学术圈撑起来的，不然早在 2.x 的时候就死了。同样的 LLVM 的出现也降低了 PL 领域发文的难度，过去想做什么先得造轮子，现在拿 LLVM 一把梭。大家互相成就

垃圾的开源项目和垃圾的公司一样多，只不过垃圾的公司死了就灰飞烟灭了，而垃圾的开源项目仍然有可能被看见。
100 个开源项目可能只有 1 个优秀的项目，但这一个优秀的项目又会直接、间接促使 1000 个开源项目出现，从而诞生更多的优秀的项目

@14m3 我们现在招实习，你要不要尝试一下

@14m3 没有专门的校招，但是应届生想来我们也欢迎，直接投简历即可

@chendy sonar 本身的规则太弱了，作为一个靠插件的 framework 还行，我们自己也实现了 sonar 的插件给客户使用过

知道什么样的代码是好代码：看书，各种 effective 系列
知道如何写出好代码：看源码，看多写，写之前多想
保证一直产出好代码：上工具，单测、自测、CI、Static Analysis、Code Review
顺便推荐我司的产品，国内最好的（未来是全球最好的）静态代码分析工具 https://www.sourcebrella.com ，欢迎土豪使用
非土豪请使用各种开源工具

@jdz 如果你对编译和操作系统感兴趣要不要考虑下我司 https://www.sourcebrella.com

个人看法
1、先说第二点，虚拟机和解释器没啥区别，硬要说不同，那就是针对 opcode 除了解释执行外还有 AOT 和 JIT，所以 vm 可以看做是针对 opcode 的 runtime （ AOT + JIT + Interpreter ）的统称，也就是直接面对 opcode 的抽象概念。CPython 叫 Interpreter，如果它加了 Jit，或者本来就有 JIT 的 PyPy，把他们叫做 Python VM 也没啥毛病。
2、除了统一平台，有了 VM 可以做跟多的事情，有些事情可以做的更好，当然也有些事情会更差。做的更好的事情最直观的就是可以带牛逼的 GC，除此之外还有 Virtual Inline，PGO，LTO，以及十分牛逼的 Partial Evaluation，这些 AOT 做起来很麻烦的事情，在有 VM 的情况下属于家常便饭，当然也有做的更烂的比如启动时间，比如要命的 Interproducer Analysis。这就看各种语言的取舍了

第一步文档、README
第二步搞清楚构建过程，编译依赖
第三部执行 testcase、unittest，搞清楚模块的功能，输入输出，重点 API
第四步构造一份输入，从 main 开始执行，尝试调用指定的功能