项目开源方面： 什么叫开源项目

最直接的说法就是开放源代码。开放源代码软件就是在开放源代码许可证下发布的软件，以保障软件用户自由使用及接触源代码的权利。这同时也保障了用户自行修改、覆制以及再分发的权利。简而言之，所有公布软件源代码的程序都可以称为开放源代码软件。

其他答案:开源项目要求低点，比较容易普及，往往会向平民化发展，发展变化比较快，比如安卓，非开源项目要求高点，往往会向高层次发展，创新变化要慢点，比如苹果。

项目开源方面： 工程项目如何开源增收？ 爱问知识人

1、合理利用承包合同中有利条款因招投标制度在国内建筑市场的广泛实施，特别是最低价中标原则的实行，施工企业中标项目的利润已经很小，个别情况下甚至没有利润。 在这种情况下，项目实施过程中能否依据合同条款进行有效的变更和索赔，成为项目是否...展开全部

项目开源方面： 项目管理：开源、节流哪个更重要？

项目管理，有两种管理思想是平时遇到最多的。一种是节流型，管理者强调执行力和管理纪律，严抓员工纪律，从各个方面节约成本，力求最低成本最高回报；另一种是开源型，管理者强调结果导向，为了实现目标，不记一切努力。两种管理风格，没有绝对的错...展开全部

项目开源方面： 如何熟悉一个开源项目？

1.首先，查找和阅读该项目的博客和资料，通过google你能找到某个项目大体介绍的博客，快速阅读一下就能对项目的目的、功能、基本使用有个大概的了解。2.阅读项目的文档，重点关注类似Getting started、Example3.如果该项目有提供现成的example工程...展开全部

其他答案:相信自己的判断吧

项目开源方面：开源项目通常是怎么赚钱的?譬如像Vue这种，不太清楚开源项目背后的商业逻辑？

很多人愿意把自己的代码开源，大概分三种情况吧。

第一、纯粹是为了获得成就感和心理满足感，无经济收益

人嘛，总得有个追求，不是所有追求都可以用钱来衡量的。最典型的，有的人每天花几个甚至十几个小时玩网络游戏，建立游戏中的公会(帮会)，玩得不亦乐乎，还花大量精力在游戏论坛免费分享游戏心得、免费解答问题。不挣钱，反而还烧钱买道具买装备冲VIP等级，他们图啥呢？玩开源，也是类似，如果用的人多，互动多，那种成就感是很难用金钱衡量的。更极端的情况，当一个人生活不愁时，他们会做什么。除了金钱和女人，其他爱好多了去了。钟南山院士倒贴钱都要游走各地帮大家抗疫，也是这个道理。那就是使命感、成就感，甚至是责任。是将自己的高级技能免费贡献给全人类。

这个理由显然不是我们的重点，因为更多的人还是利益至上的，所谓无利不起早嘛。下面看看第二点。

第二、通过开源可以让全世界的高手共同维护代码，使它越来越完善

通常说来，做这种事的多数都是大型公司。这类开源代码质量也非常高。我们平常项目中引用的大部分都属于这种情况。有些开源项目正是开源者正在做的项目中的其中一小部分。开源后，如果反应较好，就可以得到全世界很多高手包括大公司的使用，他们会提出很多建议，还会帮着维护代码，查找和修复bug。有这种免费劳动力，多好的事！

与第一个原因不同，这个是通过代码共享，实现互利共赢。开源者能让使用者帮助完善；而使用者可以避免重复造轮子，可以直接使用优秀成果。

我们也看到了，大公司一般并不会开源他们的核心技术。比如腾讯不会开源它的QQ微信和热门游戏，百度谷歌不会开源搜索引擎。所以说，他们开源不会担心技术被人学会。

第三，开源可以做增值服务

开源软件一定是免费软件吗？按道理说是。但实际上，开源软件也是可以盈利的。这种盈利来自于服务费。意思是说软件本身免费的，随便用，但是如果想要服务，那就可以收钱了。

服务分很多形式。比如有的开源项目异常庞大和复杂，普通小公司玩不转，他们就会花钱请人帮忙咨询。还可以找人帮忙安装部署、修改配置文件、调优等等。这也算服务费(需要人工嘛)。要知道部署一个大型集群可不是那么简单！而最熟悉的莫过于作者本人(含公司)了。有的开源软件基于命令行，很难使用，作者可能会开发图形界面或集成开发环境。但是，付费的。它的逻辑就是不用这个付费软件也可以，而且工作的很好，但是如果你玩不转你就得买界面友好软件。

再比如谷歌为什么开源安卓？要知道安卓虽然开源了，但是谷歌搜索、谷歌地图可没有开源。而多数用户(不含国内)，高度依赖这些东西。那么手机厂商就要给谷歌钱购买搜索和地图的使用许可费用。

还有的开源软件分两个版本，一个是免费版，一个是付费版。前者可以用于学习和研究。后者功能更多或者用于大规模盈利必须购买后者。

有的开源软件提供付费托管服务。意思是说，要想用好这个软件还得用官方的托管服务最靠谱，自己搭建当然可以，但是难度大运维成本高或者没有生态。有的服务提供市场功能。比如一个开源游戏引擎，虽然免费，但是想获取更多的优质资源(3D模型、贴图)，需要去官方市场购买。类似于手机的APP应用商店。

项目开源方面：有适合新手的C++开源项目吗？

一般都是用的微软的MicrosoftVisualC++.

还想开源方面的就用gcc,g++.

项目开源方面：工作中，开源项目如何更好地选择？

作为一个老开发人员，我个人认为在选择开源项目的时候可以从以下几个方面考虑考虑！

软件开发领域有一个流行的原则：DRY，Don't repeat yourself。翻译过来更通俗易懂：不要重复造轮子。开源项目的主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？

然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分技术人员都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万条数据，甚至灾难性的事故是全部数据都丢失。

除此以外，虽然 DRY 原则摆在那里，但实际上开源项目反而是最不遵守 DRY 原则的，重复的轮子好多，你有 MySQL，我有 PostgreSQL；你有 MongoDB，我有 Cassandra；你有 Memcached，我有 Redis；你有 Gson，我有 Jackson；你有 Angular，我有 React……总之放眼望去，其实相似的轮子很多！相似轮子太多，如何选择就成了让人头疼的问题了。

怎么办？完全不用开源项目几乎是不可能的，架构师需要更加聪明地选择和使用开源项目。形象点说：不要重复发明轮子，但要找到合适的轮子！但别忘了，如果你开的是保时捷，可别找个拖拉机的轮子。

选：如何选择一个开源项目

1. 聚焦是否满足业务

架构师在选择开源项目时，一个头疼的问题就是相似的开源项目较多，而且后面的总是要宣称比前面的更加优秀。有的架构师在选择时有点无所适从，总是会担心选择了 A 项目而错过了 B 项目。这个问题的解决方式是聚焦于是否满足业务，而不需要过于关注开源项目是否优秀。

Tokyo Tyrant 的教训在开发一个社交类业务时，我们使用了 TT（Tokyo Tyrant）开源项目，觉得既能够做缓存取代 Memcached，又有持久化存储功能，还可以取代 MySQL，觉得很强大，于是就在业务里面大量使用了。但后来的使用过程让人很郁闷，主要表现为：

• 不能完全取代 MySQL，因此有两份存储，设计时每次都要讨论和决策究竟什么数据放 MySQL，什么数据放 TT。

• 功能上看起来很高大上，但相应的 bug 也不少，而且有的 bug 是致命的。例如所有数据不可读，后来是自己研究源码写了一个工具才恢复了部分数据。

• 功能确实强大，但需要花费较长时间熟悉各种细节，不熟悉随便用很容易踩坑。

后来我们反思和总结，其实当时的业务 Memcached + MySQL 完全能够满足，而且大家都熟悉，其实完全不需要引入 TT。

简单来说：如果你的业务要求 1000 TPS，那么一个 20000 TPS 和 50000 TPS 的项目是没有区别的。有的架构师可能会担心 TPS 不断上涨怎么办？其实不用过于担心，架构是可以不断演进的，等到真的需要这么高的时候再来架构重构，这里的设计决策遵循架构设计原则中的“合适原则”和”演化原则”。

2. 聚焦是否成熟

很多新的开源项目往往都会声称自己比以前的项目更加优秀：性能更高、功能更强、引入更多新概念……看起来都很诱人，但实际上都有意无意地隐藏了一个负面的问题：更加不成熟！不管多优秀的程序员写出来的项目都会有 bug，千万不要以为作者历害就没有 bug，Windows、Linux、MySQL 的开发者都是顶级的开发者，系统一样有很多 bug。

不成熟的开源项目应用到生产环境，风险极大：轻则宕机，重则宕机后重启都恢复不了，更严重的是数据丢失都找不回来。还是以我上面提到的 TT 为例：我们真的遇到异常断电后，文件被损坏，重启也恢复不了的故障。还好当时每天做了备份，于是只能用 1 天前的数据进行恢复，但当天的数据全部丢失了。后来我们花费了大量的时间和人力去看源码，自己写工具恢复了部分数据，还好这些数据不是金融相关的数据，丢失一部分问题也不大，否则就有大麻烦了。

所以在选择开源项目时，尽量选择成熟的开源项目，降低风险。

你可以从这几个方面考察开源项目是否成熟：

• 版本号：除非特殊情况，否则不要选 版本的，至少选 版本的，版本号越高越好。

• 使用的公司数量：一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好，数量越多越好。

• 社区活跃度：看看社区是否活跃，发帖数、回复数、问题处理速度等。

3. 聚焦运维能力

大部分架构师在选择开源项目时，基本上都是聚焦于技术指标，例如性能、可用性、功能这些评估点，而几乎不会去关注运维方面的能力。但如果要将项目应用到线上生产环境，则运维能力是必不可少的一环，否则一旦出问题，运维、研发、测试都只能干瞪眼，求菩萨保佑了！

你可以从这几个方面去考察运维能力：

• 开源项目日志是否齐全：有的开源项目日志只有寥寥启动停止几行，出了问题根本无法排查。

• 开源项目是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况。

• 开源项目是否有故障检测和恢复的能力，例如告警、切换等。

如果是开源库，例如 Netty 这种网络库，本身是不具备运维能力的，那么就需要在使用库的时候将一些关键信息通过日志记录下来，例如在 Netty 的 Handler 里面打印一些关键日志。

用：如何使用开源项目

1. 深入研究，仔细测试

很多人用开源项目，其实是完完全全的“拿来主义”，看了几个 Demo，把程序跑起来就开始部署到线上应用了。这就好像看了一下开车指南，知道了方向盘是转向、油门是加速、刹车是减速，然后就开车上路了，其实是非常危险的。

Elasticsearch 的案例我们有团队使用了 Elasticsearch，基本上是拿来就用，倒排索引是什么都不太清楚，配置都是用默认值，跑起来就上线了，结果就遇到节点 ping 时间太长，剔除异常节点太慢，导致整站访问挂掉。

MySQL 的案例很多团队最初使用 MySQL 时，也没有怎么研究过，经常有业务部门抱怨 MySQL 太慢了。但经过定位，发现最关键的几个参数（例如，innodb_buffer_pool_size、sync_binlog、innodb_log_file_size 等）都没有配置或者配置错误，性能当然会慢。

你可以从这几方面进行研究和测试，更详细的完整方法可以参考专栏特别放送《如何高效的学习开源项目》：

• 通读开源项目的设计文档或者白皮书，了解其设计原理。

• 核对每个配置项的作用和影响，识别出关键配置项。

• 进行多种场景的性能测试。

• 进行压力测试，连续跑几天，观察 CPU、内存、磁盘 I/O 等指标波动。

• 进行故障测试：kill、断电、拔网线、重启 100 次以上、切换等。

2. 小心应用，灰度发布

假如我们做了上面的“深入研究、仔细测试”，发现没什么问题，是否就可以放心大胆地应用到线上了呢？别高兴太早，即使你的研究再深入，测试再仔细，还是要小心为妙，因为再怎么深入地研究，再怎么仔细地测试，都只能降低风险，但不可能完全覆盖所有线上场景。

Tokyo Tyrant 的教训还是以 TT 为例，其实我们在应用之前专门安排一个高手看源码、做测试，做了大约 1 个月，但最后上线还是遇到各种问题。线上生产环境的复杂度，真的不是测试能够覆盖的，必须小心谨慎。

所以，不管研究多深入、测试多仔细、自信心多爆棚，时刻对线上环境和风险要有敬畏之心，小心驶得万年船。我们的经验就是先在非核心的业务上用，然后有经验后慢慢扩展。

3. 做好应急，以防万一

即使我们前面的工作做得非常完善和充分，也不能认为万事大吉，尤其是刚开始使用一个开源项目，运气不好可能遇到一个之前全世界的使用者从来没遇到的 bug，导致业务都无法恢复，尤其是存储方面，一旦出现问题无法恢复，可能就是致命的打击。

MongoDB 丢失数据某个业务使用了 MongoDB，结果宕机后部分数据丢失，无法恢复，也没有其他备份，人工恢复都没办法，只能接一个用户投诉处理一个，导致 DBA 和运维从此以后都反对我们用 MongoDB，即使是尝试性的。

虽然因为一次故障就完全反对尝试是有点反应过度了，但确实故障也给我们提了一个醒：对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。例如，如果要用 MongoDB 或者 Redis，可以用 MySQL 做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救命！

改：如何基于开源项目做二次开发

1. 保持纯洁，加以包装

当我们发现开源项目有的地方不满足我们的需求时，自然会有一种去改改的冲动，但是怎么改是个大学问。一种方式是投入几个人从内到外全部改一遍，将其改造成完全符合我们业务需求。但这样做有几个比较严重的问题：

• 投入太大，一般来说，Redis 这种级别的开源项目，真要自己改，至少要投入 2 个人，搞 1 个月以上。

• 失去了跟随原项目演进的能力：改的太多，即使原有开源项目继续演进，也无法合并了，因为差异太大。

所以我的建议是不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等。以 Redis 为例，如果我们想增加集群功能，则不要去改动 Redis 本身的实现，而是增加一个 proxy 层来实现。Twitter 的 Twemproxy 就是这样做的，而 Redis 到了 后本身提供了集群功能，原有的方案简单切换到 Redis 即可（详细可参考这里）。

如果实在想改到原有系统，怎么办呢？我们的建议是直接给开源项目提需求或者 bug，但弊端就是响应比较缓慢，这个就要看业务紧急程度了，如果实在太急那就只能自己改了；如果不是太急，建议做好备份或者应急手段即可。

2. 发明你要的轮子

这一点估计让你大跌眼镜，怎么讲了半天，最后又回到了“重复发明你要的轮子”呢？

其实选与不选开源项目，核心还是一个成本和收益的问题，并不是说选择开源项目就一定是最优的项目，最主要的问题是：没有完全适合你的轮子！

软件领域和硬件领域最大的不同就是软件领域没有绝对的工业标准，大家都很尽兴，想怎么玩就怎么玩。不像硬件领域，你造一个尺寸与众不同的轮子，其他车都用不上，你的轮子工艺再高，质量再好也是白费；软件领域可以造很多相似的轮子，基本上能到处用。例如，把缓存从 Memcached 换成 Redis，不会有太大的问题。

除此以外，开源项目为了能够大规模应用，考虑的是通用的处理方案，而不同的业务其实差异较大，通用方案并不一定完美适合具体的某个业务。比如说 Memcached，通过一致性 Hash 提供集群功能，但是我们的一些业务，缓存如果有一台宕机，整个业务可能就被拖慢了，这就要求我们提供缓存备份的功能。但 Memcached 又没有，而 Redis 当时又没有集群功能，于是我们投入 2~4 个人花了大约 2 个月时间基于 LevelDB 的原理，自己做了一套缓存框架支持存储、备份、集群的功能，后来又在这个框架的基础上增加了跨机房同步的功能，很大程度上提升了业务的可用性水平。如果完全采用开源项目，等开源项目来实现，是不可能这么快速的，甚至开源项目完全就不支持我们的需求。

所以，如果条件允许的情况下：重新设计完美符合自己业务特点的轮子也是很好的选择！