你们有没有想过创建一个插件和主题的市场?

您们有没有想过创建一个插件和主题市场?

提出此问题的原因

  1. Discourse 允许开发者创建主题和插件。这非常有趣。我想问的是,Discourse 内部是否有付费插件和主题的市场?例如,我想创建付费主题和插件。因为我可以为我为 Discourse 开发的插件和主题获得报酬。Themeforest 是一个很好的例子,你可以创建一个网站,如果有人喜欢你的网站,你就可以通过在 Themeforest 上销售该特定网站来赚钱。

  2. 在我看来,我会在 Discourse 内向特定客户或公司销售我的插件和主题。我认为这个想法的好处是可以鼓励更多开发者为 Discourse 创建更多插件和主题,并集成更多服务、公司和客户。换句话说,这只是另一种让 Discourse 更加可行的方式,而 Discourse 本身已经是一个有趣、相关且成熟的平台。市场的另一个巨大优势是,你可以在平台本身内从该插件或主题的开发者那里赚取一定比例的收入。

  3. 一些开发者可能认为这好或不有趣。因为取决于百分比价值,有时为你开发的东西却只收到很少的报酬,这很糟糕。关于这一点,正如我所说,有些人支持它,有些人认为市场不是什么好东西或不可行。

  4. 我相信像我这样的初入信息技术领域的开发者——为像 Discourse 这样已经存在且成熟的平台开发插件和主题,比从头开始创建新东西要好——因为这通常需要大量时间和大量的研究和营销才能成功并实现财务可行性。此外,通常你需要赢得客户和公司的信任,这同样需要时间。以及你建立的信誉、声誉和品牌。

  5. 通常不喜欢市场的人是想要或需要拥有自己业务的开发者。对于这些开发者来说,没有什么能阻止他们创建一个包含特定于他们有联系的公司和客户的 Discourse 主题和插件的网站,并赚取比在所谓的中央市场更多的钱。

  6. 我遇到并研究过的许多开源项目都有订阅业务模式。通常,在这些情况下,有我们称之为计划类型的东西。这些通常是这 3 种计划:社区版、企业版、商务版。社区版通常没有客户技术支持,并且是免费的。企业版是支持客户并付费的计划。商务版通常面向大公司,并且是可协商和付费的。我不知道 Discourse 的业务模式是如何运作的,但我认为从我在主站上看到的情况来看,它是订阅模式。我可能是错的,如果是这样,我道歉。

  7. 订阅模式是一种业务模式。因此,通常选择这种业务模式(即订阅模式)的公司,通常也会考虑拥有一个市场。Themeforest 是一个很好的例子,过去你只需要创建网站并将付款链接放在那里,如果有人对你的网站感兴趣,你就可以出售并赚钱。如今在 Themeforest 上你也可以创建插件并在那里销售。我认为这很酷很有趣,是一种商业模式。

  8. 正如我之前所说,这只是我对作为开发者认为有趣的事物的概述。此外,我认为市场可以赋能开源项目。主要原因是我们可以通过特定的插件和主题为我们服务的客户赚钱。这是一个非常理想的场景,我认为它很有趣,因为它让开发者有更多自由继续使用这个软件。此外,它还增加了与其他软件的集成。

注释
  1. 如果有人能阅读并讨论任何支持或反对的观点,我将不胜感激。
  2. 我无意批评 Discourse 的业务模式。
  3. 我相信,如果付费插件和主题的百分比价值不是太糟糕(太贵),那将是 Discourse 市场的一个很好的开端。
  4. 我引用了 Themeforest 的例子,但有几家公司采用订阅模式和市场,比如谷歌。许多谷歌产品都是订阅模式并拥有市场,例如 Google Docs。
  5. 我提到 ThemeForest 或 Google 或 Google Docs,只是为了引用一个拥有订阅和市场相结合的真实业务示例,我的目标不是推广任何东西,我只是将其作为一个参考。
3 个赞

我也这么想过。也许所有热衷于 discourse 插件开发的人都应该聚在一起,建立一个没有费用的加密货币市场。我们只需要一种方法来提供对 GitHub 存储库的私有访问。我们可以托管一个 Gitea 实例,并在存储库前面构建一个“加密货币门”。

1 个赞

你可以“卖”给人们一个私有 Github 仓库的部署密钥吗?

我的建议:在你的商业模式被证明有效之前,不要过度设计你的解决方案。阅读 Email-First Startups

3 个赞

这里最常用的模型是定制的付费插件和主题,以及开源插件,这些插件能为开发人员带来信誉(和技能发展)。有时,为特定客户开发的插件将被发布为开源。

寻求帮助的人可以在 Marketplace 发帖。虽然很少这样做,但你也可以在 Marketplace 提供服务。

2 个赞

授予和撤销访问权限以及管理付款的麻烦太多了,这意味着你需要收取高价,并且无法大量销售/向更广泛的受众销售。

说得非常好。

2 个赞

大家好。

我的 Discourse 市场概念:

  1. 我想到了一个简单的解决方案,可以帮助解决这个问题:我们可以要求将插件作为带密码的 zip 文件发送。服务器只需解压缩文件并将插件安装到 Discourse 中。密码可以是安装者创建的加密密钥。
  2. 这样,只有使用密钥才能解压缩。密钥仅在付款后解压缩文件。现在,这种情况适用于付费插件或开源插件,具体取决于开发人员。
  3. 如果问题在于可视化源代码,一种方法是使用混淆器。当代码发送到存储库时,它会经过混淆过程,代码会被包装起来,并且只能使用特定的开发人员密钥查看。
  4. 我所描述的解决方案类似于 Ubuntu 上的 flatpack,它是一个您下载并在 Ubuntu 上安装的包,不一定需要通过命令行安装,flatpack 就像一个可执行文件,您只需单击下一步、下一步,就像 Windows 一样。
  5. 要映射存储库,我们可以使用 Github API - 这仅适用于托管在 Github 上且公开的插件。Github 有一个 API,您可以通过标签搜索存储库。
  6. 另一种方法是使用网络爬虫来映射可能的付费存储库。我只是不知道网络爬虫是否符合 Discourse 的隐私和安全条款许可。就像评论一样,我能够阅读所有评论,如果您发布到标签 #marketplace,通常是 Discourse 上的付费插件,您可以向全世界展示。
  7. 简而言之,我认为开发人员理论上可以将这些存储库的链接直接发布到他们托管 zip 文件的网站上。然后,网络爬虫通过 marketplace 标签获取链接,并将插件显示在付费类别中。如果您想安装付费插件,一种方法是付费,然后 zip 文件就会被释放,在释放后,使用付款后生成的激活密钥解压缩 zip 文件。
  8. 为了使此解决方案更加优雅,我们可以做一些类似 .discoursepack 的事情。
  9. .discoursepack 扩展名是自定义 zip 格式的扩展名,它是用于在 Discourse 中安装插件的格式。

概念摘要 - 最小可行产品

  1. 源代码 → 源代码混淆 + 加密密钥 → 生成文件 discoursepack → | 解压文件 discoursepack ← 使用加密密钥
  2. 服务器会存储 discoursepack 文件一段时间
  3. 要在 Discourse 中安装付费插件,需要使用付款时收到的密码解压缩 discoursepack 文件。
  4. 没有加密密钥就无法创建 discoursepack 文件。同样,也无法打开或读取此类型的 discoursepack 文件。
  5. 付费插件可以托管在 Discourse 的服务器上,也可以托管在插件制造商的服务器上。
  6. 开放插件可以托管在 Github 上。
  7. 如果开源插件未托管在 Github 上且不公开,一个可行的解决方案是要求提供 discoursepack 文件所在链接。
  8. 如果是付费插件,这些插件不托管在 Discourse 上 - 在这种情况下,由于它们托管在制造商的网站上,因此制造商需要通过只有他知道且对所有付款方式都是临时的密钥提供指向该文件的直接链接。
  9. 如果您有大量插件要上传到 Discourse,建议使用 cms cockpit,它轻量级且不应占用太多资源。

插件开源 config.yml

server:
  host: 127.0.0.1
  port: 8006
  debug: true
analytics:
  enabled: true
  tag: xx-xxxxx-xxx
plugin:
  title: authmatic-example
  type: public, paid # 或 public, nopaid
  description: authmatic-example 来自一个做事的开发者。由 authmatic-example 公司提供支持。
  url: https://github.com/authmatic-example/releases/v1/authmatic-example.discoursepack
  releases: v1
  author:
    name: authmatic-example
    github: authmatic-example
    twitter: authmatic-example
    site: authmatic-example.com
    avatar: /assets/avatar.jpg
keystore:
  enabled: true
  client_id: xxxxxxxxxxxxxxxxxxxxxxxxx
  client_secret: xxxxxxxxxxxxxxxxxxxxxxxxx
  repo: authmatic-example
  owner: authmatic-example
  admins: [authmatic-example]
log: true
  format: text
  level: info
  line: true

插件闭源 config.yml

server:
  host: 127.0.0.1
  port: 8006
  debug: true
analytics:
  enabled: true
  tag: xx-xxxxx-xxx
plugin:
  title: authmatic-example
  type: private, paid
  description: authmatic-example 来自一个做事的开发者。由 authmatic-example 公司提供支持。
  url: client_url_temp
  releases: v1
  author:
    name: authmatic-example
    github: authmatic-example
    twitter: authmatic-example
    site: authmatic-example.com
    avatar: /assets/avatar.jpg
keystore:
  enabled: true
  client_id: xxxxxxxxxxxxxxxxxxxxxxxxx
  client_secret: xxxxxxxxxxxxxxxxxxxxxxxxx
  client_url_temp: xxxxxxxxxxxxxxxxxxxxxxxxx
  repo: authmatic-example
  owner: authmatic-example
  admins: [authmatic-example]
log: true
  format: text
  level: info
  line: true

MVP - 最小价值产品

可接受的文件大小限制

  1. 100mb 或 900mb 的 discoursepack 文件。

参考

我觉得你试图解决一个不存在的问题,并且在“丢弃婴儿的同时也丢弃了洗澡水”。

你的解决方案不允许轻松更新,难以/不可能在自动化部署中使用,并且容易规避。

部署密钥和 Git 存储库就足够了,并且没有上述缺点。

再说一遍,我的建议是:首先验证你的商业模式,然后关注价值。先做一个每个人都想购买的插件,然后再解决如何销售它的问题。

4 个赞

说没有人会愿意为插件付费,或者说没有人能安装加密 zip 格式的插件,这只是轻微的夸大其词。

我有一个平台,可以利用部署密钥在它管理的网站上安装插件。

另一个解决方案是公开插件,但让它在后台检查某个许可证是否有效。这很容易被编辑代码的人绕过,但我认为很多 WordPress 插件都是这样工作的。

1 个赞

你说得有道理,抱歉。你的反馈非常有价值,我之前没想到。

1 个赞

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.