UIXX

最后回复。

我觉得有一种思维方式可以让 OP 迅速判断你适不适合这样做：

假设你已经有一套与大厂开源品质差不多代码，接下来该怎么干？

@nothingistrue 我是说有商业企图的项目想开源的考虑，并没有说项目一定要商业企图，这不是充分必要条件。
你所说的只是社区里面的一些例子，整个开源社区不单只是纯软件，也有硬件、设计领域的，每个公司的规范不一样，但商业逻辑是类似的。

我稍微看了下跟贴，很多人将开源与商业放到一个层面上讲，有误区，这两个是不同领域的考量。假定某个项目有商业企图，那么与是否开源直接相关的是商业模式，而非预期的项目盈利状况。

比如我定制了一个核心板的系统并开源，并不是说该系统里面的技术不深、小众、难以变现，才作出这个决定。我可能有以下的商业布局：
- 明面上是引导大众参与（甚至是无视友商抄袭），实际上是潜移默化地确立某项重要的业界标准。
- 表层是宣传核心板，实际是推高外围插件销量。
- 咋看之下是技术分享，实际上是在钓鱼，利用开源社区降低试错成本。

开源就是种手段，而非目的，我们技术人似乎把它抬得太高了。

-----------------------------

另外，低代码开源平台有没搞头，取决于运营而非技术。

我就在干这事，做的工业软件。

有先发优势最好，没有先发优势就拼生产力，生产力跟不上就打差异化。正面搏杀毫无胜算，我现在走的是第三条路子。

---------------------------

开源是否可以当事业做？取决于项目性质。长话短说，按优先级排

- 这个开源项目有没有足够的试错成本？
- 这个开源项目有没有靠谱的盈利模式？
- 这个开源项目是否有足够的技术深度？

OP 的问题可以总结为：能否省略或者压缩流式响应中的元数据。

我的看法倾向于 8L 的观点，这个接口输出被设计成通用性更强、结构更明显的 chunk 形式，方便调用者直接使用。将其他形式的输出实现交给二次开发者。

老生常谈，程序员付出了更多时间跟精力无法获得实质回报...

我一般将这类问题归为，系统性管理问题。之前的帖子有讨论过。

我以为这种事情只会发生在大龄程序员身上。

遇到过一模一样的场景，对方是近二十年 C 龄的老兵，编码能力没得说，就是本身野路子过来的，工程习惯长时间没跟时代接轨。（根本不知道 git 是什么）

-------------------------------------------------------

个人觉得问题不大，除非对方真的特别顽固。

@lmmir

总结一下：

如果需要自行实现一套跟 CSGO 类似的物品预览程序，就是模型+贴图+着色器，磨损的效果由贴图跟着色器共同决定。磨损的数值会影响明暗，这个可由着色器实现，也可由贴图+某些磨损生成器生成（不过到了前端，这部分已经固定）。 [这里不讨论特殊皮肤，特殊皮肤的效果呈现受多种因素影响]

如果想要做一个跟 CSGO 内置一模一样的预览，建议使用 CSGO 的 workshop workbench 。

@lmmir

那你不是从零做普通的模型预览，而是做跟官方 market 一样的效果。直接用控制台里面的工作台你就能明白很多东西是怎么实现的了。