无论是论坛还是群组,关于动作加密的呼声连连。
这里我发表我的观点和论据,请大家理性讨论,请 @CL 独立思考,决策。
观点
我反对动作加密。
解决方案
- 变量加密。保护私有api等数据;
- 如果动作开发者想要盈利,可以考虑不公开分享,私有付费发布。或者通过嵌套子程序来加大他人了解动作的难度(因为Quicker编辑器不支持多窗口多模块同时运作,这种单线的设计一日未解决,都可以用来起到加大阅读难度的作用)。
论据
- 知识产权;
- 盈利
就好比我辛苦做的作业,不能随便给别人看。这是应该的。
- 动作加密将使得开放交流、新人通过研究已有动作学习动作开发的学习曲线更加曲折
- 现在的动作库就好比油猴上的脚本分享,比如 GreasyFork等平台。想要学习脚本开发的人可以在 GreasyFork上阅读已有脚本来加深对 Javascript 的理解,这种方式能够帮助新人了解开发,便于提高他们的开发能力。
我原本也不熟悉开发,但我通过阅读动作、文档和社区请教前辈们,一步一脚印地开发了些动作。其中,已有动作的参考在我遇到开发难题时提供非常大的帮助。思路的启发是动作开发的关键环节,想法很多,但如何实现才是最困难的地方。已有动作的阅读能够在实现思路和过程上提供极为有效的帮助。
我想,各位专业开发者应该知道想要精进编程,阅读优秀代码是一个选择。同样,动作的开放将能够培养通过阅读动作增强动作开发能力的新开发者。他们在开放动作的阅读和自己的努力最终能够反哺社区。
所以,这里我想讨论的是。加密动作将不便于他人通过阅读动作来提高自己的开发能力。当然,真心想要开发动作的人也可以通过阅读文档、看书和自己摸索钻研来培养自己的开发能力,但是这种方式将提高他们的学习难度。
其次,动作加密后,整个 Quicker 动作库自然会从 GreasyFork 这样开放的开源社区过渡到 像 Google play、App store和微软商城那样的应用分布商城,当然Quicker也可以阅读没有设置加密的动作,这是根据开发者决定的。这时候,如果动作收费功能也做了之后,Quicker动作库将会从中抽成。这对于开发者来说,有盈利;对于 @CL 来说,除了软件授权外增加收费动作抽成的盈利来源。
- 开发者的盈利
我理解开发者想要通过设计高级动作,并且付费来赚取外快。这是能够理解并且赞同的。
就好比不能要求软件开发者只做开源软件,开源软件尚且拥有多个盈利渠道,比如开源收费或开源免费,支持收费。Quicker目前还是集中在零售,对公业务还没成熟的商业模式。
结论
- 反对动作加密,可以变量加密或者通过嵌套来加大逆向的难度。不反对开发者盈利需求;
- 动作流程的开放能够帮助新人通过阅读动作来提高他们的开发能力;
尾声
- 动作是否加密最终是由 @CL 决定。我们的讨论只是辅助 @CL 独立思考的决策参考。
- 目前 Quicker 诞生两年左右,正在获取市场的前期冲刺,这种情况下,完善 Quicker ,通过 Quicker 成熟和完善度, 增加动作库的高级动作和整体动作数量,建立生态圈,让用户熟悉并且对Quicker 形成依赖,提高以后竟品的获客成本是关键。
短期来看,Quicker 保不全会搁置 动作加密 和 动作收费 这块。增量市场的市场占有率是关键,跑马圈地,形成细分领域的领头羊更加重要,这时候,可以通过开源开放的社区来获取口碑和人气。等到市场变成存量市场后再通过偏向开发者,引入动作加密和付费的支持。
但是,引进动作加密和付费并不和 Quicker 的市场开发有冲突。反而可能吸引一批为了盈利和认同 Quicker 对动作产权保护的开发者,深入开发各种更加复杂和高级的动作。
- 动作加密和收费并不冲突。是类似 GreasyFork 那样的开源开放脚本分享平台还是免费和收费并存的应用商城,取决于 @CL 对于 Quicker动作库未来演化的愿景。
是所有用户一视同仁,建立一个动作开源、开放的动作库还是一个允许商业化、通过加密和付费激励核心动作开发者持续开发的动作库,是一个取舍的问题,而非绝对对错的问题。
感谢
- 期待 Quicker动作库未来的演变,也期待 Quicker 以后的发展。感谢 Quicker 带来的价值;
- 感谢动作开发者们分享的动作,便利我的电脑使用体验和提供在动作设计过程中的实现思路启发;
- 感谢社区的各位解答新人的疑问,互相交流。
子程序嵌套子程序不是为了加大你们的理解难度,是为了方便开发
目前 Quicker 编辑器有一定的限制,比如不能多开编辑器模块,限制在一个模块,其他编辑窗口无法响应;子程序无法展开,而是需要新窗口打开,子程序中的子程序就无法继续编辑打开,需要换到其他动作编辑窗口中继续看。
基于此,我想到可以通过子程序嵌套来加大阅读难度。但我原文描述有误,感谢指出,我已改正。
在加大阅读难度方面我已经制作了 用来混淆动作的 动作,只不过没有发布
是的,想要拒绝他人阅读自己代码的方式有很多。最好的方式还是官方支持加密。否则的话,加入没用动作的混淆或子程序嵌套是不错的思路。
尽管我不是很支持拒绝他人阅读自己动作的方式,但我也能理解你的出发点。