前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >围绕开源的系列思考——国家篇

围绕开源的系列思考——国家篇

作者头像
开源社
发布2020-01-16 15:05:15
4540
发布2020-01-16 15:05:15
举报
文章被收录于专栏:开源社开源社

| 作者: 庄表伟

| 编辑:陈梅梅

| 责编:Corrie

从穿越小说聊起

我非常喜欢看各种网络小说,其中最大的一类,自然是穿越小说。其中又可以细分为很多类型。按照穿越回到的时代,从远古到近现代的都有,这其中有一个很小的分类,是回到大约20世纪70年代末、80年代初的。那些主人公,大概率都是要搭上改革开放的顺风车,赚取巨额红利的了。比如抢先去上海,购买股票认购证之类。

不过,有一本我个人非常喜欢的穿越改革工业文《大国重工》,非常硬核,主人公冯啸辰没去赚那种投机取巧的暴利,却一心一意的想要帮助咱们国家的工业,尤其是重大装备制造业,获得更好的发展。

事实上,所有穿越回到过去的人物,手头最大的两个武器,无非是超越于时代的知识技能,以及对于历史发展方向(甚至某些历史大事的关键线索)的把握。

于是我常常会想:作为一个软件工程师,我非常了解软件开发、软件工程、开源软件等等相关知识和技术。如果我穿越回到 IBM PC 刚刚发明的1981年,或者是穿越到GPL 首次发布的1989年,再或者是穿越到 Linus 刚刚开始写 Linux 的1991年,我可以(能够、应该)做些什么呢?如果我不仅希望自己个人发财,还希望咱们国家的软件产业更好的发展,还希望咱们国家的开源能够有更好的发展,我又可以(能够、应该)做些什么呢?

追赶曲线与距离的关系

说实话,在各类穿越小说中,越是靠近现代的穿越,就越是难写。重生到30年的改革穿,自然是最难的。个人 YY 式奋斗的模式还好写一些,妄图用现代思维,改造历史,推动历史发展进程的小说,就更加难写。

具体到改革开放这40年,为什么更加难写呢?因为,在这40年里,中国的发展思路已经很难更加正确了。积极学习西方发展的先进经验,积极引进西方先进的科学与技术,努力在认清现实,理解差距的前提下,奋力追赶。

为啥西方可能走弯路,而我们却能够走直线呢?因为西方领先了我们100~200年,他们走过的弯路,我们不必再走。

问题在于,有不少新兴产业,比如软件产业,西方也不过是出现了60年(1959年正式提出),软件工程至今不过51年(1968年提出),个人计算机以及相关软件产业的爆发式增长,至今不到40年,开源软件的概念(1998年提出),至今不过21年。

追赶成熟产业,我们可以不走弯路。而追赶新兴产业,我们多半就会跟在后面走弯路,要想追上去,何其困难?

经验曲线与人月神话

软件产业作为一个新兴产业,与传统产业,尤其是制造业,有哪些区别呢?最近我在读的另一本书《战略简史》,其中提到了“波士顿经验曲线”,给了我深刻的启发。

1960年,波士顿咨询公司(Boston Consulting Group)的布鲁斯·亨得森(Bruce D. Henderson)首先提出了经验曲线效应(Experience Curve Effect)。简单的描述是:当生产的累积数量增加后,相对应的平均成本下降。一般而言,形成经验曲线的原因有三项,分别是:

学习效果:由于重复工作所带来的学习效果。

科技进步:从事一项工作一段时间后,较容易进行生产制程改善。

产品改善:生产产品一段时间后可以清楚了解顾客偏好,经过设计改善,可以在不影响功能下,使零件减少。

这个经验曲线,能不能应用于软件产业呢?一家软件公司,开发第一个软件,到开发第10个软件,他的生产成本,是不是能够逐渐下降呢?

作为业内人士,我们经常听到的却是这种说法:

“大多数大型软件项目都没有达到预期的目标,交付推迟,预算超支,功能不完善。许多软件项目彻底失败了。”

— —FDD

“当前,软件开发的情况并不理想。很多系统最终不能交付,或者最终交付的系统经常性地发生延期或者超出预算;系统常常不能满足用户的需要,其结果是不得不一遍又一遍地开发。”

— —AM

“许多软件项目,或许应该说大部分软件项目实际的开发周期比预期的要长,实际的花费比预期的要多,实现的功能比预期的要少。这造成了严重的质量问题。 — —某一本 CMM 的书籍

在1974年出版的《人月神话》这本书里,我们可以看到这种论断,甚至在40年之后出版的纪念版本中,这些论断依然正确!

没有银弹”:没有任何技术或管理上的进展, 能够独立地许诺十年内使生产率、 可靠性或简洁性获得数量级上的进步。

不要相信人月神话”:当你向一个复杂的项目投入更多的人力时,反而会进一步延长工期!

如果不能正确认识软件这个行业的本质,我们将永远陷在“焦油坑”之中,就别再奢望什么成本逐步下降的经验曲线了。

《大教堂与集市》的观点

回顾行业的发展,似乎情况并没有那么糟糕。我们的确在开发越来越复杂的软件,我们的开发效率也越来越高了。

在《大教堂与集市》这本开源圣经中,作者 Eric S·Raymond 更是自豪的宣称:有一种与传统软件开发模式(大教堂模式)截然不同的全新的模式:集市模式。如果开发的协调者有一个至少和互联网一样好的通讯媒介,而且懂得如何不通过强迫来领导,多个头脑不可避免地优于单个头脑。

这一论断,与人月神话的观点,看起来正好相反啊!怎么解释呢?社区开发固然可以选择集市模式,企业开发,也可以选择集市模式吗?好的通讯模式容易实现,不通过强迫来领导,在一个企业里,现实吗?

2000年,Tim O'Reilly 就发明了一个新的词汇:Inner Source。按照 Wikipedia的说法:InnerSource is the use of open source software development best practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software, but internally opens up its development.

将开源的开发模式应用于企业内部,并且在企业内部营造类似于开源社区的文化。这样会带来众多的益处,这就是:内源。

参考:

https://en.wikipedia.org/wiki/Inner_source

开源对于软件产业的贡献

必须承认,真正在企业内部践行内源的企业,还是非常罕见的。不过,开源对于软件产业,也不仅仅是在开发模式方面,更加重要的贡献,还是得回到经验曲线来谈。

在此,我想提出一个假说:在一个行业的早期发展阶段,是很难有稳定的经验曲线的,原因在于这个行业还非常的不成熟,没有摸索出一套行之有效的,积累经验,持续改进的方法。即使到了今天,我们依然可以认为,软件开发这个行业,虽然已经有了很多激动人心的重大进展,但是却还没有成为一个成熟的,能够稳定发展的行业。在这40~50年的时间里,软件开发使用各种隐喻来套用在自己的工作实践中:比如建筑工程,比如手术团队,比如流水线,比如工匠作坊。

所有这些隐喻,都可以算作是盲人摸象的心得,用来指导软件开发的实践改进,往往只是缘木求鱼。到了今天我们回看过去的进展,也许只有3个方向的改进,是切实有效的:

  • 敏捷迭代式的开发(本质上就是小步试错,以降低试错成本,快速逼近正确答案)
  • 可复用的源代码(本质上就是减少重复劳动,不必每个项目都重头开始写代码)
  • 有工具支撑的 DevOps(本质上就是在软件开发的每一个环节,都不断改进工具,提高效率)

在这三个方向之后,第二、第三条事实上都是靠开源支撑起来的。开源项目,开源框架,开源组件,开源模板,开源的项目管理工具,开源的开发工具,开源的测试工具,开源的运维工具,甚至夸张一点说,现在软件行业的众多基石,几乎全都是开源的。

这正是软件行业,积累经验的方式。开源代码与开源工具,凝聚了软件开发、系统架构,项目管理等诸多经验,使得企业不用付出高昂代价,不用自行摸索,不用从零开始。

现在,我们已经很难想象一家公司,完全不采用任何开源的技术,不引入任何的开源代码,完全靠自己公司的员工,一行一行的写出自己的软件来了。

开源极大的提升了软件产业的生产效率,极大的降低了软件产业的生产成本。所以人们才会断言:软件正在吞噬世界,而开源正在吞噬软件。

开源为何能够走到今天?

如果用这个问题,去问美国政府:你们是如何发展美国的开源产业的?估计他们会一脸懵。或者更加困难的是:我们都不知道该去问美国政府的哪个部门。咱们还是只能回顾历史,去看看当年究竟发生了哪些重要的事件,以及这些事件的前因后果。

目前最方便找到的线索,还是英文的 Wikipedia :https://en.wikipedia.org/wiki/History_of_free_and_open-source_software

1.在开源出现之前,美国商人之间,就已经有了分享技术的做法(1911年起)

1911年,亨利·福特发起成立了一个新的协会,后演变为汽车制造商协会。该协会使得美国所有汽车制造商之间的专利,得以免费公开共享,到二战前,这些制造商之间共享了92项福特专利和其他公司的515项专利。

简评:通过分享技术,建立的商业联盟

2.在学术界,长期存在开放与合作的文化,后来这些文化被进一步发展为:黑客文化(1950~1960年代)

软件的源代码,通常被视作在“公共领域共享的成果”,就像所有其他的学术成果一样,在企业界与学术界之间,共享流通。更多信息,可以参考《黑客——计算机革命的英雄》一书。https://book.douban.com/subject/6860890/

简评:正是这种学院派文化,为后来 Richard Stallman 反对闭源软件的自由软件运动,埋下了伏笔。

3.在版权与专利领域的重大进展,使得基于软件的商业模式,得以出现

  1. 1976年2月3日,比尔·盖茨发表《致爱好者的公开信》,谴责软件盗版行为
  2. 1976年10月19日,美国国会修改《版权法》,把计算机软件纳入版权保护范围
  3. 1978年1月1日,新《版权法》生效
  4. 1981年,美国最高法院对《Diamond v. Diehr》案件的宣判,确立了软件专利合法,肯定了软件知识产权

简评:也许很多人会觉得,这是历史在开倒车。但是在我看来,如果没有版权和专利对于软件的保护,计算机软件这个行业都不会出现,因为没有任何人能够赚到钱,全世界的程序员总数,可能到现在都不会超过几万人。但是,在这些法律设施具备之后,的确有越来越多的商业公司,宣布将自己的软件闭源了。

4.Richard Stallman 发起自由软件运动

  1. 1983年9月27日,发起 GNU 计划,
  2. 1985年10月,建立自由软件基金会
  3. 1989年1月,发布 GPL,提出 Copyleft 概念

简评:乍一看,Copyleft 当然要比 Copyright “高尚”,但事实上,如果一个国家没有严格执行保护 Copyright 的政策,Copyleft 也不会那么有价值。这是一个硬币的两面。

5.Open Source 运动兴起

  1. 1991年,Linus 开始开发 Linux 操作系统内核
  2. 1997年,Eric S. Raymond 首次发表《大教堂与集市》
  3. 1998年1月,Netscape 公司宣布将 Navigator 浏览器的源代码开源,在加利福尼亚州帕洛阿尔托举行的战略会议上,Open Source 这个词汇,首次出现
  4. 1998年4月,Tim O'Reilly将原本计划召开的《Freeware Summit》改名为《Open Source Summit》,在此次峰会上,Open Source正式定名
  5. 1998年,开源软件促进会正式成立

简评:从自由软件,到开源软件,这其中的变化,使得技术分享的文化与商业利益之间,有了更多妥协/调和的可能性。

6.开源组织,各种非营利组织,尤其是是开源基金会的兴起

  1. 1999年3月,Apache 软件基金会
  2. 2000年,Linux 基金会
  3. 2000年8,GNOME 基金会
  4. 2003年7月,Mozilla 基金会
  5. 2004年2月,Eclipse 基金会
  6. 2005年2月,软件自由法律中心
  7. 2005年11月,围绕Linux的专利联盟,开放发明网络(Open Invention Network)成立

参考:

https://opensource.com/resources/organization

简评:开源兴起背后,其实是一批企业的兴起,比如 VA Linux 和 Red Hat 于1999年进行的 IPO,股价大幅飙升,使得开源有利可图,成为现实。在此之后,开源技术与商业正式携手,基金会和专利联盟,则是企业间技术协作的“正确姿势”。

国家应该做些什么?

简单的梳理过去几十年开源发展的历史,我们可以发现三个关键词:

教育,尤其是高校教育,更重要的是,支撑高校教育背后的“学术传统”。

法律,尤其是保护知识产权的法律,更重要的是,能够保护技术、保护创新的法律执行力,才能凸显出分享的可贵,与奉献的伟大。

基金会,尤其是企业间因为共同的利益而自发成立的基金会,才能使企业更好地支持和扶植开源技术。

话不多说,点到为止吧。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-01-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 开源社 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档