网站开通会员怎么开发,营销型网站的运营配套不包括,wordpress企业商城模板,为网站做一则广告语在上一篇文章中#xff0c;我介绍了企业开源的完全开放源码策略及其风险。完全开放源码#xff0c;即以符合开源定义的软件协议发布企业自研软件的情形。本文介绍应对完全开放源码后的风险的第一种策略#xff1a;提高市场占有率与开放标准。与其说是策略#xff0c;不如说…在上一篇文章中我介绍了企业开源的完全开放源码策略及其风险。完全开放源码即以符合开源定义的软件协议发布企业自研软件的情形。本文介绍应对完全开放源码后的风险的第一种策略提高市场占有率与开放标准。与其说是策略不如说是促使企业完全开放源码的动机。策略市场占有率与开放标准选择和坚持完全开放源码策略的一个主要原因是企业希望完全开放源码的软件赢得广泛的市场占有率甚至形成开放标准。以开源的程序设计语言实现为例在语言本身赢得用户之前很少有企业能够直接通过售卖语言实现的编译器或解释器来盈利。瑞典电信公司 Ericsson 支持工程师 Joe Armstrong 开发 Erlang 语言之后将整个 Erlang/OTP[1] 平台完全开放。从当年的发布文稿[2]中我们可以看到开放标准的典型思路Erlang/OTP was invented within Ericsson and most Erlang/OTP users are still within Ericsson. In order to speed development of Erlang/OTP, ensure a good supply of Erlang/OTP fluent programmers, minimise maintenance and development costs for the language, and keep the OTP applications up to world class, we need to spread the technology outside of Ericsson.也就是说Ericsson 内部的电信系统高度依赖 Erlang/OTP 平台为了保证劳动力市场上一直有人熟练掌握这一语言和开发平台从而保证 Ericsson 内部系统不至于无人能够维护Ericsson 希望完全开发源码以期在公司以外的广阔生态中推广 Erlang/OTP 平台。事实证明这一决定为 Erlang/OTP 平台起初在电信行业内的推广以及后来在游戏行业中的广泛应用再到近些年其底层虚拟机 BEAM 借助新语言 Elixir 的发展再次得到关注都起到了至关重要的作用。Joe 为 Ericsson 创建高可用的服务打造了一个完整的开源软件和开发平台但是如果没有开放源码这将只是 Ericsson 这个如今已不那么有名的企业的一个内部系统。或许会成为一个仅存于谈话之中的传说但是不可能有今天的生态。同样是 Erlang 生态的一部分José Valim 设计的 Elixir[3] 语言及其开发的解释器和网站开发套件代表了开放源码以赢得市场占有率的策略。José 起初在自己参与联合创办的 Plataformatec 开发出了 Elixir 语言的解释器以及 ecto[4] 工具和 Phoenix[5] 框架。后来Elixir 的使用率日益增长José 于是另外创办了 Dashbit[6] 公司来提供 Elixir 应用的开发和运维支持。从 Dashbit 公司的视角出发其拥有部分 Elixir 核心生态软件的知识产权但是它却没有通过限制核心软件使用要求用户购买 LICENSE 的方式来盈利。这是因为Elixir 毕竟还是一个小众的语言用户使用量的增长才是做企业支持的基本盘。如果小有成就马上杀鸡取卵、竭泽而渔那么新用户就很难有信心上车而存量用户也会想办法跳车最终生态凋敝没人有理由购买 LICENSE 授权。José 本人在 LinkedIn 上的头衔就是 Chief Adoption Officer 即首席用户采用官可见 Dashbit 的开源策略当中对市场采用率的重视程度。同类的案例还有 VMWare[7] 的 Greenplum Database、Spring Framwork 和 RabbitMQ 等项目这些公司在相关方向的主要商业模式是提供支持和咨询而不是售卖软件或提供云服务因此其提供支持和咨询的对象的使用率越高越好。再来看一种竞争型的开放标准策略其中典型的当属 Google 的开源矩阵1.Chromium 打下了浏览器内核的半壁江山。如今多少网页应用都注明仅在 Chrome 上经过测试。2.Android 从 iOS 和 Symbian 的夹缝中取得了移动端市场的船票并最终和 iOS 二分天下。3.Kubernetes 和 Istio 是 borg 技术溢出以后Google 主动建立生态的尝试。在相当一段时间里用上 Kuberneets 就“等于”云原生。Google 是重度参与 C 标准讨论或者说竞争的这可从 C 之父 Bjarne Stroustrup 的论文 Thriving in a Crowded and Changing World: C 2006–2020[8] 中关于 C 标准委员会的讨论中窥见端倪。应该说标准之争是激烈甚至残酷的。企业内部总有领先与行业标准所做的尝试一旦行业后续面对相同问题时将另一种解法确定为标准那么本公司不说此前的研发投入打了水瓢至少也需要付出可观的额外努力来兼容新标准。Google 深知这点的厉害而 Kuberneets 打赢容器战争对比失败的 OpenStack、Docker Swarm 和 Apache Mesos 与重金投入它们的公司Google 账面之外的获利不可计数。无独有偶Facebook 的 React[9] 前端应用开发框架已经成为无可置疑的标准对应 Google 推出的 Angular 势弱多少投资 Angular 的企业和开发者损失惨重。国内也不乏出于这个动机完全开放软件源码的企业。例如Apache InLong[10] 是腾讯大数据平台里数据集成能力的开放Apache Dubbo[11] 和 Nacos[12] 是阿里巴巴微服务架设和治理经验的开源表现CloudWeGo[13] 是字节跳动中间件能力的系列开源行动Go Kratos[14] 是 Bilibili 开源的微服务框架。当然这些软件集中在所谓的“中间件”领域是另一个值得探讨分析的话题。最后上面提到的都是体量巨大或至少相对较大的公司对于小公司来说有没有实践市场采用率和开放标准这一策略的空间呢肯定还是有的。例如近期已被 Apache 孵化器接受的 OpenDAL[15] 数据访问库就是由 2021 年初创的企业 DatafuseLabs[16] 捐赠的。又例如CockroachDB 的存储引擎 Pebble[17] 以 BSD-3-Clause 协议开源连 PingCAP 的数据导入工具 Lightning 也有使用。一般来说小公司更容易在细分领域或者新兴领域通过开放源码软件来赢得大量声誉和共同维护生态成员都有需要的基础软件。References[1] Erlang/OTP: https://github.com/erlang/otp[2] 发布文稿: https://web.archive.org/web/19991009002753/http://www.erlang.se/onlinenews/ErlangOTPos.shtml[3] Elixir: https://elixir-lang.org/[4] ecto: https://github.com/elixir-ecto[5] Phoenix: https://github.com/phoenixframework[6] Dashbit: https://dashbit.co/[7] VMWare: https://tanzu.vmware.com/open-source[8] Thriving in a Crowded and Changing World: C 2006–2020: https://www.stroustrup.com/hopl20main-p5-p-bfc9cd4--final.pdf[9] React: https://reactjs.org/[10] Apache InLong: https://inlong.apache.org/[11] Apache Dubbo: https://dubbo.apache.org/en/index.html[12] Nacos: https://nacos.io/zh-cn/[13] CloudWeGo: https://www.cloudwego.io/[14] Go Kratos: https://go-kratos.dev/[15] OpenDAL: https://github.com/datafuselabs/opendal[16] DatafuseLabs: https://databend.rs/[17] Pebble: https://github.com/cockroachdb/pebble
