As an end-user of the DBO system, I usually found and bookmarked jenkins or other download sites for easy access to updates for trusted plugins. This wasn’t always easy, and I’d appreciate a transparent system here that relies upon the principle of caveat emptor: buyer beware. Review and approval, particularly for new developers, is appropriate and I’d appreciate a system that filters them for malware and exploits. But not at the cost of the breakdown of the plugin/module/doodad submission system. Let developers host their own links at a certain trust level.
That will be the tricky part, setting trust levels (and making them visible to the public).
Option three is really the only option for many devs like myself.
I ended up hosting all my own files due to slow approval times and crazy external links rules on bukkit dev.
I think a combination of the 1st and 3rd would be good. With the second one it could allow people to let plugins though that are backdoors. With the first idea we know its safe as Bukkit used it. With the 3rd idea it would be quicker that reviewing them by hand. But if something did pop up like a backdoor then idea 1 can be used to make sure that its not a fault in the system etc
I’d suggest reviewing the first X files from any given author. As they release more plugins and gain trust from the community and developers, then they can switch from manual checking to an autoscan with the occasional “surprise check” to make sure that there isn’t anything fishy going on.
+1 Maybe something similar could be put to the modders itself.
Red: Modders signed up under a 4months and under 3 plugins
Green: Modders who signed up for over 4 months and have made over 3 plugins (one of which has 1,000+downloads)
Blue: Modders with over over 5 plugins and 1000 followers?
This might be a bit much, but would it be possible, even if it’s a long time from now, to have some way to update plugins, similar to how a package manager updates a linux system?
I’ve always wished there was an easier method than opening 30 tabs and wgetting file after file.
It could be neat if there was a utility for this. Developers could state which versions of Sponge their plugins have been tested on, and the Sponge Plugin Manager would inform you of updates, or which plugins might break after you update Sponge etc.
I woud do it for decompiling out of security reasons, to experience Staff.
Then you could have a list a bit like on the Bukkit plugin list, but when you scroll throw you have it a bit like this:
[Avatar of the Project] [Name of the Project] [Categories] [Optional: A reward or Medal] [Author(s)] [Last Update]
Then like a status:
NR [Not reviewd] but download able
CV [Communits Viewd] that the Community viewed the file ant thinks it’s ok
SV [Staff viewed] that the Staff viewed the file and it’s almost to 100% safe
Rewards or Medals:
100 Likes
500 Likes
1000 Likes
5000 Likes
10000 Likes
50000 Likes
100000 LIkes
1000 Views
5000 Views
10000 Views
50000 Views The views count +1 per User account wich mean’s the Plugin only get’s +1 View when a
100000 Views User view’s it wich diden’t view it yet
500000 Views
500 Donwnlods
1000 Downloads
5000 Downloads
10000 Downloads
50000 Downloads
10000 Downloads
1 Month existing
3 Month existing
6 Month existing Since when the project exist’s this could be used as
12 Month existing an experience notification
24 Month existing
NR [Not reviewed]
CV [Community viewed] Like already fearther up in my Post
I vote for option 2 - with a “developer karma” system, so developers dropping below a certain karma level won’t be able to upload new content - and/or it will be “readily available” for users before they download the plugins.
I feel the “dev-bukkit-way” didn’t scale very well, and given the “community feeling”, it seemed a bit too rigorious compared to “trust each other” and “innocent until proven guilty”.
I’d rather have instant access to plugins (and instant access to servers) - and then have a common sense as to what to accept/reject.
If we did the CI and made a github repo mandatory, then you could review the source without needing to decompile. When a change is submitted only the newest commit would need to be reviewed.
With the community thing, you could list the number of approvals and have an appeals process for any disapproves.
High reputation devs might get higher priority on the server.
We could restrict projects to 1 build per day with a button to trigger it, so if a projects gets 3-4 commits in sequence, it doesn’t update. It would still be recommended that they do their own CI to make sure it compiles before they press “go”.
I still strongly believe that it’s possible to achieve this securely with Travis, which should mean that rate-limiting would not be required. Besides, having open registrations for a Sponge-hosted CI would likely be a massive security hole waiting to happen (yay, arbitrary code execution!).
If it’s a public and free mod there is no reason not to have it be open-source, unless it contains malware. If it’s paid or private they can figure out distribution themselves and thus this isn’t relevant to them at all.
I’m all for open source, but not everybody wishes their code to be seen by anyone. For example, plugins authors for anti-cheat plugins may not want cheaters to find flaws in their plugin.
I hope open sourcing would not put many off, but it is a reason to be.