反对动作加密 - 动作加密是Quicker动作库在演变成油猴脚本分享平台还是应用商城的分岔口

功能建议 · 2032 次浏览
Poto 创建于 2020-08-24 18:06

无论是论坛还是群组,关于动作加密的呼声连连。
这里我发表我的观点和论据,请大家理性讨论,请 @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 带来的价值;
  • 感谢动作开发者们分享的动作,便利我的电脑使用体验和提供在动作设计过程中的实现思路启发;
  • 感谢社区的各位解答新人的疑问,互相交流。
Poto 最后更新于 2020/8/24

Cesar 2020-08-24 18:09 :

子程序嵌套子程序不是为了加大你们的理解难度,是为了方便开发

Poto 回复 Cesar 2020-08-24 18:19 :

目前 Quicker 编辑器有一定的限制,比如不能多开编辑器模块,限制在一个模块,其他编辑窗口无法响应;子程序无法展开,而是需要新窗口打开,子程序中的子程序就无法继续编辑打开,需要换到其他动作编辑窗口中继续看。


基于此,我想到可以通过子程序嵌套来加大阅读难度。但我原文描述有误,感谢指出,我已改正。

Cesar 回复 Poto 2020-08-24 18:26 :

在加大阅读难度方面我已经制作了 用来混淆动作的 动作,只不过没有发布

Poto 回复 Cesar 2020-08-24 18:37 :

是的,想要拒绝他人阅读自己代码的方式有很多。最好的方式还是官方支持加密。否则的话,加入没用动作的混淆或子程序嵌套是不错的思路。

尽管我不是很支持拒绝他人阅读自己动作的方式,但我也能理解你的出发点。

回复内容
Poto 2020-08-24 18:21
#1

原文受限于我的眼界和对开发的认知程度,可能存在歧义和荒诞的说法,欢迎大家指出、指教

FanXiang 2020-08-25 14:15
#2

我不赞成动作加密的原因是,有很多动作对于用户来说并不是完全符合自己的需求,但只要根据自己的需求稍微修改一点内容就正好符合,这种情况你去找动作的作者反馈的话,对于作者来说也是众口难调,作者也不能根据每一个人的需求都做出修改。


wzq 2020-08-26 09:23
#3

我个人也是不建议动作加密,赞成楼上观点,而且加密不利于平台交流,开源的环境有利于成长。至于说隐私什么的,既然你这么在意别人看了你的代码,你不分享不就完了;既然分享了,有人能从你代码里面获取到灵感说声谢谢,难道没有成就感吗?

wzq 2020-08-26 09:24 :

再还有一点,你都加密了,鬼知道你里面写了些什么,要是写了什么垃圾东西,给别人造成了损失,这个责任谁担?

Ever 2020-09-19 15:44
#4

现在分享分为:公开、不公开。加密就好像是“半公开”。

回复主贴