回答 | 开源项目有哪些机遇与挑战?

随着全球经济和科技环境的快速变化,开源软件项目的蓬勃发展成为了开发者社区的热门话题。越来越多的开发者和企业选择参与开源项目,以推动技术创新和实现协作共赢。你如何看待当前开源项目的发展趋势?你在参与开源项目时有哪些经验和收获?

方向一:开源项目的发展趋势

提示:分析当前开源项目的发展现状,开源社区的活跃度,以及开源项目在技术创新中的作用。

方向二:参与开源的经验分享

提示:分享自己参与开源项目的经历,包括如何选择开源项目、如何贡献代码、如何与开源社区合作等。

方向三:开源项目的挑战

提示:探讨开源项目面临的挑战,如维护难度、版权问题、社区管理等,以及如何克服这些挑战。

————————

好问题,尤其针对咱国内的环境,拿个开源的东东,一通胡改,外包个壳,就敢言必称自己是自主研发的……
 

01| 溯源

无论媒介的形式是软件还是硬件,开源与闭源指的都是信息(特别是科技信息)被共享的方式。开源通常被无差别地等同于免费(尽管不准确,但是大体上是不错的),而闭源则通常以携带copyright(版权)的方式呈现,需要付费购买

以史为鉴,笔者把人类开源的发展史划分为7个阶段,如下图所示:

最早的开源可追溯到互联网出现之前的汽车工业时代。1911年,福特汽车之父Henry Ford打赢了一场美国司法历史上著名的历时八年之久的专利官司,导致从1895年开始就垄断汽车发动机两冲程引擎专利技术的律师George B. Seldon再也无法以独享(闭源)专利的方式从数以千家的美国汽车企业(是的,没有看错,和今天的中国汽车生产企业数量一样多,但是最后终将只剩下三家)那里征收专利费用了。随之形成的机动车厂商联盟在其后的数十年间免费(“开源”)共享了数以百计的专利技术。

时间推进到20世纪70年代,ARPANET(美国高级研究计划署的简称)等机构在美国政府的推动下联合企业与高校催生了互联网的核心网络技术堆栈——如TCP/IP技术。而ARPANET成员间制定和分享技术标准的媒介为RFC(Request-for-Comments),即IETF(Internet Engineering Task Force,互联网工程任务组)组织发布的RFC文档。从1969年最早的RFC到目前为止有超过7,000个RFC1。其中最著名的有如RFC 791(IP协议)、RFC 793(TCP协议)、RFC 768(UDP协议)等。

20世纪80年代见证了免费软件(Free Software)运动的诞生,始作俑者非当时尚在MIT的Richard Stallman(RMS)莫属。他最早于1983年在USENET上面宣布开始编写一款完全免费的操作系统GNU(GNU’s Not UNIX—时代背景为当时流行的操作系统UNIX 100%被商业企业闭源控制)。为了确保GNU项目代码保持免费并可被公众获取,RMS还编写了GNU GPL(GNU General Public License,通用大众版权)。GNU的创立为Linux最终的诞生(1991年Linus Torvalds编写的Linux内核问世,采用GPL v2许可 -- 按照Linus本人的描述,1991年,时在芬兰读本科的他听到了RMS的演讲,深受鼓舞,回去就开始写个“开源”操作系统的计划...)铺平了道路,而GPL则逐渐成为开源最主要的版权许可方式。

RMS的另一大贡献是以组织、机构的方式系统化地推动免费软件深入人心。他于1985年成立了FSF(Free Software Foundation,免费软件基金会),业界为此有了个充满政治含义的新名词—FSM(Free Software Movement,免费软件运动)。从最早的GNU项目到后来的LAMP,到近年来经互联网公司大肆鼓吹的共享经济形态,究其根本是,如果有免费的“午餐”(来替代需付费的产品或服务方式),绝大多数人会趋之若鹜,此人性也。免费理念与实践之集大成者非RMS莫属。

真正的开源(Open-Source)软件要到1998年1月,Netscape公司宣布把Navigator(1994年问世的第一款互联网浏览器,Mozilla Firefox的前身)浏览器的代码开源。RMS在第一时间意识到开源的潜在价值,同年二月即成立了OSI(Open-Source Initiative,开放源码促进会)。如果说前面的FSM为颠覆20世纪60—70年代UNIX系统的商业垄断而生,而OSI则是预见性地用开源去引领互联网时代的科技进步,开创了一条与商业+闭源不同的道路。另一个因素要归功于黑客文化(Hacker Culture)—RMS、Linus Torvalds这些人都是不折不扣的黑客出身。黑客一词是一个在西语语境中趋于中性甚至偏褒义,在中文语境中略偏贬义的词汇,不过,在云与大数据的时代随着越来越多的中国青年一代接触和融入到更多的开源项目与社区中,相信中国的“黑客”必将绽放异彩。

GNU免费软件项目出现的时候其目标是构建一个完整的、可以取代UNIX操作系统的集编程、编译、调试、集成与运行环境于一体的生态系统。显然这个宏大的目标在头十年内 (1983—1993年)并没有实现,而最完整的实现是LAMP开源技术栈(见图3-2)。广义的LAMP可延展至包含一切接入互联网的软件、固件、硬件乃至内容与服务的使能型开源科技。LAMP的出现极大地推动了局域网向互联网跨越,继而奠定了云计算与大数据的技术基础,并经一路攻城略地成为主流技术(LAMP所代表的四大典型开源技术,Linux、Apache、MySQL、PHP/Python分别在服务器操作系统、WWW服务器、数据库及编程语言市场占有率接近或超过50%,并有继续上升的趋势。广义的LAMP可以非常宽泛,在操作系统层面可包含BSD等系统,如Yahoo!公司偏好的FreeBSD,WWW服务器包含Nginx等,数据库还包含PostgreSQL等,编程语言则可以泛指新兴的开源语言如Ruby/RoR等)。

02 | 黑客文化驱动开源技术

开源技术在最早期并非纯粹以商业目的为驱动,确切地说是一种黑客文化(Hacker Culture),以RMS为首的开源推动者们认为开源+共享+众筹是更高层次的精神享受(成就感)继而带来更高的劳动生产率(效率)—这一点和当下的互联网思维如出一辙。不过商业界不会错过任何提高ROI(Return-on-Investment,投入产出比)的机遇,以IBM、惠普、华为、甲骨文还有无数的互联网公司为代表,无一不是或转型来积极拥抱开源或从第一天开张即是开源驱动,即便是以偏执于闭源科技而著称的微软,也不得不在近些年开始拥抱开源软件技术(如容器计算兼容Docker)以获得更广泛的市场认知度。开源如此强势,恐怕是很多人始料不及的。

毋庸置疑,开源对传统的商业模式是一种颠覆,它以一种免费+开放的姿态赢得了黑客(Hacker)群体的心,鼓动了一批又一批的程序员投身开源社区,孜孜不倦地为开源项目贡献代码、编写文档、四处宣讲(例如近来流行的各种meet-up,是开源项目积聚人气的一种新宣讲方式)。对于长期以来只有商业+闭源一条独木桥可走的需求侧企业与机构而言,开源显然提供了另一条路(不过可能是康庄大道也可能是荆棘小路,简单来说,开源看起来很美,用好却很难,基于开源构建的产品与解决方案对于系统设计、开发、维护、升级、定制等一系列的需求通常远超想象)。对于供给侧而言,拥抱开源则是冰火两重天,一方面是积极拥抱开源可能会创造新的业务模式与现金流,另一方面是老的业务模式几乎一定会面临缩减、枯萎(这种现象我们称之为cannibalization,即业务间的“自相残杀”)。一个现实的问题是,对于工程师(特别是软件工程师)而言开源提供了新的就业机会,不过,同时也意味着那些曾经在微软、甲骨文这些主流商业、闭源体系架构上求生的成千上万的工程师会逐渐失去工作(尽管在体量上面,开源项目所能承载的体量指数级小于商业化项目,这是个不容置疑的现实存在,并不会因为互联网公司努力的白嫖开源就会改变绝大多数的商业领域中还是商业软件的天下,而开源的份额还很小)—颠覆,永远都是相当残酷的。

[任何事物都有两面性。笔者把前段时间看到的一篇文章贴到下方:《开源代码却无奈遗弃,濒临奔溃的开源开发者们!》

开源代码却无奈遗弃,濒临奔溃的开源开发者们!_Ultipa的博客-CSDN博客​blog.csdn.net/Ultipa/article/details/114658474

03| 软件在吃我们所有人的午餐

业界的另一个大趋势,是随着底层硬件的同构化(通用化、商品化),系统主要的差异性都通过软件来体现(例如,虚拟化,容器化,软件定义的计算、网络、存储等)。软件,无论开源与否,以其远超硬件的灵活性(可定制性、可编程性、可二次开发性)顺应并引领了信息时代需求多变的特点而越来越受到青睐。其结果是硬件研发厂商几乎都是赔钱赚吆喝,而软件开发商则在金字塔的顶端拿走了整个产业链最大头的利润。以手机行业为例,那些手机代工厂,大如鸿海(富士康),组装生产一部手机获利不超过4美元,而苹果公司通过控制手机操作系统和其上的软件商店,每部利润超过200美元。另外,整个智能手机产业的利润的94%都属于苹果公司—软件的力量让人惊诧。软件是否在吃我们所有人的午餐(Software is eating our lunch)?也许,我们要用更久的时间来回答这个问题。

另一方面,软件可以定义一切的时代,软件的能力被极大的神化了!一个最典型的例子就是,软件所提供的算力是不可能超越底层硬件的物理极限的,而实际上,很多软件根本就无法充分利用底层的硬件的(高并发、低延时)能力。这里面或许我们不应该点名批评任何一家公司,但是,务实的说,Hadoop生态中的解决方案,甚至包括Spark,动辄就会成百上千台机器,实际上每台机器的利用率都甚为低下!笔者曾经在之前的一篇文章中提到过,32台机器的集群,如果每台机器只有1个线程在奔跑,这个集群的算力低于一台机器上面32个线程以高密度并发的方式在奔跑的算力!(当然,这个问题复杂的地方在于,32台机器的硬盘并发的吞吐率一定会高于1台机器的硬盘吞吐率,不过,我们如果强调的是CPU的算力的话,那么事实就是如上所述!)这个问题还触及了另外一个话题,什么样的分布式系统是更高性能的问题,大家可以类比的得到答案。更小规模的分布式的集群,更密集的并发,往往会达到比那些更大规模的集群,但是却只有低密度并发,更好的效果 --- 意味着:更低的延迟、更高的并,在单位时间内更高的吞吐率,高ROI、低TCO。或许大家应该思考下,为什么有的人前2年的时候会说:Hadoop已死,⬇️。

笔者作为亲历了Hadoop肇始阶段(从2004年开始到2006年,Hadoop由Yahoo!的工程师Doug Cutting捐赠给Apache开源社区,笔者时任Yahoo! SDS战略数据部架构师。2004年时Yahoo!每天要处理全球超过30000台Apache Web服务器上面超过27TB的数据,这个数值当时比Google要庞大,是世界上最大规模的数仓),目睹过在Yahoo!内部彼时的分布式数仓系统建设中,Hadoop的性能、吞吐率、延时等很难与内部其它更实时化的数仓系统竞争,内部无法消化,进而转为捐献给开源社区 (开源很多时候是个圈子游戏,有机会再和大家分享更多内幕。)--- 笔者还记得当时就以开玩笑的方式说过:Doug, it's not gonna work (道哥,Hadoop肯定搞不定啊...)--- 我为什么要这么说?很简单,即便在今天,X86服务器的性能已经数倍高于10几年前了,但是一个普通的Hive查询,Hadoop随便一个Map-Reduce操作返回就要40秒,它是在是太慢了!几乎所有的Hadoop系统,都占用了无数的硬件资源,但是绝对不是以一种Fast Data的方式来执行任务的。这些是Big Data最令人难以启齿的问题 --- 即便是到了Spark的架构模式上,也依然远远没有达到可以实时处理海量数据的水平 --- 从投入与产出比来看,Hadoop/Spark最成功的是构建了一整套生态,但是,生态不是一切。该被替换掉的系统,还是会被替换掉!笔者始终以为,数据库、数仓系统,如果没有性能这个第一生产力,说其它的都是在耍流氓。

好了,洋洋洒洒,写了这么多,我要静静。

相关推荐

  1. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       23 阅读
  2. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       20 阅读
  3. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       21 阅读
  4. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       20 阅读
  5. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       20 阅读
  6. 开源项目哪些机遇挑战

    2024-07-13 00:54:02       21 阅读
  7. 从三个方向来谈谈开源项目哪些机遇挑战

    2024-07-13 00:54:02       24 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-13 00:54:02       66 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-13 00:54:02       70 阅读
  3. 在Django里面运行非项目文件

    2024-07-13 00:54:02       57 阅读
  4. Python语言-面向对象

    2024-07-13 00:54:02       68 阅读

热门阅读

  1. 「AIGC」TDSQL技术详解

    2024-07-13 00:54:02       19 阅读
  2. Ultralytics YoloV8库可完成任务介绍

    2024-07-13 00:54:02       24 阅读
  3. Oracle 19c RAC 心跳异常处理

    2024-07-13 00:54:02       18 阅读
  4. 音频demo:将PCM数据和opus格式相互编解码

    2024-07-13 00:54:02       28 阅读
  5. 算术运算符. 二

    2024-07-13 00:54:02       26 阅读
  6. matlab实现pid控制机械系统

    2024-07-13 00:54:02       18 阅读
  7. Http网络通信流程

    2024-07-13 00:54:02       18 阅读
  8. Mojolicious测试驱动开发:单元与集成测试的艺术

    2024-07-13 00:54:02       22 阅读