书名：开源思索集
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
大约在10多年前，那时候我成天泡在网易的宗教信仰版，在与很多不同宗教信仰的朋友讨论的过程中，我也逐渐有了自己清晰的三观，以及较为确定的信仰，于是我写了一篇《我的信仰地图》。自己写了这么一篇文章，当然是挺得意的，后来有了一个机会，我还把这篇文章发给了自己的大学哲学老师，内心其实是希望获得他的表扬的。在文章中，我对于儒家的看法是这样的：
在儒家，个人问题几乎是完全不被考虑的，社会、他人、国家、天下才是真正重要的。
正心、诚意是为了修身，而修身是为了齐家、治国、平天下。
对自己下功夫，并不是为了自己，而是为了比自己更加广大的，更加重要的事情。
儒家从来就不告诉你：“信了我的教，你能如何如何”。
我的选择，最终还是儒家信仰，有很多可以说的理由，而最大的理由，就是因为这种信仰不是为了自己。
有很多名人名言深深地打动了我，例如：“先天下之忧而忧，后天下之乐而乐”“为国为民，侠之大者”......
顾老师对于我的文章，并未做太多的评价，却问我：“你有没有想过，孔子与颜回的快乐，是从何而来？”
于是，当场我就懵了。事实上，我并未真正思考过这个问题，而作为一个儒家信徒，缺乏对这层境界的思考与感悟，可以说就是不合格的！
我虽然一直对哲学很感兴趣，但是早在小学五年级的时候，我就已经把计算机作为自己的终生爱好了。能够操作计算机，就意味着一个全新的世界，完全在我的掌控之中。只要我能够编出足够好的程序，那个世界里的一切，都会如我所愿地运行起来。
大概在初三的时候，父母终于帮我买了一台中华学习机。我开始废寝忘食地投入了所有的业余时间，开始研究。找到一切当时能够找到的代码，敲入电脑、运行，然后查看效果。
那时候的程序，其实非常简单，字符界面，BASIC语言，还有些神奇的一行代码之类。现在看来，当时真是容易满足，看到屏幕上打出一行文字，画出一个五角星，或者从喇叭里发出一些音乐旋律，我就能从中获得极大的乐趣。
当然，在追寻这些乐趣的时候，我并无伦理或者信仰上的自觉。直到，我读到了“黑客伦理”。
有一本书，在我的读书生涯中举足轻重，也许对于很多人来说，都是如此。据说，这本书让John Carmack（《Doom》《Quake》的创造者，游戏软件天才）产生了极大的共鸣，给予了它在游戏领域前行的动力。这本书名叫《黑客——计算机革命的英雄》。
我的朋友@dreamhead 对本书的评价是：“那是一部波澜壮阔的黑客史，那是一群发自内心喜欢计算机的人对技术最简单、最纯粹的热爱，那是一种超凡的魅力。如果真心热爱计算机，你会发现，其实你并不孤单。”
在这本书的第1章里，作者记录了黑客伦理最早的版本：
以上的每一条都是我100%接受并愿意信奉的信条。因此，之前在360的开源大会上，我也做了一次演讲：《Hacking the Game——聊聊黑客的三观》。在这个演讲中，我对于自己的信仰，做了再一次的梳理。
这个世界，是可以被认识的
所以，探索世界，是一件有趣的事情。
找到巧妙的方法，探索世界，是一种享受。
这个世界，并不完美
找到漏洞，是一种乐趣。
让世界变得更加完美，是一件更有趣的事情。
世界是一个游乐场，人生是一场大游戏
赢得游戏很重要。
玩得开心、玩出精彩，更加重要。
游戏要大家一起玩才开心
和会玩的人一起玩。
游戏规则一定要公平、公正、公开。
Happy Hacking & Just for Fun：有乐趣，才是最高的价值。
Freedom：自由是必不可少的价值。
Fair Play：若无公平，则一切皆休。
Better world, Better life：让世界变得更好，才能体现黑客的价值。
以上这些，其实只是上次演讲的提纲，本来我是打算把那个演讲的内容文字化写下来，就作为这篇文章的主干，但是：“这种视频转文字的活实在是太无趣了，大家有兴趣的自己看视频去吧！”
在演讲的最后一页，我事实上修正了自己对于儒家的观点，也可以说，我终于回答了多年以前顾老师对我的发问：“孔颜乐处，乐在何处？”
在西方宗教传统中，有一个著名的论点：上帝让好人成为好人，就是对他们最大的奖赏！
这个观点应用于黑客伦理之中，也可以这样表述：上帝让黑客自得其乐，就是对他们最大的奖赏。
而对于我这样的黑客型儒家信徒而言：成为一个黑客，并乐在其中，这就是我的“孔颜乐处”！
开放源码和开源软件的不同是什么？
开放源码不能叫做开源软件吗？
所谓开源，仅仅是指符合OSI定义的Open Source吗?
1997年，埃里克·雷蒙（Eric Raymond）出版其著作《大教堂和市集》，探讨黑客社区与自由软件原则。1998年初，该论文受到极大的关注，成为促成网景通讯公司将其受欢迎的互联网套装软件《网景通讯家》（Netscape Communicator）释放成为自由软件的因素之一。这些代码即为今日大家熟悉的Mozilla Firefox与Thunderbird。
网景的行动激起雷蒙及其伙伴深入研究如何将自由软件基金会的自由软件概念及优点带入商业软件产业。他们查觉基金会的社会活动不如网景等公司的行动来得吸引人，因而试图重新包装自由软件运动，以强调分享与协作软件源代码的潜在商机。他们选用的新名称为“开放源代码”（open source），很快地布鲁斯·佩伦斯（Bruce Perens）、出版家提姆·奥莱理（Tim O'Reilly）、林纳斯·托瓦兹（Linus Torvalds）及其他人支持这个新名称。开放源代码促进会于1998年2月创建，以推动使用新名称，并宣扬开放源代码的原则。
注：以上介绍来源于中文维基百科《开源软件》词条。
开放源代码由Bruce Perens（Debian的创始人之一）定义如下。
注：以上介绍同样来源于中文维基百科《开源软件》词条。
在OSI的开源定义的文本中，开宗明义的第一句话就是：“Open source doesn't just mean access to the source code. ”甚至在后面的文字里，直接将open-source连接起来，表示这是一个词，而不是两个词组成的词组。
所以，与此类似的，在中文里，我们可以认为：“开放源代码”是一个动词+一个名词。而“开源”则是一个特定的词汇。作为动词，我们说将某某软件开源，是一种行为。作为形容词，我们称某某软件是一个开源(的)软件，不仅仅是指我们能够获取到它的源代码。
从严格意义上来说：当我们判断某某软件是否开源时，首先需要检查的，是它的授权协议，是否符合OSI对于开源的定义。最好，它的授权协议已经获得OSI的认证，我们就不必仔细去分析它的条款了。
但是，如果我们看到一个软件，不含任何授权协议的文本，我们可以确定：“这只是一堆代码，虽然我可以获得代码，但是不是可以任意使用，都无法明确，更不要说算是开源软件了。”
当我将自己的源代码放到某个地方，供人公开下载。接下来会发生什么事情？如果我是一个老手，由于见多识广，我会估计到，也许会发生很多不同的事情。有些事情，我乐于见到。比如某人给我发邮件，提交bug或者patch。有些事情，我无所谓（或者也没办法干涉），比如某人在自己家里修改了代码，然后自己使用。有些事情，我认为侵犯了自己的权益，比如别人拿了我的代码，却号称是自己开发的，并且删除了所有能够证明是我的劳动的证据。还有些事情，我也很在意，比如：虽然没有侵犯我的权益，却潜在地侵害了这个软件的用户的权益等。
总之，当一个项目的源代码被公开，哪些事情，我希望发生。哪些事情，我不希望发生。这就需要在一个协议里，被明确地规定下来。
如果发布源代码的人，对此毫不在意，甚至由于“根本没仔细思考过会发生什么”，那么我们会认为，这样的“开源”的确是不够认真。
在我曾经翻译的一篇《开源项目成功的十条准则》里，第二条就明确写到：“以相同方式共享”是开源的安全带。在遇到严重的事故之前，你大可吹嘘自己完全不需要它。一旦出现事故，你就会发现自己满脸污垢，或者“轻微擦伤”，不要成为一个“伤员”。使用“以相同方式共享”的许可证吧，如果你觉得GPL/LGPL太过于政治化，那就用MPLv2。
老司机的教训，要认真地听啊！
在开源（Open Source）之前，其实还有一个重要的先驱，自由软件（Free Software）。在自由软件的定义中，维护软件用户的自由是正义的，限制（剥夺）软件用户的自由是非正义的。
自由软件用户的四项自由是指：
正如自由软件的官方文档中所说的：一个软件只有提供了以上所有的自由给它的用户，才可以被成为自由软件。否则，它就是非自由的。尽管我们也可以比较非自由软件为其用户提供的自由度，但是我们认为，无论如何，非自由软件本身是不道德的。
是的，自由软件的核心，在于其包含严厉的道德判断。事实上，在绝对的软件用户的自由背后，开发者的自由，被道德绑架了。
再引用一段：“无论在哪种情况下，只有所有用户使用的代码都满足了这四项基本自由，该程序才能被视作自由软件。例如，有两个程序，甲程序运行的时候会自动调用乙程序。发布甲程序意味着用户必须使用到乙程序，那么必须甲乙两个程序都是自由的，甲程序才是自由的。如果通过修改甲程序，使其不再依赖乙程序，那么仅仅以自由软件的形式发布甲程序即可。”
相比之下，开源软件的相关定义是：“许可协议不得限制其他软件（License Must Not Restrict Other Software）：当某一开放源代码软件与其他非开放源代码软件一起散布时（例如放在同一光盘），不得限制其他软件的授权条件，同时也要遵照开放源代码的授权”。
仔细地阅读开源软件的定义，我们就能发现，较之自由软件，“开源”是道德中立的。虽然RMS非常痛恨这样的行为，但是我们应该承认，更加宽松的、非道德化的开源标准，有助于开发出更多、更好的软件。
开源（open-source）是一个好词，虽然没有像自由软件（free software）那样标榜自己的道德属性，但这同样是一个好词。开源是一种值得赞赏的行为，虽然因为开源，企业最终能够赚得更多，但是在开源的那一刻，企业是放弃了一部分潜在利益的。
至于个人的开源，大多数是无利可图的，也就更加值得钦佩了。
在这种情况下，不仅仅是社会上对于开源有诸多褒扬，一旦企业决定开源，肯定会加入到歌颂开源，标榜&自我标榜的行列之中。既然都已经放弃了一部分潜在的“利”，当然得在“名”上面努力的赚回来呀。
于是，整个IT圈子里，会有这种一种氛围：只要一个企业愿意开源，就值得称赞。而且，企业开源，也成为这个企业变得更加开放、更加“尊重社区”的象征。更进一步地，如果大家发现，这个企业并非真正开源，只不过赚了名声，却完全没有牺牲利益时，一种感情受到伤害的心情油然而生。
对“伪开源”的道德谴责，也由此而生。
我们曾经听过一句话：“免费的其实是最贵的”。同样的理由：“当一家企业跟你谈情怀，最终还是想赚你的钱”。所以，如果一家企业声称自己的“开源”或者“赞助开源”，完全不是为了自己的商业利益。我反正是不信的。
相反，我宁愿一家企业，真的理解了以开源为基础的商业模式，并且通过成熟、有效运作，借助商业赚取了更多的利益。这种光明正大的赚钱，值得所有人敬佩。包括商业眼光、技术实力与市场手段！
假设真的有企业家，出于情怀而开源。我倒是会内心充满疑虑。这种事情，他们家真的想明白了？真的能持久？他们的开源软件，真的能够放心使用？
如果我们不但承认用户的自由，也承认开发者的自由。如果我们不但支持用户的利益，也支持开发者的利益。如果我们承认不同的软件，面对着不同的技术与市场状况。如果我们承认，应该尊重开发者对于自身利弊的判断。
那么，开发者（尤其是企业）选择以何种协议开源，是首先应该被尊重的自由。无论他选择GPL、Apache License还是MIT中的任何一种，都不会比选择其他协议，更加道德，或者更加不道德。更明确的表达是：并不是一个企业牺牲得越多，就越道德，反之亦然。
更进一步，如果他选择的不是任何一种已有的开源协议，而是自行草拟了一份协议。并以此来捍卫自己特别重视的利益。这也同样无可厚非，无可指责。
因此，当我们声称：某某软件并不是符合OSI定义范畴的开源软件。也仅仅是一种事实陈述，而非道德谴责。
这是一个很有趣的话题，我们可以以非常学究的方式来分析，也可以以较为轻松愉快的方式来研究一下。在写这篇文章的时候，我发现了两种许可协议，都非常有趣。
WTFPL（Do What The Fuck You Want To Public License，中文译名：你想干嘛就干嘛公共许可证）
大概意思是：你想干嘛就干嘛，以及，如果你改了这个协议，请不要再用这个名字。来源介绍
还有一种协议，叫做BEER-WARE LICENSE，你可以使用此软件做任何事。如果我们在某一天相遇了，而且你认为此软件很有价值，你可以为我买一瓶啤酒来答谢。来源介绍
这两种协议，看上去都非常乱来。更加有趣的是：它们都经过了FSF（自由软件基金会）的认证，确认它们是兼容GPL的自由软件许可证。
但是，它们却没有获得OSI的认证。因此，按照OSI的定义，如果有软件使用了这样的许可证，是不能称之为开源软件的。
因此，泛泛而论：我们可以认为存在狭义的（符合OSI定义的）开源软件，与广义的开源软件。
但是：我没办法准确的定义“广义的开源软件”。因为太难了！
当开源软件进入中国，当中国的个人与企业也开始参与开源，甚至发起开源项目的时候，事情变得更加复杂了。
先说说法律问题：在中国，目前“貌似能够”保护开源软件的，是两部法律：《著作权法》与《计算机软件保护条例》，但是在这两部法律中，都没有明确的开源软件的定义。而且，在《计算机软件保护条例》中，还认为“同一计算机程序的源程序和目标程序为同一作品。”但是，发布目标程序与同时发布源程序，明显是两种差异巨大的行为。
在软件著作权人依法享有的权力中，虽然包含修改权。但是，如果在发行或网络传播的时候，不提供源程序，事实上是无法转让或授予他人修改权的。（非编译型的脚本语言，混淆以后的源代码，又是两种需要分析的特殊情况）
再者，“保护条例”中所说的：“软件著作权人可以全部或者部分转让其软件著作权，并有权获得报酬”，其中的部分转让，是否包含“修改权的部分转让”？例如，虽然允许修改源代码，但是代码中关于许可证的注释内容，能不能被删除或修改？
还有就是外国开源软件，包括开源软件的许可协议，是否受到中国法律保护的问题。更进一步，直接采用国外开源软件的常用许可协议的国产开源软件，是否也能受到中国法律的保护呢？
在我看到的网上的一些分析认为：“将软件开源只是作者处置自己版权的一种方式，其附带的开源协议只要不与其他法律相违背，当然是合法有效的。开发者将软件源代码发布并附带开源协议的行为，就是向不特定多数的人作出一个附条件的意思表示，任何人只要使用该软件，就应当理解为使用的行为接受了这样的意思表示，即作者和使用者之间建立了软件授权使用合同，而开源协议中所约定的条款也就成为了这个授权合同的一部分，使用者应当在该合同项下履行自己的义务”。参考链接
但是，真正令人困扰的，是一旦侵权行为发生，如何判断？如何寻找证据？是不是开源软件的作者还需要先去做“著作权登记”？国内虽然的确有一些学术上的研究，但是因为整个法制不够健全，而且也尚未出现“开源相关的真实案件”，因此在执行上还是空白。
在这种现实情况下，一个中国企业选择开源，的确是要冒着“被侵权之后求告无门”的风险的！在放出自己的源代码时，选择更加严格的措辞，更加严格的授权，甚至明明是开源，也先写一句“保留所有权利”，也就可以理解了。
关于文章开头提出的问题，我的回答如下：
1．从严格意义上来说：开源软件是一个专有名词，特指选择了符合OSI定义的授权协议的软件。
2．另外还有大量的未选择明确的授权协议，或者自行拟定开源授权协议，并开放源代码的软件，同样也是广义的开源生态圈的一部分。
3．在国内的法律环境对于开源软件的保护逐步健全起来之前，盲目要求个人或企业，严格按照OSI的定义开源，甚至严格按照FSF的定义开源，并不妥当。以是否道德来绑架，更不应该！
4．无论当前的法制环境如何，选择经过反复锤炼的、成熟的开源协议，其实是对自身开源行为更加审慎的态度。（如果它保护不了你，你的条款再严格，它也保护不了。但是，如果你自己发明的条款有漏洞，国家法制就算再健全也帮不了你。）
5．将开源与道德脱钩，既不以道德相标榜，也不以道德相指责。这是对于开源软件，最好的态度！
Everyone wants it, lots of people try it, yet doing it is mostly painful and irritating. I’m speaking about free software aka open source. Today I’m going to summarize 30 years of coding experience in ten management-proof bullet points.
每个人都想去做，也有很多人跃跃欲试，但是真做起来却常常会令人痛苦和愤怒——我说的是自由软件，或者更宽泛一些的开源软件。今天我要将自己30年来的开发经验，总结为开源软件的十条成功法则。
This is the Golden Rule, taught to me by Isabel Drost-Fromm. Build community, not software. Without community your code will solve the wrong problems. It will be abandoned, ignored, and will die. Collect people and give them space to work together. Give them good challenges. Stop writing code yourself.
这是一条黄金法则，是Isabel Drost-Fromm（Isabel Drost-Fromm是Apache软件基金会的成员，Apache Mahout的创立者之一）教给我的。我们要建立的是社区而不是软件。没有社区，你的代码就会用来解决错误的问题。然后这些代码会被抛弃、忽略，最后死去。正确的做法是把人集结起来，给他们协同工作的空间，给他们充分的挑战。切记不要亲手来写代码！
Share-alike is the seat belt of open source. You can boast about how you don’t need it, until you have a bad accident. Then you will either find your face smeared on the wall, or have light bruising. Don’t become a smear. Use share-alike. If GPL/LGPL is too political for you, use MPLv2.
“以相同方式共享”是开源的安全带。在遇到严重的事故之前，你大可吹嘘自己完全不需要它。一旦出现事故，你就会发现自己满脸污垢，或者‘轻微擦伤’，不要成为一个“伤员”。使用“以相同方式共享”的许可证吧，如果你觉得GPL/LGPL太过于政治化，那就用MPLv2。
Seeking upfront consensus is like waiting for the ideal life partner. It is kind of crazy. Github killed upfront consensus with their fork/pull-request flow, so you’ve no excuse in 2015. Accept patches like Wikipedia accepts edits. Merge first, fix later, and discuss out of band. Do all work on master. Don’t make people wait. You’ll get consensus, after the fact.
寻求事前的共识就像是在等待理想的人生伴侣，这简直就是疯狂。借助fork/pull-request这种模式，Github已经干掉了事前共识，所以在2015年的今天你没有任何借口坚持事前共识。你应当像维基百科那样接受修改。先合并，再修复，同时单独讨论。所有工作应当在master分支上进行，不应当让大家等待。有了既成事实，共识会随之而来。
Educate yourself and others to focus on problems not features. Every patch must be a minimal solution to a solid problem. Embrace experiments and wild ideas. Help people to not blow up the lab. Collect good solutions and throw away the bad ones. Embrace failure, at all levels. It is a necessary part of the learning process.
教育自己和其他人，聚焦于问题而非功能特性。每一个补丁都必须是解决某个实际问题的最小化的解决方案。你需要勇于尝试，勇于接受疯狂的想法。你还需要帮助他人，确保他们干的事情不会导致实验室的爆炸。收集好的解决方案，抛弃那些糟糕的方案。在各个层面上都应当宽容失败。这是学习过程中不可缺少的一部分。
Be aggressive about documenting contracts (APIs and protocols) and testing them. Use CI testing on all public contracts. Code coverage is irrelevant. Code documentation is irrelevant. All that matters is what contracts the code implements, and how well it does that.
要积极地记录约定（API与协议）并加以测试。要使用持续集成工具测试所有的公开约定。代码覆盖率是无关紧要的，代码文档也是无关紧要的。真正重要的是代码实现了哪些约定，以及它们是如何实现的。
Promote contributors to maintainers, and maintainers to owners. Do this smoothly, easily, and without fear. Keep final authority to ban bad actors. Encourage people to start their own projects, especially to build on, or compete, with existing projects. Remove power from people who are not earning it on a daily basis.
将贡献者提拔为维护者，将维护者提拔为负责人。以流畅、轻松且无畏地方式来做。保留干掉‘害群之马’的最终权力。鼓励大家开始自己的项目，尤其是基于已有项目，或者与已有项目竞争的项目。每天持之以恒地检视并剥夺那些不再贡献者的权力。
As you develop your rules, write them down so people can learn them. Actually, don’t even bother. Just use the C4.1 rules we already designed for ZeroMQ, and simplify them if you want to.
当你制定规则时，请将他们写下来，以便人们可以了解它们。事实上，你甚至都不需要亲自动手——如果你愿意，可以直接套用我们为ZeroMQ制定的规则C4.1，再按需简化。
Use your power to enforce rules, not bully others into your “vision” of the project’s direction. Above all, obey the rules yourself. Nothing is worse than a clique of maintainers who act special while blocking patches because “they don’t like them.” OK, that’s exaggeration. Many things are much worse. Still, the clique thing will harm a project.
用你的权力去执行规则，但不要强迫别人认同你对于项目发展方向的“愿景”。最要紧的是，你自己必须遵守规则。最糟糕的事情莫过于维护者自己形成了小圈子，仅仅因为“不喜欢”就拒绝其他人的补丁。好吧，这样说有点夸张了。不过，很多情况其实更加糟糕。还是那句话，小圈子对项目是有害的。
Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By “large” I mean a project that has more than 2-3 core minds working on it. Don’t use fancy dependencies like submodules. Let people pick and choose the projects they want to put together. It’s economics 101.
以小型的、独立的、自组织的、竞争性的（一群可以自由协作的）项目为目标，（市场）不能容忍大项目。所谓“大”，我的意思是一个项目包含了2~3个核心想法。要拒绝子模组那样花哨的依赖关系。让大家去挑选，并将他们选择的项目放到一起（工作）。这是经济学的常识。
Maybe you noticed that “be innovative” isn’t anywhere on my list. It’s probably point 11 or 12. Anyhow, cultivate a positive and pleasant mood in your community. There are no stupid questions. There are no stupid people. There are a few bad actors, who mostly stay away when the rules are clear. And everyone else is valuable and welcome like a guest who has traveled far to see us.
也许你注意到了，“创新”并不在我的建议列表中。它很可能排在第11或12点。总之，你需要在你的社区里培养一种积极的、愉快的氛围。愚蠢的问题，愚蠢的人都应当被踢出去。就算有“老鼠屎”，也会在清楚的规范下自动消失。剩下的人是则有价值的，我们欢迎有朋自远方来。
ps. 在诸多朋友的帮助下，对此准则做了修订，其中有了不少自己的思考，仅仅是在译文之中有了体现，没有一一说明，请读者朋友见谅。详细的修订比对记录，详见我的博客http://www.zhuangbiaowei.com/blog/?p=2035。因为实在琐碎，就不再这里罗列了。
说说我的开源学习经历：
1．下载源代码之后，首先要跑起来。编译通过、正常运行。
2．在你觉得最有可能的运行到的地方，设置断点或者抛出异常，这样，就能够找到一个项目在正常运行时的入口点。
3．从入口点所在的那个源文件开始阅读，逐步把握整个项目是如何启动起来的。
4．随便改点代码，看看会不会报错，如果报错，会从哪里报错。
5．试着把报错屏蔽、修复、或者绕开。
6．尝试理解一个系统的内部结构，多少组成部分，主线模块是哪些？辅助模块是哪些？
7．从实际需要出发，修改这个项目，满足自己的某一个小的需求。
在此之前，尽量不要在网络上找答案。
8．看看相关的讨论与心得，看看是否与自己的理解相一致。
9．提交bug fix或者某个新的功能代码。
在学习开源的过程中，有以下几个方面会获得大量的收获：
1．架构与模式
2．开源社区常见的一些惯用法
3．相关领域的结构与算法
总结一点是：学习开源，就尽可能在代码里找答案，而不是在代码之外找答案，那些都是二手的，而且很可能是不准确的。
很早就因为罗聪翼的提问与邀请，关注了这个话题，却一直都没有想好怎么回答。
我算是常年混迹于开源社区的一份子，这次的开源社从发起到成立，我也算是深度参与者之一。“只缘身在此山中”，所以反而感到难以评价。越是了解细节，就越是难以客观、全面地评价。
简单的挑一些关键词来讲吧：
摸索
这个组织，从发起到成立，到各次的会议，有太多的讨论。各种意见，各种立场，各种观点，各种设想，实际上没有一个人，清楚开源社究竟要做哪些事，怎么做，以及找什么人来做？
举一个例子：我现在是开源社的文案小组的成员，主要参与起草各种的文档。从最初的《成员合作备忘录》，约定成员的各种权利和义务，到后来的各种规章、制度，都是大家参与讨论、起草、修改的。最近正在讨论的，有入社申请表、FAQ、普通会员晋升核心会员的制度等。
其他的各个小组，都存在同样的讨论、摸索的过程。我一方面从中感受到了混乱，也感受到了未来的无限可能。身在其中，我很确信的一点是：这种摸索，我也是参与者之一。如果希望开源社将来变得更好，我责无旁贷。
「混乱」，开源社的成员，有越来越多的趋势，我们的一个微信群，几乎每天都会有新的成员加入。每周的例会，也会有新成员自我介绍的环节。目前看来，开源社几乎是来者不拒的欢迎各种申请者。也由于这种源源不断的加入者，使得整个开源社，有太多想做的事情，太多的计划与太多的可能。
各种参与者，如何协调？各种利益诉求，如何协调？各种提议与建议，如何决策？各种贡献，如何衡量？
说实话，大多数问题，都还没有定论。各种组织能力与开会议事的能力，也都有待提高。
「诉求」，当然，所有的参与者都是有所诉求的。基于自己的诉求，对于整个开源社的诸多目标，也有种种赞同、旁观、不感冒的区别。我并不完全了解其他人的诉求，仅仅谈谈自己的诉求。
我虽然是以个人身份加入的开源社，但毕竟我的职业身份是华为的员工。我也希望能够对于自己的企业，带来某些益处。在我看来，国内的大多数企业，对于开源的理解，都尚处在懵懵懂懂的状态。“某个开源软件，开源类库，我们企业能不能用？”“我们企业能不能参与到某个开源社区、开源项目中去？如何参与？”“作为企业，应该如何确立自己的开源战略？”这些问题，很多企业不知道，也迫切希望得到专家的咨询与指点。
如果开源社能够通过服务企业，进而对国内的开源环境有所改善，这是我的主要诉求。至于开源社是否能够达成我的诉求，我尚且无法肯定。我认识的很多朋友，也都处于观望的状态，我想只怕也是出于这个原因。
最后，还得回到问题本身：“如何看待？”我想，也许可以拿一个小故事来作为结论：“法拉第发现电磁感应之初，有人质问，这有什么用处呢？法拉第的回答：一个新生的婴儿有什么用处呢？”同样的，对于一个新生的社区“谈不上如何看待”。
原文发布于：2014年 @ 知乎
两年后的今天，开源社已经做了很多有价值的工作，我也成为改组后的理事会的理事，希望能够为国内的开源环境，做出更多的贡献。
1．解决实际问题，这是核心。不一定要特别创新，特别酷，当然如果有的话是加分项。
2．定期发布，及时接受反馈，不断满足用户需求，形成稳定预期。
1．出色的宣传手段、引导传播的能力。很多不错的开源项目因为这一点不够，始终默默无闻 。
2．足够好的协作机制。虽然开源社区通常有较为成熟的玩法，但是做得不够好的项目比比皆是。
3．友好的参与引导。不断地吸引新人加入贡献（包括新手指南、开发文档、Demo等）。
1．商业介入，获得资金支持。很多一开始选择了不太具备商业价值的开源项目，会始终非常小众。
2．良好的社区氛围。老人有地位，新人有上升空间，公开透明不内斗。
3．正确的方向感。这是长期繁荣的保障。以上这些，都依赖于一个最重要的先决条件：足够强大、足够优秀的创始人+领导者！
这两天又思考了一下，发现开源软件与开源项目，还是有一些差别的。通常来说：开源软件，主要是供最终用户使用，而开源项目，则是一个更大的概念，可以做一个菱形图来说明：
在开源项目的基础上，可以创造一个好的开源生态圈，而基于开源生态圈，会产生一个甚至多个不同的开源产品。这里说“开源产品”，也就包含了“开源软件”与“开源硬件”。因此，深入思考的结果就是——优秀的、成功的开源产品，依赖于良好的开源生态圈，而良好的开源生态圈，严重依赖于最初开源项目的定位与类别。
例如，依赖于Wordpress的平台，诞生了一大批Wordpress的插件。依赖于Eclipese的平台，又诞生了一大批Eclipse的插件。Firefox、Chrome莫不如是。所以，一个能够让开发者参与扩展的平台，是建立生态圈的重点之一。
再者，开发、调试、发布、获取、升级、评价这些扩展插件，是否易懂，是否方便，是否快捷，也是一个生态圈，是否能够健康的重要支撑特性。例如，Ruby的gem、Node.js的npm，就是极大地提升了Ruby与Node.js的生态圈活力。所以，一个能够支持生态圈得以出现的机制，一个能够辅助生态圈形成的工具，至关重要。
再深入地想一层，当我们开发一个软件，它应该具备哪些功能，它的可扩展性该如何实现，则是考验最初创始人的架构能力的关键。例如，UNIX/Linux的核心思想——“一切皆文件”；再如，Rails的核心思想——“约定大于配置”以及"Rack架构"所带来的活力。所以，优秀的架构，能够从一开始，就为开源生态圈打下了良好的基础。
原文发布于：2014年11月
最近，有一位来自学术界朋友，找到了我们这个开源的圈子，因为他正在做一个课题《开源项目知识共享影响机理》，打算做一轮访谈。他所提出的大多数问题，都是围绕开源与知识共享展开的。我在经过相当长的一段时间思考之后，却打算撇开那些问题，谈谈我的一些思考。
最早的Source Code，其实是非常学术性的，那些科学家们，研究、发明并制造出了计算机，然后再编写计算机能够运行的代码。对于科学家来说：代码与论文非常类似，都是学术成果，饱含知识。他们应该，也必须被分享给学术界的其他专家。
所以，在非常早期的阶段：Source Code + 论文 = 知识分享
到了1976年2月3日，比尔盖茨发了一封著名的《写给电脑爱好者的公开信》，高唱版权与利益。而且愤怒地将那些免费复制软件的家伙，称之为：窃贼！盖茨的观点，可以说完全正当，甚至他的逻辑也完全成立。如果无法保护商业软件的版权，那么整个软件行业都不会出现，他们会永远停留在校园里，停留在学术阶段。
所以，在看到的软件利益之后：Source Code + 版权 = 利益
有一群黑客，他们崇尚自由，并且痛恨一切对于自由的限制，哪怕是合理的，合法的限制。伟大的Richard Stallman站了出来，在1985年发表了GNU宣言，并于1989年起草了GPL，提出了Copyleft的概念。
所以，在追求自由的黑客看来：Source Code + GPL = 自由
而在另一方面，“贪得无厌”的资本家们觉得版权法对于他们利益的保护依然不够，他们需要借助专利的力量，不仅保证对手无法盗版他们的软件，而且连仿制都将违法。从美国的软件专利的历史来看，1992年以后，美国的软件专利保护，一直在呈不断扩大的趋势。
所以，对于资本家来说：Source Code + 专利 = 受到更多保护的利益
当然，这个世界上，中庸的人与团体，还是大多数。围绕着源代码，大家也在探索，是不是能够建立某种利益的共同体，而且这个共同体，并不会追求极端的自由，并不是仅仅为了共享知识，交流学术，他们拿起了法律的武器，创作了很多种不同的License，用于规定参与各方的权利与义务，不但能够与版权相容，甚至与 专利都不产生矛盾。（最早的Open Source这个名词，诞生于1998年）
所以，成千上万的人们，从五湖四海走来，团结在某一个License之下：
Source Code + License = Open Source
就像我不会批评比尔盖茨一样，没有对于版权的强调，就不会有健康的软件行业。我也不会批评开源运动，没有足够好的利益协调机制，仅仅靠理想与坚持，根本不会有现在这么多开源软件。
总体而言，我的态度是：自由软件值得尊重；软件版权应该遵守；开源运动值得参与；专利说到底是个很糟糕的东西；而知识， 蕴含在任何能够被读到的源代码里。
据说，人之区别于禽兽，最大的特征在于利用，甚至发明工具。在没有任何其他工具时，我们只能借助于自己的肢体，一旦有了工具之后，我们的能力将会大大地增加。
但是，从另一个角度来看，工具也同时在限制我们的能力，甚至限制了我们的行为模式与思维模式。有一句俗话说得好：“手里拿着锤子，看见什么都像钉子。”
而在研发工具的领域，我们观察到另外一些有趣的现象：因为软件研发工具的开发者，同时也是工具的使用者。因此，他们不仅仅会受制于工具，也往往会由此被激发，开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一的现象，使得研发工具的发展，简直可以用“日新月异”“层出不穷”，甚至用“争奇斗艳”来形容。
随着软件复杂性的不断增加，以及软件开发的参与者不断增多，团队协作的辅助软件，也开始不断增加，随后我们发现：工具不仅仅限制了个人的行为模式，更进一步限制了团队的协作模式。
软件研发企业的管理者，往往会有某种错觉，他们会认为：管理就是定下制度、流程与规范，然后“下面的人”就会照此执行。因为有人“听话”，有人“不听话”，所以才需要奖励与惩罚的制度，来帮助管理者推行他的“规则”。他们一般都很喜欢看《执行力》这样的书。
在开源社区，事情变得有些不一样。虽说开源社区也有“领导者”，甚至往往会有“精神领袖”，但他们并没有暴力手段，也没有经济手段，甚至行政手段。因此，要协调一帮自由散漫的黑客，共同开发高质量的开源软件，必须有更加高明的手段。
由于一切都是Open的，所以，不仅代码人人可见，开源社区的协作模式也暴露在众目睽睽之下。从某种意义上来说：这促进了开源社区的协作工具的开发，进而使得开源的研发协作模式，以远远超过企业内部的演化速度飞速演化。
第一代开源协作模式，在早期几乎没有符合自身特殊需要的工具，有什么用什么，因此最为常用的email被发展为Maillist，成为整个开发团队的协作核心工具，大多数操作系统内置的diff/patch工具，使得代码的交流以email patch为主。这些老牌的开源项目，从使用RCS、CVS，到了后来也开始逐步引入svn/git、bugzilla这样的工具，但是围绕mailing list开展协作的特征，则持久不变。
一个开源社区，往往就是一个邮件列表，随着软件的日益复杂，社区的不断扩大，邮件列表也会不断分化，通常会划分为：核心组、开发组和用户组。开发组与用户组的邮件列表，随着软件的架构分化为多个模块，还会进一步分解。
在邮件列表里，所有的用户都是平等的，在无法用工具保障流程的情况下，社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规范的邮件，不会被理睬；不礼貌的家伙，甚至会被赶走。
邮件越来越多，即使分成多个邮件列表，依然太多。Archive这样的邮件归档、查阅的工具，就必须得有了。一封邮件，大家都来回复，严格re:的标题，组成了一个可供追溯的线索。
在邮件列表里，通常出现个人的名称，加上Reported-By、Tested-By、Acked-By的标记，即是一种代表个人名义的认可，也是流程规范的一部分，更是计算各人贡献的依据。
在邮件中，有一类话题是最活跃的，那就是bug。但是，通过翻找邮件查阅bug的最新的解决状况，是非常困难的。一个bug，从提出到最终解决，并被确认在哪一个版本中发布fix，是一种稳定的状态转化模式。一个专有的处理工具，势必应运而生。Bugzilla、trac等一批工具，就由此被创造出来了。
开源社区，表面上非常的崇尚民主自由，但实际上却盛行精英主义，甚至是个人独裁的。我们往往会给某个开源项目的创始人，冠以“仁慈的独裁者”的头衔。虽然，是否仁慈，大家不得而知，但独裁确实是显然的了。
最大的独裁，是代码的管理权。因为作为创始人与核心开发者，他们往往以一己之力，贡献了绝大多数的代码，确定了项目最初的架构与发展方向。他们不会容忍任何人随意地向代码库提交代码。
在邮件列表中，一个新来的家伙，从没人认识到能够独立地向代码库提交代码，非得经历艰辛的历程不可。这样的历程，简单地说，就是一次一次的Code Review。被审核通过、合入代码库的patch越多，一个人对于社区的贡献就越大，可信度也越高，身份地位也逐步提高，然后，他也就可以去Review其他人的代码了。
第二代开源协作模式，有两大特征：Web化和集成化。随着Web技术的不断成熟，开源社区也开始创造一个又一个的Web开源项目，其中Web化的项目管理工具，如雨后春笋般冒了出来。在wikipedia上，issue-tracking systems列出了55个，project management software列出了152个，其中开源的也有30+，open-source software hosting列出了22个，堪称蔚为壮观。
这类平台又可以分为两大类：基于开源的项目管理工具或issue tracking工具，自建平台，以JIRA、DotProject、Redmine为代表；基于免费开源托管平台，以SourceForge、Google、LaunchPad为代表。
第二代的开源项目管理工具，可以说，主要是在向企业内的开发管理学习。文档、流程、角色、权限、统计报表等功能都开始出现了。有些开源项目，也在用这些东西。
以SourceForge与Google Code为代表的开源托管平台免除了开源项目搭建自己的官方网站，管理工具，代码仓库之类的繁琐事务，大大促进了开源项目的发展。不过，由于平台的功能总是受限的，因此自建门户，自组工具的开源项目依然层出不穷。
在第二代开源协作模式日渐成熟的过程中，另一股潮流也正方兴未艾：敏捷软件开发。其中，最为深入人心的概念之一，就是每个迭代，完成一批User Story。
在开源社区，这个概念被进一步演绎：无论是bug和feature，都被统称为issue。这些issue被分到不同的milestone（版本），即使最后有可能延期，milestone也会定义一个预期完成时间。
这是好事，还是坏事？其实很难评价，因为从开源的原始教义而言：所有的贡献，都是自愿、随机、不可预期的。为自然生长的软件，规定里程碑，本来就显得荒谬。但是，从另一方面而言，我们可以引用另一个中国人过马路的例子：“不管红绿灯，凑够一堆人就过马路”，开源软件往往也是“不管里程碑，稳定一堆特性和bugfix，就发布一个版本”。
如果在开源软件很少，更别提形成开源生态圈的情况下，这种随意的做法还是可行的。但是在大量软件，相互依赖的情况下，一个开源项目要赢得其他协作项目的信赖与协作，必须给出稳定的规划，以便相互配合。
这种规范，也是被逼出来的。
虽然黑客们喜欢写程序，但是要写的程序实在太多了，能够不重复造轮子，有现成的好工具可以直接拿来用，也是件好事。如果可以打开一个网站，注册一个用户，创建一个新的项目，剩下的事情自有平台帮忙打理，那么大家都可以愉快、专心地写自己的代码了。
平台在逐步进化，因而能够帮助开源项目，打理越来越多的事务。通常主流的开源项目托管平台，都能够完成：
更进一步的，还有能够完成：简单的自定义工作流、文件夹与静态资源管理、输出各种统计报表，甚至提供论坛、搜索、邮件列表以及各种排行榜等。
在此之前，一个开源项目，是一个社区。到了大平台的时代，整个平台，构成了一个更大的社区。
到了MySpace、Facebook与Twitter这样的SNS网站的兴起，开源项目的协作模式受到SNS的启发，也随之进入了第三代，以Social Coding为核心的开发协作模式，这样的模式在以Github为代表的网站上，体现地最为充分，众多的模仿者也层出不穷。过去的开源项目与托管平台，都是以项目为中心来打造，而Github则是围绕着参与开源的人来打造。首先满足的不是项目的需求，而是个人的需求，由于对人的黏性大大增加，也使得Github成为近年来最具吸引力的开发社区。
围绕着Github，一大批周边扩展服务被建立起来，构成了一个更加有活力的生态圈。而程序员们，不仅在Github上参与开源项目，更在Github上结交朋友，分享经验，增进能力。甚至这样的协作模式，还拓展到了编程领域之外，成为开放式协作的流行模式。
第三代开源协作模式，以Github为代表，以Social Coding为精髓，这一代模式想要解决的问题，是激励机制的问题。
第一代开源协作，虽然创造了一批大大有名的项目，但事实上却是一个非常小圈子的事业。即使是最为成功的Linux内核开发，也不过1000~2000人。一旦人多事杂，就会出现管理混乱的现象。
第二代开源协作，虽然借鉴了很多企业界的规范管理经验，但是在事实上，却是不适应开源软件的风格的。举一个例子：在Redmine中存在的角色、权限、工作流之类的东西，实际开源项目使用的，却非常少。
第三代开源协作，借鉴了社交网络中的各种数值化模型、关注者数量、Star数量、Fork数量、Issue数量、Pull Request数量，都在显要位置标示出来，对于开发者形成正向激励，还有很多的统计图表，形象地展示了项目的活跃程度。
开源社区，原本就有非常深厚的，统计补丁数计算贡献度的传统，这一点在Github被发扬光大，可以说是优秀的继承与创新。
在Github，一键就能够fork自己的分支，然后可以跟原有的分支毫无关联，也可以非常方便地提交pull request，这就带来了更加频繁的分裂，使得分裂常态化了。
原来的开源社区，开发者修改了代码，希望能够贡献给社区，需要穿越种种障碍，如果社区不接受，最后开发者只能逼不得已，自己开一个新的分支，变成一个新的项目。
在分裂是异常的状态下，分裂是罪恶的，是不应该的，是会带来阵痛的。当分裂变得常态化，pull request也变得常态化，分分合合，以每天N次的速度发生。恰恰因为如此，它不再是一种罪恶，而是一种健康的、向上的、以更快速度进步的模式。大家不再是在一个版本下，各自贡献，而是在各自的版本下，独立发展，想分就分，想合就合。
Pull request，从一个代码合并的方式变成了开发者之间主要的交流方式，他们发现，最好的交流，正是通过源代码来交流，一切的讲道理都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢的一种交流方式。
较之上一代的平台，Github提供了优秀的开放扩展机制：OAuth、API、SDK、WebHooks、ServiceHooks等，使得围绕Github，扩展各种满足项目特定需要的服务，变得非常容易。
这就是从上一代平台的开源大社区，进化为“围绕Github的开源生态圈”。
到目前为止，Github一共支持超过170个不同的扩展服务，其中较为热门的服务有：
Github 开放平台与API，基于Github OAuth API，其他网站可以支持开发者用自己Github账号登录，并使用一些有趣的服务。
这些扩展服务，极大地丰富了开源生态圈的内涵。
目前看来，Git作为分布式配置库的王者地位，已经不可动摇了。能够初步总结的原因，至少有三个。
开源社区，一直有非常悠久的CodeReview的历史，哪怕在最早的mail & patch的时代，Review也是开源协作的头等大事。仅仅梳理Review的历程，也可以看到其中工具与流程的发展。
最初是邮件review，然后是在集成平台上内置review功能，或者提供更强大的review插件。到Github创新的提出pull request，则是一种更加方便有效的review模式。
与此同时，独立于集成平台的专门的code review工具也开始发展起来：Review Board、Google Gerrit、Facebook Phabricator是其中重要的几个代表。
在Git逐步流行之后，大家发现基于Git可以选择的“玩法”实在是太多了。从最初写下一行代码，到最终出现在项目发布的版本之中，其间可以有无数的“路径”。
在git-scm.com官方教程《ProGit》里，提及了3种：集中式工作流、集成管理员工作流以及司令官与副官工作流。
在蒋鑫的《Git权威指南》里，又提及基于TopGit、基于submodule、基于subtree、基于repo、基于gerrit、以及Git与SVN配合使用的不同工作模型。
再后来：GitFlow、Github的Pull Request，以及基于Github的Github Flow等工作模式，堪称百花齐放。
为什么会出来这么多workflow？因为团队与项目的差别实在太大了。现在到我们简直无法想象：那些在各种情况下都坚持使用SVN都开发者是怎么熬过来的？
当然，从另一方面来说：选择太多，也会带来另一种烦恼..……
从Everything as Code到Everything Automation，是另一个越来越明显的趋势。前两天，我从机场出来，正好看到两个并列的广告牌，一个广告的大意是：“UPS助您打通全球供应链”，另一个则是“中国银行助您打通全球供应链”。这真的很有意思，看来在各行各业，大家都开始在关注整个生命周期的各个环节之间的打通。
只是，在软件领域，我们会感觉到这是一种回归。毕竟，最初的软件开发都是很简单的。在一台计算机上，自己写程序，自己编译，自己调试、运行，最后发布。既不用依赖他人，更不用等待什么流程。
随着项目越来越复杂，参与的人越来越多，我们的软件不能仅仅运行在自己的机器上，或者需要部署到服务器上，或者需要发布到某种平台上。在协作者众多的情况下，如何分工合作？在开发者水平参差不齐的情况下，如何保证质量？在分工、协作、流程与质量保证的要求之下，如何提高效率？
这些都是DevOps致力于解决的问题，也是DevOps不断得以发展的原动力。
过去是如何？未来又会怎样？想要回答这类问题，其实需要更加深入的思考：“开源社区的协作模式，为何会变？变化背后的逻辑是什么？”
开源社区与普通的软件开发最大的不同，就是参与者多多益善。在《大教堂与集市》中，Eric Steven Raymond总结到：“如果开发者协调者有至少一个像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战”，这简直就是绝妙的预言。虽然当年的ESR也许并未预测到，基于Internet会出现那么多辅助开源的相关工具（他们当时还只有邮件列表）。
所以，开源社区一直在致力于两个看上去相反的目标：“吸引尽可能多的人，以尽可能简单、便捷的方式，参与到开源中来”“在人多得超乎想象的情况下，依然能够保持，甚至不断提高效率”。
开源社区不会给参与者发工资，因此激励是一个大问题。公平、公开、公正地计算所有参与者的贡献，以所有人都能够接受的形式，计算并公布各种排行榜，可以说是开源社区特有的“刚性需求”，因此，SNS与开源社区的结合成为必然。以后，面向开源协作的大数据分析也一定会出现。
计算参与者的贡献，仅仅是公平激励的基础。让激励变得有趣，变得有价值，变得有意义，则是吸引与回报参与者的不二法门。因此，游戏化的思路，会被越来越多的引入到开源社区中来。
开源项目保障项目质量的最大利器，是引入数量众多都热心测试者。但是，仅仅有人愿意测试，主动、积极地帮助测试，已经越来越不够了。随着项目越来越复杂，开源项目必须逐步走出仅仅依赖肉眼、依赖人多＋运气的质量保障模式。
自动化测试以及更加规范的Review流程，则是必然出现，而且将越来越重要的环节之一。
自由与规范，计划与变化，兴趣与责任，经常会在社区里，成为争论的热点话题。虽然在《大教堂与集市》中，ESR极力鼓吹“礼物文化远远胜过交换经济”，但是，“在一个庞大的社区，各种各样的事务都需要有人去完成，而且还不能漫无章法。”
因此："某种调节手段、协调者与协调机制、甚至是看不见的手"之类的东西，会慢慢地回到社区。
目前来说，依然只能是线上讨论+线下开会。虽然很多开源社区，开始学习《罗伯特议事规则》这样的开会圣经。但是，开会依然是最令程序员感到苦恼的事情。在这方面，将来会不会出现更好的辅助工具，这方面很值得期待。
唯有变化，是不变的。开源协作模式，同样如此。惟愿我们，能够成为推起其前进的力量之一。
开源已经是一场革命，但是在开源的发展历史上，其实依然在不断地发展，甚至革命。简单地回顾一下：
最早的开源，仅仅是把自己的源代码开放出来，或者让别人用磁带复制带走，或者放在Server上供人下载。
再后来，关于这个项目的代码与功能，就浮现出来了两个问题：代码大家都能改，如何整理与汇总各自的工作成果？功能大家都有想法，最后应该做成什么样？
于是，源代码版本管理工具与各种在线讨论的方式，开始了一轮又一轮的演进。具体的项目就不再一一列举，但是其中最大的一次创新，就是从集中式版本管理走向了分布式版本管理。如果说Github有自己的哲学，它的来源，首先是分布式开发的理念。
分布式开发与分布式版本管理：没有一个核心的版本库，意味着没有任何一个人、任何一个组织是核心，每个人都可以在自己的机器上保留全部的版本树，并且不断发展自己的版本。一个人的代码，既可以贡献给A，也可以贡献给B，一切自由。
随着Linux开发的哲学，被逐步地传播开来，才有了Github的出现。最初的Github的最大的贡献，是将这种无中心，多分支的开发模式，Web化、常态化了。一键就能够fork自己的分支，然后可以跟原有的分支毫无关联，也可以非常方便地提交pull request，这就带来了更加频繁的分裂，使得分裂常态化了。
原来的开源社区，我改了代码，希望能够贡献给社区，需要穿越种种障碍，如果社区不接受，最后我只能逼不得已，自己开一个新的分支，变成一个新的项目。在分裂是异常的状态下，分裂是罪恶的，是不应该的，是会带来阵痛的。当分裂变得常态化，pull request也变得常态化，分分合合，以每天N次的速度发生，恰恰因为如此，它不再是一种罪恶，而是一种健康的、向上的、以更快速度进步的模式。大家不再是在一个版本下，各自贡献，而是在各自的版本下，独立发展，想分就分，想合就合。
这背后折射出的哲学，可以这样总结：如果将分裂视为罪恶，而力图用各种方法去阻止，总会碰到各种各样的新的困难。如果反其道而行之，通过技术手段尽可能地方便分裂与合并，这反而是满足了真正的需求。（阻止分裂，其实是在压抑开发过程中存在的真实需求）所以，尽力满足真实的需求，才有可能获得成功。
随着这样的模式，变得常态化，然后Github才被称为一个社区，fork/pull request也从一种开发行为变成了一种社交行为。于是，程序员们发现，最好的交流，正是通过源代码来交流，一切的讲道理都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢的一种交流方式。这当然也是因为满足了真实的需求。甚至我们可以说，Github创造了真实的需求。
随后的事情是顺理成章的，程序员们泡在Github上，自然想在Github上做所有的事情，这不必再过多分析了。
从Linus抨击Github说起：托瓦兹抨击GitHub：某些功能很垃圾
开源，是一个很神奇的事情。Linus在开发Linux的时候，受到的最大的指责就是质量控制不力。但是，Linus对此并不太在乎，还发明了一个Linus定理：“足够多的眼睛，就可让所有问题浮现”（given enough eyeballs, all bugs are shallow）。
开源的精神本质，可以认为是一场不收门票的盛宴，任何人都有机会参与进来。当然，质量因此而下降，也是必须解决的问题。
从集中式代码管理到分布式代码管理，是再一次的降低门槛。开发者不依赖于主库，就可以创建自己的分支。我的代码就算原来项目的人不接受，我也可以继续搞下去。分布式的核心，是去中心化。去中心化的本质是否定权威。不过，去中心化导致的，是质量控制更加困难。
当然，Github基于Git，将去中心化几乎做到了极致；将参与开源的门槛，几乎拉到了最低点。从Linus这位发起了两次降低门槛运动的“革命老人”来说，他对于第三次降低门槛的行为，受不了了。
很多时候，我们都会在历史上看到这样的现象：革命的旗手停下来了，不再继续前进了。他喊道：够了，再这样下去，就是错的了。但是，后来者依然再继续前进，并且走得更远。
回到技术问题的探讨：为了保障质量，回到权威主导的中心化模式，当然是一个办法。但是，有没有更好的办法？
更多的工具，正在层出不穷，更多的创新，还在源源不断地涌现。
我想：向前看，才是合理的方向。
增长黑客
这本书在写的时候，我就知晓，只是一直没有去看。作者是我在盛大创新院的前同事，所以在出版之后也很高兴收到了寄来的赠书。简单翻阅之后，就大为喜欢。只不过，我与大多数人喜欢的理由，大不相同：
也许90%的人，是因为这本书在讨论“增长”，而我却是因为这本书在讨论“黑客”。也许90%的人，会非常喜欢这本书干货满满的“案例”。而我却很遗憾，这本书对于“术”讲得太多，“道”却讲得太少!
黑客文化的起源可以追溯到1961年，那一年麻省理工学院（MIT）终于得到了第一台PDP-1计算机。学院技术模型铁路俱乐部（Tech Model Railroad Club，TMRC）的信号动力委员会（Signals and Power Committee，S&P）把它作为最时髦的科技玩具，并由此产生了许多程序设计工具、术语和整个文化氛围——这些，直到今日我们仍然依稀可辨。史蒂文·利维（Steven Levy）在《黑客》（Hackers）的第一部分中详细地记录了这段岁月。
——《黑客道简史》E.S.R
也许很多人会认为，黑客就是一帮搞计算机的高手。但事实上，E.S.R在另外一篇文章里，有很清楚的表述：“黑客的思维方式并不仅仅局限在软件黑客的文化圈内。也有人用黑客态度对待其他事情，如电子和音乐方面——其实你可以在任何最高级别的科学和艺术活动中发现它的身影。软件黑客对这些领域的践行者尊重有加，并把他们也称作黑客——有人宣称黑客天性是绝对独立于他们工作的特定领域的。”
——《如何成为一名黑客》
1. 渴望了解世界，更擅长“深入”地了解世界
为了能够了解世界，他们愿意想尽一切办法，甚至不惜做一些出格的事情。小时候，他们会拆玩具，拆闹钟，拆掉各种玩意。长大以后，他们会渴望阅读源代码，并且痛恨一切闭源的行为。
所以，如果有一扇门是关着的，那对黑客就是一种挑战。而如果这扇门上了锁，那简直就是对黑客的侮辱。
2. 痛恨无聊、乏味、低效，鄙视蛮干与蠢干
这个世界上，有各种各样的蠢货，而最糟糕的那种：就是强迫他人和自己一样愚蠢，并保持愚蠢的家伙。
在黑客的文化中，干成一件事，并没有太了不起。重要的是，手法必须巧妙，甚至能够给人带来观赏的乐趣，这样的成就，才能被称之为“Hack”。
3. 死理性派
大多数黑客都是典型的理工男。当然，现在也许女黑客也有一些了。这些人，最重要的特征之一，就是非常理性，甚至较真。哪怕是在讨论那种“明显是幻想域的问题”，他们也会以严谨的形式，罗列出前后逻辑一致的一大堆证据。
对于这种死理性派来说：数据和逻辑，是他们最喜欢的武器。
我是谁：没有绝对安全的系统
这是我近年来看到的，最具有可信度的黑客电影。其中有一段情节，是那群人通过翻找垃圾堆里的明信片，然后找到了一个爱猫的目标对象的邮箱。然后再发一封萌猫的邮件包含一个钓鱼网站，再由此而植入木马……
这背后的逻辑，是“基于对人性的深入了解，进而找到了一个系统的漏洞”。这恰恰是最为典型的黑客的思维模式。只不过，应用于社会学的领域了。
在这部电影中，这种手法被称为“Social Engineering":
“人不能总藏在他的计算机后面，最大的安全漏洞并不是存在于什么程序或者服务器内，人类才是最大的安全漏洞。”
“所有黑客手段中最有效的、最伟大的幻想艺术——社交工程学。”
增长黑客，其实就是一群黑客，接到了一个“增长类”的任务，然后漂亮地“hacked”而已。
在书中的很多例子，都有这样一些要素：“数据驱动、用户心理、巧妙的手法、惊人的成效”。
如果我们阅读这本书，就是去学习这一堆一堆的案例，那简直就是买椟还珠，难免会有邯郸学步的危险。更加应该探寻的，是为何他们会干得这么漂亮？以及，如何才能在今后千变万化的市场中，不断地创造新的增长奇迹？
成为一家“黑客友好型”的公司，甚至成为一家“以黑客文化为主导”的公司，是唯一的方法。难以想象，我们可以给一个家伙，冠上“Growth Hacker”的头衔，他就自然会为公司带来惊人的增长。如果这个公司，根本没有供“黑客文化生长的土壤”，我们只会看到一个又一个“Copy To China”的愚蠢案例。
我们会设立目标，甚至设立看起来完全不可能的目标。但是：想要完成这样的“不可能的任务”，就不能规定任何“标准动作”——当然，违法的除外。
从来没有听说过，上下共有6~8个层级，等级森严的大型组织，会具有黑客型的气质。小团队，扁平化，是孕育黑客文化的关键土壤。在这种团队里，每个人都可能会承担一种以上的职责，甚至在必要时，每个人都能够补上他人的缺口。
没有谁肯定是对的，除非事实证明他是对的。没有谁高人一等，除非他确实强悍到近乎无所不能。
正如成为“黑客”的关键要素之一，是得到其他“黑客”的承认。一个黑客型组织的关键要素也包括：每个人的能力，都能够得到其他成员的认可。
这段时间，越来越流行的一个词，叫做“精益创业”，在我看来：所谓“精益”，无非是死理性派的黑客们，在创业时的必然选择罢了。
当然，这个话题又太大了，就此打住……
很早以前看过一部港剧《龙兄鼠弟》，是万梓良、郑则仕和张卫健演的。其中万梓良饰演的雷文凤，在最后写了一本书，叫做《黑白灰》。大意是：这个世界，虽然存在黑白两色，绝大多数人，却都是灰色的。而他，却一定要坚持做一个纯白色的人。甚至在他看来，灰色的人较之黑色的人，更加罪恶。
最近刚刚读完了另外一本书《若为自由故》，则是一本Richard Stallman的传记。在这本书里，红帽公司总裁罗伯特·杨（Robert Young）总结理查德看似矛盾的政治行为时，说道：“我崇拜也尊敬理查德和他所做的一切。我对他唯一的批评就是，有些时候，他对待朋友甚至比对待敌人还要无情。”
在我看来，也许发起开源运动的那群人，大多数自认为是RMS的朋友，而对于RMS而言，他们只是一群放弃了原则而站在灰色地带的人罢了。
说实话，在自由软件与开源之间，我究竟应该持何种立场？这是一个，我一直以来，都不愿意深想的问题，实在是太难了。只是这回读了一遍RMS亲笔签名的个人传记，又了解到了很多当事人的实际言论，总觉得应该督促自己，思考出一个结论出来。
在RMS看来，自由是天赋人权，可以说：因为自由本身值得追求，而RMS恰好又是个软件天才，所以他才会致力于自由软件。
而在开源运动看来：吸引更多的人参与自由软件的开发，然后实实在在地拿出优秀的开源软件来，才是真正有价值的事情。
自由软件的目的，是更多的自由，而开源软件的目的，是更好的软件。
如果RMS只是一位致力于追求软件自由的斗士，也许不会有任何人理睬他。但是他写出了Emacs、GCC这样的神级软件。以至于由此建立起了几乎无人能及的社区影响力。
因为他写的软件实在太牛，所以无论他以什么样的License来发表自己的软件，都会引发全社区的关注。
然后，GPL这种诡异的授权模式，才会有人愿意遵循。甚至，应用作为自己的开源License。
或者换句话说：RMS挂了Emacs的羊头，卖了GPL的狗肉。但是，Emacs这个羊头实在太好，买了GPL这种狗肉的人，居然也就认可了。
因为《大教堂与集市》一书，对于Linux成功之道的总结与宣传，使得Linus被人们提升到了世界上最知名黑客的行列。
说到底，在黑客这个圈子里，大家还是更注重实力，而非理念。当有人以完全不同的方式，创造出完全不逊于Emacs、GCC这样的开源软件时，RMS/自由软件/大教堂所代表的“道路”，就不再是唯一的选择了。
尤其是当Linus站在了开源的大旗下，更多的公司则出现在了Linux的周围。集市的胜利，不仅仅是开源相对于闭源的胜利，也是Linus相对于RMS的胜利。
在之后的世界里，虽然开源的代码越来越多，但是自由却越来越少被人提及了。
《公正——该如何做是好》一书中，有一个经典的伦理学命题：假设铁轨上有一辆失控的火车，在岔路的一边是一个人，而另一边则是五个人。你是一个扳道工，你会选择让火车开向一个人，还是五个人？
我曾经问过我儿子这个问题，他的回答非常有趣：“如果是五个大人，与一个大人”，那就撞一个大人。“如果是五个大人，与一个小孩”，那就撞五个大人。“如果是五个男人，与一个女人”，那就撞五个男人。“如果是五个男人，与一个胖女人”，那就撞那个胖女人……
这其实反映了一个事实：想要通过权衡利弊，来做出最有利的选择，可能会是非常没有原则的事情。即使是一个成年人，也未必能做得有多好。
对于一个像RMS这样的黑客来说：他们会被这种问题所激怒，进而会拒绝回答问题，并想尽一切办法，要hack掉这个该死的列车与轨道系统。
在这本书的第十二章“开往黑客地狱的短暂旅途”，讲了一个令RMS暴怒的故事。作者写到：“不完美的系统会激怒黑客。”史蒂芬·李维说过这样的话，这是我决定与斯托曼同坐一辆车前应该听取的另一个忠告，“这是黑客们通常不喜欢开车的原因之一：这是一个充满不确定性的程序，交通信号灯总是随机的变化，还有横七竖八的单行道，导致交通经常堵塞。这实在是太不必要了，只要让黑客们重新安排一下信号灯，打开交通灯控制盒，重新设计整个系统。”
是的，对于真正的黑客来说：适应这个不完美的世界——取舍、权衡、妥协，是别人的事情。而黑客，就一定想要改造它！
RMS这样的人，就像是在遥远的天边，在夕阳即将落下之时，努力为我们撑起天际线上那最后一点光明的人。
我没有资格自称为黑客。哪怕是改变世界的念头，我也常常是一闪而过。但是，这并不妨碍我始终对RMS，报以最高的崇敬！
至于Open Source，那至少是个很不坏的东西吧！
忍不住要深深地叹息一声，各位，这个观点真的一点都不新鲜，而且早就被批得一钱不值了。
在1998年，微软的万圣节文件被泄露，然后流到了Eric S. Raymond的手上，他是《大教堂与集市》的作者。
ESR以极其尖锐的语言，点评了这批文件，我只打算摘录与陈皓观点相关的部分。
微软的文件中说：“当向JimAll描述这个问题的时候，它提供了漂亮的模拟“追逐后灯”。要使一大批半组织的暴民合作，必须要向他们指出一个明显的目标。有后灯具体提供了一个模糊的影像。在这种状况下，有个后灯可跟是有强大中心领导的媒介。当然，一旦这个组织基础不再时 （一旦计划已达“艺术”的地位时），管理层次就很需要开拓新的疆土。”
所谓追逐后灯，也可以解释为“开源只能抄袭闭源”。而ESR的点评如下：“胡说。在open-source界，所需要的只需要一个人有好点子，就能够成就。部分open-source在这一点上的原因，是要降低造成革新所需的能量门坎。我们由经验得知，作者所赞颂的“大量管理”是其中最糟糕的一个门坎。在open-source界，革新者尝试任何事，唯一的测试是是否使用者会志愿去试用它，并喜欢上它。因特网帮助了这个过程，而open-source社团合作会议则特地设计来推销它。第三的替代“追逐后灯”或“强力的中心领导”（而且比两者更有效率）是演化出创造力无政府状态，因而有上千的领导者，而数万门人跟随。微软无法打击，我不认为它们甚至能够了解，没有那个胆子。”
简单地说：“在开源领域，创新会更加容易，门槛也更低。”
另外一段，ESR说到：“这个预测源起于作者早先的主张，即open-source开发大大有赖于前例设计，而且无可避免地向后兼容。真是近视——明显地，像Python、Beowulf以及Squeak（就讲数百个革新之中这三个）没有出现在它的雷达上。我们希望微软继续相信这一点，因为这会减缓它们的回应。许多部分将会看微软如何解释革新，诸如Linux多处理器化。有趣地是，作者在这一点上自我矛盾。”
关于微软作者自相矛盾的一段话如下：“在Linux上的研究/教学非常容易传播，因为Linux原始码很容易取得。 特别是，这通常意味新的研究点子会第一个在Linux上先实作，然后才移殖到其它平台。”ESR点评到：“同样一个作者稍后竟然说Linux暴民会很难吸收新点子。 ”
如果各位有兴趣，可以去读一读这个微软的万圣节文件与ESR的点评。
毕竟，无知容易治疗，偏见无法治愈。
原文发布于： 2014年8月 @ 知乎
首先回顾一下历史：
在Github里，组织并非一开始就有的。在2010年，他们发了一篇博客：Introducing Organizations · GitHub。
到了2012年，有了Team Mentions： Introducing Team Mentions 。
到了2014年，有了更好的组织展现形式：Better Organizations · GitHub。
可以看出：Github的各种功能特性是逐渐出现的，也可以说：他们是逐渐想明白，然后逐渐改进的。
然后做一些假设：
如果可以关注组织，我们将会收到一些什么信息？如果关注组织，就等于关注这个组织的所有项目，那么我认为就太草率了。
另一方面，Github又尚未提供组织层面的新闻发布、RSS订阅这样的服务。
因此，现在如果推出关注组织的功能，就会相当鸡肋。
为了支持组织，Github还需要开发哪些功能？
International Business Machines – GitHub这是IBM在Github上建立的组织，但是，进去一看却空空如也。他们另外做了一个Homepage，也放在Github上：IBM @ Github。
在这个Homepage里，我们发现了更多的ibm开源项目，而且从属于多个不同的组织：
所以，针对大型组织，Github还需要支持多个层级的组织架构。
另外，组织的新闻发布之外，我认为还需要有一个Release Notes自动发布新闻的功能。
总结来说，在有了以下功能之后，我认为关注组织才是有价值的：
组织架构。
组织新闻发布。
组织内项目的Release Notes转新闻。
组织新闻的RSS输出。
原文发布于：2014-05-20@知乎
最初是打算使用openhub.net的Open API的，他们有不错的API，还在Github上放了一个开源项目。只可惜，他们的API，最多只能申请5个API Key，每个Key明天的访问请求数量不能超过1000次。当时我还不知道，其实openhub的数据只有28万多，还以为满打满算，至少得60多天才能全部抓完，顿时心就凉了。
后来有朋友介绍了一个很棒的直接抓取HTML页面，然后做DOM分析的工具，名叫noodle。
接下来，只要抓取： https://www.openhub.net/p?ref=homepage&q=&page={num} 就能够拿到所有项目的概要数据了。
当然，后续的331个项目的明细数据，还是得通过OpenHub的API来抓取。
完全是土法上马：sqlite3+numbers+csv+ruby，反正各种手法，什么称手用什么。
原本是打算在numbers里想想办法的，后来发现实在太弱。Excel也差不多，只能到网上搜索一些信息图制作的工具，后来找到了几个不错的在线工具，经过一番比较，最后决定用infogr.am来完成。的确非常不错。
我与@云风 在微博上有一小段讨论，起因还是我之前分析的一些观点：
这个结论，其实在用词上，是有些讲究的：按理说，新与老相对，小与大相对；愿意与不愿意相对，能用与没法用相对，我的两个结论，对仗都不公整。其实，确实故意为之。
于是，云风与我的对话如下。
云风：项目规模和项目历史本身有相关性吧。代码规模越大的项目历史很可能越久。
我：项目的规模，主要还是与项目本身的特性有关。原本复杂的项目，才可能越长越大。原本就是小项目，也未必就会稳定地逐年增长。
云风：这只能说明小项目可以历史久，不能说明大项目可以历史短啊。很少有新项目一开始就很大啊。代码也是一行行写出来的啊。
我：那就是成长速度不同了。比如OpenStack一开始就不小。
云风：一开始就不小只能说闭源开发过一段时间，或从别的地方搬迁过来的吧。你能想象不被版本管理工具管理的情况下，首次提交 10 万行以上的代码？看这个 link 提交日志写的 initial fork out of nova。
后来，我也没有再继续这个讨论，但是却一直在思考这个问题：“项目的大小与项目的创建时间，究竟有多少相关性？”
后来，我将两个数据，做了一个分析：Log（第一次提交代码，至今的天数）/Log（代码行数），大概得到如下一个图：
经过强大的Excel的计算，两个数据的相关系数，大约是0.203的样子，也就是说：大致上有较弱的正相关。
目前，我已经将这个分析的相关数据，放在Github上开源了。简单介绍一下：
331个一个开源项目，名单如下：
这里声明一下，仅仅是学习一下：他们是用哪些工具，来管理自己的项目的？
开源项目多如牛毛，值得分析的项目也很多很多。从哪里入手呢？幸运的是，在开源社区，有一个著名的网站，过去叫oloho，现在改名叫openhub。在他的网站首页，有这么四行字，以表明他们的数据库是多么的全面、丰富：
Indexing 669,008 open source projects
Connecting 3,742,793 open source contributors
Tracking 679,761 source control repositories
Counting 31,158,335,454 lines of code这么说来，事情就变得比较“简单”了，我需要把openhub的数据都抓回来。
具体的数据抓取过程，简直不忍详述（我的内心几乎是崩溃的）。总而言之，我只抓到了289,631个项目。openhub虽然号称自己索引了66万的开源项目，其实这仅仅是他的数据库里的最大ID号！当我顺着这个ID一个一个地去抓的时候，有很多ID都已经被删除了。
在抓取到的项目数据中，有两个数值，特别值得参考：contributors（参与开发者的数量）和users（该软件的用户数量）。相对而言，users的数据，可以认为是一个样本，即该开源项目的所有用户中，愿意并且知道该如何来openhub点击I use this的人。因此，即使是排名第一的Firefox，在openhub也只有13,158个用户。考虑到Firefox的用户数，已经超过5亿（来源于维基百科英文版），因此，我们相信这个数据仅仅是一个4万分之一的采样结果。
随后，我观察了这28万多个项目的users数据与contributors数据，顿时惊讶地发现，绝大多数项目都小得可怜，用户也少得可怜。
当我以“select count(*) from projects where contributors>30”查询时，只搜到了 1662个项目...
当我以“select count(*) from projects where users>30”查询时，只搜到了1260个项目...
当我合并以上两个条件查询时，只搜到了335个项目。
再从这335个项目中，排除掉最近一年已经不再有活动的项目，于是只剩下了331个了。（1）成功的开源项目，真是凤毛麟角。
（2）绝大多数开源项目都是少数人开发的小项目。
（3）这331个项目，也许可以作为我们的重要参考。
这是331个项目使用配置库的情况（有些项目，同时使用多种配置库），有两个现象值得注意：
（1）接近92%的项目，已经在使用Git——Git的统治地位，已经无可动摇。
（2）只有53%的项目，在使用Github——那些用Git却不用Github的项目，是什么原因？
通过这个图，可以看出两个现象：
（1）越是新创建的开源项目，hosting在Github上的比例越高。
（2）越是新创建的开源项目，事实上成功的也越多（当然，2010年以后的数量锐减，我们怀疑是好酒也要陈酿的原因）
由于不同的开源项目，代码行数差异巨大，因此我们只能以log(col)对数结果，来做区间划分。可以看到一个非常明显的趋势，当然代码行数超过10万行以后，代码部署在Github上的项目，就开始明显下降，直到为0。
排名前五的工具中，Github：91个项目；Bugzilla：81个项目；JIRA：43个项目；Trac：20个项目；另外还有9个项目，完全是在maillist里“管理”issue的。
一共有39种不同的工具，另外还有6个项目，我们无法了解它究竟是用什么来管理的。
（1）Github已经占据统治地位。
（2）Github的占有率仅仅27%。
（3）Bugzilla也算老而弥坚。
（4）有很多项目，在选择自己的工具。
1990年之前创建的项目，其中有一个已经开始使用Github了。但是，这仅仅算是个案。更加明显的趋势是：越是新的项目，越是倾向于采用Github管理自己的issue。
相对而言，其他各种Issue Tracking工具的比例，都在下降。
随着用户数量的增加，我们猜想：issue的数量与复杂度也会逐渐增加。可以看到这样的趋势：Github的使用率，也在不断下降。
主要还是工作量太大了……对这个分析有兴趣的同学，可以与我联系，咱们可以一块来干。
2005年，我还是一个典型的Java程序员。一个偶然的机会，我看到了一篇文章——《Ruby on Rails实践》。
在简单的试用之后，我于2005年05月27日在当年的JavaEye社区写了一篇热情洋溢的帖子：Java社群该向Ruby on Rails学习些什么？
当时的JavaEye站长Robbin回复到：“Python/Ruby是下一代的编程语言，Java是这一代的编程语言，要等到Python/Ruby流行，至少5年以后。正因为5年以后，所以我现在先不考虑。”
到了2006年9月11日，JavaEye上线基于RoR的2.0版本，的确是非常有趣的华丽转身。
但是，这不仅仅是个案，到了2009年5月，Ryan Dahl在GitHub上发布了最初版本的部分Node.js包，随后几个月里，有人开始使用Node.js开发应用。
随后，一股Node热潮开始出现。到了2013年，Github上一共有了5万多个Nodejs的项目；在npmjs.org上，有将近5万个Package。大量的热门项目，频繁出现在Github的排行榜上。
为什么会那么火爆，当然可以分析出很多的原因，我想聊聊最为打动我的一个原因：
当初用rails，我只需要输入：gem install rails
现在如果想用node开发Web应用，我也只需要输入：npm install express
从Github Clone一个Ruby的开源项目，想要在自己的机器上运转起来，往往只要一行命令：bundle install，而node项目呢，更加简单，只要npm install。
下面进入更加令人兴奋的环节：如果我开发了一个node.js的包，想要分享到社区，可以分两步：
（1）在npmjs.org上，注册一个账号。
（2）在本地执行：npm publish ...
这，实在是太简单了！
简单地说：通过提供易用性极高的包管理工具，大量的ruby和node项目，不必从头构建，发布代码时，也不必发布所有的依赖文件，围绕包的使用、分享、开发、协作，一种新型的开源生态圈，被建立起来了。
而这种生态圈，在老牌的开源社区里，是看不到的。
BTW： 这篇文章写于2013年，现在看来，当初的判断没啥问题，只是没想到因为NPM实在太方便了，结果......还闹出那么大的风波。
这篇文章的缘起，是一个朋友的约稿。但是，这篇约稿，实在是太难写了。打了3个礼拜的腹稿，还是一肚子杂乱的思绪、感想以及不吐不快的槽！可是文章不能这样来写呀，必须得有点条理啊。我试着按照某种“介绍–总结–反思–分析–杂谈”的逻辑来写吧。
我曾经在一家公司负责“开发者关系管理（DRM）”的工作，而运营一个公益性质的开源社区，是这个“DRM”工作的其中一部分。简而言之，公司的目标很简单，办一个开源社区，在技术圈子里树立良好的形象，以便改善公司与外部开发者之间的关系。
基于这样的目标，我们的开源社区不会有太多的KPI压力，纯公益性质的网站，给公司带来的利益都是间接的（或者说难以衡量的）。在公司发展顺利的时候，老板不妨睁一只眼闭一只眼，随便我们去折腾。一旦公司的战略发生调整，业务出现转向，这种“锦上添花”的工作，对于老板而言就是可有可无的。
归根结底，公司与外部开发者保持良好的关系，究竟能够给公司带来多大的利益，是没法说明白的。直白一点讲，我们虽然在做的是开源技术社区，而实质却是在做公关类的工作。而针对外部开发者的公关，往往无足轻重。
所以，如果企业开源不能给企业带来切实的利益，那么这种事情就肯定会昙花一现。
出于对于开源事业的持续的热情，我也一直在反思，如何才能确保这个事情能够长久地做下去，也许有以下几点需要考虑：
（1）企业开源，必须自顶向下，最高领导必须切实赞同。仅仅是“随便他们去玩玩吧”是不够的。而最高领导的切实赞同，又取决于一个企业是否真正意识到（并且相信）开源能够给企业带来好处。较之专利与基础研究，开源对于企业的价值，会以更加（复杂、交错、间接）的方式体现出来。由于涉及不可控的外部交流，开源甚至是有利有弊的。这使得企业评估开源为企业带来的利益，更加困难。所以，在获得实际的回报之前，对于开源，是需要某种信仰的。
（2）企业开源，必须持之以恒，个人玩开源，随时可以加入，随时可以退出。Free Software，不仅仅是软件自由，人也是自由的。但是，企业开源，绝对不能玩玩而已。高兴的时候办一个网站，没兴致了，就随手一关。这种事情，对于企业的形象和声誉，是有相当大损害的。
（3）企业开源，必须在内部找到持久的动力。开源不仅仅是开放源代码，更重要的是由此引发的企业技术文化的演进，如何在企业内部传播并推进一种开放、活泼、自由、创新的文化，是必须在制度层面解决的大问题。
开源当然会为企业带来价值，这篇文章不去多谈那些虚幻的、文化层面的、企业形象层面的价值，谈点实际的内容。
（1）操作系统开源，以Google的Android为例。由于Google的开源政策，Android在移动领域的占有率一直在持续上升，则将为Google移动领域的领导地位，奠定坚实的基础，由此带来的价值，简直是难以估量的。
（2）平台类开源，以Firefox和Chrome为例，作为上网的入口，浏览器的市场占有率对于企业的利益，有着战略级别的影响，如果不以开源的方式来做，IE的地位几乎是不可撼动的。
（3）语言开源，Google开源了Golang、爱立信开源了Erlang、Sun开源了Java，其中以Java占据了最为广阔的开发者市场，可以毫不客气地说，如果没有Java，Sun早就不存在了。而Sun公司围绕Java进行的一些开源项目的开发和推广，也是Sun公司能够持续扩大Java影响力的关键。
（4）参与或赞助开源项目的开发，由于企业原本就会用到某个开源项目，比如Linux、OpenStack、Hadoop，MySQL。企业的内部员工，会参与到这些开源项目中，共享全球开源协作的开发成果，同时也对这种重量级的项目施加符合自己利益的影响。
（5）被迫开源，由于授权协议（License）的限制，企业在使用、修改、分发了某个开源项目时，必须遵守相应的开源协议，以避免不必要的利益损失和形象损失。
当然，企业参与开源的形式还有很多，以上5种，可以说是比较能够向CEO们讲得明白的价值。任何企业，如果不能找到参与开源带给自己的价值，他们的开源总归是无法长久的。
从我个人而言，我肯定相信开源能够给参与其中的每个人、每个企业都带来回报。但是要说服具体企业相信这些，依然是困难的。
从由易到难的步骤而论，我想建议大多数企业，考虑以下的路径：
（1）依法开源：那些必须开源的，别再藏起来了。
（2）赞助开源与开源社区：找到对自己公司有价值的开源项目以及开源社区，哪怕仅仅出于公益，也赞助一些。
（3）鼓励员工参与开源：从这个阶段开始，会收到“变化气质”的效果。
（4）自身产品、项目开源：这一步需要慎重选择。
（5）主导某些开源项目或开放标准，这个就是至高境界了。
原文发布于：2013年08月
@johnniechau 推荐的《代码阅读方法和实践》，是一本好书，我只打算在这里简单地聊一聊自己的经验与思考。
我们先假设一种最恶劣的状况，你被迫接手一个遗留项目，原来做项目的家伙，全都四散逃亡了，不但没有任何说明文档，而且还找不到人，老板给你一段并不宽裕的时间，你得读懂他们的代码，然后接着维护……通常，这是噩梦的开始。
当然，从提高能力的角度而言，这是一个好机会。所以，@刘立 虽然只说了两个字“压力”，我认为的确正中要害！
我们可以用拼图这样的游戏，来做一个比喻。一地的碎片，你如何将他们尽快地拼在一起？
回到代码阅读，我们来做一个类比：
另外推荐阅读我目前正在写作的一份文档《借助开源项目，学习软件开发》——第五章：理解开源项目：link
<下略>
原文发布于：2013-02-19 @ 知乎
这本来是一篇打算投稿给《程序员》杂志的稿子，可惜他们用不上了。于是我就打算发在这里，欢迎大家多多批评。
关于开源，我有很多的感想，但是在一篇文章之中，我可以谈些什么呢？在与程序员杂志的编辑杨爽聊天时，我虽尚未理清自己的思路，却想到了一个听起来不错的标题《当谈开源时，我谈些什么》。因为像这样一个看起来完全开放的标题，似乎什么都可以往里面装，简直可以随便涂涂就写出一篇形散神不散的散文了。
那么，到底应该如何看待开源呢？近日我在读的一本书：美国的Steven Weber写的《开源的成功之路》，其中说到一个非常重要的世界观的区别：关于人类的动机，具体到编写软件上，究竟是为了挣钱，还是像真正的艺术家一样就是为了创作和尝试？在比尔盖茨看来，盗版的行为，偷窃软件，让程序员免费干活，最终都会抑制创新。而在开源黑客看来，发布软件却不发布代码，限制了合作的范围，也阻断了别人可能的改进和进一步的创新。看起来，两边都说的很有道理，而且有趣的是，都在拿创新说事儿。究竟什么样的激励，才能激发更多、更好的创新呢？是金钱，还是纯粹的爱好、乐趣和荣誉感呢？
公平一点说，如果没有软件版权、专利法、代码编译与加密技术，软件产业可能远远没有现在那么庞大，也难以养活像现在那么多的程序员。也许只会剩下一部分真正热爱编程，有没有钱都要编点什么的人了。但是，我更想从另一个角度来提问：“这个世界上，最重要、最伟大、最具有影响力的创新，有多少是金钱激励出来的呢？”
再提一个问题来问咱们程序员自己：“选择程序员这样一个职业，是因为它能够有一份足够体面的薪水？还是因为它让我有机会创造一些改变世界的东西呢？”最能够激励创新的，难道不是创新本身吗？在《失控》中我读到过一段话，曾令我激动万分。研究人工生命的最高远的动机是“目前，普通的计算机程序可能有一千行长，能运行几分钟。而制造人工生命的目的是要找到一种计算机代码，它只有几行长，却能运行一千年”。如果我们能够创造出这样的代码，那简直就是一个程序员最高的追求。
所以，在谈开源的时候，我想谈的第一点，是关于创新。究竟什么样的模式，才能更好地激发创新？
除了《开源的成功之路》，还有一本书也很值得一读，那就是Steven Levy写的《黑客——计算机革命的英雄》。豆瓣上有一位Pope写书评，非常精当：“这本书并不是很有吸引力，因为每翻过几页，就恨不得撇开书，抡起胳膊大干一场。”是的，那些黑客英雄的故事，令我们读来大呼过瘾。那样的生活、那样热血的日子，真是令人神往！
在《黑客》第二章，以非常概括的方式介绍了“黑客伦理”：任何人与任何规则，都无法阻断人类的好奇心；没有权威，凭实力说话；你可以在计算机上创造出艺术与美；计算机可以让你的生活更美好……
如果你看了以后，也深有同感，那么成为一个黑客就是你自然的选择。成为一个黑客，就是选择一种生活方式，选择无尽的探索与创造；选择用键盘书写代码，来改变这个世界；选择向全世界展示自己的成果；选择和全世界的聪明头脑联接在一起。而对于黑客来说，无法看到源代码，无法了解事情是如何运作的，无法掌握与控制那些系统，这简直就是一种难以想象的罪恶。
所以，在谈开源的时候，我想谈的第二点，是关于生活方式，以及选择这种生活方式时，背后的信仰。
这篇文章，我是用简体中文写的，面向的目标读者是国内的开发者。无法否认的一点是：现状的确不容乐观！
曾经我在CSDN接受过一次书面采访，CSDN的记者提了很多问题，整篇文章的标题是《拥抱开源从中受益》。但是，下面的跟贴评论，实在是令人丧气：收入可怜，没有属于自己的居所，开毛源；开源在咱们的社会主义初级阶段根本行不通。搞技术的都是穷人，开个狗屁的源；估计开源在中国，就是有钱，有房，有车，有老婆，有孩子，还没什么具体的事情干的人，无聊了然后去弄弄的东西……
这是现状之一。
在国内，我看到很多人自称屌丝。而程序员，则自嘲为码农。自我贬低，自我嘲讽，自怜自艾，自诩为苦逼。放眼望去，人家全是高富帅，官二代。唯独自己是看不到未来，买不起房的矮穷挫。
这是现状之二。
这个世界上有两种奇怪的逻辑（而且在国内都很常见），一种是“国外有一个好东西，咱们克隆一个吧”；另一种是“已经有一个很好的了，我们为什么还要做一个”。这两种逻辑背后，其实掩藏着同一种不自信，那就是：“我们不可能有创新，不可能做出更好的东西来，不可能后来居上！”这是何等的可悲！
这是现状之三。
做开源的人，往往非常孤独。一个开源项目，默默的诞生，默默的改进，然后默默的停止，最后默默的消失。这样的孤独感，很多开源人都体会过。国内的开源人，还有一些特别的体会：被人质问“做这个干啥，又不能挣钱”；被人贬低“国产的东西，会有好东西”；被人反问“你们不是做免费软件的吗？怎么还要收服务费”。
这是现状之四。
所以，在谈开源的时候，我无法绕过现状不谈。
有一种常见的思维方式，就是分析复杂现象背后的因果关系。通常我们会发现一个循环依赖的因果链。既可以用于解释现状，也可以用来指导破局之法。简单的分析国内的开源领域，我们也可以发现这样的循环。因为缺乏足够多、足够好的开源爱好者，自然无法做出更多优质的开源产品；因为缺乏优质的国内开源项目，大多数开源产品的使用者，都习惯于在国外的开源社区寻找项目；因为大家的眼光都放在外面，作为受益者的个人用户与企业用户，也难以兴起回馈社区、捐赠开发者的念头；因为国内的开源人难以得到足够的赞助和支持，自然不会有很多人热心的投入开源。这样，开源人、开源产品、开源用户的循环依赖，就成了一个死结。
当然，如果乐观一点来看问题，我们也可以说：要建立一个良性循环的开源生态圈，既可以从任何一个要素入手，也不妨大家齐努力，从多个方向下手。日拱一卒、不期速成。逐步推动，总会有所进展。
如果要分一个轻重缓急，那么我认为给国内开源，找到更多的生力军，也许是可以优先考虑的做法。一方面要让更多的程序员意识到，即使不挣钱，做开源也是有收益的。我想引用微博上的两段话，来说明我的观点：＠姜宁willem“知识改变命运，想通过开源项目获取知识，只要你愿意，地球上没有人能阻挡你。 在这里不拼爹，不拼公司背景，拼的是对技术追求的那颗心。 通过开源项目能实现个人价值，只是在国内这样的成功案例不多”， ＠Freeman小屋“相对于在闭源公司的工作，开源社区的工作决不会让你成为nobody，每一次代码提交，每一次回答问题，都是对你自身reputation的积累，并且你的工作都有track，想想找工作的时候你只要说我是某社区的谁就能拿offer了。而且，我特别希望在校的大学生，能够意识到这一点，在完全没有经济压力、思想又最为活跃的阶段，多多参与开源，绝对是有益无害，一本万利的好事情”。
其次，则是帮助国内现有的、优秀的开源项目，找到用户，找到参与者，找到加盟者。让他们能够更好的发展起来，成为国内开源项目的榜样。诞生一个一个的成功故事，使得做开源，也变得越来越有吸引力。这方面的工作，我想CSDN、《程序员》杂志这样的社区与媒体平台，也许可以做得更多。如果能够出现国外那样的成熟的开源基金会，以某种公开、公平的方式，赞助各种开源项目。以及帮助那些顶级的开源项目，更好的走向商业化的方向。总之，可以做的事情非常多。
当然，帮助众多的、不知名的开源项目，能够出现、能够发展，则是开源托管平台这样的服务应该努力做的事情了。在知乎，有一个问题“GitCafe 这样的代码托管网站在国内的前景如何”，我的回答是：“我在盛大创新院工作，我们团队，正在做一个叫做 www.teamhost.org 的开源托管服务。说起来，还是GitCafe的竞争对手。在我看来，中国的开源社区，不是太多，而是太少太少。应该有至少10～20家，努力的、优秀的、互相良性竞争的开源托管服务社区，大家一起来做开源服务，不但竞争，而且合作。不但努力争夺用户，而且共同把开源的爱好者服务得更好。这样，中国的开源才能发展起来，而且发展得越来越好”。
再其次，才是说服更多的企业，赞助开源。毕竟商业公司，不容易看到太虚幻的利益，只有实实在在的好处才能够有说服力。当然，这个事情总是困难的。所以，对于这种困难的事情，说得太多意义不大，倒不如各自努力去做。
就此搁笔。
本文写于：2012年7月
今天，@小马msn 的一条长微博《开源就是一锅石头汤》，引发了很多开源爱好者的思考与探讨。我当时的回复是：“这个话题很值得细细分析一番。回头好好写一篇”。
1．这是一个老故事，主角有时是士兵，有时是流浪汉，有时是聪明的小孩子。但是寓意非常清晰：走投无路的家伙，凭借忽悠，让别人付出了很多资源，而他(们)得以坐享其成。
2．汤的底料是石头，人人都明白，石头对于汤毫无贡献。但开源不是这样一种生态，在一个开源项目中，发起人投入的，是整个项目中最为宝贵的财富：源代码。也正是因为有这样的投入，才能引来更多的人投入其他的资源。
3．这个故事的发生地，通常是某个村庄，因为只有“没什么见识的村里人”，才会相信石头做汤的“鬼话”。而开源社区，恰恰是最为开放，也最无法骗人的。源代码就在那里，而且是放在互联网上。那些能够上网的人，他们那么容易被骗吗？
4．这个故事的噱头，是“一个秘诀”。一个令人感到匪夷所思的秘诀。更加有趣的是，故事从头到尾，在石头汤做出来以后，在村民们已经喝到以后，居然大家还在赞叹不已。这样的故事本身已经令人生疑，更不要说在开源社区。源代码是不是能够运行起来，是不是真的有用，难道不是立马就能判断出来的吗？
5．@小马msn 这个版本的故事，有一个更加光明的结尾：“有一颗宽容之心，真诚善良之心，石头也会做出美味的汤来”。但是，宽容、真诚、善良，真的可以建立在谎言的基础上吗？
6．抛开故事不谈，开源的确是非常难以成功的事业。这需要很多方面的投入，也需要各种层面的努力，包括智力、耐力、人力、财力、物力、天时、地利、人和，等等。而这一切的基础是开放、包容、坦率、真诚，以及能够体现出开发者这些品质的“源代码”！
7．的确，开源也需要忽悠，也需要对外说服。但是，这样的说服，恰恰不能建立在谎言的基础上。如果，你自己并不真诚的相信，自己的开源项目一定能够成功，怎么可能让别人相信呢？
8．这个故事中，的确存在一个真理，那就是协作的力量。当然，不仅仅是开源如此。不过，在我看来，开源的确是最有可能改变世界的协作方式。
9．总结观点：在我看来，开源不是石头汤，不是忽悠别人投入资源，不是无奈，不是空想。而是一种信仰，是一种价值观，是一种生活方式，是一种推动世界，变得更好的力量！
原文写作于2012年5月，某次《我们的开源项目》活动之后。
《界面》的一篇《隐形战友》，引发了霍炬的批评《那些被歪曲的开源软件和OpenSSL的真实历史》
然后新浪名博@破破的桥，也写了一篇《针对OpenSSL捐助的讨论》。
破桥的观点，浓缩以后，是这么一句话：“openssl长期以来代码更新慢，质量差，根本原因是缺钱。它找不到商业模式，大公司不重视。个人用户虽然在用，但对它没任何概念，认捐者寥寥，每年几千美元。”
我的批评如下。
看了破破的桥的回应。别的不多说，就一条。霍炬说，openssl主要是管理问题，不是钱的问题。而他说：请好的管理人员要钱。也许有些程序员是天生的管理人员，但这很罕见。问题在于，OpenSSL基金会暴露的管理问题，不是需要花高价请优秀的管理人员才能解决的。而是他们犯了很多完全不应该犯的低级的错误！
如果我开源了一个项目，然后人家批评我的代码烂。我辩解道：“还不是因为你们都不给我捐款，害我没法雇佣到优秀的程序员，所以漏洞一直存在，代码只能那么烂。”我如果真敢这么说，以后就别再开源圈子里混了。但是，破桥的观点，本质上就是这种推卸责任的逻辑。这就是圈子外的人常见的想当然了！
在开源圈子里，正确的回复应该如何呢？骂我的代码烂，没问题！要么给我贡献代码，要么给我提issue，要么自己fork一个版本自己玩。给钱当然也很好，但是那个不是关键。帮助一个开源项目越来越好的根本，是一个一个优秀的patch，除此而外，全是间接贡献。钱是最间接的。
而且这种逻辑，对于那些从来没有收到过捐款，全部是由自愿者业余贡献，但是却非常优秀的开源项目是非常不公平的！
常见的故事应该是：一个开源项目，因为贡献者越来越多，质量越来越好，用户越来越多，才会有商业与个人的捐助出现。如果一个开源项目在走下坡路，质量越来越差，捐助越来越少，那首先应该反省的，也是开源项目的开发者与管理者自己，而不是倒果为因，推卸责任。
以上，是我对破桥文章的一点看法。总结来说，我对OpenSSL的批评，要远大于同情。
这是因OSTC大会的需要，接受CSDN采访的一个答复稿。文字与CSDN网站的略有不同。
我是2013年11月加入华为的，目前主要的工作是华为的内源社区平台建设。简单的说，这项工作的主要目标，是将开源社区的思想、方法、开发模式与激励机制，引入到华为内部，让华为内部的六七万研发人员，能够以开源的方式，开展内部的开发协作活动。（Open Source -> Inner Source）
在加盟华为之前，我就清楚的认识到，这项工作的难度会非常大。但是，令我惊讶的是，在华为内部，从上到下，都有相当多的开源热心人，开源爱好者，甚至开源大行家，在积极的推动这一平台的建设，在努力推动内部文化的逐步变革，也在推动着华为变得更加开放，甚至更加积极的参与到开源社区之中。
总体而言，我认为这一变革大有可为。能够身处其中，并贡献力量，我也非常自豪。
事实上，当年的活动，我只是首先提出了倡议，不能算是我一个人创建的活动。从一开始，就有很多很多的热心朋友参与了进来。
在《大教堂与集市》一书中，有一条经验是这么说的：“当你对一个项目失去兴趣时，你最后的职责是把它交给一个称职的继任者”。
后来，“我们的开源项目”活动，被“开源力量”的朋友继续发扬光大，后来又进一步推出了“开源力量公开课”的一系列线上、线下的课程。目前也办得红红火火，相信很多朋友也都知道。
至于对开源的宣传效果，我感觉很难评估。总体来说，国内的各种平台、媒体、渠道，对于开源项目、开源社区、开源参与者的宣传，已经越来越多，也越来越好了。
依然是“慎入”，其实，任何时候做开源，都不危险。但是，个人参与开源，始终是一个小众的，孤独的，大多数时候没有太多回报的事情。
如果一开始期待太多，很可能会迅速感到失望。做好心理建设，对开源有深入理解，然后再投身开源，我想会有更大的收获。
在那篇文章中，其实有一个观点，我并没有明确的表述出来：在开源社区，除了有开放、温暖、善良、互助的一面，同样还有冷漠、残酷、甚至无情的一面。
在同一个领域，最初可能有多达几十、上百的同类开源项目，纷纷涌现，各领风骚。不要说那些始终默默无闻的项目，即使是那些曾经风光无限的项目，一旦新的替代技术出现，大家就都开始转移兴趣，投入新的热潮之中。大家不再批评，甚至不再谈论，甚至都不再记得曾经有过的开源项目。所谓前浪死在沙滩上，指的就是就是这种情况。相对来说，OpenSSL已经足够幸运了。
我一直认为，互联网的众多思想和实践，其根源来自于开源。这里只举一个例子：注意力经济。开源项目，开源创始人，其实同样迫切渴望吸引更多的注意力。有人关注，有人使用，有人反馈，甚至有人批评，对于开源项目的发展至关重要。这也正是霍炬的文章中谈到的观点：“使用它就是对它的帮助”。
需要区分的是最想得到的帮助与最有价值的帮助。最想得到的是关注度，而最有价值的是patch。有人源源不断的为我的项目提交patch，这是最有价值的贡献。当然，这个需要有正确的态度。《大教堂与集市》中所说的“正确的态度”。这是避免项目流产的关键。至于何谓“正确的态度”，建议还是去通读《大教堂与集市》全书为好。
我最近刚刚写了一篇文章《experience.exe》，是讨论一个现象：在以docker为代表的容器技术出现之后，可执行的经验，变得更加容易了。
当然，这仅仅是非常窄的一个观察角度。事实上，Docker的出现，有可能改变一切。上次在某个技术群里有朋友说：“Docker也不会是银弹”，而我的看法是：“Docker不会是银弹，但是容器技术是可以确认的未来”。
从容器的视角出发，我们得以重新思考：操作系统与发行版、服务化架构与架构设计、自动化运维与监控、自动化部署与虚拟化、自动化测试、协作开发模式......新的商业机会，也会从中孕育。
当然，我一直说“以Docker为代表”，而不是单单谈Docker。就像上一个问题中谈到的：前浪死在沙滩上，也很有可能。
只有我不需要的广告，才是我会反感的广告。当然，更好的、更有技术含量的广告，是需要花心思的。站着把钱挣了，善用技术很重要。
另外，这其实是一个有含金量的问题。越是有好的内容的社区，用户越是能容忍社区的广告。基于优质的内容，赚钱不难。
最后，恢复形象是最难的事情。一失足成千古恨，印象坏了就很难恢复了。
社区与代码，我认为是土壤与种子的关系。没有土壤，种子不可能生根、发芽、茁壮成长。但是，再肥沃的土壤，没有栽下种子，什么都长不出来。
热火朝天的社区，当然会帮助开源项目成长的更好。不过，我认为另一句话也很重要：Talk is cheap, show me your code。
所以，我认为能够帮助社区成员，专注于代码的社区，才是真正的好社区。
中庸之道很重要，太过于清高，拒绝任何商业的社区，同样很难发展壮大。
所以，社区成员的共识很重要。较之众说纷纭的意见，后台的运营数据，是更加重要的参考依据。
换言之，开辟广告位，投放广告，然后观察数据，再决定如何调整。这样会比较稳妥。
之前看过一篇文章，标题是《开源已经完胜，但这并不是结束》。在我看来，越来越多的商业公司，开始意识到开源的价值，也因此各怀目的地投入到开源之中，在最初的开源黑客们看来，这未必就是什么好事。
开源作为一种标签，开源作为一种口号，开源作为一种企业形象，开源作为一种手段，开源作为一种商业模式，在很多真正热爱开源的人看来，往往并不是那么对胃口。
当然，还是得回到中庸之道上来，拒绝商业、质疑动机、预设立场、甚至草木皆兵，都未见得是好事情。
总体而言，我认为未来几年的开源，肯定会越来越繁荣，越来越热闹，吸引越来越多的参与者甚至搅局者，这都是好事情。距离开源的盛极而衰，现在还早得很。
庄表伟，盛大创新院高级研究员。1997年毕业至今，始终战斗在编程的“第一线”，2009年加入盛大创新院。一直致力于推广并服务开源，热爱社区，热衷参与各种社区的交流活动。对于开源的事业贡献度很低，目前稍微能够拿得出手的项目，是一个正在进行中的写作计划：《借助开源项目，学习软件开发》。
这个活动，最初是因为即将召开的QCon，那天我在网上浏览QCon的演讲主题列表，就发现绝大多数的演讲主题，都是在讨论人家的、热门的、主流的技术，而没有一个讲坛，可以让大家聊聊自己的开源项目。在4月19日的QCon的演讲中，我也说了这样的言论：“大家来参加技术聚会，都怕听到水货，希望听到干货，但是，我今天带来的，不是水货，也不是干货，而是一些“鲜货”，一些设想，一些思考，一些正在进行的工作，不仅仅来传播些什么，更希望能够有所交流，能够找到一些同道”。
所以，在2月24日我就在新浪微博上喊道：”有没有可能组织一个技术聚会，大家各自聊聊自己做过的，正在做的，打算做的开源项目啊？“ 这条微博引起了远远超出我预期的反响，很多朋友都因此而积极的投入进来，比如@程开源，比如@ben_杜玉杰，比如车库开源小组的@赵乐天。还有很多很多我不认识的志愿者，愿意加入，愿意帮忙，愿意报名，愿意讲讲自己的开源项目。
这个活动，一下子就“火”起来了。
从微博上的一句话，到现在差不多半年过去了，我们一共举办了6场“我们的开源项目”活动，分别为：
2012年5月20日——上海
2012年5月26日——北京
2012年6月15日——成都
2012年6月30日——深圳
2012年7月14日——北京
2012年7月21日——上海
参与活动的总人次超过500人，其中志愿者约有40多人。20多个有分量的主题演讲，以及超过30个的5分钟闪电演讲。
不过，这些数据其实并不是特别重要，因为我这不是在写某个工作汇报，而是在聊聊感想，这些活动，吸引到了很多朋友，这些朋友原本都是各自为战，孤军奋斗。现在大家终于发现，原来有那么多人，都热爱开源，都在为之默默的努力着。从这一点来说，我们发起这个活动的初衷已经实现了。
印象深刻的项目有很多，但首先是因为开发者令人印象深刻，连带着项目也变得有趣起来。
@游戏开发极客的GEEK：这个项目吸引我的，首先是演讲标题《开源屌丝养成计》，在第一次活动中，这位“屌丝”闪亮登场，以活力十足的方式介绍着自己的项目，赢得了满堂彩。现在他正在做一个HTML5的类似于马里奥的游戏，大家可以先去玩玩看。
@OpenERP_Jeff的OpenERP中文社区：OpenERP中文社区也有很多“苦逼”的数据。一个Wiki，非常非常多的内容，只有4个人撰写，而且其中90%的内容，还是Jeff一个人写的。为了养活社区，Jeff在外面接活，一年赚了3万多，还分了2万多给社区的会员。但是，他演讲中的一页，引起了很多人的共鸣：
通过实现理想，证明实现理想是可能的。
通过改变世界，证明改变世界是可能的。
即使是在中国。
@李大维、@何琪辰爱上大的ArduBlock：这是一个开源硬件的配套开源软件项目，通过拖拽的方式为Arduino编程，何琪辰当场演示，当那块Arduino板子，开始闪亮起来的时候，全场响起了热烈的掌声。值得一提是，何琪辰目前还在上海大学读研，真是很棒！
@zozoh的nutz：zozoh是我在所有活动中，发现的最擅长演讲的家伙。风趣冷幽默，简直可以去讲单口相声。因为他对nutz的生动介绍，我才去看了那个项目，发现已经相当完整，文档清晰丰富，足够可以用于生产开发了。
@老赵的Jscex：Jscex是一个Javascipt的异步编程类库，现在改名为（Wind.js），本身的代码质量与完成度都非常高，但是更加值得一提的是老赵的一记狠招，他自2012年起，每月1号将为Jscex拨款1024元人民币，用于鼓励个人对Jscex的研究及使用，包括但不限于推广建议，研究，案例，或是在开源项目中使用Jscex。真是很令人佩服！
@開源哥的ADB GUI 4 Linux：这个项目，还没有在“我们的开源项目”中讲过，但是那次在北京活动后吃饭的时候，我遇到了这个项目的作者：開源哥，一个刚刚满17岁的高二学生，目前在加拿大读书，暑假的时候回来参加咱们的开源活动。作为一个新鲜的95后开源人，我感到很有必要介绍给大家！
国内开源项目的数量，是一个很难定义的概念。从最广的定义来说：某个开发者，把自己的代码放在一个公开的网络上，就算开源。现在更加简单：在Github上fork了一个项目，也得算一个。按照这个计数规则，超过10万的项目，甚至更多，都有可能。
稍微窄一点的定义：由国内开发者发起的开源项目，从历史上算起，无论现在的死活情况，相信应该能够上万吧。
再稍微严格一点的定义：到目前还在持续开发、维护的项目，最多能够上千。
这真的非常不容乐观！至于开源开发者，实在没法统计，也许类似于人口普查的工作，可以由谁牵头来做一下。
我的看法是这样的。一个好的开源生态，应该有以下几个部分组成：
热情的、爱好开源的开发者；
能够源源不断培育优秀开发者与发起优秀开源项目的高校；
能够资助开源项目的基金会；
愿意捐助开源基金或开源项目的企业。
在目前国内的状况是：四个方面都相当缺乏，但是最为缺乏的是一批开源基金会，其他的国内或多或少还有，基金会目前就是空白。其次是高校，国内愿意或者已经发起开源项目的高校，可以说凤毛麟角，而对于在校大学生的计算机教育，也不重视开源这一方面。愿意支持开源的企业，近年来略有上升，但是的确还远远不够。目前的现状就是如此。
之前我写过一篇文章，叫做《当我谈开源时，我谈些什么？》其中谈到了一些观点。
改变世界：程序员的梦想，是希望能够创造一些改变世界的东西。而开源程序员的梦想，则是希望汇聚所有可能的力量，一起来改变世界。
好奇心：开源的动力，其实是来源于探究事物本来面目的好奇心，对于那些有好奇心的程序员来说，不能了解一个软件的内部是如何工作，简直是令人无法忍受的事情。
乐于分享：这是另外还有一个没有谈到的观点，是受知乎的创始人周源提到过的一本书《认知盈余》的启发：那些有着足够积淀，又有足够的业余时间的人，是非常乐意分享的。这种分享在社会化问答出现之前，也许只有开源程序员，做到了这一点。
我们欢迎所有的朋友参与进来。
有自己的开源项目，当然非常欢迎。仅仅是对开源感兴趣，想来了解一下，感受一下氛围的朋友，也非常欢迎。
有一次来参加活动的，是一个学专利法的律师，他说想来了解一下国内开源的情况，我认为也很有助益（无论是对于他，还是对于我们这个活动都是）。
也不仅仅是欢迎国产的开源项目，那些参与了国际上著名的开源项目的开发者，例如@Freeman小屋，@姜宁willem，就是Apache Member。通过他们的介绍，我们也对Apache，对国际上通行的开源项目组织，对全职的开源生涯，有了更多的了解。
慎入。
这个圈子看起来很有意思，但是进来以后你又会发现没有自己设想的那么好。做开源的人其实很孤独。它不像发微博，有两个人转发，五个人评论，你会收到一些反馈。写一个开源软件，三五个月没人理你是很正常的事，因为（如果）你写得不够好，别人可能没兴趣来看你的东西。所以需要熬得住，熬不住的人就会退出去。熬得住的人坚持做下去一定会有回报，但是这个回报一定不是很快的。如果说你想进来玩玩儿，你很有可能觉得没劲很快就退出去了，出去的时候还会说：开源没什么意思，都没人理我。很多人都是开源一个项目，扔在那没人管，也没人理，时间长了他也就不管了。这种事情是再平常不过了的。他们可能就是长江后浪推前浪里的前浪吧。
我没有这方面的太多想法，但是我觉得开源和商业应该是不矛盾的，所以如果要我选择许可证的话肯定不能和商业矛盾。但是同时我也很敬佩GPL背后的理想精神，它的背后是有着崇高理想的。也许在有些人看来它显得有些莫名其妙，甚至和商业有一些冲突，但是我个人很尊重GPL。有一些项目我觉得会很适合用GPL来开源，但是如果是偏应用型的项目我会选择类似于Apache这样的许可证，这需要依具体情况而定。
我希望，这个活动能够变成一个在国内多个城市，都同时存在的常态聚会。很多IT较为发达的城市，都有一群热爱开源，从事开源的朋友，大家能够因为“我们的开源项目”这样的活动而结识，进而成为越来越熟悉的朋友，那么朋友之间定期聚会，就会是一件顺理成章的事情。
每个月，大家碰碰头，聊聊最近自己那个项目的进展，各自抱着自己的笔记本，show一下自己的代码和界面，大家在互相品评一番，也许有些新的点子，新的创意，就会在其间诞生。
我前面也说过，做开源的人其实很孤独，能够有一个定期的聚会，大家互相打打气，鼓鼓劲，将会起到一种抱团取暖的作用。
另外，还有一个大的设想，当然目前还仅仅停留在设想的阶段，就是搞一个国内开源爱好者的年度大会，把大家都聚到一起来，畅所欲言，深度交流。如果能够将这样一个大聚会办成，我将会非常的兴奋！
发布于 2012年08月13日 @ CSDN
今天，整个上午我都在创智天地7号楼，参加一个社区经理的活动。社区经理培训活动之四 ——“如何从0开始做一个很棒的社区”
来了很多朋友，大家都是8分钟快速演讲，给我留下最深刻印象的，是OpenERP社区的Jeff，还有ThinkLAMP社区的板子。
Jeff的社区，做了很多很多的贡献，但是也有很多“苦逼”的数据。一个Wiki，非常非常多的内容，只有4个人撰写，而且其中90%的内容，还是他一个人写的。为了养活社区，Jeff在外面接活，一年赚了3万多，还分了2万多给社区的会员。
板子说：对于社区来说，如果钱不是问题，那就没有问题了。
我能够体会到这种孤独，做社区是孤独的，做开源是孤独的。那些需要理想支撑，需要奉献精神的事情，大多数时候都是孤独的。
今天R语言社区的朋友（不是李舰，但是名字我忘记了），在演讲中一直在强调“少数民族很团结”。我的感想就是，我们这些努力想要做社区，想要做开源的人，也是一种“少数民族”。尤其需要抱团取暖，需要相互鼓励、需要相互支援。
我们都是干柴，但是孤零零的燃烧，是无法长久的。
我们过去都相当缺乏交流，互相都很少知道其他人的存在。
我们期待能够有更多潜在的干柴，能够因为我们的燃烧，而感觉到光亮，进而变成新的干柴。
我们更期待更多的干柴加入我们，大家抱成团，一起燃烧。这样才有可能烧成熊熊烈火。
当然，如果能够有越来越的企业，能够多多的赞助汽油，我们会更容易烧起来。
我们都是干柴，期待烈火！
原文发布于：2012年06月10日
导读：盛大创新院高级研究员庄表伟近日编撰系列文章《借助开源项目，学习软件开发》活动，引起业界关注。庄表伟认为，通过编撰这些文章，希望更多开发者能够借助开源项目提高开发效率，减少重复劳动并从开源软件中受惠。同时，他呼吁更多开发者参与此项活动，通过分享过来人的经验教训，帮助那些初次接触开源的朋友。为此，CSDN记者就开源社区未来前景，开源所带来的机遇和开源是否受到企业青睐等几方面对庄表伟进行了采访。
以下是采访内容：
CSDN记者：您为何如此重视开源？
庄表伟：随着科技的不断进步，整个世界正在发生着日益深刻的变化，而在我看来，开源则是改变这个世界最为重要的一股力量。因为本着开放、共享、互助、共赢的精神，开源不但改变着这个世界，而且在很多方面，都在使这个世界变得更加美好。这个事实，几乎已经被全世界所认可，但是在中国，开源的发展与中国程序员的数量，却远远不成正比。因此，我希望能够尽自己的一份力量，并且尽可能多的借助企业、学校、组织、社会的力量，找到更多的开源同道与发烧友，将国内的开源社区，建设得更加繁荣一些。
CSDN记者：目前中国开源使用者的贡献是否在稳步增长？
庄表伟：是指开源的使用者，还是开源的贡献者？如果是使用者，那么很少有开发者是完全不用任何开源软件的。从传统的Linux+Apache+MySQL+PHP，到现在新兴的各种语言、框架、类库、工具，开源软件已经无处不在了。
但是如果要说开源软件的贡献者，那就少得厉害了。当然，我没有任何的统计数据支持，所以究竟相比其他国家，这个比例低到什么程度，我也不知道。不过经常会听到这样的观点：开源？我还要吃饭呢！还要买房结婚，还要养活老婆孩子呢！每天正经的工作都干不完，哪里有空做开源这种“奉献”？
CSDN记者：您认为中国开源社区未来发展前景如何？
庄表伟：较之国内开源的贡献者数量，由国内的开发者发起并主导的开源项目，少之又少。 在我看来，中国开源社区之所以发展得如此落后、缓慢，是存在着很多原因的。也许将来我会专门写一篇博客，来探讨一下这个话题。
CSDN记者：企业在选择解决方案的时候必须要考虑成本问题，例如部署成本、长期管理成本、用户支持成本、故障停机成本等。而且需要大量的技术人员来维护和管理，您认为在考虑成本的情况下，开源会得到企业们的青睐吗？
庄表伟：“开源软件的长期管理、维护成本，会高于闭源软件、稳定性会低于闭源软件”，本来就是闭源软件公司在长期散布的谣言之一。对于大多数企业来说，只要不断的告诉他们：“选择开源，就是选择没有支持服务，就是选择不稳定，就是选择高风险，就是选择无尽的烦恼。”他们就会战战兢兢，心甘情愿的购买闭源软件。直到那些敢于尝试的企业，真正尝到开源的甜头，随后那些胆小的企业才会迎头赶上，放心大胆的拥抱开源。这样的故事，将会不断的在一个一个的IT领域发生，直到这样的神话，再也没有人相信为止。
CSDN记者：您认为未来开源技术人员的数量会成线性下降还是增长？
庄表伟：在未来，没有什么技术人员是完全不和开源打交道的，是完全不懂开源的。也就是说，按照某种定义来看，未来所有的技术人员都是开源技术人员，同时也是闭源技术人员。
CSDN记者：现在有很多公司都或多或少的做开源项目，但是他们所走的路却截然不同，您认为开源项目能为开发者带来什么样的商机或是机遇？
庄表伟：企业开源，与个人开源，与开源项目企业化，可能是开源这个生态圈中，众多不同的形态之一。至于开源项目能够为开发者带来什么？我想，绝大多数开源爱好者与开源项目，都是没有盈利目的，都是没有想过什么“商机”的。也许出于一个很简单的原因，开发者想要做个什么，然后就很自然的把源代码开放出来，让所有的人都有可能参与进来并从中获益。乐趣是第一位的。当然，有一些美妙的成功故事会传到我们耳朵里，XX万美元的投资如何如何。不过，这个真的不太重要。
CSDN记者：最后请您与我们分享下有效地学习开源项目的建议或忠告？
庄表伟：我在知乎曾经简短的回答过这个问题。 简单的摘抄最后一段过来，“总结一点是：学习开源，就尽可能在代码里找答案，而不是在代码之外找答案，那些都是二手的，而且很可能是不准确的。”当然，更多的建议与忠告，敬请关注我们正在进行的开放文档协作项目：《借助开源项目，学习软件开发》。
原文发表于：2012-03-26 @ CSDN
我想来回答这个问题，说说我对开源托管网站的看法。
1．我在盛大创新院工作，我们团队正在做一个叫做 http://www.teamhost.org的开源托管服务。说起来，还是GitCafe的竞争对手。
2．上一次“我们的开源项目”活动，淘宝的淘叔度（淘蝌蚪），ThomasYao（GitCafe），我（Teamhost），以及上海锐道的朋友（http://BSDN.org），汇聚一堂，共话国内的开源社区发展，大家在一起聊了很多。参见活动报道： http://www.sarons.org/article-view-16.html
3．在SourceForge之后，按照某种理由，Google Code根本不必再做。同样的，在Google Code这样的“王者”出现之后，Github根本就不必再做。再后来，Bitbucket自然也不必再做，CodePlex也不必再做。如果你去看英文 维基的一个条目：开源托管服务比较，至少有几十个这样的网站，按照某种逻辑，都不必再做。开源托管服务比较
4．这个世界上有两种奇怪的逻辑（而且在中国都很常见），一种是“国外有一个好东西，咱们克隆一个吧”；另一种是“已经有一个很好的了，我们为什么还要做一 个”。这两种逻辑背后，其实掩藏着同一种不自信，那就是：“我们不可能有创新，不可能做出更好的东西来，不可能后来居上！”这是何等的可悲！
5．在我看来，中国的开源社区，不是太多，而是太少太少。应该有至少10～20家，努力的、优秀的、互相良性竞争的开源托管服务社区，大家一起来做开源服务， 不但竞争，而且合作。不但努力争夺用户，而且共同把开源的爱好者服务得更好。这样，中国的开源才能发展起来，而且发展得越来越好。
6．@sapjax 这样的回答，在我看来，是非常糟糕的一种思维定势。在http://blog.teamhost.org/?p=91 这篇博客的评论里有类似的观点：“劝你们还是别做了，github 那么强大，真不知谁会用你们的，对于coder来说，都会选择github吧！” 我的回答是：人比人，还气死人呢！怎么咱们都还活着呢？
原文发布于：2011年 @ 知乎
到2012年11月，teamhost被关闭；
到2014年8月，coding.net上线；
到2016年3月，GitCafe被Coding.net收购；
世界变化真快，幸好热爱开源的人，的确是越来越多了。
花了一周的时间，看完了《Dreaming in Code》（梦断代码），看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是：外国大牛也不过如此。
别看他们名头那么响，做了那么多超有名的项目，实际的能力（软件开发能力与项目管理能力）看来相当有限。感想很多，想到一点说一点吧。
1．以前有一篇文章叫《谦卑的程序员》，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。但是，那些所谓的大牛，却一点的不知道这一点。一开始他们就决定要做一个桌面软件，然后打算用python+wxWidgets来实现。到后来我才知道，这帮家伙居然一个都不懂python的桌面开发。那个他们伟大的梦想——要打通所有的数据间的隔阂——究竟意味着多少技术难度，他们心里也一点数都没有。总之，这些“大牛”，让人想到的是自我感觉良好的“半瓶醋”。他们的目标太伟大了，这是我在看到这本书的中段的时候的体会。技术要最新潮的，软件要革命性的，要平台化以支持插件的，用户体验要最好的，代码要开源的，唯独工期是不确定的。越是伟大的目标，越是需要强有力的风险控制能力。再引用一遍范总的格言：“欲望不要超过能力”。而他们，就根本没有意识到自己的能力严重不足。
2．一个team中，牛人太多了！如何才能良好的合作呢？他们永远在开会，却始终议而不决，大家都是管过“大团队”的，要他们几个人合作起来Coding，就太难了。
3．还有一个证明他们不是“大牛”的证据是：他们缺乏技术决断力。那几年里流行起来的很多技术，他们都有随波逐流的冲动。比如他们尝试过RDF来描述数据；尝试过Python的ZOPE；憧憬过P2P（但是他们的团队里没有一个懂P2P的）；企图从wxWidgets转到Mozilla的XUL……怎么说呢？这样的摇摆和见异思迁，简直是典型的初哥的作风。真正的大牛，对于技术的趋势，以及如何在项目中运用，心中都自有判断的。
4．据说Chandle 1.0也正式发布了，我去下载了一个，希望能够有惊喜发生……还是奇慢无比，根本就不具备实用价值！
5．如果是我来做这个项目的话，首先就不会在这么多个方面同时冒险。其次，在项目开始之前会先安排一个技术可行性的研究阶段。最重要的一点，我会早点把不称职的“大牛”开走。
随便再说两句：
参加CSDN 2008英雄大会上海站的活动，听了Ivar Jacobson博士的演讲，对他的说法的“不以为然”依然不变。无论是Smart Process还是Smart Software Development，我都还是不以为然。韩磊在介绍Ivar的时候，说博士的演讲价值3000美金，我认为，未必。
与上次介绍Smart Process时提到WayPoint相比，这回的演讲没有再提到“明确的知识”，也没有介绍什么能够帮助开发的软件工具，而是更加强调人的重要性。总算是进步了。
原文写于：2008年09月13日
后记：现在想来，当时的评价的确略苛刻了些，开源项目从来难做，成功的极少而失败的极多。依托Github这样的社交化平台，似乎会比过去容易一些了。
当然，根本的要点依然是：talk is cheap, show me the code。
中学的时候，就看过这么一个故事，法国的文学巨匠莫泊桑，曾经拜福楼拜为师，学习写作，他不断的写作，交到老师那里，都被打了回来：“不行”“不行”。直到有一天，莫泊桑写出了不朽的《羊脂球》，福楼拜才让他去投稿，由此一举成名！
最近这段时间，出来了好多的开源项目，不劣质的，很少！我认为，就该狠狠的打击这种项目。
认为不该打击这些项目的理由，主要有三条：
1．应该多鼓励嘛，毕竟人家勇气可嘉！
批评才能使人进步，鼓励能使人进步吗？
2．只有开源出来大家用，才会发现问题所在呀！
只有你自己已经很难发现问题，才应该开源出来，而不是弄一堆垃圾出来，让人家帮你找错误。那么低级的错误，你都要人家帮你找出来，你是在做贡献呢？还是找人义务帮忙的呀？
3．中国的软件已经够落后了，你还要打击？
好的软件，好的开源项目，自然是中国软件事业的骄傲。反之，就是中国软件的耻辱。像JDonFramework那样的项目，冲到TSS的首页上去丢人，我看也是中国软件的悲哀啊。相比之下，EasyJF这样的项目，不过是冲到BlogJava的首页上去丢人，毕竟没有丢到外国去，还算不是太糟糕。
所以，还是应该不遗余力的打击，只有淘汰掉垃圾，才会显出真正的金子。
原文发布于：2006-08-22
Crmky独立开发Cindy，已经很久了……至今只有他一个人。
这是一个Java的NIO开发框架，我任职的上一家公司，和现在所在的这家公司，都已经使用了这个框架。但是，开发人员始终只有他一个人。
前天他写了一篇Blog：《目标》，对我有很大的触动。我也一直存在这样的疑虑，为什么我们要用Java开发网络应用？或者说，使用java开发的网络应用，难道注定只是一个快速原型，就像当年用VB开发桌面应用？一旦需要面对性能需求时，就得推翻过去的工作，用C/C++重新实现一遍？
现在，目标已经很明确了——“无限接近于C/C++效率的java网络框架”。这是Cindy的终极目标，而我则相当确信，我一定要为这个目标，做出贡献！现在，我已经是Cindy项目的第二名成员了。:)
正好今天看到一篇Leal的blog。我能为开源社区做些什么？
zoomq在woodpecker上写道：
每日至少抽一刻钟解答列表中初学者的问题，
每周至少抽两小时整理新学知识，用Blog/Wiki/mail将体验发表/分享出去,
每周至少抽四个小时来翻译自个儿喜爱的自由软件的文档，
每月至少抽八小时编程，推进自个儿的项目，
每年至少参加一次自由软件的活动，传播自由软件思想，发展一名“自由人”……
只要我们每个人都坚持下去……
10年！就足以改变中国软件的整体风貌！
自接触电脑以来，自由/开源软件也一直给我诸多帮助和乐趣，Linux、Python、Vim凡此种种。当我有些业余时间，有些体会和收获时，又该为自由/开源社区做何回馈呢？
我的思考是：参加一个项目，或者发起一个项目，使用一个项目并且提交反馈，宣传一个项目。不要仅仅是感叹中国开源项目的水平。如果你是一个程序员，那么，你也可以为之做点什么。
原文写于：2006年3月27日，这时候，我还不知道zoomq就是大妈，这也是我第一次写出自己对于开源的看法，现在想来，还是比较稚嫩的呀。
软件开发者是分社群的，大多数时候都是按照语言来划分大的派别，门派不同的人，很少相互交流——“跟那种用XXX的有什么好说的”。越是这门语言足够的自给自足，越是懒得看别的语言的东西。作为一个次新兴语言，Java社群已经足够封闭了。自己内部热闹非凡，新技术、新名词、新战争、新领袖层出不穷，哪里有空去理会Java以外的世界？
可是最近的事情有点奇怪了，Java社群在非常热烈的讨论另外一个语言的项目“Ruby on Rails”！这是什么东西？
CSDN的Java频道出了一篇文章：《最美的MVC,ORM方案原来在别处–Ruby on Rails》！
是不是很令人惊讶？这么长他人志气自己灭自己威风的事情，咱们Java社群的人可是从来没干过的。
我当时也看了这篇文章，第一反应就是无动于衷，我还跟同事讲：“现在年纪大了，早就没有学新语言的冲动了 。 ”
后来呢？偶然的机会我下载了一份PDF，下载地址是：
然后就看起来了。
多好的介绍啊！简单，清晰，准确，有诱惑力！于是我下载了Ruby，One-Click就安装完成了，然后在DOS窗口下输入了一条命令：
gem install rails –remote
就安装了Ruby on Rails。
再输入一条命令：
rails mybook
就建立我的第一个Web应用项目。
再输入一条命令：
ruby mybook\script\server
就启动了WEB Server。在浏览器里，就看到了初始的Welcome页面！
再说两个数字：
一个Web Server需要8行代码。
一个CRUD需要1行代码。
我的浅尝到此为止，但是留下的印象确实无比深刻！
为什么Java社群里那么多开源项目，“成百上千的Framework”，没有一个有这么方便？注意，我只说方便！
方便才是硬道理！这个道理，Java社群里也有人懂的，比如Hibernate的作者Gavin King就说：“10分钟之内把Hibernate跑起来”。Good，但是，一个包含Hibernate的Web应用要跑起来，需要多少时间？
一个流行的架构“WebWork+Spring+Hibernate”，加在一起的一个最简单demo，需要多少时间才能跑起来？等等，还没有选定WebServer呢！
再有，为什么不是iBaits呢？为什么不是Pico呢？为什么不是Velocity呢？为什么不是……
有人也许会说：“ruby社群只是发展得比java晚，所以现在只有这么一个拿得出手的东西，咱们java的好东西太多了，所以选起来累一些。”
但是，问题在于，Java社群里的那么多好东西，怎么就没有一个有RoR那么方便呢？
java社群必须认真反思了！我们究竟在追求什么？
“美感”
“架构”
“灵活性”
“健壮性”
“先进性”
“规范性”
“设计模式”
那么“易学性”和“易用性”呢？难道我们开发新的框架，不是为了减少程序员的劳动吗？
看到人家做出来的东西，总感觉有不足之处，然后呢？
自己另外做一个。然后呢？还有人又做了第三个，第四个。。。。
其实我们不需要那么多“富有创意”的项目，只要有几个能用的，顺手的就好了。如何才能改变Java社群的这种现状呢？
思考中……
原文写于：2005年05月27日
后记：这就是我最早接触Ruby & Rails的记录了。至今未悔……
