既然在语言层面上 Java 要落后于 C#

既然在语言层面上 Java 要落后于 C#，那为何国内 Java 架构到处都是？

差不多四年前，做项目的时候跟阿尔卡特朗讯（现在已经被诺基亚收购了）的一个加拿大小哥、天才程序员聊过天，他才20岁不到，已经是他们那的顶级程序员了，待遇在当时的我们看来是个天文数字。成功在"Java fucks"的话题上达成一致之后，我说C#是不是比Java好点，他是这么回答的：

“Yes，C# is better, but it's Microsoft, so who cares?"

当年C#的语法一直是领先同时代的Java的，一直到现在Java的新功能都还有一些C#至少5年前的版本的功能的影子。它的致命弱点就是第一当时只能跑在Windows上，第二需要买微软的开发工具（免费版在商用上有一些限制），这导致了什么问题呢？如果我是一个用Linux的程序员，你开发了一个超级NB的C#库，领先业界100年，你也愿意开源出来，结果呢？我们没人用的了，因为第一我们没有Windows Server可以运行，第二我们没有Visual Studio可以开发。那么用C#的人还做什么开源啊，自己的代码自己凑合着用用得了。这就导致C#的开源社区远远落后于Java。

等到微软醒悟过来，搞了可以在Linux上用的平台，和免费的Visual Studio社区版的时候，已经太晚了，大部分人的态度都已经变成了“Who cares？”我现有的平台上该解决的问题都解决的差不多了，你也没比我现在强太多，凭啥我要换个平台再解决一遍呢？再说，阴谋论一点，你一个卖软件起家的公司，现在说是拥抱开源了，可维护你的开源代码的都是你的公司员工，等用的人多了万一你再来一个新版本不再开源要收费，

开源？不好意思，你们都理解错了
PS：文章仅为个人观点 —— 本文的内容基于我这几年在开源世界的观察得出的结论，并非调查所得到的结果。

上周，我在 GitHub 上发布了 Ledge 知识平台，我以一种“重量级”的方式来运行这个开源项目。换句话来说，以正确的方式运行起了这个项目。因为我知道怎么运作一个开源项目，加上一些外部的原因，我开始思考个人开源和组织开源的一些困境。

开始之前，让我讲个笑话和无奈：

组织开源的四大笑话是：一次性开源、按揭开源、KPI 驱动式开源、社区是什么？（分别代表了国内的几加大公司的开源做法）

不好意思，你们是对开源有什么误解吗？

什么是开源
事实上，我们经常混淆了两个概念，那就是开源软件和开源这个行为。

开源软件是源代码可以任意获取的计算机软件，任何人都能查看、修改和分发他们认为合适的代码。开源软件依托同行评审和社区生产，皆以分散、协作的方式开发。 —— 红帽官网

换句话来说，你选择一个协议，将你写的代码公开发布，这叫开源一个软件。但是，它并不叫你搞开源。开源源于开源软件，但是它现在已经成为超越软件生产的运行和工作方式。

开源源于开源软件生产的运行和工作方式，它是一种基于去中心化、自组织式的软件开发模式运作的工作方式。它以社区作为根基，通过开放、透明、协作几项原则开展的活动。

开源不是公开代码
在那本开源的《GitHub 漫游指南》里，我一直在讲述如何在 GitHub 上开发一个 “成功” 的开源项目。因为开源不仅仅只是说源代码的开源，还包含了设计文档、产品的内容等等，还要以开源的方式来运作。以 opensource.com 对于开源方式的解释来说，需要这么五个维度：

透明度。
协作。
迟早发布、持续发布。快速建立原型，发布第一个版本，并且不断地快速地迭代。
精英制度。根据提出的最佳方案做决定的方式
社区。形成社区，提升社区参与度，转化为社区目标。
也因此，如果只是公开源码的话，那是走到开源的第一步，刚来到开源的起跑线上而已，还没参与到这个游戏中去。

一个开源项目是一个产品
作为一个资深的开源运动参与者，我有一个这样的体会：运营一个开源项目，就好像创业一样。我们需要采用《黑客与画家》作者 Paul Graham 所说的创业公式：

1. 搭建原型
2. 上线运营
3. 收集反馈
4. 调整产品
5. 成长壮大
所以，开源就像是一场小型创业，需要进行竞品分析，需要制定合理的策略。当然了，如果你的东西绝无仅有，那就无需如此。而除了分析市场，针对于开发人员，还要考虑：

1. 作为投资人（技术投资），他们能获得什么？提升技术？找个好工作？
2. 作为潜在的用户，从哪里知道这个项目？
3. 作为贡献者，如何提供不同级别的贡献计划？
4. ……
你并不一定非得去考虑这些问题，只要在持续完善的过程中，这些问题的答案就会浮现出来。只是呢，在你开始之前想好，可能会事半功倍。

开源的重点在于生态建设
对于个人来说，开源的目的可能是找个好工作、为以后找个好工作……；对于一家组织来说，他们考虑开源可能有多种多样的目的：

1. 降低开发、维护成本。由社区来帮助寻找 bug，提出一些观点。
2. 技术影响力招聘
3. 建立技术壁垒。
4. 营造生态。
5. ……
一个好的开源作品，需要连接到上下游，即影响开发者，又影响使用者。慢慢地，它个作品就会成为一个影响行业的存在。尽管会不断有其它的项目冒出来，但是由于稳固的生态建设，将巩固组织在该领域的影响力。

组织需要制定开源策略
从开头的大部分四大难题：一次性开源、按揭开源、KPI 驱动式开源、社区是什么？。我们就会发现：国内大公司的开源策略都是错的。

他们可能，今年发布 Phodal UI，明后发布 Phodal Compiler，后年发布 Phodal OS。然后，中间靠各种公关稿，完成在社区的宣传。

应该是这样的，今年发布 Phodal UI 1.0，年中发布 Phodal UI 2.0，明年发布 Phodal UI 3.0 和 Phodal Compiler 1.0，明年年中 Phodal UI 4.0 + Phodal Compiler 2.0。过程中，需要依赖于布道师来进行闭环：

1. 维护开发者关系
2. 在社区进行宣传
3. 对社区进行支持、收集社区反馈
4. 建立连接内部的通道
5. 促进内部进行改进。
这些组织需要建立一个具备可持续性的开源策略：

1. 明确其带来的业务价值（如人才引进 、生态等）
2. 专职的开发人员进行开源支持
3. 开放式的开源团队组织结构
4. 合理、适当地长期 KPI 考核机制
5. 政策和流程支持。如专项鼓励奖金
6. 明确地专利和知识产权机制
开源到开放式组织
领导力变化，当我们在组织中开发一个软件应用时是以职权影响力为核心构建的；而开源方式，则是以非职权影响力构建的。

社区的每个人都可以提出自己的意见，你可以 say No，但是每个人都可以提出意见。就这一点来说，对于大部分的国内公司来说是一种挑战，大部分的领导希望听到统一的声音 —— 论组织内多样性的重要。

简单来说，大家想来就可以来，想走就可以走。所以，开源的一个难点就在于：如何吸引到人来参与开发。

尽管大部分项目都是围绕个人、团队的中心化开放式组织，如 linus 之于 Linux。但是，开源还可能变成一个中心化的组织，如 Node.js 的 IO.js 出走事件。根据开源协议，人们可以很容易派生出一个新的项目。

结论
开源，就是生态。

我现在是看到c#都有点杵，微软的封装太变态了，对我来说就是变态

楼主每天钻研的这些太烧脑了