我觉得@余天升 说的已经相对完整了。但是我觉得大家的回复还是偏片面了一些。而且部分回复的火力主要集中在评价这两种语言上，实际没有回答LZ的问题。

首先，应该从开源社区的风格来说，“一个大集市”我认为是一个比较恰当的比喻，一个吵吵嚷嚷的地方，必然每个项目都可以决定自己项目的开发方式。由于现在彼此之间相互依赖的开源项目大多数都是以Linux平台为开发对象，所以自然和Linux平台自身提供的技术解决方案保持一致是一个比较容易想到的技术策略。

其次，因为Linux社区中的领军人物对C++抱有顾虑（先不谈这个顾虑是否是正确的），导致Linux社区对C++的顾虑比较大。

那么LZ的问题就可以转化成开源社区对C++的顾虑究竟是正确的，还是错误的？我的看法是既正确，也错误。而原因都在于精英治理。

由于Linux内核，以及核心的GNU软件，开发者都是技术上数一数二的精英。所以他们的产品目标，和第三方公司基于Linux平台开发的软件产品目标，略有不同。包括 Linus Torvalds在内的精英们都害怕因为不好的代码而“毁掉”一个优良的作品（当然还有其他的因素）。

而反观一些商业上比较成功的软件，并没有过分强调技术性上的“纯粹性”，而是更多的以商业利益为导向，我认为他们的成功很大程度上是因为他们深刻认识到人的思维很容易将大的问题做分解，但是比较难将小的解决方案组合成大的解决方案。而在这方面，C++应该比C更有优势，更能通过接口、通过封装降低产品各个部分的复杂度，不仅使开发者能够更容易的进行开发，也更能够让需求分析、设计更容易贴近用户实际的使用方式，而不用过分考虑其实现形式是否能够承载。

总之，这两种语言更大的区别我觉得在于设计的哲学，正是由于这种哲学上的不认同，导致了开源项目更多的使用C而不是C++。

《C专家编程》第二章《这不是Bug，而是语言特性》里有一句话：

它（C++）对C语言中存在的一些最基本的问题没有什么改进，而它对C语言最重要的扩展（类）却是建立在脆弱的C类型模型上。

第十一章《你懂得C，所以C++不在话下》里还有一段话：

编程语言有一个特性，称为正交性(orthogonality)。它是指不同的特性遵循同一个基本原则的程度（也就是学会一种特性有助于学习其他的特性）。例如，在Ada中，程序员一旦明白了包(package)的工作原理，也就能够把这个知识应用于泛型包中。令人不快的是，C++中的许多特性是非正交的。精通C++的某个特性并不能给你带来什么线索或向你启发适用于其他特性的思想模型。大多数程序员选择了只使用C++中较简单的一个子集的方法。

STL作为一个模范放在那里人们都不看，非要去写

• 披着C++外衣的C语言

中枪踩坑学不会都是正常的。这根本不是C和C++哪个好的问题，是大众对C++的误解造成的。在用C++的时候，自己水平不高，就不要去用C的部分。都是因为人类的意志力太脆弱，才造成这么多问题的。

不过话说回来，我觉得是因为现在牛逼的一帮人都太老了，但是还没有脱离岗位，所以普遍有这些想法。我们组有一个超厉害的在M$干了二十几年，刚开始进来就用汇编写Fortran编译器的菊苣说，他还是不太喜欢封装得太多的东西。不过人家说得好，这只是一个喜好问题，根本不是什么好什么不好的问题。等以后CPU的核变得跟GPU一样多的时候，C语言就只能成为负担了。

从Github的语言排行榜（）看来，C比C++多了将近一倍。

原因：对于面向对象的编程语言， 除C++外还有许多更好的选项，比如Ruby、Python、PHP和Java（全都比C++排名先前）；相反，C的代替品不多。

1 历史原因, C的历史悠久，基础项目多，很多40多岁的大牛也是基本用C用的多
2 C++属于实验性质的先驱，很多东西都是在C++里面广泛应用起来才推广的，面向对象，泛型等，另外继承C的一些不良东西，导致臃肿琐碎，上手容易，产生高质量的代码不容易，标准不稳定，编译器很后时才支持的比较好。
3 Linus说的很对，关键是设计，如果借鉴设计模式的一些想法，C一样可以写的很好，如果习惯了，开发效率未必会比C++低
4 现代的软件设计讲究模块化设计，各模块分工好了，整个项目不必使用同一种语言，C++的生存空间被压缩不少
6 C++易学难精，很容易纠结到语言细节中，而忘了项目。
7 C++还是很有发展前途，一些必须用native code的，如果不是用C的高手，用C++还是写的快。
8 还忘了一条，C语言都是一个人从头定义的，标准委员会只是略打个补丁。C++是委员会妥协(商业政治和技术)的结果，所以混乱，标准制定进度缓慢。来自于不同的想法，没有很强的一致的风格。不过C++毕竟是需求推动起来的，所以还是符合了开发的需要。

（1）C++比C多了很多特性，让用C++写出来的代码容易不伦不类。
从风格上来说，钟爱C的程序员可能不喜欢。

虽然C++在绝大部分情况下是可以兼容C的，但在某些情况，还是不得不使用 extern C 这样的代码。

（3）我还是认为 C++ 比 C 优秀很多，如果你能很好地驾驭它。
C++ 大师 Bjarne Stroustrup 回答过很多人的一个疑问，大致就是说“C++特性太多了，变得很臃肿，你会不会考虑裁掉一些特性”。他给的答案是“不会，无论是异常、多重继承、还是RTTI”。
原因很简单。如果说多重继承会带来问题，难道C的指针不会吗？还是那句话，只要你能很好地驾驭它！

就我个人来说，作为一个C++程序员，我永远是被C程序员摆在瞧不起的位置，所以开源软件这种证明程序员荣誉的东西，怎么能让那些高傲的人低下头来使用C++呢……
说起来，本人一路低头，从C++学到JAVA再到OB-C……越来越被同行瞧不起……

我认为就是推广，C本来接受度就更好，各种编译器全部可以编译，任何项目都可以借鉴，而且C更简单易维护。C就是首选。不但要首选C，若有可能要做到Clean-C.
我觉得可推广性考虑完全击败linus和大胡子

作为开源项目，和封闭项目不同，要尽量支持更多的平台，对开发环境也不能做太多要求和指定。C 语言比较简单，编译器稳定可靠。而 C++ 虽然有一个标准，但是实践中，各个编译器的实现都不同程度地偏离了标准。这种差别是很恼人的，为项目带来很多麻烦。这时采用纯 C 而不是 C++ 就是一个十分合理的选择。

另外，开源项目很多是基础类库，而 C++ 在很多平台缺乏统一而稳定的二进制接口，无法做到二进制复用。（很遗憾，像 Boost 这样难得一见的著名开源 C++ 项目，在不尊重二进制接口的稳定性这一点上，又是臭名昭著。）那么，从节约用户的编译时间和环保的角度考虑，开源项目采用纯 C 而不是 C++ 也是有理有据的。

C++ 编译器做了很多额外的工作，如程序员不合格，隐藏很多bug。

c++过于复杂，绝大多开发者都不能完全掌握c++所有的特性（c++iso文档有600页你读完了？boost你都看懂了?）c++的另一个问题是不少程序员 包括我 在使用时，不少设计是利用了语言的一些特性，造成了设计上的不良。到最后就很难修改了。某牛说过c++是座山，世界上最大的屎山。我认为也是源于此吧。总之c++容易写出复杂而晦涩也不易修改的代码，这一切不是c++的错。但在c++里很容易发生。这是门给iq190
以上人用的语言，但太多iq70的人在用，所以大牛门纷纷不用了。

c++太复杂了，c++写的库也很复杂，比如stl和boost，调试不方便，不如c清晰简单直接。

C相对于C++而言简单、快速、灵活，C++ 复杂到超出绝大部分精英程序员的控制，而对他们而言用C同样可以实现优雅的继承、封装和多态。C++ 侧重于考验一个人的架构能力，而这种能力对程序员有着很高的要求，稍有不慎，就会伤到自己，还不如用C来实现更完美。

虽然说面向对象给了程序员贴近显示的思考模型，但是在代码中，一些违反常识的事情还是会发生。实际模型和代码模型会有微妙的差别。纯粹的面向对象还比较好处理，一旦用错也可以有一种回到正确模式的倾向。但是c++的面向对象一旦用的不好，或者说用错，各种补丁，不合格的代码，非面向对象的代码就会添加进来，最后导致项目代码混乱，不可维护.....

个人观点，c++的特性比c语言要多得多，如果是一群人共同维护一个项目，很有必要先坐下来定下一些规范：哪些库哪些特性能用，哪些不能用。要不然各自都看不懂对方写的代码。
而参加开源项目的程序员，坐下来沟通的机会相对少一些，而且热衷于开源活动的人们似乎都比较爱好自由，不容易达成一致的意见。
所以干脆选择特性少一点的c语言了。

不能因C++复杂而去唾弃它。。。很多人都是因为它复杂。。所以不用。。那不是语言的错。是人的智商不好。。对于一个大项目来说。。当你的代码超过50万行。。你会发现C++的优势是C永远不能代替的。。。。。

如果你说的开源软件是做底层，用C写是必须的。我不讨论C++的好处，但是他有做不到的东西。
如果底层开源软件用C++写，那么当需要别的语言来使用这个软件时，即作为基础库，这时就有麻烦了。用C写了，很多语言可以真接和C的库交互。C++写的库，只能C++自己使用。必要时还必须用C到处。这也是为什么操作系统不用C++,不是不想用，而是不能用。

这种问题的答案的首要因素不应该是代码积累/沉淀/延续吗？为什么现在人都把精力放在语言特性的比较上？就算很多认识并较好掌握了复杂语言特性的他们，是否有足以拿得出手的项目/代码可以分享或者重用。
显然开源的老祖宗GNU（Gnu's Not Unix）是脱胎于Unix文化，C语言那个时候也已经得到了普遍的接受，兼容性也是最好的，用c并延续已有的c的成熟经验和代码是最自然的事。几乎所有流行的linux环境也都是在这个基础上被搭建起来的，在没有足够大的改变开发工具的必要性来推动的话，这么惯性会延续很久。（其实已经逐步在改变，比如gcc转换到c++上开发）
任何一个仔细考察和研究开源项目，或哪怕仅仅GNU项目本身的人都会发现其中蕴含的是一个巨大的宝库。实际上对于从微软/单机时代走过来的每一个人，在介入到网络（Fidonet/Internet）那一霎时，无不对突然暴露在眼前的源代码项目充满好奇，就仿佛突然发现了宝藏一般迫不及待要去挖掘。
C++乃至后续的项目的确给出了更多的方便编写代码的特性，但因为目前使用的冯氏计算机体系结构以及底层都是类Unix的操作系统也决定的的这些特性都可以通过C这个冯氏汇编语言实现，最多是偶尔稍过繁琐，这种现状暂时还不会得到改变，至少在自动生成代码的量占据一定比例以前。
那么从项目沉淀的角度看，一个最少抽象，又已经有足够底层支撑的语言是最适合用于开发希望被大众接受并广为传播的开源项目的。尽管眼下基本上各种流行语言都有不少的类似项目，但如果以一定的质量/价值/普适性阀值做一个过滤的话，基于c的项目可能存活下来的概率是最高的。越是新潮的高级的东西，要不是只是作为练手的玩具，要不往往仅局限于一个某个较窄的应用场景。
所以某些高级的东西，它们的确能够提高某个具体项目的开发效率，但其中提高最多的是那些随心所欲的成分，而真正能够拿来重用那部分沉淀/积累的东西并不会因此改变太多。人们往往发现每当一个高级的东西被发掘出来，能够得到流行的关键往往是其自身究竟积累到何种程度，实际上每次这个积累过程很可能只是一个重新制造轮子的过程，尽管这些个新造的轮子可能表面显得更加漂亮和光滑。

没那么复杂吧，就是c存在的时间长而已 c本身是优秀的语言，所以一直活到现在。旧时代的项目没有更换语言的理由 但如果看这远些，互联网时代出生的开源项目，基本就是使用新兴语言了。如果还要高性能，c++是不多的选择之一 其实c++11不该和老c++相提并论的