Question Are premium add-ons not allowed?

Discussion in 'Community Feedback and Suggestions' started by RobiRami, Apr 21, 2017.

Thread Status:
Not open for further replies.
  1. l recently posted a premium add-on for my plugin LeaderHeads, like I've done before with this add-on.
    I checked all the rules and made sure I met them, which I did. I've spent hours writing documentation and creating demo's to now see that the resource is rejected.


    First of all, this 'rule' is not in the Spigot guideline page.
    Second of all, there have always been premium add-ons to premium plugins, take for example the skill packs for the plugin Heroes.


    If this is a new rule, I would like to know why it was added, because to me it looks there's a common misapprehension of the quality of premium add-ons.
    • Agree Agree x 5
    • Optimistic Optimistic x 2
  2. DavidDevelops


    Im not sure why it was rejected but it shouldn't have been I wish I could help more... Have you tried contacting a staff member to help you?
  3. No, because I feel like it's a public issue.
  4. It's a premium plugin. Add all the features you want to the original plugin - problem solved...
    • Agree Agree x 1
  5. That's your opinion.
    What if an add-on adds tons of new unique features but is dependent on another plugin?
  6. Celebrimbor


    If it is an actual cited rule, it must be brand new. I see paid add-ons to premium resources everywhere. Some of the top resource contributors have paid add-ons. This is odd. Definitely report via the appropriate routes though.

    I don't see any issue posting publicly if it involves asking the community if he missed a rule that he can't seem to find.
    • Like Like x 1
  7. latiku


    This was never a rule. Take TokenEnchant for an example, 70% of all the author's extra resources (~200 ) are premium add-ons for his plugin.
    • Agree Agree x 2
  8. Celebrimbor


    I wasn't going to name names, but that's the obvious one :p
  9. Isn't right tho imo, charging stupid money for an extra enchant.. and spigot allow it..
  10. Celebrimbor


    It is what it is. Don't like it, don't buy it. Some devs are clearly monetizing unnecessarily, but I actually prefer supporting devs for work that I did not originally purchase.

    What is this addon @RobiRami?
    • Like Like x 1
  11. True but robiramis web addons are more valuable and beneficial than a snippet of code to add an extra enchant.
    • Agree Agree x 1
  12. Celebrimbor


    That was not my argument. I agree 100%.
    • Like Like x 1
  13. The add-on adds new ingame leaderboards for factions and includes a complete web interface with a faction leaderboard that uses combined player stats based on Leaderheads to order the factions. Of course that's not all and that's just a brief summary.
  14. Celebrimbor


    Pssssshhh, factions. Never heard of it :rolleyes:

    I was excited.
  15. Since my plugin was mentioned and I do have add-ons for my premium resource, I felt I should mention something.

    TokenEnchant was originally released as one standalone plugin. However, many developers expressed their interests in developing their own custom enchantments. I thought that would be good idea, hence I released TokenEnchantAPI resources (free) so that other developers can start developing their unique custom enchantments (also by doing so I do not have to implement all requested enchantments). Subsequently, I released add-on framework, which allows TokenEnchant to dynamically integrate those 3rd party developed custom enchants at the runtime. With this add-on framework, anyone can create add-on modules for this premium resource. If one developer spend significant amount of his/her time to implement something worthy of requesting his/her compensation, she/he should be allowed to publish his/her add-on module as a premium resource.

    I can understand that prevention of excessive monetisation only the developer of mothership plugin can publish add-on modules. However, if the add-on framework is open to general public and all developers have the equal opportunity in publishing their own add-on modules, I don't see why Spigot need to prevent the release of such add-on as premium resources.

    If Spigot were to add a new rule on premium. add-on modules for a premium resource, it should say something like "the premium resource, which offer add-on framework, must have publicly accessible APIs, which allows 3rd party to develop independent add-ons. With this condition provided, the author of the mothership premium plugin should also be allowed to publish a premium add-on resources as an independent add-on developer.

    Having said all this, I would not have high expectation Spigot to understand it and allow you to now publish a premium add-on to your premium resource since it seems that they now have a set of new internal rules which are not publicly disclosed nor communicated.

    Only choice we have is to do whatever they say. After all this is their site and they can do whatever they wish regardless of how non-spigot staff members think.
    #15 vk2gpz, Apr 22, 2017
    Last edited: Apr 22, 2017
    • Optimistic Optimistic x 2
    • Like Like x 1
    • Agree Agree x 1
  16. I'm a "very" junior plugin developer and without this sort of add-on framework, i would not have been able to make my contributions to the area of custom enchantment. Also, this type of add-on framework allowed me to request small compensation (adequate for my skill level) in a form of a premium add-on.

    It looks like no I have to release all TokenEnchant custom enchantments for free (regardless of how original the idea was or how much I had to sped on it, etc.)

    Do I now have to re-release all my premium add-on as free resoruces? Do I need to make refunds?
  17. md_5

    Administrator Developer

    I can't specifically quantify when this was first implemented, but I can ascertain that it has been the case since at least January 26th 2017 when some premium TokenEnchant addons were rejected for this same reason.

    As with all rules on this site we try to enforce them consistently based on precedent, but it is not possible to codify every single thing that we do as changes are made dynamically in response to issues as they arise.

    I have updated the rules with a statement:
    We still feel that this rule is necessary to prevent resources from being tightly coupled to either dependencies which the author can never control, or have the effect of creating an expensive dependency chain / "incomplete" resources, and do not wish to see the market regress to having an excess of "unlockables".

    Is your resource being denied perhaps outside the original aim of these rules? Maybe, but for the reasons above objective rules are better than subjective rules. If we allow stuff to slide past the rules (grandfathering excepted) then there is no clear expectation of what the rules are, and people who don't get exceptions will feel they are even more unfair.

    I suggest you look at ways of restructuring your resource such that it is not dependent on another premium one.
    • Winner Winner x 1
Thread Status:
Not open for further replies.