开源软件公司易犯的 5 大错误,又该如何避免?

简介:

来自Thevarguy的 Christopher Tozzi撰文总结了开源软件公司常犯的5个错误,并给出了要避免这样的错误的建议。

在开始作者述说了为何要写这么一篇文章:

要如何做才能够让那些开源软件公司以及他们的合作伙伴茁壮成长?若是回到15年前,这个问题确实是难以回答的。但是,今天开源已经是一种常态,有太多的开源公司在这15年此消彼长的发展着,我们回顾过去,是什么让开源软件公司在健康成长,那些常犯的错误是否能够让后来者吸取教训,避免重蹈覆辙。

像一个严谨的程序员一样,作者对于文中出现的一些概念进行了解释:

本文所说的开源软件公司,指的是在开源生态系统下占据某个环节的公司,他们未必是需要将所有的产品都开放源代码,也未必一定是开发过开源的代码,他们只是以这样或那样的方式混迹于开源界。

当我们去回顾这些公司的历史时,其中的错误或成功都一目了然,以下内容是这些公司所常犯的5个错误,应该极力去避免,避免的方法也在其中。

以下是正文。

期望人们来为你的项目贡献代码

那时还是1998年,网景将其著名的浏览器开源成立了 Mozilla,这在当时是绝对的震撼新闻。Mozilla 是第一家闭源公司向开源模式转换的大型组织,因为当时他们认为开源的模式才是真正的出路。(编辑注:关于当年网景的决策,请移步网景的历史)

但是,Mozilla 很快就意识到了问题的所在,简单的将网景浏览器开源并不能够让那些志愿者大军蜂拥而至,从而帮助他们开发出产品来,相反,Mozilla 一开始就陷入了项目延期的尴尬境地,甚至雪上加霜的是 Mozlla 的一名高管 Jamie Zawinski 在社区成立一年(准确的说,一年零几天)就跳槽了。

当然,后来的故事大家都知道了,Mozilla 解决了此问题,Mozilla 火狐浏览器最终成为了最为成功的开源项目,因为 Mozilla 学到了一件事,那就是将代码开源很容易,难得的是让更多的开发者参与进来共同开发!

对于自己的产品是有选择的去开源

其中一些开源公司将自己置于一个非常尴尬的位置,因为其对于自己的产品是有选择的去开源。举例来说,如Canonical,此家公司通过开源的 Ubuntu 操作系统成为了跻身于世界前列的 GNU/Linux 发行版,但是他还干了一件惹人恼怒的事情:其中一些代码并未开源。

让买卖做大有很多种办法,但是在社区这样做显然是有问题的。这等于向社区发送了多个信号,会削弱开发者们的热情。你可以不去选择开源,但是似开未开的“伪开源”着实令人反感。

忽略文档的重要性

如果你是一名开发者的话,可能相对于写文档宁愿去选择撰写代码,或者说更加的享受代码。但是由于软件的特殊性,若是设计师没有提供如何真正使用它的文档的话,其实这款软件用处不大。

但是文档的问题一直以来都是困扰 GNU,自由软件项目的首要问题,(我知道,GNU 并非是一家商业公司,但是在此举例仍然适用。)在1988年 GNU 的开发者们已经开发出了令人印象深刻的代码。但是仅有非常少量的文档。那时 GNU 甚至都在邮件列表中发出“雇佣一些专门的人来撰写文档”的信息,通过呼吁捐款来尝试解决这一重大问题。当然,后来来自旧金山的加利福尼亚大学教授:Dick Karpinski 赞助了 1000 美元现金算是解决了此问题,直到这时方才有人开始撰写 GNU 的文档。

GNU 从此学到的教训就是在完成了代码之后,文档并不总是能跟上,你须在一开始就得确保文档的开发要和代码保持一样的进度。

采用了简单粗暴的商业模式

随便去问问你周边的人们,开源软件该如何赚钱?大多数的回答恐怕是免费奉送代码然后销售技术支持。但是,你仔细的去近距离的观察的话,这并不是那些成功的开源软件公司所采用的关键的商业模式。

以红帽为例。是的,红帽确实也在售卖他们多个产品的支持服务,但是正如公司的创始人和前CEO Bob Young 在一篇名为“另辟蹊径:红帽是如何偶然发现新的经济模式并助力改进整个业界”(1999年出版的图书《开源》,编辑:Chris DiBona、Sam Ockman 以及 Mark Stone)所指出的那样,红帽的壮大是因为专注于构建自己的品牌,而不是随大流的去为开源的产品提供支持服务。

Young 比较了红帽的产品和其它行业的商品,得出了一条结论:让 Linux 赚钱就像是售卖番茄酱。就其本身来说,番茄酱很便宜而且可以在自家的厨房里就可自行制作。但是亨氏就通过售卖番茄酱赚了上亿美元,为什么?因为亨氏构建了一个得到人们信任的品牌!人们可以在自家的厨房亲手来制作番茄酱,一如管理员们可以自行构建自己的 GNU/Linux 发行版一样。但是人们是不会这么干的。人们购买亨氏的番茄酱完全是因为亨氏的品牌,正如人们采购红帽企业版 Linux 的订阅服务完全是因为红帽的品牌。

成功的方法不仅仅是提供某种形式的支持服务就希望人们购买它。你需要给客户一个信服的理由去第一时间找寻商业的服务,一旦他们相信你了,他们就会决定购买你所提供的产品和服务。

重复制造轮子

人们之所以热衷于开源的其中一个论调就是开源可以让开发者们不去“重复发明轮子”,相比于从头开始一个项目而言,借用已经实现了同样功能的代码更加的划算,这样可以腾出时间和精力去做额外的创新和开发新的功能。

但是这并不能阻挡依然有很多的开源软件公司和项目在创建着冗余的代码。举个例子,目前针对 Docker 容器的编排工具平台至少有一打,如 Swarm、Kubernetes、Mesos 等等。它们是看起来不一样的,但是它们做的却是同样的事情,这样就难以让某一个编排项目、或者是其背后的公司,从中脱颖而出!

关于这点的教训就是,开源组织若想壮大就尽量的去避免构建冗余的解决方案,否则的话,很难出人头地。

文章转载自 开源中国社区[http://www.oschina.net]

相关文章
|
6月前
|
SQL 安全 程序员
PHP编程中的关键性错误及解决方法
在PHP编程过程中,程序员常常会遇到一些关键性错误,这些错误可能会导致程序运行异常甚至崩溃。本文将重点探讨PHP编程中常见的关键性错误,并提供解决方法,帮助程序员更好地应对这些问题,提高编程效率和代码质量。
36 1
|
监控 安全 数据安全/隐私保护
在开源代码的时候该如何避免安全风险的发生?
作为开发者来讲,不管是在实际开发中使用开源项目,还是直接投身于开源的贡献中,关于开源相关的内容想必都有自己独到的见解。开源与开发者息息相关,可能有的开发者会觉得不使用开源项目,自己就与开源无关了?这种想法是片面的,因为就算没有在实际开发中使用开源项目,但是在实际开发中肯定会用到一些第三方的插件,那么能保证这些插件没有用到开源的内容么?所以,开源与每一位开发者都有联系。
283 2
在开源代码的时候该如何避免安全风险的发生?
|
数据管理 项目管理
谈谈实施数据治理时常犯的10大错误
我所见过的最大的错误就是企业没有将文化变革纳为数据治理举措的一部分。到目前为止,这个错误是最大和最常见的错误,它最终可能导致数据治理计划的彻底失败。
|
存储 Unix 程序员
程序员的自白:我如何让失败项目起死回生,变成价值 270 亿美元的应用程序?
Slack 是颇受欢迎的企业沟通和协作工具,目前有 63 万企业在使用。2014 年初拿到了 4000 多万美元融资之后又完成 1.2 亿美元的融资,其估值达到了 11.2 亿美元。2015 年 2 月,slack 成立一周年日活跃用户就达到 50 万人。2019 年 6 月 20 日,创业公司 Slack 正式登陆纽交所。 这个应用起源于一个几乎已经宣告失败的游戏项目,发展成今天一家价值 270 亿美元的公司实属不易。今天,我们来听听 Flicr 与 Slack 的联合创始人 Stewart Butterfield 的轶闻趣事。
137 0
程序员的自白:我如何让失败项目起死回生,变成价值 270 亿美元的应用程序?
|
存储 安全 Python
本想让程序执行加速,却无意中走上了bug之路
在日常的python开发中,经常会碰到使用threading模块提升程序执行效率的场景。但今天却遇到了一个翻车场景,所以赶紧拿出来分享给大家。 省略掉业务功能,来举一个场景出发的demo吧
108 0
|
开发者 前端开发
[译] 如何避免我作为初级开发者时所犯下的 7 个错误
我们应该从中吸取教训。在成为高级开发者的过程中,我犯过许多错误。本文讲述了当我还是初级开发者时犯过的 7 个严重错误,以及如何避免这些错误。
892 0
|
Web App开发 JavaScript 前端开发
容易忽视的前端陷阱
1 CSRF CSRF(Cross Site Request Forgery)是伪造客户端请求的一种攻击,字面上的意思是跨站点伪造请求 CSRF的定义是强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求,最后达到攻击者所需要的操作行为。
892 0
|
NoSQL 测试技术 程序员
关于代码的那些低级错误,都是血泪的教训
无论你是初级工程师,中级工程师,高级工程师,甚至是全栈工程师、架构师,都是从零开使一步一步走出来的,想必都会犯过一些低级错误。 那些错误都是怎么发生的,如何避免发生错误呢,看看我们各位资深的程序员以自身为例,告诫我们敬畏每一段代码
5449 0
开源项目中经常出现的七种错误
启动一个新的开源项目可能会遇到一些困难。也许你脑子里有一个很棒的想法,但是想把它们变成富有成效的、健康的、吸引人的社区还需要做很多工作。令人叹息的是,相同的错误总是被无代价的重复,出现低级错误是团队中的忌讳。
1199 0

相关实验场景

更多
下一篇
无影云桌面