我们对在OpenERP开发过程中没有做好相关充足的交流感到抱歉，我们愿意不断地花更多时间去修复缺陷以及开发更棒的功能。 正如您可能所知道的，我们把全部的代码都公布在 launchpad 和 runbot.openerp.com 上面，但是其中的上千个 branch 可能会使普通门外汉晕头转向。 我们也广泛地应用由我们自己所开发的OpenERP项目管理模块，比如看板视图，etherpad和 openchatter. 每一项任务都包含了所涉及的多个branch的链接。
第八版现有可提供测试的内容如下：
我们使用的阶段:
- 素材积累 (新的主意或想法)
- 具体规划 (功能, 技术和使用性)
- 项目开发
- 功能测试
- 代码审查
- 公测发布 (更新进度表和变更日志,博客)
- 正式部署
任务目前分成了6个项目进行:
其中三个是长期持续的:
- 架构 (比如 apiculture, 全新的商业智能 BI 矩阵/图表)
- 实用性和功能改进 (比如 gamification, 问卷调查, 批量邮件, 工作日资源等这些在 base_action_rules, 还有其他许多小细节上的改进)
- 平台 (我们内部的 openerp, 和 saas 云管理)
剩余三个是临时的 (以月或年进行).
- 网站 (内容管理系统 电子商务 ...)
- 仓库 (全新的仓库管理系统)
- 零售终端 (pos机硬件 + 许多改进)
其他一些目前重要的任务可以在pipe中找到，（如有任何问题您都可以给我留言，但前提是请先在runbot上测试)
http://runbot.openerp.com/ 找到对应的 branch 并点击箭头旁边的连接 -> "所有插件" 全新的日历 + 谷歌同步 (已经整合) 服务器动作和 base_action_rule 改进 (已经整合) openerp数据用谷歌电子表格访问 (已经整合) gamification (已经整合) trunk-website-al (将在几日内整合完毕)
- 网站架设
- 博客引擎
- 电子商务
- eventbrite 克隆
- 合作方与推荐目录
- 团队页面与人力资源的关联
- 职位申请页面与人力资源的关联
- 全新的电子邮件模版设计
trunk-new-graphview-ged (将在明日内整合完毕)
- 全新的图表视图和多维矩阵
- group_by 粒度可支持read_group，就像create_date: 月/天/周
trunk-quote-roller (将在近期内整合完毕)
trunk-pos-ugly-but-fast (将在明日内整合完毕)
- 全速完善中
- 开箱即用，硬件支持: 打印机 扫描仪 保险柜
- 平板和移动设备的支持 + 许多错误修复
trunk-survey2-rim (预计在1个月内完成整合)
- 在原问卷调查模块和网站架设的基础上克隆 serveymonkey
trunk-bs3-jke (预计在3个月内完成整合)
- 网页客户端内实现 css 转 boostrap3
- 从移动手机到4K屏幕的响应设计
trunk-wms (预计在2个月内完成整合)
- 量化代码重构
- 先入先出, 后进先出
- 多处简化与代码精简 (比如删除一些工作流)
- 尽可能向 SAP 一样给力 (现在我们可以做到像 SAP 一样使用案例)
trunk-apiculture (预计在3个月内完成整合)
- 全新的应用程序接口 (全新的字段, 不再有id,cr,uid,等列表)
- onchange 修复
关于整合与外部化，新版本的OpenERP能提供什么功能?
我知道长久以来关于openerp的
NIH syndrome 一直存在抱怨, 我想大部分是正确的. 但是首先请允许我分享我个人坚持的4大信念 (我也和Fabien分享过). 这些信念目前还没有被动摇 (因为我经常会摒弃旧思路, 他亦如此).
1. 重视一款软件中的整合
我不认为这是一个能保持独立的简单软件，正相反，一款好的应用恰恰就是能将不同软件的组成和功能汲取在一起. 正如我喜欢用Lesuisse law1来阐述Metcalfe's law (将来可能这么说:"一款软件的价值是和有多个高度且完美整合在一起的应用成比例的") 用一些我所欣赏的软件系统来描述: 经典的 unix 工具箱, 功能强大的系统包含了许多命令, 但是他们在整合方面做得太差了. Debian 发布, 数量庞大的apps, 整合的跨度分布各种 packages. 整合套件比如 Microsoft Office, Adobe suite, apps数量不多但是他们都是高度整合. 我也欣赏那些一应俱全，开箱即用的软件. (我不会拿 emacs 来举例，因为我不了解它). 比如 Blender, facebook, chrome, Ableton live... Ableton Live 是个非常好的例子, 在它之前我都得花费大量时间下载 VSTi 和 VST effects, 使用多种软件来排序midi文件, sample 追踪, 多种ui处理工具还要同时打开很多个窗口. Live 改变了这一切, 所有的一切都整合在了一起，只需要使用同一个ui-control 你就能对生成的midi, sample, drum-kits 和音效进行无缝工作. 我也喜欢通用的或者能提供多套解决方案的软件，比如: linux - 所有的架构都是从嵌入的NUMA排名前500的电脑，每台设备的驱动来自一个源资料库 ffmpeg - 所有的视频与音频解码来自一个代码库. mess/mame - 能仿真所有的计算设备. qemu - cpu 翻译/仿真组合 cpu 同步 和 cpu dest. 当然 ERP 系统更是如此.
2. 内部整合 vs. 差异整合
你或许注意到了那些伟大的程序开发者 (fabrice bellard, john carmack, linux torvalds... 等等) 他们很少有个依赖喜好表. 你也许会说他们正备受 NIH syndrome 的折磨, 不过从他们的角度上看却合情合理. 首先我想要把整合分成两个角度来谈: 内部整合是你可以从其他系统中连接到库或复制代码,思路,结构. 它们可以在相同的内存空间中运行, 功能可以在相同的数据模型和类型中实现且不需要异步运行. 你能够完全由自己, 按照你的规则, 设计, 架构进行控制. 差异整合是指你想要与其他平台, 架构, 数据模型, 或类型的体系上的另一个系统进行对接, 且它位于其他终端或可以在相同的机器上进行简单处理. 举例来说就是 microkernels 和 kernels. 然而要做到这一点是非常困难的, 所以这样的整合所花费的成本往往会与原来的内部整合方案进行权衡, 即便它只需要通过复制实现. 尤其是当涉及到的协议非常复杂时. UDDI WSDL SOAP 这三个缩写就足以令人心生畏惧,叫开发人员止步. 我们还重视用户体验, 如果用户在现有界面直接看见两个系统之间的切换过程, 对他们来说是痛苦的. 在我们做决定之前, 我们会试着去权衡以上这些方面. 而且我认为即便是只需要通过复制实现也不会变得那样糟, 即便是高级工具, 它本身并不复杂, 通常复杂的是将整合它们在一起. 比如我听说 john carmack经常从草稿中开始他的项目. 当然也有例外情况, 利用 HTTP 和 JSON 作为通用的协议和数据类型系统会把事情变得简单. 有时我们不得不去做一些比如在服务器和浏览器, 或数据库和openerp的远程调用这样的事情. 差异整合模块以前总是给人留下性能差的印象, 这是因为它需要非常多的工作量: webdav, document_ftp, caldav, import_sugarcrm, auth_openid, event_moodle... 因此我们打算精简它的数量. 我个人不喜欢那些非必须的依赖, 实际上, 对最新版本的Debian中现有的python函数库我会采取限制. 我们还将一些js 函数库包含在内, 但是我尽可能地减少保留的数量.
3. KISS
4. 只有傻瓜和死去的人固守着他们的思想.
openerp的战略思想是为最终用户与开发人员提供最有效率和最棒的一体化商业应用系统. Antony Lesuisse
https://twitter.com/antonylesuisse 实施您的OpenERP项目以及升级到第八版，请联系上海寰享:
contact@elico-corp.com
