标签 开源 下的文章

如果你想要使用指标来追踪你的自由开源软件(FOSS)的社区。现在就面临着一个问题:我应该去追踪哪些指标呢?

要回答这个问题,你必须知道你需要什么信息。比如,你可能想要知道一个项目社区的可持续性。一个社区对问题的应对速度有多快。一个社区怎么吸引、维护或者流失贡献者。一旦你知道需要哪类信息,你就可以找出哪些社区活动可以提供你想要知道的内容。幸运的是,自由开源软件(FOSS)遵从开放式开发模型,在其软件开发仓库里留下了大量的公共数据,我们可以对这些数据进行分析,并从中收集到一些有用的数据。

在这篇文章中,我会介绍一些指标,从而为你的项目社区提供一个多方位的视角分析。

1. 社区活动(Activity)

一个社区的总体活动和这个社区怎样随着时间演变,是度量所有社区好坏的非常有用的指标。社区活动是评价一个社区工作量的第一印象,也可以用来追踪不同种类的活动。比如,提交次数,给人的第一印象就是跟开发工作量挂钩。通过 提出的问题 tickets opened 我们可以大概知道提交了多少 bug 或者又提出了多少新特性。邮件列表中的邮件数量或者论坛帖子的数量可以让我们了解到有过多少次公开讨论。

Activity metrics chart

OpenStack 活动看板上面显示的项目代码提交次数和代码评审之后代码合并次数随时间变化的趋势图(周数据)

2. 社区规模(Size)

社区的规模指的是参与到这个社区的人数,但是,基于不同形式的参与人数也有很大的差别。好消息是,通常你只对积极活跃的贡献者比较感兴趣。活跃的贡献者会在项目的仓库留下一些线索。这意味着你可以通过查看 git 仓库存放的代码中 author字段来统计积极贡献代码的人数,或者通过看积极参与问题解决的人数来统计活跃人数。

所谓活动(某些人做了某些事)可以扩展到很多方面。一种常见的跟踪活动的方式是看有多少人做了工作量相当可观的任务。比如,通常一个项目代码的贡献者是来自这个项目社区的一小部分人。了解了这一小部分人,就对核心的工作组(比如,领导这个社区的人)有一个基本的认识了。

Size metrics chart

Xen 项目开发看板上展示的该项目邮件列表上作者人数和提交人数随时间的变化趋势(每月数据)

3. 社区表现(Performance)

到目前为止,关注点主要集中在活动数量和贡献者数量的统计上了。你也可以分析流程还有用户的表现如何。比如,你可以测量某流程需要多久才能执行完成。解决或者关闭问题的时间可以表明一个需要及时响应的项目对新信息的应对如何,比如修复一个报告过来的 bug 或者实现一个新需求。代码评审花费的时间,即从代码修改提交到被通过的时间,可以看出更新一个提出的改变要达到社区期望的标准需要多久。

其他的一些指标主要与项目处理挂起的工作表现如何有关,比如新的和被关闭问题的比例,或者仍然没有完成的代码评审的队列。这些参数能告诉我们像投入到解决这些问题的资源是否充足这样的一些信息。

Efficiency metrics chart

2015第三季度 OpenStack 开发报告上显示的,每季度关闭与打开状态的问题数之比,接受与放弃的改变提案与最新的改变提案之比

4. 社区人口特征(Demographics)

随着贡献者的参与或者退出,社区也在不断改变。随着人们加入和退出社区,社区成员的会龄(从社区成员加入时算起)也各异。社区会龄统计图表很直观的展现了这些改变随时间的变化。图表是由一系列的水平条组成,每两条水平条代表加入到社区的一代人。对于每一代, 吸引力 Attracted 水平条表示在相应的时间里有多少人加入到了社区。 活跃度 Retained 水平条表示有多少人目前仍然活跃在社区。

代表一代人的两个水平条的关系就是滞留比例:依然在这个项目中的那一代人的一部分。 吸引力 Attracted 水平条的完整集合表示这个项目在过去有多么受欢迎。 活跃度 Retained 水平条的完整集合则表示社区目前的会龄结构。

Demographics metrics chart

Eclipse 开发看板上显示的 Eclipse 社区的社区年龄表。每六个月定义一次

5. 社区多样性(Diversity)

多样性是一个社区保持弹性的很关键的因素。通常来说,一个社区越具有多样性(人或者组织参与的多元化),那么这个社区的弹性也就越大。比如,如果一个公司要决定离开一个自由开源社区,那么这个公司的员工贡献5%要远比贡献85%所可能引起的潜在问题要小很多。

小马因素 Pony Factor ,是 Daniel Gruno 为“最少的开发者贡献了50%的代码提交量”这一现象定义的术语。基于小马因素, 大象因素 Elephant Factor 则是指最少量的公司其员工贡献了50%的代码提交量。这两个数据提供了一种指示,即这个社区依赖多少人或者公司。

Diversity metrics chart

2015开发云数量状态统计显示的在云计算领域的几个自由开源社区项目的小马和大象因素。

还有许多其他的指标来衡量一个社区。在决定收集哪些指标时,可以考虑一下社区的目标,还有哪些指标能帮到你。


via: https://opensource.com/business/15/12/top-5-open-source-community-metrics-track

作者:Jesus M. Gonzalez-Barahona 译者:sonofelice 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

学术界是培养和塑造未来的开源开发者的最佳平台。研究中发现,我们偶尔会开源自己编写的软件。这样做有两个理由,一是为了推广自己编写的工具的使用,二是为了了解人们使用这些工具时会遇到哪些问题。在这样一个编写研究软件的背景下,我的任务就是为 Bradford 大学重新设计二年级的本科软件工程课程。

这是一个挑战,因为我所面对的 80 个学生是来自不同专业的,包括 IT、商务计算和软件工程,这些学生将要在一起上课。最有难度的是,需要和这些编程经验差距很大的学生一起编写代码。按照传统,该课程允许学生选择自己的小组,然后给他们布置构建一个加油站数据库系统的任务,最后提交报告作为评估的一部分。

而我决定重新设计课程,让学生了解现实中的软件团队是如何协作的过程。根据学生的专业和编程技能,我将他们分为五、六个人一组。这是为了确保每个小组的整体水平相当,避免小组之间的不等。

核心课程

课程的形式改为讲座和实践课两项结合在一起。然而实践课作为指导过程,主要是老师监督各个小组的实践进度以及他们如何处理客户和产品之间的关系。而传统的教学方式由项目管理、软件测试、工程需求分析以及类似主题的讲座组成,再辅以实践和导师会议。这些会议可以很好的考核学生的水平以及检测出他们是否可以跟得上我们在讲座部分中的软件工程方法。本年的教学主题包括以下内容:

  • 工程需求分析
  • 如何与客户及其他团队成员互动
  • 程序设计方法,如敏捷和极限编程方法
  • 如何通过学习不同的软件工程方法进行短期的水平提高
  • 小组会议及文档编写
  • 项目管理及项目进展图表(甘特图)
  • UML 图表及系统描述
  • 使用 Git 来进行代码的版本控制
  • 软件测试及 BUG 跟踪
  • 使用开源库
  • 开源代码许可及其选择
  • 软件交付

在这些讲座之后,会有一些来自世界各地的嘉宾为我们说说他们在软件交付过程中的经验。我们也设法请来大学里知识产权律师谈关于软件在英国的知识产权问题,以及如何处理软件的知识产权问题。

协作工具

为了让上述教学内容的顺利进行,我们将会引入一些工具,并训练学生在他们的项目中使用这些工具。如下:

  • Google Drive:团队与导师之间进行共享的工具,暂时存储用于描述项目的文档和图表、需求收集、会议纪要以及项目时间跟踪等信息。采取这样一个方式来监控并提供直接反馈到每个团队,是非常有效的。
  • Basecamp:同样是用于分享文档,在随后的课程中,我们可能会考虑用它取代 Google Drive。
  • BUG 报告工具,如 Mantis:只能让有限的用户免费提交 BUG。稍后我们提到的 Git 可以让小组内的所有人员用做 BUG 提交。
  • 远程视频会议工具:在人员不在校内,甚至去了其他城市的情况下使用。学生们可以定期通过 Skype 来交流并记录会议内容或则进行录音作为今后其他用处。
  • 同时,学生们的项目中还会用到大量的开源工具包。他们可以根据自己小组的项目需求来选择自己使用的工具包和编程语言。唯一的条件是,这些项目必须开源,最后成果可以安装到大学里的实验室,并且大多的研究人员都非常支持这个条件。
  • 最后,所有团队必须向客户交付他们的项目,包括完整的可以工作的软件版本、文档和他们自己选择的开放源码许可。大多数的团队选择了 GPLv3 许可证。

技巧和经验教训

在最后,这一年过的很愉快,并且所有学生的项目都做的非常棒。这里有一些我学到的经验教训,可能有助于提高明年的课程质量:

  1. 提供各种各样有趣的选择项目给学生选择。比如说,游戏开发或者移动应用开发以及完成各种目标的项目等。建立普通的数据库系统已经不能提起学生的兴趣了,而参与到有趣的项目中去,学生本身就是自学者,同时可以帮助解决小组成员和小组之间的常见问题。再通过一个消息列表,学生们发表他们在测试中遇到的任何问题,以寻求其他人的帮助建议。然而,这种方法有一个缺点。外部考官建议我们使用统一种类型的项目和统一的编程语言以帮助缩小对学生的评估标准。
  2. 定期给学生在每一个阶段的表现进行反馈。比方说,可以在和各个小组开指导会议的时候,或者每个阶段进行反馈,以帮助他们在接下来的工作中自我改进。
  3. 学生更加愿意与校外的客户一起协作。他们期待着与外部公司代表或校外人员协作,不过是为了获得新体验而已。与导师进行交流时,他们都能够表现得很专业,这样使得老师非常放心。
  4. 很多团队版将开发单元测试的部分放到项目结束之后,从极限编程方法的角度来说,这是一个严重的禁忌。也许测试应包括在不同阶段的评估中,来提醒他们需要并行开展软件开发和单元测试。
  5. 在这个班的 80 个人里边,仅有 4 个女生,每个女生都分在不同的小组里边。我观察到,男生们总是充分准备好来承担起领队角色,并将最有趣的代码部分留给他们自己来编写,女生则多大遵循安排或者是编写文档。出于某种原因,女生选择不出头,即使在女性辅导员鼓励下,她们也不愿编写代码。这仍然是一个需要解决的主要问题。
  6. 允许不同风格项目文档,比方说,UML 图表、状态图或其他形式的。让学生学习这些并与其他课程融汇贯通来提高他们的学习经验。
  7. 学生里边,有些是很好的开发人员,有些做商务计算的则没有多少编程经验。我们要鼓励团队共同努力,避免开发人员做得比那些只做会议记录或文档的其他成员更好的错误认知。我们常在辅导课程中鼓励角色转换,让每个人都有机会学习如何编程。
  8. 小组与导师每周见面沟通是非常重要的,可以有效监督各个小组进展情况,还可以了解是谁做了大部分工作。通常,没来参加会议的小组成员基本就是没有参与到他们的团队工作中去的,并且通过其他成员所提交的工作报告也可以确定哪些人不活跃。
  9. 我们鼓励学生们把许可证附加到项目中去,使用外部库以及和客户协作的时候要表明确切知识产权问题。 这样可让打破陈规,开拓思维,并了解真实的软件交付问题。
  10. 给学生们自己选择所用技术的空间。
  11. 助教是关键。同时管理 80 个学生显然很有难度,特别是需要对他们进行评估的那几周。明年我一定会找个助教来帮我一起管理各个小组。
  12. 实验室的技术支持是非常重要的。大学里的技术支持人员对于本课程是非常赞同的。他们正在考虑明年将虚拟机分配给每个团队,这样没个团队可以根据需要自行在虚拟机中安装任何软件。
  13. 团队合作,相互帮助。大多数团队自然而然的支持其他团队成员,同时指导员在中间也帮助了不少。
  14. 来自其他同事的帮助会锦上添花。作为一名新的大学导师,我需要从经验中学习,如果我想了解如何管理某些学生和团队,或者对如何让学生适应课程感到困惑时,我会通过多个方面来寻求建议。来自资深同事的支持对我来说是一种极大的鼓励。

最后,对于作为导师的我以及所有的学生来说,这都是个有趣的课程。在学习目标和传统评分方案上还有有一些问题需解决,以减少教师的工作量。明年,我计划会保留这种教学模式,并希望能够提出更好的评分方案以及引入更多的软件来帮助监督项目和控制代码版本。


via: http://opensource.com/education/15/9/teaching-open-source-development-undergraduates

作者:Mariam Kiran 译者:GHLandy 校对:Caroline

本文由 LCTT 原创编译,Linux中国 荣誉推出

在开源和 Linux 方面,2015年的微软有许多惊人的举动!让我们来盘点一下这一年来微软都做了些什么。

这一年对于微软来说是不寻常的一年,不管你喜欢不喜欢微软,都让我们对这个 Windows 的缔造者在开源和 Linux 方面 2016 年的表现拭目以待吧!

大约一年前,微软宣布开源了 .NET 框架的大部分。当时,Scott Hanselman 使用微软 Power BI 对代码库做了一个漂亮的分析。 现在一年过去了,我想要试试对以下问题做个解答:

微软开源了 .NET 框架的大部分之后,社区参与贡献了多少?

我着眼于以下三个项目做了分析,它们是 .NET 生态系统中最主要部分之一,也是 .NET 基金会内 最活跃/收藏/分支的项目之一:

  • Roslyn – .NET 编译器平台,提供了开源的 C# 和 Visual Basic 编译器,以及丰富的代码分析 API。
  • CoreCLR – .NET Core 运行时环境和底层库(mscorlib),它包括垃圾回收、JIT 编译器、基本的 .NET 数据类型和许多底层类。
  • CoreFX – .NET Core 基础库,包括 collections、文件系统、console、XML、异步以及其它方面的类。

数据来自哪里?

GitHub 自身已经内建了很多漂亮的图表了,你可以看看这一年来每月提交数的图表:

Commits Per Month

还可以看看每月动态

github stats - monthly pulse

但是要回答上面的问题,我需要更多的数据。幸运的是, GitHub 提供了非常全面的 API, 再配合上出色的 Octokit.net 库以及 brilliant LINQPad,我就很容易的得到了我所需的全部数据。如果你想要自己试试这些 API ,这儿有个示例的 LINQPad 脚本

然而,仅仅知道它的每月 “ 问题 issue 数量” 或 “接受的PR( 拉取请求 Pull Request )”并没有太大用处,这并不能告诉我们是谁提交了这些问题或 PR。 幸运的是, GitHub 典型的用户是有分类的,比如下图来自 Roslyn 第 670 号问题 ,我们可以看到是哪种类型的用户提交的备注:“ 拥有者 Owner ”、 “ 协作者 Collaborator ” 或者为空——这就是“社区”成员,比如下面的某人(我觉得)并没有在微软工作。

owner collaborator or community

结果呢?

现在我们可以得到我们所需的数据,也就可以生成结果了。

全部问题 - 按提交者分组

项目拥有者协作者社区全部
Roslyn481186715963944
CoreCLR86298487871
CoreFX3349117351980
全部90130762818

这里你可以看到拥有者和协作者在某些情况下占有主导地位,比如,在 Roslyn 项目中 60% 的问题是他们汇报的。但是在另外的例子中社区非常活跃,特别是在 CoreCLR 项目中社区成员汇报的问题超过了拥有者/协作者之和。造成这种情况的部分原因是项目的不同, CoreCLR 是 .NET 框架中最引人注目的部分,因为它包含了 .NET 开发者日常使用的大部分库,所以并不用对社区提交了很多改进建议和错误修复的事情感到惊奇。 另外, CoreCLR 已经出现了较长时间,社区已经使用了一段时间,也能找到它的一些不足的部分。而 Roslyn 则相对较新一些,还没有被太多的使用过,而且找到一个编译器的 bug 显然会更难。

全部已接受的 PR - 按提交者分组

项目拥有者协作者社区全部
Roslyn46520931182676
CoreCLR3785672011146
CoreFX51614094642389
全部13594069783

但是,如果我们来看一下已接受的 PR ,可以看到在这三个项目中社区的贡献量非常低,仅仅只有 12% 左右。不过,这并不令人吃惊,因为 PR 需要达到相当高的水准才能被接受。如果项目采用这种机制,首先你必须找到一个 “需要解决” up for grabs 的问题,然后如果你要改变 API 就必须通过代码审查,最后你必须在代码审查中符合可比性/性能提升/正确性等。所以,实际上 12% 是个相当不错的结果,接受的 PR 解决了不少的问题,特别是考虑到大部分贡献都是社区成员在工作之余完成的。

更新:关于对“需要解决”的要求,参见 David Kean这个评论,以及这条推来了解更多信息。“需要解决”是一个准则,旨在帮助新手,但是并不是必需的,你可以提交一个解决问题的 PR 而不打上这个标签。

最后,如果你看一下每月的数量(参见下面的两张图,点击放大),很难找到特定的趋势,或者说,社区肯定会随着时间的变化或多或少的做出贡献。不过,你也可以说,过去一年来社区一直在做贡献,而且看起来还会继续贡献下去。这不是仅仅出现在项目刚刚开源后的一次性喷发,而是一整年以来的贡献的持续水平。

每月的问题数 - 按提交者分组

Issues Per Month - By Submitter (Owner, Collaborator or Community)

每月接受的 PR - 按提交者分组

Merged Pull Requests Per Month - By Submitter (Owner, Collaborator or Community)

前 20 的问题标签

最后一件我想对我拥有的这些数据所做的事情是找到那些最流行的问题标签,这可以揭示从三个项目开源以来哪种类型的工作不断出现。

Top 20 Issue Labels

以下是关于这些结果的一些看法:

欢迎回到全新的 Six Degrees 专栏。和往常一样,请把你对此文的想法发到意见箱,把对专栏将来建设的建议发送到我的收件箱。

现在我坦诚的讲,这个专栏的走向和预期有些不同。

几周前当我思考要写些什么的时候,我详尽研究了 自由软件基金会 Free Software Foundation 的30周年庆和它在当今计算机世界的相关影响。

为了给这个话题添些料,我想我应当采访一下 John Sullivan,他是自由软件基金会(FSF)的首席执行官。我的计划和想法很典型,写一些叙述性的事实,然后插入采访片段以充实内容。而后,我收到了 John 发给我的一篇极具细节、内容丰富的采访稿,然后我最初的想法被全部抛到九霄云外。我决定把这篇稿子全篇呈现作为主线,再加入一些注释性的评论。所以这篇专栏会看起来很长,但我想它为这本极具观赏里的杂志增添了迷人的色彩。我建议你倒杯茶或者咖啡,然后坐下来细细品味。

时光变幻

自由软件基金会成立于1985年。让我来描绘一下那时的计算机世界,Amiga 1000计算机已经问世,C++ 成为了那时主宰计算机的编程语言,Aldus 的 PageMaker 刚刚发布,计算机网络开始萌芽。同一年,Wham! 的 Careless Whisper 风靡各地。

30年的时间世事大变。回到1985年其时,FSF 重点关注于主要给那些计算机高手们用的自由软件。而现在我们有了软件、服务、社交网络和很多很多。

我首先了解一下 John 认为会影响到现今的软件自由的突出问题的哪些。

“我认为电脑用户的自由所面临的巨大风险已经得到广泛的共识,只是也许说法不同。”

“第一点是我们所谓的‘微型计算机无处不在’。在这一点上自由软件基金会算是成功的,因为完全自由的操作系统可在笔记本电脑、台式电脑和服务器上运行所有商用系统所能运行的一切。也许还有些需要修补,但它们最终可以解决。然后的挑战是我们如何越过上亿美金的市场和与我们针锋相对的法律制度,把这些系统交付于用户手中。”

“然而,一个很严重的问题是那些以体积小为基本特征的计算机设备——即便目前汽车的体积并不算小,但其内置的计算机还是很小的——此类型计算机设备,与手机、平板电脑、智能眼镜、智能手表等都在此讨论之列,这些计算机设备通常都以自由软件为基础,比如说,使用 Linux 内核和一些自由软件,例如安卓或者 GNU,它们的主要作用是运行专有软件和服务支撑,由用户无法控制的远程服务器替代本地计算机完成处理。这些设备服务于关键功能,一些对大众通讯至关重要,还有一些就在我们身边发挥实际作用,另外一些则关系到我们的人身安全,这些软件应该运行在自由软件之上、完全掌控在用户自己手中。而现如今,尚还不是这样。”

John 觉得危险并不仅仅是平台或形式,而是整合它们所运行的后台服务。

“我们面临的第二大威胁是这许多设备所涉及的服务。如果我们日常工作和休闲应用都运行于我们毫无掌控的服务上的话,那么转而使用自由软件则是有益无害。使用自由软件的关键在于,我们可以直接查看、修改和共享代码。这种自由相当于提供了一层保护膜,即便非技术人员也可以防止自己受制于人。而这种自由是 Facebook、Salesforce 或者 Google Docs 的使用者所感受不到的。更让人揪心的事,有种趋势就是人们为了享受到某些服务,似乎适应了安装于本地电脑的专有软件所带来的羁绊。浏览器,包含 Firefox,现如今都会自动安装一个 DRM 插件,从而方便 Netflix 及其他一些视频巨头的运作。我们需要更加努力的开发去中心化的自由软件来替换媒介分发,这样才可以真正的让用户、艺术家、或者用户艺术家有自主权,其他服务也一样。对于 Facebook 我们有 GNU social,pump.io,Diaspora,Movim 和其它的一些,对 Salesforce 我们有 CiviCRM,对 Google Docs 我们有 Etherpad,对于媒体软件我们有 GNU MediaGoblin。但这所有的项目都需要帮助,而且还有许多服务我们尚没有可替换的竞争软件”

有趣的是,John 提到的关于找到如今常见应用软件和服务的替换。FSF 在维护着一个“高优先级项目”列表,设计用来弥补这些缺失。不幸的是这些项目的能力大相径庭,而我们又处于一个社交媒介所主宰的时代,软件只是问题的一部分,而真正的挑战是如何让人们知道并使用它们。这一切都取决于 FSF 如何适应当今的计算机世界。我本人是 FSF 粉丝,我认为他们所做的努力都非常有价值,我也在经济上支持它。他们是一个建立开放计算机环境的重要组织,但所有组织都需要成长、协调、调整,尤其是科技领域的。

我更希望了解关于 FSF 如今的作为与创建之初的不同。

“我们现在的听众相对于30年前有了很大增长,也扩大了受众领域。现在不止是只有黑客,或者程序员和研究人员需要了解自由软件,每一个使用计算机的人都需要,而如今几乎人人都拥有计算机”

John 继续提供了关于这些努力方向的一些例子。

“我们针对自由软件运动的问题在协办一些公众倡议活动,早先,在这些事情上我们都会发表意见,然后酌情采取行动,但在过去的十年我们着意于制定规范和采取一系列活动。我们在一些领域获得了重大成就,比如 Design 的防缺陷数码限制管理(DRM),这当初曾让 iTunes 音乐下架(当然现在 Apple 已经将 DRM 应用于 Apple 音乐)。我们创建了对于自由软件的新用户有吸引力和实用的介绍资料,比如我们的用户解放的动画视频电子邮件自防卫指南

我们还推崇尊重用户自由的硬件。已经得到 FSF 认证的硬件提供商被要求只包含自由软件才可显示其认证。扩大自由软件用户量和自由软件运动分为两部分:获取人们的关心,然后使其行动成为可能。在创始期,我们鼓励生产商和零售商做同样的事情,让已经开始关注自由软件的用户轻松的买其所用,从而避免做决定前所采取的大量调查。我们已经通过认证了一种家庭 Wifi 路由器、3D 打印机、手提电脑和 USB 无线适配器,将来还会有更多。

我们收集了自由软件目录中能找到的所有自由软件,我们还有很长的路要走 —— 如今我们只有 15,500 个软件包,而我们可以预知到关于它们的设计和功能改进将要付出的努力 —— 但是我认为这个资源对于协助用户找到他们需要的自由软件有重大潜力,尤其是那些尚未使用完全 GNU/Linux 系统的用户。面对从网络下载未知程序的潜在危险,我们绝对需要这么一个清单。它还将成为用于用户研究的机器可识别的数据资源。

我们目前为几个特殊的软件项目扮演着经济资助者的角色,为它们募集资金来开发。它们中的大多数是 GNU 的组成部分(我们在持续提供着各种底层支持),但我们还资助着 Replicant,一个最大限度的提供用户自由的完全自由的安卓设计。

我们还帮助开发人员正确的使用自由软件许可证,我们还在持续跟进投诉不遵循 GPL 协议的公司。我们帮助他们纠正问题而后重新部署。RMS 曾是 GPL 的先驱,但如今是我们在继续着这项工作。

FSF 现在所做的一些事情是30年前所没有的,当然从最初的企划到如今有了一些变化 —— 我们的目标是创建一个用户能在任何计算机上使用自由软件完成一切的世界,一个绝无第二人而是用户自己完全掌控其个人电脑的世界。”

个人崇拜

每个人心中都会对 FSF 可能带来的价值存有疑惑,正如 John 所提到的,我们的努力不仅涵盖了自由软件的开发和许可,还有认知、证实和鼓吹一种技术自由文化。

FSF 的老大是无可替代的 Richard M. Stallman,我们都称呼他为 RMS。

RMS 拥有好奇的性格,他对于自己的主意、哲学思考和对软件自由的道德推崇都有不可思议的表现。

他偶尔会在网上自嘲其社交上的拙劣,相对于他演讲中所提之事,比如他蹩脚的旅行行头,或者其他囧事,他对于软件自由的见解则是坚定不移。他作为一个严谨的思考者对于软件自由拥有着超凡的信仰,不仅仅是如何实现自己的构想,还有针对他所领衔的活动的广泛思考。我唯一想批评的就是他偶尔在措辞上展现的诸如多加一个鸡蛋在布丁上的贪婪,但是,考虑到他对于当今世界的重要性,我宁愿多加一个鸡蛋在布丁上,也不想让布丁不足以满足每个人的需要,好吧,关于这个布丁的事情有些小题大做了。

所以说 RMS 是 FSF 的重要部分,但组织重要性则更重要。我们有雇员、董事和其他的捐助者。我很好奇 RMS 在当今的 FSF 扮演了一个什么角色。John 对我分享了他的观点。

“RMS 是 FSF 总裁,但从未自 FSF 拿过一分钱报酬。他拥护自由软件和计算机用户自由,并且满日程持续着每年20多个国家的巡回讲演。他联系社会运动,接受政要和各地区积极团体的接见,他还为 FSF 募集资金,鼓励人们做志愿者。”

“在各种忙碌间歇,他对于软件自由运动中存在的问题做进一步思考,并且直面新的挑战。经常这样的举措都会有新的文章发布,今年初他为 Wired 写了关于自由软件和自由硬件设计的三篇文章,或通过与 FSF 员工交流讨论从而摸索将来项目的发展。”

既然我们讨论到了个人崇拜,我想针对 John 关于软件自由运动的发展宏图略谈一二。

我记得在 开源智囊团 Open Source Think Tank (一个聚集了各个开源组织的执行者的大会)上曾有一个关于在座人员推荐任意项目许可证的用例分析,大多数重要组织都推荐了Apache 软件许可(APL),而非 GNU 公众许可证(GPL)。

这让我记忆犹新,因为我也曾注意到许多公司看起来都选择了 GPL 之外的其他开源许可,我很好奇是否 John 也注意到了这个 与 GPL 相斥的 APL 的发展趋势。

“是这样子吗?我不清楚。几年前我为 FOSDEM 做了一个名为‘ 版权被陷害了吗? Is Copyleft Being Framed? ’的专题,它揭示了一些有据可依的许可证接纳背后的问题,我也将很快为此发表一篇文章,在此列出了一些主要论点:

  • 自由软件的协议许可证的选择并不是空中楼阁。人们选择专有软件许可证也需要考虑各种后果,我发现人们更多是在宽松的许可证(如 APL 或三句版 BSD 许可证)与专有软件许可证之间做权衡,而不是 GPL。
  • 令人感到讽刺的是,统计软件许可证的人通常不会把他们收集数据的软件以自由软件发布,这意味着我们无法研究它所使用的方法或重现其统计数据。一些人现在开始发布其使用的源代码,当然这不应该完全忽视。科学是讲究方法的。
  • 按什么统计许可证?我们真的要将以 APL 发布的一个发出有趣声音的 App 和 GPLv3 下的 GNU Emacs 视同1:1吗?如果不是,我们如何计算同等?我们只计算有功能的软件吗?我们确定没有两倍或三倍计算那些在多宿主服务器上的应用吗?那么不同操作系统之间的移植呢?

每个问题都值得推敲,但每个结论在我看来都距事实很远。我宁愿给程序员做一个调查关于为什么他们在项目中直接选择那些特定的软件许可证,而不是尝试编程去探明程序的许可证的真相,然后把自己的臆想揉入这些数据中。

Copyleft 如它既往一般依旧必不可少,带许可证的软件仍是自由软件,这怎么说都是件好事,但它需要强有力的社会认可不要将其纳入到专有软件。如果自由软件主要的长期影响是让企业能够更有效地开发制约我们的产品的话,那么我们对计算机用户自由的贡献就微乎其微了。”

直面挑战

30年对于大多数组织都不算短,尤其是对于那些有重大目标又横跨各行业、专业、政府和文化的组织。

当我准备结束这次访问时,我希望自己对30岁的 FSF 现如今的发展有一个更好的理解。

“我想 FSF 现在处于一个非常有趣的位置,它同时做为一个坚硬的磐石和一个推动潮流的推动力。”

“我们有核心文档比如 Free Software DefinitionGNU General Public License ,还有我们维护的自由和非自由软件的许可证列表,这是创建我们当今的自由软件世界的顶梁柱。人们非常信任这些文档中陈述的原则,在他们的新产品和将来的实践中正确明智的使用它们。从这个角色来说,我们为用户的成长架设了云梯。就好比 501(c)在法律层面为公益提供了保障,使得85%的资金募集自个人,我们也有如斯的运营架构。”

“但我们还在推进改革,我们接受别人所认为的艰巨的挑战,我认为那说明了我们作为梯子的作用?或者我不应当用这种比喻的说法。”

John可能不善于打比方(我看起来也是),FSF 着实是善于创始大事件,并且实践于任务的推进。而这一使命始于自由软件应该无处不在的信仰。

“我们并不满足于在笔记本上除了极少数组件外全部运行着自由软件,也并不满足于一个平板电脑多数运行着自由软件,而只用专有软件连接网络、加速视频加载,或照相、查询航班、使用Uber...好吧,我们对于这样的发展也是欣慰的,但对于仍要取悦其它软件却并非我们所希望的。因为系统上安装的任何一个专有软件,对于用户都既不公正,也在未来埋下了安全隐患。这些近乎自由的一切是步入自由世界的踏脚石,但这需要我们的脚步永不停歇。”

“在 FSF 早些年,我们事实上一直致力于开发一个完全自由的操作系统。这现在已经被 GNU 和 Linux 和一些合作伙伴实现了,尽管总有新的软件要开发,总有缺陷要被处理。所以当 FSF 仍在某些领域资助自由软件开发时,令人欣喜的是很多其他组织也在做着同样的努力。”

面临的挑战中还有关键的一块,John 提到,就是让正确的人群掌控正确的硬件。

“我们目前专注于我上面提到的第一个问题的推进。对于一些特别应用,我们急需一些硬件来支持自由软件的运行。在 FSF 我们基本尝试了我们能尝试做的一切,我期待一方面对我们进行中的项目提供更多的支持,另一方面通过我们的 尊重你的自由 Respects Your Freedom 认证活动得以对项目进行扩展,从而开发出一些我们自己的项目。同样的问题存在于网络服务问题。我想我们需要把它们综合处理,因为对手机组件的完全掌控很可能会改变服务需求,而服务的分散也将更好的使手机组件化。”

“我希望人们能一直支持 FSF 的工作,尤其是当我们所面临的这些挑战的时候。制造提供可用的、分散而关联的替代网络服务的硬件是昂贵而复杂的。我们需要很多资源和有创造力的人们。但是,这在30年前,我们还只是一个围绕在 RMS 身边和以Copyleft 理念开发整个操作系统的社区。我过去的12年时间留给了 FSF,因为我坚信我们总会直面新的挑战。”

写在最后

在阅读 John 对于我的提问所做出的回答,和认识一些 FSF 的成员时,我有一个深切的感受,这是一个活力十足的社区。这绝非一个无聊的组织,也没有愧对其使命,其激情和承诺一如既往的旺盛。

当然我也不总是赞同 FSF,甚至有时我觉得它所用的方法太过执拗,但我将一如既往的做它死忠粉来支持它的工作。FSF 还代表了相当一部分自由软件和全球开展的开源工作的道德水准。它代表了一种很难舍弃的世界观,我相信它的热情和信条帮助人们从著作权接近了著佐权(双关语,further to the right a little closer to the left too。right/copyright 和 left/copyleft 分别代表左右和著作权/著佐权 )。

当然,RMS 有些古怪,有还有些强硬,一点敏感,但它却是一个包容整合了技术、伦理和文化的运动的坚定的领导者。我们需要一个 RMS ,从某种程度讲就如我们需要 Torvalds、Shuttleworth、Whitehurst 和 Zemlin 一样。这些不同的人将各种远见整合,并将技术灵活分配运用于各种不同个例、道德准则和前景发展。

所以,在完成这次采访的时候,我想借此机会感谢 FSF 所做出的巨大贡献,我希望 FSF 和它的勇往直前的领导者们,Richard M. Stallman 和 John Sullivan,在未来的30年有更长足的发展。加油!

此文章为Jono Bacon的Six Degrees专栏的一部分,此专栏用来分享他关于文化,交流和开源新趋势的想法和见解。

经过了一整天的Opensource.com社区版主年会,最后一项日程提了上来,内容只有“特邀嘉宾:待定”几个字。作为Opensource.com的项目负责人和社区管理员,Jason Hibbets起身解释道,“因为这个嘉宾有可能无法到场,因此我不想提前说是谁。在几个月前我问他何时有空过来,他给了我两个时间点,我选了其中一个。今天是这三周中Jim唯一能来的一天”。(译者注:Jim是指下文中提到的Jim Whitehurst,即红帽公司总裁兼首席执行官)

这句话在版主们(Moderators)中引起一阵轰动,他们从世界各地赶来参加此次的拥抱开源大会(All Things Open Conference)。版主们纷纷往前挪动椅子,仔细聆听。

“他会首先作半个小时的演讲,然后会回答几个提问。”,Jason说道。

会场的门开着,似乎一直在等着这位大人物的出现。这时,会场前唯一一个空位上来了一位高个子。

“大家好!”,这个家伙开口了。他没穿正装,只是衬衫和休闲裤。

这时会场中第二高个子的人,红帽全球意识部门(Global Awareness)的高级主管Jeff Mackanic,告诉他大部分社区版主今天都在场,然后让每个人开始作简单的自我介绍。

“我叫Jen Wike Huger,负责Opensource.com的内容管理,很高兴见到大家。”

“我叫Nicole。是ByWater Solutions的副总裁,我们在做免费的开源库。我到各地旅行并教会人们如何使用软件。”

“我叫Robin,从2013年开始参与版主项目。我在OSDC做了一些事情,工作是在City of the Hague维护网站。”

“我叫Marcus Hanwell,来自英格兰,在Kitware工作。同时,我是FOSS science software的技术总监,和国家实验室在Titan Z和Gpu programming方面合作。我主要使用GentooKDE。最后,我很激动能参与到FOSS和开源科学。”

“我叫Phil Shapiro,是华盛顿的一个小图书馆的28个Linux工作站的管理员。我视各位为我的同事。非常高兴能一起交流分享,贡献力量。我主要关注FOSS和自豪感的关系,以及FOSS如何提升自豪感。”

“我叫Joshua Holm。我大多数时间都在关注系统更新,以及帮助人们在网上找工作。”

“我叫Mel Chernoff,在红帽工作,和Jason HibbetsMark Bohannon一起主要关注政府渠道方面。”

“我叫Scott Nesbitt,写过很多东西,使用FOSS很久了。我是个普通人,不是系统管理员,也不是程序员,只希望能更加高效工作。我帮助人们在商业和生活中使用FOSS。”

“我叫Luis Ibanez,刚加入Google。我对DIY和FOSS感兴趣。”

“我叫Remy DeCausemaker,在RIT MAGIC Center的黑客学院(Resident Hackademic),也是交互式游戏和媒体系的一个兼职教授。现在为Opensource.com写作将近四年。”

“你在新FOSS Minor教书?!”,Jim说道,“很酷!”

“我叫Jason Baker。我是红帽的一个云专家,主要做OpenStack方面的工作。”

“我叫Mark Bohannan,是红帽全球开放协议的一员,在华盛顿外工作。和Mel一样,我花了相当多时间写作,也从法律和政府部门中找合作者。我做了一个很好的小册子来讨论正在发生在政府中的积极变化。”

“我叫Jason Hibbets,我组织了这次讨论。”

会场中一片笑声。

“我也组织了这个讨论,可以这么说,”这个棕红色头发笑容灿烂的家伙说道。笑声持续一会逐渐平息。

我当时在他左边,时不时从记录的间隙中抬头看一眼,我注意到淡淡微笑背后的那个令人瞩目的人,是自2008年1月起开始领导红帽公司的CEO Jim Whitehurst

“我有世界上最好的工作,”稍稍向后靠、叉腿抱头,Whitehurst开始了演讲。“我开始领导红帽,在世界各地旅行到处看看情况。在这里的七年中,FOSS和广泛的开源创新所发生的最美好的事情是开源已经脱离了条条框框。我现在认为,信息技术正处在FOSS之前所在的位置。我们可以预见FOSS从一个替代品走向创新驱动力。我们的用户也看到了这一点。他们用FOSS并不是因为它便宜,而是因为它能带来可控和创新的解决方案。这也是个全球现象。比如,我刚才还在印度,然后发现那里的用户拥抱开源的两个理由:一个是创新,另一个是那里的市场有些特殊,需要完全的可控。”

孟买证券交易所想得到源代码并加以控制,五年前这种事情在证券交易领域就没有听说过。那时FOSS正在重复发明轮子。今天看来,实际上大数据的每件事情都出现在FOSS领域。几乎所有的新框架,语言和方法论,包括移动通讯(尽管不包括设备),都首先发生在开源世界。”

“这是因为用户数量已经达到了相当的规模。这不只是红帽遇到的情况,GoogleAmazonFacebook等也出现这样的情况。他们想解决自己的问题,用开源的方式。忘掉许可协议吧,开源绝不仅如此。我们建立了一个交通工具,一套规则,例如HadoopCassandra和其他工具。事实上,开源驱动创新。例如,Hadoop是在厂商们意识到规模带来的问题时的一个解决方案。他们实际上有足够的资金和资源来解决自己的问题。开源是许多领域的默认技术方案。这在一个更加注重内容的世界中更是如此,例如3D打印和其他使用信息内容的实体产品。”

“源代码的开源确实很酷,但开源不应当仅限于此。在各行各业不同领域开源仍有可以用武之地。我们要问下自己:‘开源能够为教育,政府,法律带来什么?其它的呢?其它的领域如何能学习我们?’”

“还有内容的问题。内容在现在是免费的,当然我们可以投资更多的免费内容,不过我们也需要商业模式围绕的内容。这是我们更应该关注的。如果你相信开放的创新更好,那么我们需要更多的商业模式。”

“教育让我担心,其相比与‘社区’它更关注‘内容’。例如,无论我走到哪里,大学的校长们都会说,‘等等,难道教育将会免费?!’对于下游来说FOSS免费很棒,但别忘了上游很强大。免费课程很棒,但我们同样需要社区来不断迭代和完善。这是很多人都在做的事情,Opensource.com是一个提供交流的社区。问题不是‘我们如何控制内容’,也不是‘如何建立和分发内容’,而是要确保它处在不断的完善当中,而且能给其他领域提供有价值的参考。”

“改变世界的潜力是无穷无尽的,我们已经取得了很棒的进步。”六年前我们痴迷于制定宣言,我们说‘我们是领导者’。我们用错词了,因为那潜在意味着控制。积极的参与者们同样也不能很好理解……Máirín Duffy提出了催化剂这个词。然后我们组成了红帽,不断地促进行动,指引方向。”

“Opensource.com也是其他领域的催化剂,而这正是它的本义所在,我希望你们也这样认为。当时的内容质量和现在比起来都令人难以置信。你可以看到每季度它都在进步。谢谢你们付出的时间!谢谢成为了催化剂!这是一个让世界变得更好的机会。我想听听你们的看法。”

我瞥了一下桌子,发现几个人眼中带泪。

然后Whitehurst又回顾了大会的开放教育议题。“极端一点看,如果你有一门Ulysses的公开课。在这里你能和一群人一起合作体验课堂。这样就和代码块一样的:大家一起努力,代码随着时间不断改进。”

在这一点上,我有发言权。当谈论其FOSS和学术团体之间的差异,像“基础”和“可能不调和”这些词语都跳了出来。

Remy: “倒退带来死亡。如果你在论文或者发布的代码中犯了一个错误,有可能带来十分严重的后果。学校一直都是避免失败寻求正确答案的地方。复制意味着抄袭。轮子在一遍遍地教条地被发明。FOSS让你能快速失败,但在学术界,你只能带来无效的结果。”

Nicole: “学术界有太多自我的家伙,你们需要一个发布经理。”

Marcus: “为了合作,你必须展示自己不懂的地方,这些发生在幕后。奖励模型是所有你信任的东西,我们需要改变它。尽可能多地发表,我们最后会发布,但希望能尽早地释放努力。”

Luis: “团队和分享应该优先考虑,红帽可以多向它们强调这一点。”

Jim: “还有公司在其中扮演积极角色了吗?”

Phil Shapiro: “我对FOSS的临界点感兴趣。Fed没有改用LibreOffice把我逼疯了。我们没有在软件上花税款,也不应当在字处理软件或者微软的Office上浪费税钱。”

Jim: “我们经常提倡这一点。我们能做更多吗?这是个问题。首先,我们在我们的产品涉足的地方取得了进步。我们在政府中有坚实的专营权。我们比私有公司平均花费更多。银行和电信业都和政府挨着。我们在欧洲做的更好,我认为在那工作有更低的税。下一代计算就像‘终结者’,我们到处取得了进步,但仍然需要忧患意识。”

突然,门开了。Jim转身向门口站着的执行助理点头。他要去参加下一场会了。他并拢双腿,站着向前微倾。然后,他再次向每个人的工作和奉献表示感谢,微笑着出了门……留给我们更多的激励。


via: https://opensource.com/business/14/12/jim-whitehurst-inspiration-open-source

作者:Remy 译者:fyh 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出