I don’t know how we could charge for people to upload plugins when they won’t be able to legally make money off of what they post. We don’t want to get involved in a legal mess. We could potentially use ad revenue to pay for hosting if we don’t go with a sponsor.
1 Like
As someone else mentioned, would it be easier to use Curse to host the plugins, then just build a front to access them on the Sponge website? Or does Curse do that for plugins hosted elsewhere?
I think that a system like “Proposal 3” would work out ok. However i would like to make sure that the community has a say. I think a system that allows others to flag / report the plugin, as well as rate the plugin should be implemented.
Community Wise
I think this system would best be implemented in this situation so that the community can respond to issues when administrators cannot. Now as we are all aware this can be easily abused and should only be integrated if it can be properly set up. If the system has loop wholes that allow a player to vote for their own plugin up (EX:Player just votes their plugin up as another login user.) it should not be used. There are many different ways to stop this type of abuse, and just the same there are many different ways around the attempts to stop it however i will not discuss those here.
Administrative / Sponge dev team
From the Admins point of view any system in general is a pain to integrate and maintain.
However i believe if you have a trust based system that allow trusted developers to post
and maintain their own plugins would be grate and as time goes on the developer could
have a high “trust level” or lower “threat level” however you look at it i think that it’s worth
having at least a team of plugin auditors to ensure that the plugin meets standards / security
requirements.
Plugin dev
Its worth noting that the plugin developer will have to deal with the system used the most. I think the process should be streamline and at least the first plugin a developer posts will need to at least go through a approval process. It may be that a plugin developer’s first plugin will be fine. However the second plugin could contain the contaminated code with the back door. A combination of a automated scrubbing system / public reviews and random audits should be enough to resolve these issues.
On another note if performance is an issue and you think scrubbing may cause a lot of performance problems i’m sure that you could come up with some type of “Que” system that allows a uploaded plugin to be “Qued” and wait for the scrubbing process to happen so that the server is not over loaded with scrubbing request from new plugins. Vs. Doing a on demand type system that will scrub the plugin when its uploaded.
Well thats about all i have to add though so hope it helps. sorry it isn’t very well organized.
It would only be a small amount, under the same principle as the shopping trolley coins.
I’ve been around Bukkit forums for a while. The pants-on-head stuff has ratcheted up to new levels recently though! 
There’s nothing stopping developers making money off open-sourced plugins, either directly or through some sort of service (creating configs, helping set it up, etc.)
That’s what I was thinking. If a plugin adds perks to the server, then I still think they’re allowed to monetize on it, so long as it isn’t vanilla features they’re restricting.
Remember that for underage people, it’s often the act of paying (over the internet) itself that is the problem, not just the amount.
Anything involving money becomes at least 10x as painful, since you now have things like taxes and liability to consider, in addition to the current grey zone created by the EULA debate.
1 Like
Missed your first comment entirely @coldandtired XD And hafta agree with @teozkr, paying online for people who don’t have accounts can be a pain. And even explaining to parents what you want them to pay for in this situation can be a bit strange.
1 Like
That’s kind of the point 
By setting up a barrier to entry you switch the burden to developers who really want to release some plugins rather than trolls who can dump their rubbish and back-doory plugins on the public.
Obviously it adds more complexity and headaches but you have to decide whether, in the long run, these are preferable to the other options listed.
1 Like
I don’t really care for this idea, in the case of Google Play/App Store, the understanding is that if you make a good app, you will recover the losses you incurred due to the entry barrier, yet as users cannot sell Sponge plugins for money, they will never recoup what was lost. Thus I regard an economic barrier as untenable.
Why don’t we make it a deposit, you get it back after, say 200 (or whatever, I just threw out a number) happy users vouch for your plugin. I think sponge could still make some money this way, as many plugins will not receive that many “points” or whatever we call them.
While possible, we would also incur fees for transferring the money, so the plugin developer would never actually get their full deposit back. Also, some developers may have trouble regarding access to credit/debit cards or paypal accounts due to age restrictions/parents, so I believe we should keep those issues in mind.
6 Likes
There are plenty of free apps in all four of the big stores, all of which have cost developers real money to release. $5/10 is small beer compared to the work involved in making software but it has an important psychological effect.
Unless Sponge is going to force some very draconian licence on devs they can always choose to sell their plugins/support instead of giving them away.
Typically those free apps will utilise advertising as a revenue stream, something not really feasible in minecraft, furthermore I’m still quite concerned as to the possible discouragement of those who simply don’t have access to some manner of payment service.
I don’t believe we can permit plugins to be sold (or links to paid plugins) on our site due to the following clause in the Mojang EULA:
OWNERSHIP OF OUR GAME AND OTHER THINGS
Any tools you write for the Game from scratch belong to you. . Modifications to the Game ("Mods") (including pre-run Mods and in-memory Mods) and plugins for the Game also belong to you and you can do whatever you want with them, as long as you don‘t sell them for money / try to make money from them. We have the final say on what constitutes a tool/mod/plugin and what doesn‘t.
As to services/support, I believe that developers can provide that at cost, though that is somewhat unrelated to the plugin repo. Though of course, developers can use free plugins to attract paid work. So I’m open to debate on the issue, though I still think an entry fee is unwise.
SpongeAPI’s license does nothing to prevent this, but that doesn’t mean that the hosting solution has to accomodate for it. Additionally, Minecraft’s EULA makes charging for anything related a pretty gray zone.
2 Likes
Possibly, although I would say that clause is almost certainly not enforceable and there are multiple workarounds for it.
I’m not overly pushing for paid dev accounts, only pointing out that it’s an effective way of reducing fake, malicious, and junk plugins. Without any numbers concerning how many hours are being spent checking code per bad plugin it’s impossible to say whether it’s worth it or not.
Proposal #1.
It worked, people got their plugins out quickly, and there was virtually no Bukkit malware out there at all.
Combination of Proposal #1 and #3
Automated scanning is a must, there is no reason why it shouldn’t happen even if files are approved by default.
By all means have community reporting, it should assist the moderators or staff of the DBO equivalent.
If an auto-package tool like bukget happens for either the client or the server, there should be manual review, perhaps disabling this functionality for any plugin that hasn’t had this review, and marking it as potentially dangerous until the review happens. People can take the risk if they want, but will be informed.
Additionally links to external sites for plugins/CI/dev builds shouldn’t be banned (or should they? if fast release builds are allowed on the plugin repository, then maybe banning the sites could work), but discouraged, Warnings could appear when you click the link to go to an external site, and attempting to evade this rule should be a reportable offence by the community.
In short, have reviews, as well as a trust based flair system, after all, we are trusting the moderators to curate the repository correctly.
As far as reviewing the plugins, make anyone able to review plugins, decompiling and diffing versions could help to make the process quicker (but I’m sure that was done already). Anyone can decompile a plugin manually so why shouldn’t anyone be able to review the decompiled source? they shouldn’t be allowed to “allow” a plugin but certainly raising flags would be useful.
I’m basically thinking of a limited form of a github review type process. Anyone can browse the difference and can flag potential issues to the moderators.
2 Likes
I really like the idea of having the source code and diffs viewable/flagable!
We could have incremental updates to the decompiled versions, but I fear it will still eat up quite a lot of disk space on the server.