SN-Machine-01

作为CopyCenter协议的内容，LitC并不强制要求开发者一定使用该类工具
只不过，对于面向科学研究的工程师与科学家来说，多数人员并没有精力完全投入到Coding当中，其有限的精力应当重点关注各自研究领域的议题
例如材料科学问题、粉体科学问题等，所谓术业有专攻。
那么，使用LitC组件能够极大节约这些科研工作人员的精力，使得其更多思考于本专业，而不是计较Coding的细节

多数科研工作者并不是真正意义上专业的程序开发人员，这就好比技能树，这些科研人员的核心技能应点在其专业领域。
而对于Coding领域，多数科研工作者只要不出错，就已经是十分优秀的了，毕竟术业有专攻。
另外，大多数科研微型工具的应用领域十分狭窄，受众十分稀少，客观说，黑客不值得承担风险破解，故而也可以看到，大多数工业软件，特别是涉及行业内的专有工具，其安全设计并不考究

因而，我们认为开发者应当将精力投入于如何提高软件核心用途的效能，而不是放在辅助措施上，特别这对于一些冷门的专有工具。
实际上，行业内的用户范围有限，授权机制更像是一种君子协定，而不是要求理论上的无懈可击。
过分追求安全设计，可能会让软件负重前行，这就本末倒置了。

更有甚者，一些工具的防盗措施非常bug，正版用户甚至需要采购license后再用破解版执行任务。
所谓的正版，因为高超的安全机制而变得非常难用。其使得用户成为了完美的【正版软件受害者】。
此时，这种方式是否显得滑稽了？

未来的工业软件一定会走向服务模式，一份正版的授权，不仅仅是许可用户使用功能，更重要的是提供技术支持。
因此从这一点来看，正版的订单重要性，远远比授权的理论安全性高得多。
而服务必然来自于真实的订单，破解用户是不会享有的。
然而，一份能够被破解应用的软件，这说明至少是有广泛的需求的，那么与其相关的核心技术服务必然具有高价值。

故而，刚入行的新人开发者，特别是对于专业领域的年轻科学家、工程师，你们在专业领域的知识要远远比代码水平重要。
你们应该在自己的领域，将代码视为工具去勇往直前地应用，而不宜掉落在讨论Coding优雅的天坑中耗散掉精力。

当你的项目足够复杂，足够宏大，必须需要可能几十人、上百人的团队来维护，且面临着复杂的用户服务时。
换言之，简易的授权方案已经成为了阻碍进一步扩大用户规模的障碍时。此时才是讨论精妙的授权技术之时。