微软因为以前对开源软件的态度而臭名昭著，但是公司改建后对开源软件发出了积极的信号。CNet报道了微软对开源软件认知的行为的改变。
CNet消息： 虽然微软资助开源软件有一些时间了，并且那些曾经反对开源软件的领导者们已经退出了或者不在位了。开源软件现在用在遍布全世界的公司当中，但这些与微软帝国无关。 一些新的想法反映了企业顶层的一些变化，今年二月初Satya Nadella代替鲍尔默成为了微软CEO，Nadella已经给微软带来了一些新的东西改变了微软以前的一些束缚。
我是一个持悲观态度的人，但是我认为微软和开源软件之间的信任关系是有待确定的。一个新的CEO和些许改变或许会改变微软在开源世界中的存在状态，但是对于微软这么大的企业来说改变并不容易，所以对于开源的世界来说微软是否真的改变还有待确定。
我也从来不会忘记微软用“欢迎，扩大，压死”的策略来打翻其他的竞争软件，光这一条凡是微软参合的开源项目就必须瞪大眼睛，或许这家公司真的改了，但如果没有呢！我们还是用几年时间来观察下吧。
译者：jiajia9linuxer 校对：wxy
“开源之神圣独裁者”越来越少了，不过没事！
Roy Rubin这位流行的电子商务开源项目Magento的联合创始人，从这一2008年启动的项目中功成身退后在这周说出了上面这样的话语。
这已经不是第一次一个开源项目的领导者出走项目了，但值得注意的是对于它带来的反响是：没啥大的反应。
并不是因为Rubin对于Magento项目不重要，实际上他非常重要。六年来，Rubin实际上是Magento项目的灵魂。但是开源软件一直在成长，它一直在削弱个人对其的影响。当然没人希望Linux的创始人Linus Torvalds不小心被车撞了，在这点上我们是爱他的。但是另外一方面其实我们并不太在意。
但是并不总是这样的。
在好的一面，成功的开源项目一直以来都和伟大的领导者密不可分。对一个充满活力又有独立思想的一个开发团体施加影响，必定是众口难调的事情。在一个专门的开源项目当中不同的观点会产生各种不同的路线（在代码层上，管它叫做“分支”），通常这时候，要么是“开源之神圣独裁者”，要么是项目领袖，将会介入，施展自己的领导才能让开发人员团结在一起。
“开源之神圣独裁者 BDFL”这个词可能第一个用于Python项目的领导者Guido von Rossum。它现在也被用到了Linux的发明人Linus Torvalds身上，以及Ubuntu的领导者Mark Shuttleworth和其他人身上。有时候另外两个人也会冠以这个称号，比如Django项目的Adrian Holovaty和Kaplan-Moss。（LCTT译注：BDFL，benevolent dictator for life ，由LCTT 核心译者 Viz 建议译作“开源之神圣独裁者”。）
在他们影响力最大的时候，这些领袖离开项目会对项目的将来产生灾难性的影响，这展现出这些伟大领导者与项目之间紧密的关联。但是，有时候，也不总是这样。Django的领导者去了其他的项目，但是Django依然不断前行着，像Python、Lucene（领导者Doug Cutting）、Jboss（领导者Marc Fleury）和其他很多的项目也是这样。
现在开源软件研发的团体依然围绕着伟大的领导者，但我们似乎并不像曾经的那样依赖他们了。开源软件的“个人崇拜”正在褪色，也有可能已经消亡了，但是接下来会怎么样呢？
是的，社区开始崛起了。我意识到我在做出一些自以为是的论调，但是根据我在开源项目15年的经验来说，我观察到开源软件项目从非常严格的控制阶段缓慢的转向了松散的开源团体，他们经常是因为兴趣才互相合作的。
当然并不清楚是先有 BSD/Apache之类的许可证的“鸡”还是后有开源软件相互合作的“蛋”，这两个很明显的一起改变了开源软件的运作模式。
当然还是需要“开源之神圣独裁者”。举个例子，当自由GNU还不是一个项目时，很难想象如果没有了Richard Stallman会是怎么样。相反的，很容易想象Apache Hadoop如果没有领导会怎么样…，等等，好像Hadoop真的没有人领导…
如果真的要说答案的话，那就是这里每个人或者许多人。当然Hadoop由Doug Cutting启动，但是它已经发展成了一个公司和个人（不过大多数的公司雇佣了这些人）的协作的社区。
OpenStack与之类似，被涉及的公司所主导，如果某一个Openstack的开发者离开了，Openstack依然能够继续。因此，对于一个成员正在增加的开源项目来说，这种类似是确信无疑的。
并不是说在以后的开源项目中不需要领导者。需要，但是越来越多的开源项目转为团体之间的合作，失去他们的风险消失了。坦白的说，即使公司们没有深入的参入进来，Apache许可证的项目反正也不依赖“开源之神圣独裁者”们。
Photo of Richard Stallman courtesy of Friprog on Flickr
via: http://readwrite.com/2014/05/02/open-source-magento-roy-rubin-bdfl#feed=/hack&awesm=~oDgSTEdnXAjUv0
译者：jiajia9linuxer 校对：wxy
如果你的公司依赖像OpenSSL这样的开源软件，是时候主动点了。
心脏流血漏洞让开源社区如芒在背。
ComputerWorld的Richi Jennings 抨击说“又一个非常可怕的开源失败。”（他是要做标题党么？）ZDNet的Steven J. Vaughan-Nichols不像是作秀反开源，却仍旧将心脏流血漏洞渲染为“开源软件的最遭时刻”。而最后，ZDNet的Chris Duckett则务实地倡议：“商业公司（应该）筹集资金来避免心脏流血再次发生。”
而实际上，企业资金并不是解决心脏流血事件的最终答案 。你才是！
想要避免开源失败的公司应该不仅仅是开源软件的用户，还要是贡献者。
贡献者能够引导特定的项目。他们占据主动，而不是被动接受。大多数企业缺乏资源参与他们所使用的所有开源项目，但每家公司都可以资助给那些真正关系到他们的项目。并且资助得越多，得到的好处越大。
开源就是一个不断给予的礼物，尤其是给予那些对开源反哺的人们。
我在MongoDB的同事Adam Comerford让这点更有说服力：如果你看看第一批得知Heartbleed漏洞的时间线，那些第一批得知的（如谷歌）有一个相当大的优势。如Comford所说的，这些公司有一个显著的优势就是他们可以在bug还未大规模传开的时候率先采取措施保护他们的系统。
鉴于早期了解像Heartbleed之类问题的优势，Comerford问：“我如何确保我在这类问题的早期通知列表里面？”
如果你依赖于专有软件，你有一个答案：向卖方支付大量的金钱，并希望他适时地响应。但是，如果你正在使用开源软件，有一个更多选择： “要么有大量的员工给[开源项目]做贡献 ，或者...有认识主要贡献者的员工（我们可以找找，他们大多也会贡献其他开源软件项目，像其他的极客和呆瓜一样。“
Comerford断言说，好处不止这样：
这有很多好处 - 除了让问题及早通知，让手头上的专家来应付这些棘手的更新，以评估你的风险，甚至可能在公众知道之前内部解决问题。在确定项目的方向上你还可以得到重视的回馈，可以影响到关键特性的优先级。最终，你会得到社区的善意，使产品变得更好，并有可能成为其它的聪明贡献者的工作目标。
换句话说，参与进来。成员有特权，主要的特权可能就是信息。
同样，没有一家公司有足够的资源来有效地促进所有它所使用的项目，这就是为什么Comerford建议对关键项目上这么做的原因：
如果你要人们列出在企业中所有开源关键技术，你可能会得到一张很长的名单。然后，告诉他们，他们将必须清点人工和预算来支持清单上的每一种技术的话（并验证它） - 它可能会迅速缩水。
如果你是一个AMD那样的芯片公司，给Linux内核贡献基本驱动程序和其他代码很可能是强制性的。给LibreOffice贡献可能不是。或者，如果你判断你的未来在Hadoop上进行深层数据分析，你应该贡献Hadoop，即使你依旧免费使用OpenSSL社区的成果。比如Dish Networks公司，它的 CIO告诉上周在开放商业会上的人们，他们正在将重要的数据从关系型数据库转到Apache的Kafka，那他最好研究Kafka的代码，即使他不贡献给Apache HTTP服务器项目。
每家公司都有其优先级，以及这些优先级应该以严肃的承诺而确立。
这是确保这些项目安全的一部分办法。而另一部分，它是一种形成影响力指引的方式。但同时，红帽公司CEOJim Whitehurst早在2008年声明，它是显著减少IT花费的办法：
今天编写的绝大多数软件是企业编写的，不得转售。并且绝大多数是从来没有真正使用过。IT软件开发中的浪费是巨大的....最终，开源给全世界的客户提供价值，我们不仅需要让我们的客户作为开源产品的用户，而且真正加入开源和参与在开发社区。
Comerford坚持认为：“如果我在业务中使用开源软件，我应该雇开发人员来积极给软件做贡献，如果他们自己不是核心开发者，那就雇佣核心开发者。 ”这是充分利用开源软件的关键：给它做贡献，不只是使用它。
via: http://readwrite.com/2014/05/14/heartbleed-open-source-contribution-users
今天，我们兴奋地宣布：在MIT开源许可证下，Atom开源了！我们看到，GitHub努力以构建更好的软件为首要任务，而Atom对此是一个完美的补充。Atom是个长期的投入，GitHub将继续由专门的团队支持其发展。但是我们也知道，我们对Atom的愿景不可能独自实现。在过去的30年里Emacs和Vim已经证明，如果你想建立一个活跃的持续的文本编辑器社区，必须开源！
Atom的许多功能是通过包来提供的，从我们发布beta版开始所有Atom包就已经开源。今天，我们会开源Atom的剩余部分，包括核心应用程序、Atom包管理器，以及基于Chromium的桌面应用程序框架和Atom Shell。
Atom核心包含了包以外的应用程序部分。包括构建系统、Atom国际化环境、工作区和窗口，以及文本编辑组件。随着时间的推移，我们从Atom中把一些功能提取出来放入库中以便能独立使用，我们期望这个过程能一直持续下去。
Atom包管理器，apm, 是个客户端库和命令行多功能程序，用来帮助发布和安装Atom包。 apm目前是由atom.io提供支持，但是我们计划将后端API标准化，如此你就能管理自己的注册簿（registy）了。
最后，同Atom一样，我们真的很兴奋Atom Shell也能够开源。超过2.5年的开发，Atom像个寄居蟹一样，它首先在Cocoa WebView中开始生命，然后移居到Chromium嵌入式框架, 最终安家在Atom Shell中。我们短暂尝试了使用Node-Webkit，但是我们决定采用@zcbenz构建的框架。
我们采取在整洁、可维护的环境中整合Chromium和Node，包括在Node中发起增加multi-context支持。我们也建立了brightray和libchromiumcontent，使其更易嵌入Chromium到本地应用程序作为共享库。
在准备发布Atom 1.0版本之前仍然有大量的工作要做。在接下来几个月，我们将集中改善性能，在Linux和Windows上发放测试，以及使API趋于稳定。我们认为开源会帮助我们更快达到目标，更重要的是，源代码将给你透明度和控制权，你能从你的工具中告诉我们你想要的。
在迄今为止的Atom beta版本中我们感谢每个参与进来的开发者。你的反馈，包和推送请求（PR）是无价的。如果我们不是打算做个能够陪伴一生的编辑器的话，我们是不会创造它的，我们很高兴把这关键的一步变为现实！
via: http://blog.atom.io/2014/05/06/atom-is-now-open-source.html
新一项调查显示，曾经作为开发者癖好的开源文化如今正在蔓延
十年前，开源是一项开发者运动，今天已远非如此。
Linux 基金会的一项新调查显示，“企业管理者认识到，企业不仅迫切需要开源软件，而且也率先参与开源软件的研发。”这一点反过来也巩固了开源软件作为企业关键驱动力的地位，而不仅仅是一种高效的代码编写方式。
作为昔日自主创新的模仿者，开源软件早在若干年前就确立了行业创新的计划。计算机行业最主流的趋势——从云计算到大数据，再到移动互联网——都是由开源软件推动的。这一点企业用户已经注意到了。
过去，仅仅是开发者习惯于借助开源软件的力量，把自己从繁重的企业需求开发中解放出来。而现在，企业管理者也更多地在公开求助于开源软件。
通过对 686 名软件开发人员与企业管理人员的调查，我们发现，与开发者不同，企业开始使用开源软件是出于不得已。
从 Linux 基金会的调查可以发现另一些有趣的事实，每一点都表明将来开源会对企业有更大的影响力，企业也会更多参与开源。
这一调查结果的潜台词很明显：开源软件开发更多是受到商业需求的驱使。事实上，44% 的企业管理者表明他们会在未来六个月内增加对软件协同开发的投资，另42%的企业管理者也说他们计划维持目前的投资数额。没有受访者表明他们打算削减投资。
人们对开放协同开发抱有令人兴奋的乐观主义信念。这种信念的能量，一部分源自于 Hadoop 和 Android 这样的特殊项目，更多的源自于业界同行甚至竞争对手之间协同开发解决艰难技术问题的过程。OpenStack、OpenDaylight、Eclipse 和 Linux 都是业界合作的项目。对于像 IBM 这样的公司，合作基金会在开发中已经成为了新的默认组织。
但协同软件开发背后的目的可不是围着营火手牵着手唱“kumbaya”。各种组织对协同软件开发的期待都是出于驱动有形商业利益的目的。
这不该是个令人震惊的消息。随着自由开源软件运动的成熟，约束较少的协议方式 Apache 许可协议比 GNU 通用许可协议（GPL）更受到了青睐，运动本身的理念也走下神坛被越来越多地接受和采纳。巨大变革已经产生，Github 一代常常回避各种正式许可协议这一点已经成为事实（不过反过来也为自己带来了商业上的麻烦）。
在各行各业里，组织都迫于压力降低成本提高产出，交付软件产品的时限也远比以往严格。作为其中之一的 Google 曾说，没有开源和开放标准，就没有今天的 Google。其他组织也逐渐意识到了这一点。
GitHub 的新文本编辑器并不完全开源，看起来并没有人在意这一点。
Samuel Greenwald 认为“任何 IT 领袖如果没有开源观念，那注定会失败。” 然而即使你的开源观念打了折扣、不那么纯粹，其实大众也并不会刁难你。特别是在你祭出古怪反复的许可证花招时，即使是开源界最精明的精英也可能被忽悠住。
例如就拿GitHub来说。GitHub 刚刚发布了Atom文本编辑器，获得了很多赞赏。虽然有些人赞美Atom“完全开源”，但其实它并非如此。在我看来，还差得很远。
不管怎样，并不是说 GitHub 把Atom 全部伪装成开源。正如 GitHub 联合创始人Tom Preston-Werner所说，只有“Atom 核心”代码将会是闭源的，而“其余现有的所有Atom 代码将永远遵守 MIT-licensed许可证。”原因纯粹是商业化的，他这么解释道：
Atom将不会封闭源代码，但它也不会开源。它将介于两者之间，这样我们更易于对 Atom 进行掌控，同时，人们还可以在许可证的限制下看到它如何运行。关于这一点，我们还没有最终决定究竟如何具体实施。我们将在充分的细节准备后正式启动。
早在开源的初期，我们就有了这个概念。事实上，微软也是这么做的。微软称之为“共享源代码”， 于2002年推出，共享源代码是微软为其社区提供的一种方式，用来监测，但不触及（或重新分配）微软的源代码。SAP 的大数据主管 Vijay Vijayasankar 提醒我们，对微软来说这个方法没有这么好，但对GitHub 可能会做的更好：
@dberkholz 我记得OSI人士严重批评了微软，说这是微软的一个营销噱头。但这次 GitHub 会做得更好 — Vijay Vijayasankar (@vijayasankarv) 2014年2月27日
他也许是对的。
毕竟，微软是邪恶帝国，一直将开源抹黑为“毒瘤”之类的东西。而 GitHub，无论在哪儿，都是开源项目的养父母。 2013年 GitHub突破千万代码库，增添300万新用户，每周狂热的活跃量包括：20,000个问题，50,000个评论，250,000个来自世界各地贡献者的提交，保证了代码库进展。
换句话说，GitHub是零起点的开源项目。
也许正因为如此，GitHub 得到了一个免费通行证。在HackerNews评论上，少数人似乎过于在意，他们认为 GitHub 没有真正开源 Atom。作为一个社区，开源已经在很大程度上战胜了免费软件：少教条，更实用。我们已经身处这样一个节点，许多所谓的“GitHub一代”甚至懒得去费心将许可证分配给他们的软件。
这是好事吗？
很难说，甚至很难与 GitHub 的做法争辩，它带给世界一个高品质、低成本的文本编辑器，似乎并没有伤害任何人，潜在里还可能帮助许多人。开源社区是自由意志论者：并不愿意去制定许可证，它更关心的是良好的代码和产品。
这就是为什么 GitHub、Atlassian 和 Amazon 的 Web 服务都依赖于专有软件或服务来赚钱，同时却如此惊人地受到开源开发者的欢迎。
你了解了吗？
via: http://readwrite.com/2014/02/28/github-atom-text-editor#feed=/hack&awesm=~oxpErHVIIaxz3H
