其实呢,,,很早就已经有大牛说尽了此事儿: 来自:

Simon Phipps 的长文:

Open source community collaboration strategies for the enterprise

作者

简单的说,是位资深人士, 在各种技术公司负责战略层面的领导以外, 也深入一线,折腾过 现场工程师,程序员和系统分析员,以及技术出版. 主要成就:

• 上世纪80年代曾与OSI标准
• 上世纪90年代的参与过第一个商业协作会议软件
• 将Java和XML引入IBM
• 开放移动联盟的创始董事

主要的技术媒体阵地在:

• 自个儿的 blog
• UK’s Open Rights Group
• Open Source Initiative
• IDG的 InfoWorld 和 ComputerWorldUK
• FossAlliance

快译

庄) 前缀的代表 庄表伟 试译为主

庄) OSCON(O’Reilly开源大会)的主题,去年是”从分裂到缺省”. 在过去的十年中,我们看到开源从默默无闻到万众瞩目. 如今,越来越多的企业比以往任何时候都更多的考虑开源在其经营战略中扮演的角色. 我有机会观察并且参与那些首次使用开源的无论新老的众多企业或经营单位的转化进程,去观察开源战略如何进化以适应那些软件企业.

庄) 在许多人看来,开源是”软件自由”这一伦理思想的实际表达,通过Richard Stallmand的GNU项目与BSD项目这两个社区以各种方式来阐述. 开放源码与自由软件的要点是能够简单把握的:自由软件授权给任何目的的使用,学习,修改和分发行为,而开源的定义则澄清了伦理结构与务实原则的一部分,以帮助定义版权许可并促进软件自由. 正如简单的乐高积木开启了一个无限创造的世界,这些开放源码的基石,提供范围广泛的使用模式,至今仍在不断发展.

本文为各种软件组织提供了一点值得思考的思考和策略指导, 旨在帮助大家向有关企业领导解释时必须思考的概念, 包含:

• 用以理解社区不同层面的模型
• 用来解释社区关系的一种策略
• 其中的用户/客户价值
• 所有综合起来后的反思: “影响贸易管制”

社区类型

庄) 企业从依照互联网时代之前的软件采用模型到拥抱开源,在这样的旅程的每个阶段,我常常觉得需要区分不同类型的,分为不同层次的围绕着各种各样的自由软件共享的社区. 社区成员经常被形容为”开发者”(“开放源代码”的世界观,经常强调这一点)或”用户”(“自由软件”的世界观,经常强调这一点). 其实都一样,使用术语”社区”去称呼各种风格的社区就会导致混乱,尤其是针对参与的动机时.

自由软件一般包含软件以及代码仓库, 当然有的简单到只有一个下载目录. 以及相关许可证/资源/商标/BBS 以及其它社区资源, 加上人们如何使用资源的规范,统称为 “社区管理”. 这当然很关键,不过,本节要讨论更加基础的.

以作者的丰富经历,目测出至少有四种类型社区, 当然,多数情况下社区是混合有其中至少两种类型. 不过,先定义明确社区类型,对接下来的探讨很必要.

分层模型 Layered model

此模式当然不是万能的,而且偏重从外面来考察社区. 不过,总之是个模型了.

据此模型,俺发现从企业角度, 社区类型分层结构就是洋葱样的:

从内向外:

• 合作开发社区 一般都是核心代码开发者聚合而酻 其实有些甚至于是带薪的

• 部署用户社区 以核心代码/软件为基础 结合具体应用场景的用户聚合成的社区 专注测试/部署/应用 以及传播这类知识/技巧

又各自能划分为另外两种子类型

合作开发社区:

核心合作开发:

• 开发/运维/修订 核心代码的开发者
• 毫无疑问的,他们是核心项目的真正拥有者
• 而且一般形成有非常坚固的内在文化
• 无论你是否提供了多少赞助,一般是无法轻易强加什么意愿到他们心中的
• 并且极其反复任何类型的营销信息

扩展合作开发:

• 类似 i18N, 不同平台的移植,不同系统的安装包封装等等
• 他们为核心项目创建扩展/插件/原形/示例/文档/教程…
• 两样,也对各种营销信息无爱

部署用户社区:

部署开发者:

• 基于公开内容,能熟练部署/应用项目的开发者
• 理解所有配置细节/技巧并能完善的安装/运维
• 很可能是相关企业内部,具体应用项目的集成/开发者
• 有兴趣为企业提供具体的培训/定制服务
• 他们才是企业最应该接近的社区群体

用户:

• 受委托来使用开源项目的开发者,
• 可能是项目的热心倡导者,
• 最感兴趣的是针对开源项目的服务/培训/咨询/定制…
• 基本上他们不可能有进一步的发展了.

模型的含义 Implications of the model

以上社区模型,虽然没有确切的名称,但是,俺继续推导出了以下几点:

1. 虽然指出了4种类型的社区,但是,同一个人,完全可以同时扮演不同的角色
2. 测试人员横跨了所有类型的人群
3. 对项目的贡献有很多种,成熟的社区关注所有角色的所有贡献渠道
4. 毎一类型的成员对自由的需求各不相同, 自由软件的许可证指出的四大自由,是一个基线; 而我们必须认真对待毎一种类型社区得以流畅运营所依赖的 “自由”
5. 如果一个商业团队想影响社区,必须针对性的进行目标明确的沟通,广播营销信息是没有用的
6. 其实对社区的描述有很多种模型 比如Sun公司以工程/营销和管理来划分社区类型 但是,约定一组明确的术语来描述是非常必要的
7. 常见的对社区的误读有 公司认为 社区 就是 市场 企业软件厂商认为 社区 就是 免费支持 认真的理解社区,有助于企业不会想当然的作出损害社区的决策

透明度和隐私 Transparency and privacy

无论哪一层的参与, 开源社区的成功有赖与一个核心要素:

人人平等

平等已经是个用烂了的词儿, 但是,在社区是真正的实在的. 虽然,平等不等于民主, 但是,在社区意味着相互尊重是基于贡献的.

因此,任何一个社区都是据有极大透明度的, 包含强力价值观的,并]尊重所有参与者隐私和独立思维的.

这样的社区,基本不可能用版权转让之类的操作来进行商业化.

兴趣的同步 Synchronization of interest

人们在社区中最重要的需求是什么? 一个开源社区,每个人都有不同的利益同步了进来:

• 涉及社区以及自身(雇主)的费用
• 寻求从开源软件获得的能力
• 自由的参与引发自身的进步/贡献

在社区中,谁都不欠谁的. 社区本身没有商业模式, 参与者只应在社区以外表达商业利益.

要创造一个人人都愿意参与的社区,必须同步所有人的利益和兴趣

• 每一个行为都应该公开
• 毎一次代码的提交都应该是可理解/测试/改进的
• 毎一条社区规则都必须是理性/合理的
• 毎一笔支出都应该有解释和适当的

但是,社区的透明并不会超越参与者的社会生活/商业利益. 只要不涉及代码的贡献关系,就不是社区关系.

这是非常重要的认识.

在我经历的一些社区严重问题, 都是对社区成员私下谈判, 然后社区被代表,形成了一些既成事实, 从而用法律超越了社区规约.

社区的价值在代码中, 代码是不言而喻的. 即使你是社区的主要赞助方, 也没有权利强迫社区接受你的商业模式.

私人动机, 透明社区 Private motivations, transparent community

因此,在一个健康的开源社区, 我可以自然的保持我的内在动机/隐私/资金/参与/愿意.

另外一方面,又是在一个公开透明的环境中进行持续贡献

• 所有代码是公开的
• 所有修订是已知的
• 所有缺陷是公开的
• 所有决策是在列表中进行的

在我看来,一个有效的开源社区主要特征就是,透明和隐私的有效结合.

开放源码是社区层面的透明, 而个人隐私是个人层面的. 两者的接口就是一个正式的社区/贡献 协议.

为了保持信任以及社区的持续发展, 和每个参与者承诺都能接受的协议是社区的基本规范, 特别是捐款以及专利相关的协议.

这协议必须对社区所有成员适用,不同与奥威尔的 “动物庄园”, 在社区没有任何一名参与者比其它人更加平等.

不排他 No exclusivity

没有任何一位参与者有独家优势,无论以什么方式.

类似 “我们必须赚取利润!” 或是 “我们贡献了源代码” 之类言论,都是个人的和社区无关的. 因为,社区并没有强迫你贡献代码.

这不是一个哲学问题,而是现实!

“开源社区中赞助和贡献的规则” , 一文中,明确的指出了, 如果作为一个公司,启动了一个开源社区, 试图采取排他性措施, 将总是导致社区的自动分支和衍生, 反反复复,无论你用什么方式来阻止.

游戏系统

~ Gaming the system

这种利益分离也有其局限性,

当然, Apache 基金会已经在此领域成功运营了十多年, 并证明,这是一种成功的共存模式.

但是,其中也发生过很多奇葩的事儿.

讽刺的是,隐私文化也阻碍了合理的干预. 因为无法绑定其它价值取向的协议, 在开源项目过程中, “do-ocracy” 导致人们要不沉默,要不排挤出社区.

所以, Apache 基金会也进行了改进.

通过建立 孵化器 机制, 所有项目必须先在 孵化器 中进行观察, 通过仔细检查,明确社区足够正向后, 才得以升格为正式赞助项目.

从而建立了自己的 “游戏机制”.

其实,有人的地方就有江湖, 任何系统中都有内在的游戏规则, 唯一的对策只能是更加多元化的社区参与方式.

开源商业模式: “开核”是作死

~ Open source business models: Open core is bad for you

我们已经考察过技术类型,以及企业和开源社区的关系.

接下来才是重点: 商业模式 !

在各种现行模式后,可以提纯出的一个核心结构是:

以你之丰富
足用户所缺

开源商业模式的关键点永远是:

• 确保稀缺性是真实的
• 而且只有你能解决之

开源软件的商业模式一向是个广受争议的巨大的热点,比如: Wikipedia article 以及研究员 Carlo Daffara 的: 系列著名文章

当然,当前文章无法覆盖所有开源商业模式. 但是,目测 "开核" 已经成为全新的 开源商业模式 一个必要指标.

这不科学! 因为这样并没有确保成本的节约和定制的灵活性.

以 Compiere ERP 为例. 企业的生存,直接决定了社区的命运.

• 如果社区分支没有给予支持,瘁
• 如果无法及时影响用户需求,瘁

“开核” 的模式很单纯,比如以此模型为业务的企业报价时会曰:

我们提供一个完全功能的社区版
但是必须以 GPL v3 许可形式使用
另外,
我们也提供了企业版
需要付费才能下载
当然是核心开放的

听起来挺合理,但是,都是坑哪…

软件自由的游戏

~ A game on software freedom

所有的系统都有漏洞. 任何商业模式,都是利用软件系统中内在的问题, 包装成游戏来推进下去.

"”开核”模式” 的游戏,需要重新定义其中的稀缺性, 故而比较难以玩起来.

“开核” 当然是种游戏, 其并不是自由软件的一个有效表达式, 因为其目标并不是培养自由软件的用户.

一般而言,一个所谓 “开核” 业务是这么配置的:

• 一个 核心包 是 “开源” 的,提供了基本功能,可以自由使用在开源许可证保护的各种场合
• 但想有效的用起来,企业就会发现,核心包根本不足以支持所有必要功能
  • 而常见的那些必要功能,包含在 “企业版” 中,要付费
  • 想使用这些功能,你必须成为赞助客户,没有其它任何替代方案
  • 然而,即使你付费用了起来,也不意味着有了可靠的支持厂商
  • 因为这是 “开核” ,你只有选择用还是不用

众目睽睽下隐藏的问题

~ Hiding the problem in plain sight

这只是典型的 “开核” 诡辩术. 没人搞的清 “双重许可” 和 “开核” 的花招.

• 他们常说 “充满活力的社区” ,但多数情况下,都是用户, 而不是协同开发者聚集的社区.
• 他们所说 “活泼的生态系统” , 但是本质上只是通过核心组件来确保合作伙伴生态,而不是通过社区形成更好的可替代品.

让我们再次回顾 Compiere的ERP系统, 其创始人Jorg Janke 曰过:

"...Compiere 肯定不是因为技术问题而失败,
败在销售/营销的执行以及错误的决策,
'升级'对于开源合作社区和传统客户间,
我认为商业模式是存在的,
但是,
Compiere 没找到专有组件和开源核心间的良好平衡
...
"

围绕开源项目,提供附加服务, 其实一直有,无论 GPL 或是 BSD 社区都有10年以上的运营.

问及 Apache 基金会怎么看 “开核” 时:

"..."开核", 在Apache 也在实践,
这能使产品受到关注,
免费向用户提供,由赞助发布的基础核心.
但,至关重要的是,
开放的产品就能够满足用户的所有功能;
否则,社区无法形成足够的吸引力,
形成一个宽松许可证约束下的多元社区.
Apache 社区内的各种合作者,
很多来自风险投资,
通过提供配套的特定功能选择,获得了显著的收入
"

是的, Apache 生态的整个儿前提, 就是创始人,能分享 无论核心还是周围组件, 并且,任何情况下, Apache 都是完备的, 足以部署在企业级用户中, 提供引人瞩目的产品.

简单的说, 有的人有銭想节省时间, 有的相反, 在开源社区大家可以自由合作. “开核” 模式中,不成.

“开核” 损害软件的用户

~ Open core harms software users

概括分析下来, “开核” 引发的问题是, 不提供/培养软件自由, 核心业务模式是试图将软件锁定在一个供应商上. 所以, “开核”模式其实是种短线交易模式.

他们维护的 开放核心 同你的业务距离很远, 只是个逼你付费的诱誀, 整个模式是要用你的自由来转换为他们的利益, 而又期望你注意不到.

这不仅是个哲学游戏, “自由软件” 听起来佷抽象, 但是,其背后的思想,已经支撑起了广大企业在使用的非常实用/实惠的系统. 正如以往定义的四大自由 (软件的使用/学习/修改/无限制分发) 已经通过成本节约以及灵活的定制, 创造出了广阔的市场.

如果你是一个软件供应商, 请尊重你的客户的自由. 帮助客户意识到他们的付出是值得的. 反之,你要知道开源世界足以替代你, 所以,不要尝试用隐藏的控件来尝试控制用户.

如果你是一个软件的消费者, 请正视并认真培养你的自由. 如果你总是有其它的选择,这将在谈判中获得强大的力量; 持续的关注技术变化,总是选择创新, 这样就不会因为省钱而交出你的自由, 从而最终浪费更多的金銭.

版权能积累?

~ Copyright accumulation?

版权引发了各种负面问题, 最多视为一个应急的特殊工具. 其不应该是一个公司的利益点, 因为这将创造一个不平等的环境,最终毒害社区.

总之,版权交易与事无补, 别折腾了.

稀缺

~ Scarcity

最终,任何企业都必须通过满足客户的稀缺来丰富自身, 从而形成双赢.

但是,在软件业务领域,稀缺是难以辨别的. 以往,还能通过人为的制造稀缺来控制支付, 现在,网络时代,基本进行不通了.

我能理解为毛老牌软件厂商,总是试图设立一个贡献者协议, 因为他们习惯基于 稀缺 来套现了.

基础设施/业务技能/行政差异… 根本不用和开源软件打交道,就能整回銭来.

但是,互联网制造了一个网状社会, 已经无法简单的绕过来套现了!

参与协议

~ Participation agreements

为了彻底清除潜在的危害, 版权转让警告是社区必须有的规约. 参与者的协议有多种用途:

• 设置为默认许可证
• 并对捐助以及原创性承诺进行声明

好吧,这已经是通例了.

但是,这一切,都需要有法律人士的参与, 最好有专职的顾问,才能作好.

其中,对社区版权的积累,可以防止未来许可证切换的问题. 如果版权被保留在原先的出资者手中, 许可证更改的最终日期将是个噩梦!

当然,著作权并不是唯一可用的工具. 还可以使用 Apache 2型许可证, 给未来各种切换保留足够的余地.

或是,使用 “附加许可证” 的手法, 可以在同一许可证之下,获得更多可能. 这种”许可证升级”功能涵盖更加灵活.

对于文件级的 copyleft (弱许可证) 当前 Mozilla公共许可证第二版是最好的选择.

而想更加强大的许可证,选择 GPL v3 吧. 或是,更加古典的 GPL v2.

(译注: 再次推荐 台湾 OpenFoundry 社区发布的: 授權精靈 ~ License Wizard 3.3 以及 理查德·斯托曼一直是对的 - 阮一峰的网络日志 )

谁之自由?

~ Whose freedom?

在设计新业务前, 终极判定应该是软件自由最终给谁带来了好处? 你还是你的客户?

新企业的 泡沫 总是发端自对颠覆开源的 “双重许可” 以及 “开核”商业模式 后获得了资金. 热衷公司的品牌,而不再依赖开源术语的RP公关技巧. 等等…

因为太多人理解并熟悉了社区的软件自由, 并且,社区总是能跳出版权积累的危害.

结论:影响贸易的控制

~ Conclusion: Trade control for influence

在各种企业同社区的合作案例中,可以感觉出最佳实践的共性. 在社区中,企业寻求更大的控制权时, 除非其目的是推动整个社区的发展, 并获得了 整个 社区各种成员的充分同意时, 否则,极大的可能是适得其反!

有关争议有 Hudson/Jenkins 项目对 OpenOffice.org/LibreOffice 项目.

相反,更加明智的策略是, 寻求对社区更大的影响力. 在许可证和社区固有的规约框架之内. 否则,社区有充分的自由度不跟你玩.

也许你想,干脆将合作伙伴聚合起来模拟一个开源社区, 尽管可能一样能提供灵活/丰富的解决方案. 但是为毛要这么作呢?

隐私/透明并重的社区,引导开发者高度活跃的贡献, 而你与客户的贸易是另外一回事儿, 这和控制他们并没有对应关系.

当你能做到以上这些,将收获强劲的社会影响力;-) 这影响力因为众多参与者对你的信任以及尊重, 从而允许你引导社会前行! 也使你的企业获得社区其他成员的支持共同抵御挑战者.

最终,你最好的社区协作策略就是通过影响力控制贸易!

是也乎

不过, 呢…

是的,这是当年(2012-08-06),俺认领却没有完成翻译的坑: 图灵社区 : 阅读 : 企业与开源社区的合作策略…[done:0%]

启动 DevRel 后,就一直记挂着这一极其相关的文章, 终于快速翻译出来一读,发现,的确应用不到中国来.

接上回关 乎社群:2 什么是技术社区?

再再再再再再再次强调,大妈只专注技术社区:

有相对固定的 一堆程序猿
在相对固定的 线上列表/github/wiki...
对相对固定的 技术领域进行持续的折腾
执相对固定的 目标:学习/实践/推广/完善明确的领域技术/框架/服务/作品

注意: 是作品,不是产品.

是的,俺只关注 技术社区 在中国社会的立足和发展, 其它的,先呵呵了…

只是,必须再次吐糟一下老外专家的语气, 好象统一培训了一般,总是反过来倒过去,对同一概念/事件/理论反复再三不断内外的来说, 其实,整篇文章,除了对技术社区的分类研究外,就说了一件事儿:

企业最好别妄图控制社区

PS:

若无意外,题图都是从原文提取或是通过 Google 图片搜索出来的, 版权属左, 不负责任 ;-)