可以做，都可以做，这是你的自由

您的自由。

开源相当于把设计图纸给你，开源许可证就是你用了图纸或者改了图纸以后是不是要把图纸再公开的问题。关键是您读不读得懂图纸。。。

我建议不要有人再回复了，浪费时间。

说到底你还是太过于迷信开源了，当然这也是咱们考虑问题所站的角度不同而已，但我始终认为，防患于未然是必要的。

你还是没明白这个问题，标准的制定不难，你我都可以制定，问题是标准的实施。

我从未说过“不优秀的企业不允许/不能/不应该制定标准”，但是你的标准能否被人接受就是实实在在地看你的影响力。

请不要将“能不能”做某些事情和“要不要”做某些事情混为一谈，这是两个问题。“能不能”是看你的能力，而“要不要”是看这件事情值不值得你为此付出。“推倒重建”要比“从头开始”更难，因为这需要你抛弃过去积累的成就。在经济学上，“没赚够本应该赚的钱”就属于亏损。你重新开始另立门户，放弃过去的标准，实际上也要算进你的成本里。你的收益是回报与付出的差值。如果做这件事的投入大于回报，那做这件事就是“不划算的”

至于debian和redhat系的包管理孰优孰劣，这个是另外的话题。但是经过长期的发展，结果是：1.他们走的路线是不同的并且难以兼容；2.双方都积攒了相当体系的软件生态、下游发行版以及支持者；3.双方发展的土壤——自由（开源）软件，完全可以兼顾支持两者而非二选一，不存在你死我活的生存争斗或者必须借助对方生态来开疆扩土之需。因此只要冷静下来仔细分析就会明晰他们选择的理由。

只说deepin，deepin的发展已经做出了相当大的变革，前Linux的时代不提，之后的几次转变：从使用现成的应用程序到自研桌面环境（积攒了相当的口碑）；从ubuntu换成基于debian（破坏了原来的使用体验，并且产生了一系列的后遗症）；软件源与上游分离（被抱怨软件版本太旧、新硬件也支持不好）；重新设计用户界面（被骂了一整年，而且花费了很长时间打磨用户界面而没有推出更有价值的功能）等。我并不认为deepin这些改变是没有价值的，提出这些案例旨在表明：更换一个成熟的设计，不异于伤筋动骨。而楼主所提出的这个设想，不仅没有足够的利益来支撑，也不与deepin的发展策略和目标相关；如果你从根源上去改deepin的目录结构，相当于要抛弃现有的几乎全部资源、软件生态和工作成果；如果你不去改系统的包管理设计，而是只把deb包换层皮改个名字，木兰语言、红芯浏览器就在对岸等着你。

还觉得linux下的软件包格式不够多吗？一个打包方式而已，别以为一个打包方式特立独行了就等于标准自主了？标准自主的前提是你够强大，否则你自己定一个标准自嗨，没人认可和拥护，有什么用？

生态都没搞好就造新包格式不就是等死吗...现在光是现成的debian标准都要求人开发

deb就是个压缩文件，和zip,rar之类的没有本质区别。那么，我们平时那么频繁地使用zip压缩文件，为什么我们不担心有一天zip文件会被封锁呢？

严重同意这个意见，为啥要搞统信？就是要统一平台，统一标准，这样不同开发者基于统一标准开发就不用个别适配，任意一台机器拿来就能安装，安装就能使用，不用再去单独为具体的机器去改代码。

deb 跟 rpm 就是个压缩包而已.这还能被制裁吗?像pacman 系的都直接用压缩包的格式了,比如 tar.xz,tar.zst 之类的.

deepin 自己再重新搞一个规范真是费力不讨好.

天哪，现在连生态都没完善，就定标准，谁理你啊。

这就是空想，毫无意义啊。

• 大多数的源码包都可以编译安装
• 我们是否可以针对DEEPIN 的环境进行一个源维护「并找到一个管理这些的源编译的的管理方式」
• 大多编译后的二进制，我们可以在源中提供编译好的依赖二进制，
• 在本地进行安装编译时候，进行拉回这些二进制文件并指向其版本
• 进行社区维护测试
• 提供上传审核测试入口

我绝的LINUX 很多源码开源软件MAKE或者其它构建之后，就是通过环境变量即可，就是一个绿色的，完全可以用压缩包，但是这个二进制文件可能不适合DEEPIN ，我们是否应为维护一个源，提供社区提交入口，测试等等

不急，饭要一口一口吃，正如前面那位老哥说的，制定标准谁都可以，但别人遵不遵守是另一回事了，只要影响力大了，才有更多的软件公司和个人开发者加入。