[Issue] 以共同体为名对开源软件开发最应该带来什么变化?
18 views
Skip to first unread message
Zoom.Quiet
Dec 24, 2019, 3:12:48 AM12/24/19
to Open-Source-Community-Leadership-development
先说一下这几天回响在俺内心深处的偏见:
中国人其实一直是地球上最擅长大规模协作的民族;
古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
企业软件就一定能高速获得成功...
其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
以及所有领域真正商用的高能软件, 多数都是闭源的,
只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
0: 开源, 为了消除各种 diss
1: 开源, 为了吸引更多开发者
2: 社区, 服务于开源开发模式
但是, 这几点前提, 却有一系列更加高层的条件:
0: 必须按照计划, 及时交付可用稳定版本
1: 必须有优先吻合对应硬件的核心功能
2: 必须有打动更多厂商的特性
那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
这可能是大家比较关心的真实问题;
那么, 俺建议:
0: 开源只是开发形式, 并不是管理机制
1: 商业只是运营目标, 并不代表文化氛围
2: 所以, 完全可以使用全套的开源许可证以及对应开发环境/流程,
但是, 配上 HW 军事化管理机制,
并对每一个有效贡献直接给予真实的回报: 奖金/算力/硬件/...
也就是说, 用现代开源软件开发环境来容纳大型商业软件的开发过程,
但是, 用上世纪中国特有的大会战组织形式, 来管理公司以外的海量开发者;
这样, 并不违背开源开发模式, 又能对开发过程强有力的管理,
同时, 给予参与者真实动力;
进一步的, 也因为必须作到开源的基本原则:
对的代码, 才能合并
也逼 HW 完成真正的能应对海量协同/提交行为的开源开发平台构建.
甚至于, 进一步的, 给开源世界带来有中国特色的会战式开源社区,
没毛病哪.
--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!
中国人其实一直是地球上最擅长大规模协作的民族;
古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
企业软件就一定能高速获得成功...
其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
以及所有领域真正商用的高能软件, 多数都是闭源的,
只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
0: 开源, 为了消除各种 diss
1: 开源, 为了吸引更多开发者
2: 社区, 服务于开源开发模式
但是, 这几点前提, 却有一系列更加高层的条件:
0: 必须按照计划, 及时交付可用稳定版本
1: 必须有优先吻合对应硬件的核心功能
2: 必须有打动更多厂商的特性
那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
这可能是大家比较关心的真实问题;
那么, 俺建议:
0: 开源只是开发形式, 并不是管理机制
1: 商业只是运营目标, 并不代表文化氛围
2: 所以, 完全可以使用全套的开源许可证以及对应开发环境/流程,
但是, 配上 HW 军事化管理机制,
并对每一个有效贡献直接给予真实的回报: 奖金/算力/硬件/...
也就是说, 用现代开源软件开发环境来容纳大型商业软件的开发过程,
但是, 用上世纪中国特有的大会战组织形式, 来管理公司以外的海量开发者;
这样, 并不违背开源开发模式, 又能对开发过程强有力的管理,
同时, 给予参与者真实动力;
进一步的, 也因为必须作到开源的基本原则:
对的代码, 才能合并
也逼 HW 完成真正的能应对海量协同/提交行为的开源开发平台构建.
甚至于, 进一步的, 给开源世界带来有中国特色的会战式开源社区,
没毛病哪.
--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!
willem.jiang
Dec 24, 2019, 8:47:25 PM12/24/19
to Open-Source-Community-Leadership-development
这个问题聊的比较深入，我直接在原文中回复了。
On Tuesday, December 24, 2019 at 4:12:48 PM UTC+8, Zoom.Quiet wrote:
先说一下这几天回响在俺内心深处的偏见:
中国人其实一直是地球上最擅长大规模协作的民族;
古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
企业软件就一定能高速获得成功...
其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
以及所有领域真正商用的高能软件, 多数都是闭源的,
高效协作的基础是建立在信息充分交流的基础上的， 闭源软件阻碍信息流动所带来的低效不知道你没有体验过。
以我自己之前06年参与的商业支持项目为例，我看到客户提到的问题到调研解决方案，实现解决方案花了2天， 但是等到补丁发布，用户再次确认花了两个月的时间，当我看到用户的反馈之后，我还需要花上半天的时间把我带回之前的解决问题的现场，用半天时间给出进一步的解决方案。 这样一来一回的沟通，充分让用户体验到了他买的支持的价值 ：）
只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
0: 开源, 为了消除各种 diss
1: 开源, 为了吸引更多开发者
2: 社区, 服务于开源开发模式
但是, 这几点前提, 却有一系列更加高层的条件:
0: 必须按照计划, 及时交付可用稳定版本
1: 必须有优先吻合对应硬件的核心功能
2: 必须有打动更多厂商的特性
那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
这是一个特别好的问题，这是现在特别困扰我的问题。
这可能是大家比较关心的真实问题;
那么, 俺建议:
0: 开源只是开发形式, 并不是管理机制
1: 商业只是运营目标, 并不代表文化氛围
2: 所以, 完全可以使用全套的开源许可证以及对应开发环境/流程,
但是, 配上 HW 军事化管理机制,
军事化管理是建立在强有力的执行基础之上的，但是这对指挥者有很高的要求，
在需要创造性的解决问题的时候，如果不持续点燃基层员工的激情与思想火花，是很难取得成功的。
并对每一个有效贡献直接给予真实的回报: 奖金/算力/硬件/...
也就是说, 用现代开源软件开发环境来容纳大型商业软件的开发过程,
但是, 用上世纪中国特有的大会战组织形式, 来管理公司以外的海量开发者;
会战式的开发很难积累出可以持续发展的能力，就如现在的会战式开源想得最多的是要把代码开出来，但是开出来之后呢？
我们还会以会战的方式在哪不断完善开源项目吗？
这样, 并不违背开源开发模式, 又能对开发过程强有力的管理,
同时, 给予参与者真实动力;
进一步的, 也因为必须作到开源的基本原则:
对的代码, 才能合并
也逼 HW 完成真正的能应对海量协同/提交行为的开源开发平台构建.
这是一个好的时代，如果在一年前我觉得大家不会去思考要和外界构建一个协同发展的平台，现在越来越多的人意识到生态价值。
但是要构建起我们期望的生态，还有很长的路要走。
Zoom.Quiet
Dec 24, 2019, 9:30:50 PM12/24/19
to Open-Source-Community-Leadership-development
willem.jiang <willem...@gmail.com> 于2019年12月25日周三 上午9:47写道：
>
> 这个问题聊的比较深入，我直接在原文中回复了。
>
是也乎,(￣▽￣)
必须的, 这才是列表真正的战斗力所在...
buttom-post 才是最优雅的讨论形式...
> On Tuesday, December 24, 2019 at 4:12:48 PM UTC+8, Zoom.Quiet wrote:
>>
>> 先说一下这几天回响在俺内心深处的偏见:
>> 中国人其实一直是地球上最擅长大规模协作的民族;
>> 古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
>> 进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
>> 而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
>>
>> 只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
>> 以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
>> 企业软件就一定能高速获得成功...
>>
>> 其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
>> 证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
>> 以及所有领域真正商用的高能软件, 多数都是闭源的,
>
>
> 高效协作的基础是建立在信息充分交流的基础上的， 闭源软件阻碍信息流动所带来的低效不知道你没有体验过。
> 以我自己之前06年参与的商业支持项目为例，我看到客户提到的问题到调研解决方案，实现解决方案花了2天， 但是等到补丁发布，用户再次确认花了两个月的时间，当我看到用户的反馈之后，我还需要花上半天的时间把我带回之前的解决问题的现场，用半天时间给出进一步的解决方案。 这样一来一回的沟通，充分让用户体验到了他买的支持的价值 ：）
>
...闭源软件阻碍信息流动所带来的低效...
这个假设在当前场景中已经不存在了:
- 闭源阻碍信息流动的原因, 不是闭源, 而是对应的商业模式
- 要知道, 闭源商业模式的赢利基础就是信息差, 所以, 天然将开发者和用户隔离了
- 现在讨论的开源会战模式, 开发者和用户都是 HW 自己, 哪儿来问题?
- 另外, VxWorks/AUTO Desk 们为什么闭源成功? 因为信息流动在有些领域是有害的, 毕竟稳定为最高指标时,
信息不流动才是最好的, 这样才能在已知不变数据场景中持续优化功能;
- 所以, 以往闭源软件有自己的版本升级周期
- 只是时代在进化, 社会变化超过了闭源软件升级周期时, 就不得不加以改变了...
>>
>> 只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
>> 主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
>>
>> 为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
>> 毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
>
>
> 兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
> 现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
> 这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
>
...兴趣是激发人们创造性解决问题的最大动力...
对应的
收益是支持人们创造性持续解决问题的最大动力..
如果没有足够的收益, 解决问题的乐趣, 无法支持自己和家人有尊严的生活,
那么, 理智的人, 一定放弃解决问题, 而去制造问题...
所以, 有断言: 商业才是最好的慈善
...红帽软件就雇佣了大量的开源开发人员
是的, 这也是俺建议的形式, 将自由开发模式和商业软件管理机制结合.
只是你忘记分析, 为什么 `...他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率`
- 没有多余会议
- 只有 bug list
- 以及自由的工作时间
自由软件开发模式, 和现在流行的远程办公模式有共通之处;
当然, 俺也没好意思多说中外差别:
0: 文化上西方早已进入个性经济时间, 加之社会福利制度确保好人能很容易生活下去, 那么多余时间先人到自己喜欢的事儿中,
毫无压力....特别是芬兰这种有半年极夜的国家, 程序猿比例非常高...
1: 中国还在中国特色社会主义建设中, 所有成员都在拼命寻求安全感, 一件注定看不到合理收益的事儿, 基本上不是富二代, 没人敢于去作的...而不是不会..
2: 中国企业....
>>
>>
>> 所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
>> 0: 开源, 为了消除各种 diss
>> 1: 开源, 为了吸引更多开发者
>> 2: 社区, 服务于开源开发模式
>>
>> 但是, 这几点前提, 却有一系列更加高层的条件:
>> 0: 必须按照计划, 及时交付可用稳定版本
>> 1: 必须有优先吻合对应硬件的核心功能
>> 2: 必须有打动更多厂商的特性
>>
>> 那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
>
>
> 这是一个特别好的问题，这是现在特别困扰我的问题。
>
其实, 这个问题的提出模式已经决定了, 解决的切入点:
- 谁主张谁执行
- 构造生态的主体在企业
- 那么, 一切以企业述求为核心
- 何况, 企业又不可能真的将核心系统 100% 的开发都丢给社区吧
- 所以, 这就象中国经济建国以来的发展路线
- 企业军事化管理教堂式开始为主体
- 开源社区自由软件开发模式为补充
- 先开始, 慢慢的, 通过持续聚焦开发者, 直至社区开发者超过企业开发者很多倍,生产的代码也超过企业开发者时
- 才是困扰的开始...
>>
>> 这可能是大家比较关心的真实问题;
>>
>> 那么, 俺建议:
>> 0: 开源只是开发形式, 并不是管理机制
>> 1: 商业只是运营目标, 并不代表文化氛围
>> 2: 所以, 完全可以使用全套的开源许可证以及对应开发环境/流程,
>> 但是, 配上 HW 军事化管理机制,
>
>
> 军事化管理是建立在强有力的执行基础之上的，但是这对指挥者有很高的要求，
> 在需要创造性的解决问题的时候，如果不持续点燃基层员工的激情与思想火花，是很难取得成功的。
>
...持续点燃基层员工的激情与思想火花
严肃,活泼,积极,主动
是的, 类似口号一直在各种领域都有,
其实, 这种目标非常容易解决:
0: 问问自己, 当前提出的功能有用嘛?有趣嘛? 有种嘛?
1: 如果没有, 为什么提出?
2: 为什么无用无趣无种的功能,一定要提出来逼大家开发?
Linux 为什么成功? 因为,无人看好个人作品能替代大公司的操作系统, 太有种了...
MongoDB 为什么成功? 因为无人看好 文档数据库能有什么应用场景, 可用起来太爽了根本没废话...
Python 为什么成功? 因为科学家们根本没时间学习复杂的专业开发语言, 长的最象自然语言又有这么多专业模块的 Python 当然成为首先语言....
所以, 从 HW 自身来说, 选择开发自己的移动 OS 是政治/市场/...多种博弈的结果,
可从开发者以及应用厂商看来:
- 重复制造一个国产轮子
- 等于自己的作品不得不重新开发一遍,还不一定有对应的收益
- 那么, 为什么选入精力?
所以, 想构建自己的开源社区生态,
首先就得从自己目标生态成员角度去思考, 分解问题, 并给出简洁的回答.
否则, 最好从行政路线, 强行要求所有相关院校/科系, 将学分划分一部分,指向相关研究和开发,
从内部人海战术, 坚持几年, 先有足够多自己系统的开发者,再建立开源社区.
否则, 想从已有生态中抢夺即有开发者, 太不现实了.
>>
>> 并对每一个有效贡献直接给予真实的回报: 奖金/算力/硬件/...
>> 也就是说, 用现代开源软件开发环境来容纳大型商业软件的开发过程,
>> 但是, 用上世纪中国特有的大会战组织形式, 来管理公司以外的海量开发者;
>
>
> 会战式的开发很难积累出可以持续发展的能力，就如现在的会战式开源想得最多的是要把代码开出来，但是开出来之后呢？
> 我们还会以会战的方式在哪不断完善开源项目吗？
>
...会战式的开发很难积累出可以持续发展的能力...
嗯嗯嗯? 这结论怎么来的?
核工业
高铁
高速公路桥
运载火箭
...
大国重器, 纪录片中, 哪个领域的发展不是持续几十年的会战式投入?
成功的开源项目, 从全球视角来看, 不也是会战式的? 特别是 Ubuntu 大投入大产出, 定期交付...
已经将开源开发模式和闭源发行模式基本对等起来了...
开源一定要浪漫自由?
千万别被各种翻译误导了....
自由软件当年是迫不得已, 开源概念的提出也是迫不得已...
然后各种鼓吹, 更加是迫不得已...
黑猫白猫, 解决问题才是好猫...
用自己最擅长的能力来组建社区发展生态, 不被其它各种特殊场景中形成的特殊精彩迷惑,
形成, 有 HW 特色的开源社区生态, 才是有种有用有趣的目标吧.
>
>>
>>
>> 这样, 并不违背开源开发模式, 又能对开发过程强有力的管理,
>> 同时, 给予参与者真实动力;
>> 进一步的, 也因为必须作到开源的基本原则:
>> 对的代码, 才能合并
>> 也逼 HW 完成真正的能应对海量协同/提交行为的开源开发平台构建.
>
>
> 这是一个好的时代，如果在一年前我觉得大家不会去思考要和外界构建一个协同发展的平台，现在越来越多的人意识到生态价值。
> 但是要构建起我们期望的生态，还有很长的路要走。
>
>>
>>
>> 甚至于, 进一步的, 给开源世界带来有中国特色的会战式开源社区,
>>
>> 没毛病哪.
>>
>>
>>
>> --
>> life is pathetic, go Pythonic! 人生苦短, Python当歌!
>> 俺: http://zoomquiet.io
>> 授: http://creativecommons.org/licenses/by-sa/2.5/cn/
>> 怒: 冗余不做,日子甭过!备份不做,十恶不赦!
>> KM keep growing environment culture which promoting organization learning!
>
> --
> 触发: http://2019.openi.org.cn/
> 文案: https://shimo.im/docs/wrtvHxhykq3DKRhP/
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“Open-Source-Community-Leadership-development”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到open-source-community-leader...@googlegroups.com。
> 要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/open-source-community-leadership-development/0d311960-96cb-4ea9-a6e1-76442fb344b1%40googlegroups.com。
>
> 这个问题聊的比较深入，我直接在原文中回复了。
>
是也乎,(￣▽￣)
必须的, 这才是列表真正的战斗力所在...
buttom-post 才是最优雅的讨论形式...
> On Tuesday, December 24, 2019 at 4:12:48 PM UTC+8, Zoom.Quiet wrote:
>>
>> 先说一下这几天回响在俺内心深处的偏见:
>> 中国人其实一直是地球上最擅长大规模协作的民族;
>> 古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
>> 进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
>> 而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
>>
>> 只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
>> 以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
>> 企业软件就一定能高速获得成功...
>>
>> 其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
>> 证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
>> 以及所有领域真正商用的高能软件, 多数都是闭源的,
>
>
> 高效协作的基础是建立在信息充分交流的基础上的， 闭源软件阻碍信息流动所带来的低效不知道你没有体验过。
> 以我自己之前06年参与的商业支持项目为例，我看到客户提到的问题到调研解决方案，实现解决方案花了2天， 但是等到补丁发布，用户再次确认花了两个月的时间，当我看到用户的反馈之后，我还需要花上半天的时间把我带回之前的解决问题的现场，用半天时间给出进一步的解决方案。 这样一来一回的沟通，充分让用户体验到了他买的支持的价值 ：）
>
这个假设在当前场景中已经不存在了:
- 闭源阻碍信息流动的原因, 不是闭源, 而是对应的商业模式
- 要知道, 闭源商业模式的赢利基础就是信息差, 所以, 天然将开发者和用户隔离了
- 现在讨论的开源会战模式, 开发者和用户都是 HW 自己, 哪儿来问题?
- 另外, VxWorks/AUTO Desk 们为什么闭源成功? 因为信息流动在有些领域是有害的, 毕竟稳定为最高指标时,
信息不流动才是最好的, 这样才能在已知不变数据场景中持续优化功能;
- 所以, 以往闭源软件有自己的版本升级周期
- 只是时代在进化, 社会变化超过了闭源软件升级周期时, 就不得不加以改变了...
>>
>> 只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
>> 主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
>>
>> 为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
>> 毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
>
>
> 兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
> 现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
> 这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
>
对应的
收益是支持人们创造性持续解决问题的最大动力..
如果没有足够的收益, 解决问题的乐趣, 无法支持自己和家人有尊严的生活,
那么, 理智的人, 一定放弃解决问题, 而去制造问题...
所以, 有断言: 商业才是最好的慈善
...红帽软件就雇佣了大量的开源开发人员
是的, 这也是俺建议的形式, 将自由开发模式和商业软件管理机制结合.
只是你忘记分析, 为什么 `...他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率`
- 没有多余会议
- 只有 bug list
- 以及自由的工作时间
自由软件开发模式, 和现在流行的远程办公模式有共通之处;
当然, 俺也没好意思多说中外差别:
0: 文化上西方早已进入个性经济时间, 加之社会福利制度确保好人能很容易生活下去, 那么多余时间先人到自己喜欢的事儿中,
毫无压力....特别是芬兰这种有半年极夜的国家, 程序猿比例非常高...
1: 中国还在中国特色社会主义建设中, 所有成员都在拼命寻求安全感, 一件注定看不到合理收益的事儿, 基本上不是富二代, 没人敢于去作的...而不是不会..
2: 中国企业....
>>
>>
>> 所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
>> 0: 开源, 为了消除各种 diss
>> 1: 开源, 为了吸引更多开发者
>> 2: 社区, 服务于开源开发模式
>>
>> 但是, 这几点前提, 却有一系列更加高层的条件:
>> 0: 必须按照计划, 及时交付可用稳定版本
>> 1: 必须有优先吻合对应硬件的核心功能
>> 2: 必须有打动更多厂商的特性
>>
>> 那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
>
>
> 这是一个特别好的问题，这是现在特别困扰我的问题。
>
- 谁主张谁执行
- 构造生态的主体在企业
- 那么, 一切以企业述求为核心
- 何况, 企业又不可能真的将核心系统 100% 的开发都丢给社区吧
- 所以, 这就象中国经济建国以来的发展路线
- 企业军事化管理教堂式开始为主体
- 开源社区自由软件开发模式为补充
- 先开始, 慢慢的, 通过持续聚焦开发者, 直至社区开发者超过企业开发者很多倍,生产的代码也超过企业开发者时
- 才是困扰的开始...
>>
>> 这可能是大家比较关心的真实问题;
>>
>> 那么, 俺建议:
>> 0: 开源只是开发形式, 并不是管理机制
>> 1: 商业只是运营目标, 并不代表文化氛围
>> 2: 所以, 完全可以使用全套的开源许可证以及对应开发环境/流程,
>> 但是, 配上 HW 军事化管理机制,
>
>
> 军事化管理是建立在强有力的执行基础之上的，但是这对指挥者有很高的要求，
> 在需要创造性的解决问题的时候，如果不持续点燃基层员工的激情与思想火花，是很难取得成功的。
>
严肃,活泼,积极,主动
是的, 类似口号一直在各种领域都有,
其实, 这种目标非常容易解决:
0: 问问自己, 当前提出的功能有用嘛?有趣嘛? 有种嘛?
1: 如果没有, 为什么提出?
2: 为什么无用无趣无种的功能,一定要提出来逼大家开发?
Linux 为什么成功? 因为,无人看好个人作品能替代大公司的操作系统, 太有种了...
MongoDB 为什么成功? 因为无人看好 文档数据库能有什么应用场景, 可用起来太爽了根本没废话...
Python 为什么成功? 因为科学家们根本没时间学习复杂的专业开发语言, 长的最象自然语言又有这么多专业模块的 Python 当然成为首先语言....
所以, 从 HW 自身来说, 选择开发自己的移动 OS 是政治/市场/...多种博弈的结果,
可从开发者以及应用厂商看来:
- 重复制造一个国产轮子
- 等于自己的作品不得不重新开发一遍,还不一定有对应的收益
- 那么, 为什么选入精力?
所以, 想构建自己的开源社区生态,
首先就得从自己目标生态成员角度去思考, 分解问题, 并给出简洁的回答.
否则, 最好从行政路线, 强行要求所有相关院校/科系, 将学分划分一部分,指向相关研究和开发,
从内部人海战术, 坚持几年, 先有足够多自己系统的开发者,再建立开源社区.
否则, 想从已有生态中抢夺即有开发者, 太不现实了.
>>
>> 并对每一个有效贡献直接给予真实的回报: 奖金/算力/硬件/...
>> 也就是说, 用现代开源软件开发环境来容纳大型商业软件的开发过程,
>> 但是, 用上世纪中国特有的大会战组织形式, 来管理公司以外的海量开发者;
>
>
> 会战式的开发很难积累出可以持续发展的能力，就如现在的会战式开源想得最多的是要把代码开出来，但是开出来之后呢？
> 我们还会以会战的方式在哪不断完善开源项目吗？
>
嗯嗯嗯? 这结论怎么来的?
核工业
高铁
高速公路桥
运载火箭
...
大国重器, 纪录片中, 哪个领域的发展不是持续几十年的会战式投入?
成功的开源项目, 从全球视角来看, 不也是会战式的? 特别是 Ubuntu 大投入大产出, 定期交付...
已经将开源开发模式和闭源发行模式基本对等起来了...
开源一定要浪漫自由?
千万别被各种翻译误导了....
自由软件当年是迫不得已, 开源概念的提出也是迫不得已...
然后各种鼓吹, 更加是迫不得已...
黑猫白猫, 解决问题才是好猫...
用自己最擅长的能力来组建社区发展生态, 不被其它各种特殊场景中形成的特殊精彩迷惑,
形成, 有 HW 特色的开源社区生态, 才是有种有用有趣的目标吧.
>
>>
>>
>> 这样, 并不违背开源开发模式, 又能对开发过程强有力的管理,
>> 同时, 给予参与者真实动力;
>> 进一步的, 也因为必须作到开源的基本原则:
>> 对的代码, 才能合并
>> 也逼 HW 完成真正的能应对海量协同/提交行为的开源开发平台构建.
>
>
> 这是一个好的时代，如果在一年前我觉得大家不会去思考要和外界构建一个协同发展的平台，现在越来越多的人意识到生态价值。
> 但是要构建起我们期望的生态，还有很长的路要走。
>
>>
>>
>> 甚至于, 进一步的, 给开源世界带来有中国特色的会战式开源社区,
>>
>> 没毛病哪.
>>
>>
>>
>> --
>> life is pathetic, go Pythonic! 人生苦短, Python当歌!
>> 俺: http://zoomquiet.io
>> 授: http://creativecommons.org/licenses/by-sa/2.5/cn/
>> 怒: 冗余不做,日子甭过!备份不做,十恶不赦!
>> KM keep growing environment culture which promoting organization learning!
>
> 触发: http://2019.openi.org.cn/
> 文案: https://shimo.im/docs/wrtvHxhykq3DKRhP/
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“Open-Source-Community-Leadership-development”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到open-source-community-leader...@googlegroups.com。
> 要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/open-source-community-leadership-development/0d311960-96cb-4ea9-a6e1-76442fb344b1%40googlegroups.com。
willem.jiang
Dec 24, 2019, 10:46:16 PM12/24/19
to Open-Source-Community-Leadership-development
On Wednesday, December 25, 2019 at 10:30:50 AM UTC+8, Zoom.Quiet wrote:
willem.jiang <wille...@gmail.com> 于2019年12月25日周三 上午9:47写道：
>
> 这个问题聊的比较深入，我直接在原文中回复了。
>
是也乎,(￣▽￣)
必须的, 这才是列表真正的战斗力所在...
🤝 太同意了！
buttom-post 才是最优雅的讨论形式...
> On Tuesday, December 24, 2019 at 4:12:48 PM UTC+8, Zoom.Quiet wrote:
>>
>> 先说一下这几天回响在俺内心深处的偏见:
>> 中国人其实一直是地球上最擅长大规模协作的民族;
>> 古埃及/古印加/古... 都是靠血腥的奴隶制, 才能聚集上十万人的协作, 完成各种奇迹般的工程;
>> 进入现代, 随着各种技术和工具的高速发展, apollo 计划, 也仅仅涉及3万家企业, 就从无到有的将活人送到月球并安全返回...
>> 而同时代, 中国依然能用非常原始的通讯方式, 指挥上亿人, 联合完成一大批超级工程;
>>
>> 只是, 进行互联网时代后, 大型工程组织经验, 没能及时渗入 IT 行业,
>> 以及, 外国因为自由软件发展起来的开源开发模式, 变成了一种神奇的良方, 好象嘦用了,
>> 企业软件就一定能高速获得成功...
>>
>> 其实, 真的来分析开发效能, 开源模式并没强过闭源模式:
>> 证据之一, SMMI 起源领域的军用软件基础OS, VxWorks 一直是闭源软件,
>> 以及所有领域真正商用的高能软件, 多数都是闭源的,
>
>
> 高效协作的基础是建立在信息充分交流的基础上的， 闭源软件阻碍信息流动所带来的低效不知道你没有体验过。
> 以我自己之前06年参与的商业支持项目为例，我看到客户提到的问题到调研解决方案，实现解决方案花了2天， 但是等到补丁发布，用户再次确认花了两个月的时间，当我看到用户的反馈之后，我还需要花上半天的时间把我带回之前的解决问题的现场，用半天时间给出进一步的解决方案。 这样一来一回的沟通，充分让用户体验到了他买的支持的价值 ：）
>
...闭源软件阻碍信息流动所带来的低效...
这个假设在当前场景中已经不存在了:
- 闭源阻碍信息流动的原因, 不是闭源, 而是对应的商业模式
- 要知道, 闭源商业模式的赢利基础就是信息差, 所以, 天然将开发者和用户隔离了
- 现在讨论的开源会战模式, 开发者和用户都是 HW 自己, 哪儿来问题?
这部分要实现起来会很有挑战， 如果有内源的成功经验的话，演进到内外协作会有比较大的胜算。
- 另外, VxWorks/AUTO Desk 们为什么闭源成功? 因为信息流动在有些领域是有害的, 毕竟稳定为最高指标时,
信息不流动才是最好的, 这样才能在已知不变数据场景中持续优化功能;
- 所以, 以往闭源软件有自己的版本升级周期
- 只是时代在进化, 社会变化超过了闭源软件升级周期时, 就不得不加以改变了...
在我看来软件项目的难点是如何应对需求的变化，这个问题在《人件》这本书中已经有比较好的阐述了。
开源带来的生产力的提升让业界看到开源的价值，各大企业这才开始拥抱开源。
就好比现在我们的思想碰撞不是在办公室里，而是通过邮件，通过论坛在激烈的讨论。 这样的交流方式如果放在三十年前，是很难想象得到的。
>>
>> 只是进入云时代后, 为了更大规模的吸引用户, 以及减少软件许可证成本, 大公司才开始使用开源软件,
>> 主要目的也不过是为了将原先使用开源软件的用户吸引到商用服务平台中来而已....
>>
>> 为什么? 以 Linux 为例, 从1.0发布到真正开始大规模部署在商用场景中, 用了多少年?
>> 毕竟, 以纯粹兴趣驱动的大规模协作, 必然包含更多的冲突和决择, 也就等于包含更多管理成本和对应时间.
>
>
> 兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
> 现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
> 这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
>
...兴趣是激发人们创造性解决问题的最大动力...
对应的
收益是支持人们创造性持续解决问题的最大动力..
从可持续发展的角度来说，一定要解决商业层面的问题。Open Source这个词的提出也是在商业层面上的一种创新。
如果没有足够的收益, 解决问题的乐趣, 无法支持自己和家人有尊严的生活,
那么, 理智的人, 一定放弃解决问题, 而去制造问题...
所以, 有断言: 商业才是最好的慈善
我觉得这个和视野以及外部环境有很大的关系， 如果你每天接触到的都是重复的搬砖工作，很难跳出弱鸡循环。
在开源被越来越多人认同的今天，参与开源项目给大家了一个翻身的机会。
...红帽软件就雇佣了大量的开源开发人员
是的, 这也是俺建议的形式, 将自由开发模式和商业软件管理机制结合.
只是你忘记分析, 为什么 `...他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率`
原因归结到一点是信息的高效流动。
每一次的信息流动就可以产生更多有价值的信息，自然效率就很高了。
从我的经历来看，基于邮件的交流是被逼出来的，因为除此之外没有其他的选择。反观及时通信流行的今天，更多人会认为花上半个小时在邮件上进行讨论不如花上十分钟打个电话跟别人拉通一下直接了当。
- 没有多余会议
- 只有 bug list
- 以及自由的工作时间
自由软件开发模式, 和现在流行的远程办公模式有共通之处;
当然, 俺也没好意思多说中外差别:
0: 文化上西方早已进入个性经济时间, 加之社会福利制度确保好人能很容易生活下去, 那么多余时间先人到自己喜欢的事儿中,
毫无压力....特别是芬兰这种有半年极夜的国家, 程序猿比例非常高...
1: 中国还在中国特色社会主义建设中, 所有成员都在拼命寻求安全感, 一件注定看不到合理收益的事儿, 基本上不是富二代, 没人敢于去作的...而不是不会..
2: 中国企业....
要是放在十年前，我会很认同你的想法。
但是现在我看到很多成功的开源项目，他们不但能养活自己，而且也融入了主流开源社区，并且在借助风投的力量持续发展。
>>
>>
>> 所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
>> 0: 开源, 为了消除各种 diss
>> 1: 开源, 为了吸引更多开发者
>> 2: 社区, 服务于开源开发模式
>>
>> 但是, 这几点前提, 却有一系列更加高层的条件:
>> 0: 必须按照计划, 及时交付可用稳定版本
>> 1: 必须有优先吻合对应硬件的核心功能
>> 2: 必须有打动更多厂商的特性
>>
>> 那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
>
>
> 这是一个特别好的问题，这是现在特别困扰我的问题。
>
其实, 这个问题的提出模式已经决定了, 解决的切入点:
- 谁主张谁执行
- 构造生态的主体在企业
- 那么, 一切以企业述求为核心
- 何况, 企业又不可能真的将核心系统 100% 的开发都丢给社区吧
- 所以, 这就象中国经济建国以来的发展路线
- 企业军事化管理教堂式开始为主体
- 开源社区自由软件开发模式为补充
- 先开始, 慢慢的, 通过持续聚焦开发者, 直至社区开发者超过企业开发者很多倍,生产的代码也超过企业开发者时
- 才是困扰的开始...
现在我的担心问题还有如何聚集足够多的开发者，让这些开发者转换成为社区生力军。
会战意味这高强度的长期投入， 也许只有公司级别的项目才会有这样的机会。
但是对于很多不确定的创新项目来说，我们应该用什么样的策略来投入呢？
软件开发是一个手工活，让十个孕妇在一个月的时间里把孩子生出来事情觉得用会战的方式也很难解决得了。
当会战阶段性目标实现完了之后，就会出现大部队撤离的情况，这个时候我们积累的成果如何发扬光大。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到open-source-community-leadership-development+unsub...@googlegroups.com。
Zoom.Quiet
Dec 24, 2019, 11:33:56 PM12/24/19
to Open-Source-Community-Leadership-development
willem.jiang <willem...@gmail.com> 于2019年12月25日周三 上午11:46写道：
...
>>
>> ...闭源软件阻碍信息流动所带来的低效...
>> 这个假设在当前场景中已经不存在了:
>> - 闭源阻碍信息流动的原因, 不是闭源, 而是对应的商业模式
>> - 要知道, 闭源商业模式的赢利基础就是信息差, 所以, 天然将开发者和用户隔离了
>> - 现在讨论的开源会战模式, 开发者和用户都是 HW 自己, 哪儿来问题?
>
>
> 这部分要实现起来会很有挑战， 如果有内源的成功经验的话，演进到内外协作会有比较大的胜算。
>
>>
>> - 另外, VxWorks/AUTO Desk 们为什么闭源成功? 因为信息流动在有些领域是有害的, 毕竟稳定为最高指标时,
>> 信息不流动才是最好的, 这样才能在已知不变数据场景中持续优化功能;
>> - 所以, 以往闭源软件有自己的版本升级周期
>> - 只是时代在进化, 社会变化超过了闭源软件升级周期时, 就不得不加以改变了...
>>
>
> 在我看来软件项目的难点是如何应对需求的变化，这个问题在《人件》这本书中已经有比较好的阐述了。
是的, 只是, 需求为什么变化?
没有变化的需求为什么要被迫变化?
人件中, 对此也说过, 而且表示无能为力,
这点在开源软件开发过程中从根上解决了, 开发者只开发自己原意以及有意义的功能.
这当然比领导一抽风就要开发的脑残功能来的要少, 变化要稳定...
> 开源带来的生产力的提升让业界看到开源的价值，各大企业这才开始拥抱开源。
>
是也乎,(￣▽￣)
正好相反吧, 开源的生产力提升, 从来不是业界关注的东西,
开源的吸粉能力, 以及全民参与的欢乐感,
对流量为主的云服务, 异常重要...
当流量等于銭时, 谁能吸引更多流量, 谁胜出....
而开源本身的生产效能之低, 不得不发展出可以无限扩大参与的机制, 造成流量/关注比闭源要高几个量级...
> 就好比现在我们的思想碰撞不是在办公室里，而是通过邮件，通过论坛在激烈的讨论。 这样的交流方式如果放在三十年前，是很难想象得到的。
>
是也乎,(￣▽￣)
相反吧? 参考Free minix-like kernel sources for 386-AT - Google 网上论坛
https://groups.google.com/forum/#!msg/comp.os.minix/4995SivOl9o/GwqLJlPSlCEJ
在 web 为主的互联网成型之前, hacker 们就早已通过电话线和 mailling-list 建立起来宏大的社区,
一起开发/讨论/游戏/写作/...
只是, GUI 占领了大家的注意力后, 纯文本的交流界面退到背景中,
主要由主机与主机间自动化交流进行了..
但是, 以 GNU 计划为首, 所有历史超过15年的开源社区, 都保有 列表交流的习惯,
这也是为什么 google 一直不关闭 gmail 以及 googlegroups 的原因,
因为, 这个世界上交流质量最高, 而且一直非常活跃的思想交流,
依然在邮件, 在 mailing-list 中, 只是中国, 自己主动放弃了, 这一空间而已.
...
>> > 兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
>> > 现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
>> > 这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
>> >
>>
>> ...兴趣是激发人们创造性解决问题的最大动力...
>> 对应的
>> 收益是支持人们创造性持续解决问题的最大动力..
>
>
> 从可持续发展的角度来说，一定要解决商业层面的问题。Open Source这个词的提出也是在商业层面上的一种创新。
>
是也乎,(￣▽￣)
在俺看来, 开源的提出, 只是在 GNU 计划中, 自由软件开发者, 看不到未来可见收益时,
自我阉割了一定自由度后, 可以重新将自己融入商业开发中, 就象 Matirx 中主动要求重新回到母体那位一样;
而历史也证明了...
开源, 其实并没有自由...
>>
>>
>> 如果没有足够的收益, 解决问题的乐趣, 无法支持自己和家人有尊严的生活,
>> 那么, 理智的人, 一定放弃解决问题, 而去制造问题...
>>
>> 所以, 有断言: 商业才是最好的慈善
>
>
> 我觉得这个和视野以及外部环境有很大的关系， 如果你每天接触到的都是重复的搬砖工作，很难跳出弱鸡循环。
> 在开源被越来越多人认同的今天，参与开源项目给大家了一个翻身的机会。
>
是也乎,(￣▽￣)
这么论述没问题, 只是, 这个机会的阀值在哪儿, 大家心里是有数的
- 在 linux 1.0 之前, 可能我们投入半年业务时间就可以进入内核开发团队, 然后10年后, 变成各大厂商的核心
- 现在, Android 内核代码超过 当年 Linux 代码几万倍, 个人要努力多久可以翻身?
- 或是说, 现在的开源项目, 什么项目是个人可以参与就能翻身的?
- 这个概率从自由软件开始就非常低...
- 所以, 拿这种飘渺的自己都不相信的机会来激发广大厂外开发者...其效果当然不怎么样
>
>>
>> ...红帽软件就雇佣了大量的开源开发人员
>>
>> 是的, 这也是俺建议的形式, 将自由开发模式和商业软件管理机制结合.
>>
>> 只是你忘记分析, 为什么 `...他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率`
>
>
> 原因归结到一点是信息的高效流动。
> 每一次的信息流动就可以产生更多有价值的信息，自然效率就很高了。
> 从我的经历来看，基于邮件的交流是被逼出来的，因为除此之外没有其他的选择。反观及时通信流行的今天，更多人会认为花上半个小时在邮件上进行讨论不如花上十分钟打个电话跟别人拉通一下直接了当。
>
- musk 至今只邮件回复具体业务问题
- facebook 创始人也是...
- 技术领域的效率问题, 有技术手段解决, 但是, 意识上的误解不解决, 只能说是习惯使然, 而习惯是环境造成的...
- 从大学开始, 以往用邮件交作业, 现在也都是微信群了, 那你如何纠正这种习惯?
没错, 这就是俺一直想让大家分清什么是
- 野生自然开源项目
- VC 向工业开源项目
这两种开源社区和项目, 就象智人和现代人, 学术上都是人科人种,
可依存的基础/文化/目标 从根儿上就不同,
偏差的那 0.42% 基因, 才是要关注的,
而不是一定要混在一起讨论哪...
>
>>
>> >>
>> >>
>> >> 所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
>> >> 0: 开源, 为了消除各种 diss
>> >> 1: 开源, 为了吸引更多开发者
>> >> 2: 社区, 服务于开源开发模式
>> >>
>> >> 但是, 这几点前提, 却有一系列更加高层的条件:
>> >> 0: 必须按照计划, 及时交付可用稳定版本
>> >> 1: 必须有优先吻合对应硬件的核心功能
>> >> 2: 必须有打动更多厂商的特性
>> >>
>> >> 那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
>> >
>> >
>> > 这是一个特别好的问题，这是现在特别困扰我的问题。
>> >
>>
>> 其实, 这个问题的提出模式已经决定了, 解决的切入点:
>> - 谁主张谁执行
>> - 构造生态的主体在企业
>> - 那么, 一切以企业述求为核心
>> - 何况, 企业又不可能真的将核心系统 100% 的开发都丢给社区吧
>> - 所以, 这就象中国经济建国以来的发展路线
>> - 企业军事化管理教堂式开始为主体
>> - 开源社区自由软件开发模式为补充
>> - 先开始, 慢慢的, 通过持续聚焦开发者, 直至社区开发者超过企业开发者很多倍,生产的代码也超过企业开发者时
>> - 才是困扰的开始...
>>
>
> 现在我的担心问题还有如何聚集足够多的开发者，让这些开发者转换成为社区生力军。
>
是也乎,(￣▽￣)
俺目测, 你的担心只是成本问题...
可以简单的将这种担心变成成本计算就好:
0: 开源移动操作系统想快速成功, 大致需要多少开发者?
1: 内部核心开发者要多少? 外部社区开发者要多少? 管理外部社区开发者的内部管理员要多少?
2: 外部社区开发者投入开发, 平均需要多少周薪足以支持他全心投入?
3: 社区开发者从初级到核心开发者, 一般要多少时间?
4: 来自社区的核心开发者, 达到多少数量, 基本就可以形成足够自发吸引力令社区可以自驱动了?
这些数量, 对应 Ubuntu 社区都可以获得,
具体到 HW 的中国项目, 嘦分配一定全球开发者和国内开发者比例就好...
这样初步有个预算, 先执行, 就知道预计的转化率以及转化成本,
然后有针对性的优化转化,
很可能最后发现是土耳其的开发者转换成本最低开发效率最高...
一切, 都得在 run 起来之后实时观测才可能知道,
而在没开始之前, 就担心, 那是一点儿用也没用的哪...
...
>> > 会战式的开发很难积累出可以持续发展的能力，就如现在的会战式开源想得最多的是要把代码开出来，但是开出来之后呢？
>> > 我们还会以会战的方式在哪不断完善开源项目吗？
>> >
>>
>> ...会战式的开发很难积累出可以持续发展的能力...
>> 嗯嗯嗯? 这结论怎么来的?
>> 核工业
>> 高铁
>> 高速公路桥
>> 运载火箭
>> ...
>>
>> 大国重器, 纪录片中, 哪个领域的发展不是持续几十年的会战式投入?
>
>
> 会战意味这高强度的长期投入， 也许只有公司级别的项目才会有这样的机会。
是也乎,(￣▽￣)
当然的了, 难道现在对标的各种开源组织/项目, 那个不是大公司在支持的?
> 但是对于很多不确定的创新项目来说，我们应该用什么样的策略来投入呢？
这种东西现在为什么要支持?
> 软件开发是一个手工活，让十个孕妇在一个月的时间里把孩子生出来事情觉得用会战的方式也很难解决得了。
这才是误解吧...
现在大厂, 一起在思考以及实践的, 就是如何通过 AI 自动化生成业务代码,
将手工活尽可能减少几近无,
如果 HW 还在以 十个孕妇 还是 1000个孕妇 来思考大型软件工程...
那基本很难了...
> 当会战阶段性目标实现完了之后，就会出现大部队撤离的情况，这个时候我们积累的成果如何发扬光大。
>
是也乎,(￣▽￣) 这句陈述有很多梗哪:
0: 通过会战锻炼出来的部队是珍贵资源, 历史上怎么处理的?
1: 撤离到哪? 当然是另外一个会战哪
2: 积累的成果是什么? 是软件哪, 软件是什么?自动化工具哪? 工具如何发扬光大? 用哪
当然,这里涉及到一个 KM 问题
- 会战过程中, 从组织到开发工具各种层面形成的全新知识
- 如何有效变成新人/项目/工程, 可以有效复用的形式/机制?
- 一次会战后, 积累的成果中, 什么是价值最高的? 是有形的代码, 还是积累下来的声望和信心?
- 为谁发扬? 光大什么?
这些都是常识性的问题, 现在才问出来, 可以说, 非常迟到了...
....
>> >
>> > 这是一个好的时代，如果在一年前我觉得大家不会去思考要和外界构建一个协同发展的平台，现在越来越多的人意识到生态价值。
>> > 但是要构建起我们期望的生态，还有很长的路要走。
>> >
还是那个根本问题: 什么是生态?
一个生态研究是如何形成的?
这个问题, 没形成共识, 一切以生态为目标的努力都是乱来.
...
>>
>> ...闭源软件阻碍信息流动所带来的低效...
>> 这个假设在当前场景中已经不存在了:
>> - 闭源阻碍信息流动的原因, 不是闭源, 而是对应的商业模式
>> - 要知道, 闭源商业模式的赢利基础就是信息差, 所以, 天然将开发者和用户隔离了
>> - 现在讨论的开源会战模式, 开发者和用户都是 HW 自己, 哪儿来问题?
>
>
> 这部分要实现起来会很有挑战， 如果有内源的成功经验的话，演进到内外协作会有比较大的胜算。
>
>>
>> - 另外, VxWorks/AUTO Desk 们为什么闭源成功? 因为信息流动在有些领域是有害的, 毕竟稳定为最高指标时,
>> 信息不流动才是最好的, 这样才能在已知不变数据场景中持续优化功能;
>> - 所以, 以往闭源软件有自己的版本升级周期
>> - 只是时代在进化, 社会变化超过了闭源软件升级周期时, 就不得不加以改变了...
>>
>
> 在我看来软件项目的难点是如何应对需求的变化，这个问题在《人件》这本书中已经有比较好的阐述了。
没有变化的需求为什么要被迫变化?
人件中, 对此也说过, 而且表示无能为力,
这点在开源软件开发过程中从根上解决了, 开发者只开发自己原意以及有意义的功能.
这当然比领导一抽风就要开发的脑残功能来的要少, 变化要稳定...
> 开源带来的生产力的提升让业界看到开源的价值，各大企业这才开始拥抱开源。
>
是也乎,(￣▽￣)
正好相反吧, 开源的生产力提升, 从来不是业界关注的东西,
开源的吸粉能力, 以及全民参与的欢乐感,
对流量为主的云服务, 异常重要...
当流量等于銭时, 谁能吸引更多流量, 谁胜出....
而开源本身的生产效能之低, 不得不发展出可以无限扩大参与的机制, 造成流量/关注比闭源要高几个量级...
> 就好比现在我们的思想碰撞不是在办公室里，而是通过邮件，通过论坛在激烈的讨论。 这样的交流方式如果放在三十年前，是很难想象得到的。
>
相反吧? 参考Free minix-like kernel sources for 386-AT - Google 网上论坛
https://groups.google.com/forum/#!msg/comp.os.minix/4995SivOl9o/GwqLJlPSlCEJ
在 web 为主的互联网成型之前, hacker 们就早已通过电话线和 mailling-list 建立起来宏大的社区,
一起开发/讨论/游戏/写作/...
只是, GUI 占领了大家的注意力后, 纯文本的交流界面退到背景中,
主要由主机与主机间自动化交流进行了..
但是, 以 GNU 计划为首, 所有历史超过15年的开源社区, 都保有 列表交流的习惯,
这也是为什么 google 一直不关闭 gmail 以及 googlegroups 的原因,
因为, 这个世界上交流质量最高, 而且一直非常活跃的思想交流,
依然在邮件, 在 mailing-list 中, 只是中国, 自己主动放弃了, 这一空间而已.
...
>> > 兴趣是激发人们创造性解决问题的最大动力。开源软件带来的最大好处是让大家的微创新变得更加容易。
>> > 现在业界已经有很多拿着工资的专职开源开发人员，之前我所工作过的红帽软件就雇佣了大量的开源开发人员。
>> > 这些开发人员大多是项目的maintainer，他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率。
>> >
>>
>> ...兴趣是激发人们创造性解决问题的最大动力...
>> 对应的
>> 收益是支持人们创造性持续解决问题的最大动力..
>
>
> 从可持续发展的角度来说，一定要解决商业层面的问题。Open Source这个词的提出也是在商业层面上的一种创新。
>
在俺看来, 开源的提出, 只是在 GNU 计划中, 自由软件开发者, 看不到未来可见收益时,
自我阉割了一定自由度后, 可以重新将自己融入商业开发中, 就象 Matirx 中主动要求重新回到母体那位一样;
而历史也证明了...
开源, 其实并没有自由...
>>
>>
>> 如果没有足够的收益, 解决问题的乐趣, 无法支持自己和家人有尊严的生活,
>> 那么, 理智的人, 一定放弃解决问题, 而去制造问题...
>>
>> 所以, 有断言: 商业才是最好的慈善
>
>
> 我觉得这个和视野以及外部环境有很大的关系， 如果你每天接触到的都是重复的搬砖工作，很难跳出弱鸡循环。
> 在开源被越来越多人认同的今天，参与开源项目给大家了一个翻身的机会。
>
这么论述没问题, 只是, 这个机会的阀值在哪儿, 大家心里是有数的
- 在 linux 1.0 之前, 可能我们投入半年业务时间就可以进入内核开发团队, 然后10年后, 变成各大厂商的核心
- 现在, Android 内核代码超过 当年 Linux 代码几万倍, 个人要努力多久可以翻身?
- 或是说, 现在的开源项目, 什么项目是个人可以参与就能翻身的?
- 这个概率从自由软件开始就非常低...
- 所以, 拿这种飘渺的自己都不相信的机会来激发广大厂外开发者...其效果当然不怎么样
>
>>
>> ...红帽软件就雇佣了大量的开源开发人员
>>
>> 是的, 这也是俺建议的形式, 将自由开发模式和商业软件管理机制结合.
>>
>> 只是你忘记分析, 为什么 `...他们（4，5个人）在有效的协调社区开发资源的生产力是可以媲美 IBM 几十人规模的商业开发团队的效率`
>
>
> 原因归结到一点是信息的高效流动。
> 每一次的信息流动就可以产生更多有价值的信息，自然效率就很高了。
> 从我的经历来看，基于邮件的交流是被逼出来的，因为除此之外没有其他的选择。反观及时通信流行的今天，更多人会认为花上半个小时在邮件上进行讨论不如花上十分钟打个电话跟别人拉通一下直接了当。
>
- facebook 创始人也是...
- 技术领域的效率问题, 有技术手段解决, 但是, 意识上的误解不解决, 只能说是习惯使然, 而习惯是环境造成的...
- 从大学开始, 以往用邮件交作业, 现在也都是微信群了, 那你如何纠正这种习惯?
>
>>
>>
>> - 没有多余会议
>> - 只有 bug list
>> - 以及自由的工作时间
>>
>> 自由软件开发模式, 和现在流行的远程办公模式有共通之处;
>>
>> 当然, 俺也没好意思多说中外差别:
>> 0: 文化上西方早已进入个性经济时间, 加之社会福利制度确保好人能很容易生活下去, 那么多余时间先人到自己喜欢的事儿中,
>> 毫无压力....特别是芬兰这种有半年极夜的国家, 程序猿比例非常高...
>> 1: 中国还在中国特色社会主义建设中, 所有成员都在拼命寻求安全感, 一件注定看不到合理收益的事儿, 基本上不是富二代, 没人敢于去作的...而不是不会..
>> 2: 中国企业....
>>
> 要是放在十年前，我会很认同你的想法。
> 但是现在我看到很多成功的开源项目，他们不但能养活自己，而且也融入了主流开源社区，并且在借助风投的力量持续发展。
>
是也乎,(￣▽￣)
>>
>>
>> - 没有多余会议
>> - 只有 bug list
>> - 以及自由的工作时间
>>
>> 自由软件开发模式, 和现在流行的远程办公模式有共通之处;
>>
>> 当然, 俺也没好意思多说中外差别:
>> 0: 文化上西方早已进入个性经济时间, 加之社会福利制度确保好人能很容易生活下去, 那么多余时间先人到自己喜欢的事儿中,
>> 毫无压力....特别是芬兰这种有半年极夜的国家, 程序猿比例非常高...
>> 1: 中国还在中国特色社会主义建设中, 所有成员都在拼命寻求安全感, 一件注定看不到合理收益的事儿, 基本上不是富二代, 没人敢于去作的...而不是不会..
>> 2: 中国企业....
>>
> 要是放在十年前，我会很认同你的想法。
> 但是现在我看到很多成功的开源项目，他们不但能养活自己，而且也融入了主流开源社区，并且在借助风投的力量持续发展。
>
没错, 这就是俺一直想让大家分清什么是
- 野生自然开源项目
- VC 向工业开源项目
这两种开源社区和项目, 就象智人和现代人, 学术上都是人科人种,
可依存的基础/文化/目标 从根儿上就不同,
偏差的那 0.42% 基因, 才是要关注的,
而不是一定要混在一起讨论哪...
>
>>
>> >>
>> >>
>> >> 所以, 简单的说, 以 HW 开源移动OS 项目为假设目标:
>> >> 0: 开源, 为了消除各种 diss
>> >> 1: 开源, 为了吸引更多开发者
>> >> 2: 社区, 服务于开源开发模式
>> >>
>> >> 但是, 这几点前提, 却有一系列更加高层的条件:
>> >> 0: 必须按照计划, 及时交付可用稳定版本
>> >> 1: 必须有优先吻合对应硬件的核心功能
>> >> 2: 必须有打动更多厂商的特性
>> >>
>> >> 那么, 这种商业气息浓重的KPI 和开源技术社区比较散漫的氛围如何调和?
>> >
>> >
>> > 这是一个特别好的问题，这是现在特别困扰我的问题。
>> >
>>
>> 其实, 这个问题的提出模式已经决定了, 解决的切入点:
>> - 谁主张谁执行
>> - 构造生态的主体在企业
>> - 那么, 一切以企业述求为核心
>> - 何况, 企业又不可能真的将核心系统 100% 的开发都丢给社区吧
>> - 所以, 这就象中国经济建国以来的发展路线
>> - 企业军事化管理教堂式开始为主体
>> - 开源社区自由软件开发模式为补充
>> - 先开始, 慢慢的, 通过持续聚焦开发者, 直至社区开发者超过企业开发者很多倍,生产的代码也超过企业开发者时
>> - 才是困扰的开始...
>>
>
> 现在我的担心问题还有如何聚集足够多的开发者，让这些开发者转换成为社区生力军。
>
俺目测, 你的担心只是成本问题...
可以简单的将这种担心变成成本计算就好:
0: 开源移动操作系统想快速成功, 大致需要多少开发者?
1: 内部核心开发者要多少? 外部社区开发者要多少? 管理外部社区开发者的内部管理员要多少?
2: 外部社区开发者投入开发, 平均需要多少周薪足以支持他全心投入?
3: 社区开发者从初级到核心开发者, 一般要多少时间?
4: 来自社区的核心开发者, 达到多少数量, 基本就可以形成足够自发吸引力令社区可以自驱动了?
这些数量, 对应 Ubuntu 社区都可以获得,
具体到 HW 的中国项目, 嘦分配一定全球开发者和国内开发者比例就好...
这样初步有个预算, 先执行, 就知道预计的转化率以及转化成本,
然后有针对性的优化转化,
很可能最后发现是土耳其的开发者转换成本最低开发效率最高...
一切, 都得在 run 起来之后实时观测才可能知道,
而在没开始之前, 就担心, 那是一点儿用也没用的哪...
...
>> > 会战式的开发很难积累出可以持续发展的能力，就如现在的会战式开源想得最多的是要把代码开出来，但是开出来之后呢？
>> > 我们还会以会战的方式在哪不断完善开源项目吗？
>> >
>>
>> ...会战式的开发很难积累出可以持续发展的能力...
>> 嗯嗯嗯? 这结论怎么来的?
>> 核工业
>> 高铁
>> 高速公路桥
>> 运载火箭
>> ...
>>
>> 大国重器, 纪录片中, 哪个领域的发展不是持续几十年的会战式投入?
>
>
> 会战意味这高强度的长期投入， 也许只有公司级别的项目才会有这样的机会。
当然的了, 难道现在对标的各种开源组织/项目, 那个不是大公司在支持的?
> 但是对于很多不确定的创新项目来说，我们应该用什么样的策略来投入呢？
这种东西现在为什么要支持?
> 软件开发是一个手工活，让十个孕妇在一个月的时间里把孩子生出来事情觉得用会战的方式也很难解决得了。
这才是误解吧...
现在大厂, 一起在思考以及实践的, 就是如何通过 AI 自动化生成业务代码,
将手工活尽可能减少几近无,
如果 HW 还在以 十个孕妇 还是 1000个孕妇 来思考大型软件工程...
那基本很难了...
> 当会战阶段性目标实现完了之后，就会出现大部队撤离的情况，这个时候我们积累的成果如何发扬光大。
>
是也乎,(￣▽￣) 这句陈述有很多梗哪:
0: 通过会战锻炼出来的部队是珍贵资源, 历史上怎么处理的?
1: 撤离到哪? 当然是另外一个会战哪
2: 积累的成果是什么? 是软件哪, 软件是什么?自动化工具哪? 工具如何发扬光大? 用哪
当然,这里涉及到一个 KM 问题
- 会战过程中, 从组织到开发工具各种层面形成的全新知识
- 如何有效变成新人/项目/工程, 可以有效复用的形式/机制?
- 一次会战后, 积累的成果中, 什么是价值最高的? 是有形的代码, 还是积累下来的声望和信心?
- 为谁发扬? 光大什么?
这些都是常识性的问题, 现在才问出来, 可以说, 非常迟到了...
....
>> >
>> > 这是一个好的时代，如果在一年前我觉得大家不会去思考要和外界构建一个协同发展的平台，现在越来越多的人意识到生态价值。
>> > 但是要构建起我们期望的生态，还有很长的路要走。
>> >
一个生态研究是如何形成的?
这个问题, 没形成共识, 一切以生态为目标的努力都是乱来.
Reply all
Reply to author
Forward
0 new messages