关于OpenERP

OpenERP的一些技术数字

关于OpenERP的一些技术数字

https://www.ohloh.net/ 是个好网站,上面有很多开源项目的统计信息。

关于OpenERP,它记录了以下有趣的数字。

代码成熟,管理规范

OpenERP的第一行代码在2006年提交。虽已是5年之久,这个项目现在仍旧保持活跃,正在解决大量的问题和持续创造价值,得益于一个有组织、有良好盈利模式的持续贡献者团队。

这么长的项目历史,现在仍能保持如此活跃,表明这个项目的代码和社区长期来看值得信赖,也证明了产品的成熟度和代码缺陷较少。

超大的活跃开发团队

在过去12个月,有240个开发者向OpenERP提交代码。这是全世界最大的开源团队之一,在Ohloh有统计的项目中属于领先的2%项目。

这个估算还仅限于最近12个月,从项目的整个历史来看,有931个开发者贡献了代码。

(译注:此网站上包含了全世界90%的开源项目统计数据,统计依据是代码库。这个OpenERP项目的统计只包含launchpad上三个OpenERP 主项目 server 、gtk、 web的代码库,没有考虑社区贡献的代码集。粗略估计,未参与统计的社区代码和贡献者应有核心代码的10倍左右。)

逐年增长的开发活跃度

在过去的12个月中,OpenERP的活跃度稳步增长。这意味着对项目的关注度在增加,开源社区已经忠于这个项目了。

Ohloh是按照过去12个月代码提交的次数来下的这个结论。开发者人数和代码行数没有考虑进来。

代码平均注释量

OpenERP使用Python语言。

在Ohloh统计的Python项目中,平均来说,26%的代码行是注释(不可执行,为了阅读和维护方便)。OpenERP也符合这个平均标准。

大量的注释证明代码组织良好、文档规范,也证明了开发团队协作有力、训练有素。

编程语言

总代码行数 : 813,153   编程语言 : 17

有效代码 : 628,692                   占比 : 77.3%

注释行数 : 112,110                   占比 : 13.8%

空行数 : 72,351                         占比 : 8.9%

其中:

有268,184行Python代码

有309,341行XML代码

有179,073 行JavaScript代码

以上翻译自 https://www.ohloh.net/p/openerp/factoids,以下为我关注的话题,自己写的。

OpenERP的代码值多少钱

按COCOMO的成本估算方法,OpenERP有628,692行有效代码,相当于168个人年的工作量,按每人年平均工资55,000美金计算,OpenERP的代码价值 $9,214,319,即九百二十一万四千三百一十九美金。

出于好奇,我还看了其他几个相关开源项目的估值,列在一起做个比较。

Linux Kernel                27076万美金

Python                           1310万美金

PostgreSQL                    995万美金

OpenERP                        921万美金

Apache HTTP Server    251万美金

NGINX                            167万美金

同样出于好奇,我看了几个Java开源ERP项目的代码量和基于代码量的估值,基本都过亿了。这也难怪,Java程序员写上百行代码完成的功能 Python程序员几行就搞定了。ZOPE搞了这么多年只有37万行代码。JFire只是个简陋的ERP开发框架(人财物管理的功能还没实现)就已经87 万行了。

ERP并非软件 开源必死无疑

一、ERP并非只是一个软件。
ERP系统跟操作系统有个非常大的不同,就在于ERP系统不仅仅是一个软件,更多的倾向于是一种管理的工具。而 对于操作系统来说,其仅仅是一个软件,所以,LINUX等开源的操作系统可以取得成功,可以跟微软分庭抗礼。但是,ERP不行,因为ERP不仅仅是个软 件,更是个工具。
对于ERP项目来说,三分软件七分实施。一个好的ERP项目,实现要有一个好的项目实施团队。可惜的是,现在市场上ERP实 施顾问本来就是个比较抢手的资源。在国内,从事开源ERP项目的实施顾问可以说比较少,而经验丰富能力强的实施顾问更加是少之又少。没有好的项目实施团队 的支持,即使ERP软件设计的再出色,开源ERP软件在企业中实施的效果也是有限的。更何况,根据我的观察。现在开源ERP软件的功能实在不怎么样,而 且,其BUG又多的要命。在这种情况下,若没有经验丰富的实施顾问在那边统揽全局,开源头ERP项目,要能够在企业中取得不错的业绩,那真的是奇迹了。
其实,很多企业把ERP项目在企业中没有用好归咎于软件产品不好。其实,这只是他们的借口。根据我的工作经验,其实软件本身在ERP项目中起到的作用最 多只有 30%,而且,现在各个产品之间也在相互模仿,同质现象比较严重,各个品牌的产品若光从产品功能上来看,其实真的没有多大的区别。而有区别的就是软件的实 施团队了。所以,项目的实施效果好坏,大部分不在于软件的本身,而在与好的项目实施团队。而真是开源软件所缺少的。
我也接触过一些开源软件的 实施顾问,说实话,他们的顾问团队跟金碟、SAP、神州数码等软件巨头的实施顾问水平还是有一定差距的。其实有这个差距也不用奇怪,因为开源软件企业的利 润本来就没有商业软件那么高,所以,他们顾问的待遇普遍没有商业软件公司那么高。而没有很好的待遇的话,很难留住优秀的ERP实施顾问。而根据我的了解, 开源软件的实施顾问流动性也普遍比商业软件公司的流动性要高。因为很多有经验的开源软件实施顾问在有几个项目经验后,都会考虑转型到商业软件公司。
毕竟,水往低处流,人往高处走。这就如同一些小型的ERP软件公司的实施顾问,拼命往SAP、ORACLE等ERP产品发展,同一个道理。不过,有些开 源软件,确实也有一两个好的实施顾问在那边独揽大局。若企业能够跟这些经验丰富的实施顾问合作的话,那可能ERP项目的效果会好一点。
二、程序开发,远远没有我们想的那么简单。
企业的IT技术人员,拿到ERP软件的原代码,就可以进行二次开发了吗?其实,真的没有这么简单。
这就好象我们烧饭一样。你若把米烧成饭可能简单一点,但是,若想利用剩饭经过重新加工做出可口的饭来说,那可能对厨师的要求会高一点。其实,软件开发也 是如此。对于软件开发人员来说,若从零开始进行开发,可能还会简单一点;但是,若要在原由软件的基础之上,进行软件二次开发的话,难度可能会比较大。因为 他们首先要先去了解原有软件的思想、结构、设计思路等等。而到软件开发人员了解这些内容后,早就黄花菜都凉了。
我曾经有个朋友,他们公司里上 了一个开源项目。一开始的时候,他们是叫了一家专门做这个开源产品的软件公司进行二次开发。那时候,他们由于熟悉这个系统,在这套系统上,他们起码已经钻 研了五年。我朋友企业根据用户需求,整理了一份资料,叫他们进行开发,大概花了一个星期左右的时间,就开发完成了。后来遇到版本升级了,我朋友企业就找了 本地的一家软件公司进行开发。为了更他们达成长期合作的意向,企业还自己掏钱送他们的程序员去培训。结果呢,花了近两个星期的时间,这个原来二次开发需求 的升级工作工作还没有做好。这主要还上因为他们对于开源软件的原由系统架构与设计思路不熟悉所造成的。所以,我们若采用开源软件的话,那么拿到代码后,很 长一段时间不是在新功能的开发上,而是在对原有系统设计思路的理解上。
所以说呀,开源软件ERP不是说我们拿到源代码就可以直接进行二次开发的,软件二次需求开发的准备工作,即对于原代码的研究工作,可能在我们平时的工作中,需要占据比较多的时间与精力。
三、对于需求的把握与控制
我刚开始的时候,是在企业内部做项目实施的。那时候,我们关注的需求是什么呢?这个单据的格式不好看,要弄的好看一点;这个查询不方便,要多设置一些查 询参数;这边输入不方便,最好能够直接选择就好。那时候,我们关注的就是这些细小的需求,在这些细小需求的实现上,浪费了大量的时间。而对于一些比较具有 价值的需求,如收货数量的控制与超收管理控制方面,我们反而抛之一旁。以企业现有管理水平跟不上为由,来个不管不顾。而老是在一些这些没有实际价值的小功 能上,弄个没玩。最好开发成本花了不少,但是,却没有带来多大的实际价值。这个问题到底是出在哪里呢?这主要就是在对于需求的把握与控制不是很好。
现在回过头来想想,确实如此。以前在企业里负责信息化项目的时候,站在用户的角度上考虑问题。由于缺乏实际项目经验,很难站在全局的高度去思考一个 ERP项目该如何去运作,哪些方面的改进会给企业带来商业价值。这就导致我们在实施项目的时候,围绕着用户转。他们说这个不好,那就改这个。解决的永远是 哪些鸡毛蒜皮的小事情,一些单据、报表的格式问题。而对于流程的改善 与控制,这方面却做的非常的不到位。
所以,企业若现在采用开源的ERP 软件项目,由于缺乏知道,不免也会陷入这个困境之中。我有个朋友,现在就在企业中负责开源的ERP项目。他们公司还好,一个专门负责实施,而他就是负责开 发。他跟我说,他现在开发的内容,就是围绕报表呀、表单呀、字段的格式呀;而对于功能方面的改进基本上就没有。因为他们也不知道到底哪些东西需要改进。为 什么呢?很明显,用户连准确的该怎么做都不知道,那当然不知道系统的功能有哪些缺陷,若有缺陷的话该如何走,这些内容也不会很熟悉。所以,他们现在是系统 有什么他们就用什么,没有的话就用手工来替代。而我朋友负责程序开发,整天在那边做的就是单据、报表格式的调整,数据库字段长度的调整等等简单的开发工 作。
这都是因为企业没有比较专业的人来分析、调查企业需求所造成的。而商业软件不同。他们会把企业的需求调研当作项目实施过程中的一项重中之 重的工作来对待。因为他们清楚,把企业的需求搞清楚了,那么企业的ERP项目也就成功一大半了。可见,需求调研、需求分析的工作,对于ERP项目的重要 性。而开源软件项目,缺少的就是这么一个比较专业的人来负责企业的需求分析工作。从而导致开源软件的二次开发,老是围绕哪些细枝末节的东西在展开。
四、开源软件升级的顾虑。
由于开源软件存在众多的 BUG,所以,其版本升级也是非常之快,可以比得上微软操作系统的版本升级了。但是,微软操作系统出现新补丁的话,只需要在原有系统上打补丁就可以了。但 是,开源ERP系统则不是。他需要重新安装、部署系统。但是,开源、开源,其版本升级的话,支持的并不是很好。要解决版本升级带来的麻烦,企业至少需要解 决两个问题。
一是数据迁移的问题。由于新版本的ERP系统需要更改数据库或者其他内容,所以,原由的数据库直接备份恢复到现有的数据库中,明 显是行不通的。所以,用户面临的第一个问题就是开源ERP系统,若遇到升级的话,数据如何迁移。对于商业ERP软件来说,虽然也遇到类似的问题。但是,他 们一般会提供技术支持,甚至帮助用户完成数据迁移的工作。但是,开源项目来说,由于本身就是免费的,企业就不能享受这么好的服务了。除非企业愿意花钱。
二是二次开发需求迁移的问题。在原先版本上所做的需求,如何迁移到新版本之上呢?这是用户在版本升级过程中遇到的第二个难题。在商业软件中,这一般不是 问题,只要你交了每年的服务费用,则他们在软件升级的过程中,他们会帮你完成二次开发需求的迁移工作。而对于开源软件来说,不不怎么好办。一方面,用户自 己会开发很多需求;另一方面,若需求外部帮助的话,他们也会开发一些相应的需求。若现在让他们负责进行二次开发需求迁移的话,则不仅企业要付出昂贵的升级 费用,而且的话,用户自己开发的需求也需要重新定制。这中间的需求确认、开发版本控制、文档制作、功能测试等等会遇到很多问题,不是三言两语可以说的清楚 的。总之是一句话,非常的头疼,非常的麻烦。

OpenERP创始人的战斗檄文 – OpenERP 7.0发布前夕

我要改变世界,我要…, 这些誓言伴随着你的伟大梦想,而当年的你正值青春风华,意气奋发,懵懂天真。我当年的梦想就是要用完全开源的软件来开辟企业管理应用的新天地。(我也曾经发誓要在30岁以前独立经营一个超过百名雇员的公司,但是这个誓言不久后就破灭了)

为了更好的激励自己,我必须选择一个挑战的对象。商业与孩童游戏没有什么两样。当进入一个新学校,如果想要快速的成为老大,你就要揪出那个整天欺负小同学的班级小霸王,当着众人的面踹他的屁股。这也是我对付SAP这个企业软件巨霸的方法。

因此,2005年我开始着手开发TinyERP这个我心中在未来会改变商业世界的软件。并且在2006年准备着“决斗之日”的到来。在那一年我买下了 SorrySAP.com 的域名。我等待了六年,随时等待着用到它的那一刻。我本以为只要3年就可以淘汰掉那个770亿美元市值的巨无霸公司,因为开源是如此之酷。但是,有时候现实与梦想有着遥远的距离…

为了梦想成真,我殚精竭虑,焚膏继晷,每周工作7天,每天工作13个小时,7年来没有任何节假日。我疏远了朋友,放弃了家庭。(幸运的是,我现在找到了一位更“有价值”的妻子,我会稍后解释她与1百万欧元的故事)

在这样3年后,我发现如果我是如此的渺小(Tiny)又怎能改变世界。尤其是当这个世界是由象美国这样的国家主导之时,看来只能用“大ERP”(BigERP)而不是“小ERP(TinyERP)来打破格局。你可以想象一下,当面对达能总裁们的问题:”为什么我们要付几百万美金来买你这个小(Tiny)软件“时,我会感觉自己如何的渺小。因此,我将TinyERP更名为OpenERP。

我们努力工作,事情开始有了进展。我们开发了数以百计的OpenERP模块,开源社区开始成长,我也再不用为月末员工的工资发愁了。(我曾为此挣扎努力了4年)

2010年我们这个超过100名员工的公司叫卖着OpenERP的服务和这个强大但又漏洞百出的产品。这是因为直接服务于终端客户分散了打造精品的资源和精力。

是到了转变商业模式的拐点了

转变之拐点

我们希望将服务型公司转变为软件发布型公司。这样就能使我们在研发中能投入更多的精力和资源。为此,我们改变了现有的商业模式:不再为客户直接提供服务,转而建设一个强大的合作伙伴体系和提供维护服务支持。这需要很多的钱,因此我不得不设法筹募几百万欧元的资金。

经 过几个月的推销,我们从不同的风险资本那里获得了大约10个意向合同,最终与Sofinnova Partners 以及 Xavier Niel先生达成协议。Sofinnova Partners是欧洲最大的风险资本,Xavier则是法国10年来唯一达到10亿欧元市值的lliad公司的老板。

我签下了意向合 同, 却并没有意识到这可能将会让我变得身无分文(除了一条跟随我的狗)。募资规模是基于对公司的现有估值的,但另有一个根据未来4年的公司营收将公司重估到 980万欧元的财务安排。如果我们的营收符合商业计划书所定之目标,我所获得的该数额认股权证将可转变为对应股份。

在面对公证接收这批认 股权证的前夜,我妻子再次检查了合同。她问我这批认股权证是否有涉税问题。我给律师打了个电话,我晕,比利时竟然是全世界唯一一个需要对认股权证付税的国 家,即使我还没有达到条件将这些权证转为股票前。如果我接受这些权证那么就意味着我就要为980万欧元支付12.5%的税,也就是要在18个月里支付将近 120万欧元的税款。因此,我老婆值回这120万欧元。如果没有她,我将身无分文,因为在那时我并没有收入。

我们变更了协议,我因此获得了300万欧元。它使我能召集起一支强悍的管理团队。

成为一个成熟的公司

用这些募集的资金,我们扩充了两个部门:研发和销售。我们在18个月里烧掉了200万欧元,主要用于工资支付。公司开始快速成长。我们在100个国家建立了超过500个合作伙伴的庞大合作伙伴网络,我们也开始签署7位数的合同了。

接着,事情开始变得不同了。人事啦,董事会议啦,大客户合同处理啦,开海外分支啦,预算啦,繁文缛节,不可避免又超感不爽。

2010到2011是比较复杂的年度。我们没有达到我们的预期:我们只达到了销售预测的70%。管理层会议密集。我们自觉表现不佳而自惭形秽。但我们总觉得是否忽略了什么东西,否则怎么会创造了如此卓越的成绩竟然还不能为此自豪。

直 到有一天,某人(我不太记得是谁)做了一个过去两年来每月营收的图表。我们才如大梦初醒。实际上,真的并不赖,在近两年的时间里我们把月收入提高了10 倍。我们意识到OpenERP正在经历的是一场马拉松而不是一个冲刺。哪怕每年只有100%的增长,如能保持这样的增长率几年的话,就很牛了。

一如既往,我本应听从我们家老大的话,她总是比我更明事理。我过去老是向她抱怨:“还不行啊,我们要再快一点,还缺点什么呢?” 她会回答我说:“但你已经是比利时成长最快的公司了!” (德勤因为我们在2007到2011年度1549%的增长率授予我们比利时最快成长公司荣誉)

改变世界

梦想开始成真了。我们开始找到改变世界的感觉了:

有些事正在发生… 带着霹雳和火焰!

OpenERP 7.0将要发布,我相信你会为之震惊欢呼。

正式发布计划在12月21日。玛雅人预言的世界末日,传统ERP恐龙的终结之日。
是时候祭起那支利斧了,那个我六年前购下的 SorrySAP.com域名。

Fabien Pinckers,
OpenERP创始人
日期:十二月三日,贰零壹贰年
中文翻译:Tony Gu (digisatori AT gmail.com)
英文原文网址:http://www.sorrysap.com/node/1291

 

OpenERP能否“行”SAP之所不能!

从公司层面上来说,SAP已经做得足够成功:它持续发展、日益壮大,成绩令人瞩目。 然而,有这样一个领域却目睹了它的溃败,那就是它从未给世界上数以百万计的中小型公司提供过合适的商业软件。

美国人口普查局的资料显示,在美国,98%的公司拥有不到100名员工,然而这些公司却占据了美国活跃劳动力的35%以上。 在世界其他地区,这一比例甚至更高。 这类公司当中的绝大多数都找不到一款合适的软件来管理他们的日常运营。

难道是他们没有这方面的需求? 最初去探访一位企业主时我纯粹是出于好奇,当时觉得他的公司可能不需要通过这种平台来获取客户,包括产品制造、客户支持与售后、信息反馈和团队管理等都可 能用不到这种平台。而事实上我却从来没有遇见过一位真正不需要类似平台的企业主。其实小企业和大企业一样有着相同的需求,他们无法得到满足只是因为他们拥 有更少的资源。

其他的厂商为了极力满足客户需求,已经在产品研发和销售上投入了数百万美元。 此时,Excel和QuickBooks(或其他领域类似的执行相同功能的软件)仍然是大多数企业最流行的管理工具。 然而客户真正期望的,这些工具却往往力所不能及。 客户期望有功能强大、灵活可用,易于上手而且经济实惠的解决方案。 他们希望产品可以直观到几乎不用怎么培训就可以使用,因为他们IT资源有限,有些甚至完全弄不到这种资源。 因此他们很想有一套无需在ERP实施方面砸入大把大把时间的综合业务解决方案。

我们并不主张去改变中小企业客户的思考方式,我们只是主张应该转变软件的开发模式。 随着OpenERP 7.0的推出,我们提供给客户在一个时间段执行一个特定应用的选择,无论是何种应用,都会给他创造更多的商业价值,并且可以使他完全依照自己的进度来构建 综合性的解决方案。 这个看起来似乎很明显,但是迄今为止却没有其他的平台可以提供类似的功能,因此我们相信,此举为我们创造了一种全新的业务应用模式,即“综合业务应用程 序”。

我们已经在之前从未接触过它的客户上测试过最新版本的OpenERP, 这些客户仅仅在几分钟之内就能够操作一些简单的流程(诸如创建销售订单,开具客户发票和登记支付订单等)。 从来没有人是通过培训而学会使用Facebook,LinkedIn或Gmail的。 那为什么商业软件却一定要先培训才能懂得使用呢? 我们只是认为,绝大多数在办公室使用的软件其设计都是不敢恭维的。

因此,客户所期望的并不是不可能实现的。它只是要求我们在做任何事情时,可以尝试去换一个角度,比如利用我们的开源社区将软件翻译出超过25种语言;从 业务流程的角度入手去设计软件的用户界面,以便客户用起来可以得心应手。 当然,软件的简洁性在其设计过程中是最复杂的任务。 我们推出了一个创新性的商业模式,目的是能够在保证企业长期财政活力的前提下,可以以半价于竞争对手的价格提供产品。

每个月都有超过150个国家的20.000家公司安装和测试OpenERP,每个月都有将近700个新的公司使用OpenERP来控制生产流程。 这些数字已经非常明确(地表明OpenERP的可行性),然而和我们的目标市场相比,这些数字还远远不够。 OpenERP 7.0彻底打破了障碍,使得企业可以各取所需;OpenERP 7.0也将使我们在SAP失败的领域能够获得巨大成功……不好意思,SAP,让您难堪了!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>