开源软件公司应注意的的几个问题

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

那时还是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 等等。它们是看起来不一样的,但是它们做的却是同样的事情,这样就难以让某一个编排项目、或者是其背后的公司,从中脱颖而出!

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