This really needs to stop.

Discussion in 'Plugin Development' started by Nijikokun, Aug 3, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    I don't think I've ever posted here before, but I'd like to weigh in on this topic.

    I have watched this community develop since work on hMod stopped and work on Bukkit became more active, and this is when I started running my own small servers for friends or to satisfy my need to show other people my great works. On several occasions I have considered getting into the modding community for Bukkit as well, but it has continued to frustrate me as it makes all overtures of being "open source" without following through on some of the key principles of open source; thus, I have been discouraged from participating much as I had considered getting into other modding APIs of popular game products that have suffered from a similar lack of organization.

    So, organization is the first problem. As far as I know (and I'm not extremely well-versed), Bukkit is both the premiere software package for hosting SMP, and is primarily expanded by community-made addons. Why then is there no member of the bone-fide Bukkit team that acts as a release manager, or why isn't there an arms-length release management team that organizes and coordinates tagging for plugins that developers have registered for Bukkit? Is there one and I just can't find reference to them? Seems like a pretty important thing. Not to mention, having a release manager whose sole responsibility is to tag and release builds would eliminate the chance that duplicate projects would pop up when the developer goes AWOL. "Hey release manager, Joey has been missing for a month and a half and I've committed several bugfixes to X branch, can you please tag and release?"

    This problem is compounded when the Bukkit developers themselves get in on it. A real-life anecdote here that happened to me just this week was dealing with superperms - I've been running a couple dozen various addons, and been using the Yeti/rjr Permissions mod, which I felt has been more or less "the standard" mod. Therefore, I'm familiar with the whole wildcard node thing. Great, that works for me. Then I get into installing Multiverse 2, which required PermissionsBukkit. Okay, so I narrow my eyes reading about this and how I have to install PB -and- Superpermbridge, and not only that but have to screw around with explicitly giving permissions. The documentation was so obtuse at the time that I wrestled with this for 4 or 5 days before discovering that MV2 could use the "standard" Permissions mod, and thus reverted and had wasted many hours this week building 600-line permissions lists. So, wtf. Why did I spend so much time on that? Because a member of the Bukkit Team had endorsed PermissionsBukkit. So, in this case, reducing the amount of packages is something that has to happen from the top-down.

    The second problem is developer ego. This happens in the true Open Source community as well, but it is usually moderated by the fact that project owners are obligated to communicate with their users and developers, and denying needed changes because "I didn't think of it first" usually results in the project owner feeling the heat. In this community, there seems to be quite a bit of.. competition between some mod authors, and inevitably this sort of struggling for fame is something that diminishes the community. This has a history of going back all the way to things like VoxelSniper vs iStick. Ultimately, this sort of thing needs to be put down by someone with some sense and preferably with enough authority to make sure that what s/he says, goes. Project owners whose release notes read like a page from How To Act Like A Jackass should be addressed (and I won't name names), this does nothing for the community and only makes the end-users feel bad for not understanding if something works (due to crap documentation). This community sets the tone for itself, and to be quite honest this is the result of a semi-hostile community.

    The third thing that has made this all but impossible for you guys to correct now is the fact that the community has embraced the idea of donations for mod support. Yes. Does this happen in the real Open Source community? Rarely. But almost every author here has a donations link on their page. Look, I'm not saying that developers don't deserve to be compensated for their time, because they do. But true Open Source innovation comes from people that are more interested in improving something and knowing that they have contributed to something that's very popular, not people that are looking to slap together something to augment a piece of software and then make subtle statements about "Donating will give me more time to work on the plugin". Almost like a veiled threat, really. Of course, this even goes so far as to have people actually starting to turn plugins into a revenue source. Did you know that there is one plugin developer that requires people to donate to him to receive a beta key for the web-based interface required to use his plugin? Paying for a beta key for a plugin that interacts with a beta SMP API for a beta product? Ridiculous. Why doesn't the community stomp on it? Because it's hard to stomp on someone for collecting money for their work when they are doing the same. Plugins SHOULD be developed for the betterment of the community, not for money - and if a mod author can't manage to keep up with demand, that mod author should make himself a project owner instead and solicit contributors instead of sitting on it and doing nothing. Of course, now that so many people have seen what a potential source of revenue making crap clone addons could be, why wouldn't they get in on it?

    Ultimately I feel like this current development community has made its own mess, and while I'm not partial to kicking people when they are down it's pretty obvious that it is going to continue to become ridiculously overpopulated with addons that duplicate the same functions until someone takes a heavy-handed approach to turning the development community back to Open Source values - whether that requires the community to terminate the current semi-open submission policy and force mod authors to become project owners instead with a centrally operated release structure, or purging authors that act disingenously or otherwise are not representative of the community image the Bukkit team wishes to project. I have seen a lot of really great addons out of this community; my mind is blown when I see them come up with things when the publisher of the game itself is still fumbling around to duplicate the same functionality. I see a lot of developers that are hard workers and enjoy giving people options, that are happy just to contribute and have their contributions appreciated. But quite frankly, this community can do without the grandstanders and donation trolls regardless of how amazing their work is.


    Oh, one more thing. Documentation. Someone mentioned this above. With Minecraft having passed 3 million sales, that is potentially 3 million users circulating in the system, and unless you want to see popular server owners paying thousands of dollars a month to host them, there will be more that crop up. Having to navigate the hundreds of plugins that all seem to do the same thing is daunting in itself as a potential new server administrator, but having most of those plugins poorly documented at the start is absurd. "I'll get to documenting it when I get time." BS. It should be documented first. I'm not even talking about the code being documented, I'm talking about the "how to use this plugin" documentation! I get that this community is more likely to have "cowboy coders" because it is an incubator, but this sort of business in tolerating the vast number of authors that do this, is just stupid.

    Thanks for reading.
  2. Offline

    Connor Mahaffey

    You make a lot of valid points. Everyone here is volunteer so you do have to be understanding - especially since the people who manage the forums also code most of the time - it's a lot to do. As far as cleaning up plugins it's been posted about before:

    The forums are supposed to be a temporary solution for hosting plugins. Later there is supposed to be a plugin management system called "fill" that automatically updates plugins, etc. Hopefully that will be more organized. It's hard to do anything about duplicates, because it feels wrong to turn down a (presumably young and inexperienced) coder because their plugin "isn't that good".

    On the Permissions front, it has been a heated debate for devs.
    We understand that Permissions was the "standard" - but it's caused countless headaches. You've got people using odd versions, little to no support, hard work for developers, and recently - a ton of new Permission systems coming out that we also would have to support.

    Bukkit's Permissions are a central way for dev's to check Permission, that still gives the user freedom of choice when picking a Permission's plugin to use. Already (along with the default) there is another plugin that uses .txt files instead of .yml. Anyone can develop a permissions plugin and it works on the dev side. Always up to date. Always working. And when a user writes a permission wrong, it won't glitch our plugin.

    Permissions hasn't been updated in months - since May. A lot of people are using 2.7 which is inactive. We're trying to set a standard but its going to take time. Especially since a lot of new users go and grab Essentials and WorldEdit - which both use Permissions only.....

    When the original creator of Permissions 2.7 says this you know it's time to let it go.
  3. Offline


    Thank you. I didn't write the above to come off as a jackass; I can respect that a lot of the people that would police the plugin submission forums would probably rather be spending time on their own creations than sorting and approving submissions, tagging and releasing builds, etc. That being said, Fill has been "coming soon" since the plugin list was a link to a bunch of forum stickies. Is it an active project? As far as duplicate or near-duplicated functionality, it's not a terrible thing to tell them "no" if its entire purpose is already covered. If you don't tell them no, that's how that author ends up writing MORE of the duplicated plugins. What they should be told, and taught if necessary (although I wouldn't take more than 20 minutes) is how to pull from a repo, how to fork a release, and how to commit their changes. In the long-standing tradition of not being That Guy that makes a bunch of suggestions but won't follow through on any of them, I would go so far as to volunteer myself to the task of helping to consolidate the current author base; but I would warrant that there is at least one other person that is more familiar with Bukkit than I, that has been around longer, that would probably volunteer to do the same - they just don't see someone asking for a person to do that.

    As for the permissions thing, I don't really agree with you that it is difficult to propagate a standard at this point of maturity of the community, as long as people don't take a hands-off approach for it. Whomever administrates the plugin listing just has to say "Support for Permissions 2.x/3.x has been terminated, all plugins that are not superperms compliant within X days will be removed from the listing". And the plugins will change rather quickly or will die off, leaving the option to incorporate it into another project with similar scope. Mind you, as a user if the interface or method to deal with permission nodes is crap, complicated, or broken it's a non-starter for me, and I will resent having to use a different permissions system. In fact, I am confused in this day and age of OOP as to why you would even need to change the format of permissions for the end-user.

    Personally, I cut my teeth on coding for MUDs back in the day. For those of you that weren't around for the days of 20,000 Rom2.4 MUDs, a codebase that was written reasonably terribly but terribly prolific among the many, many, many admins that didn't like their current MUD, got snubbed for immortality by that MUD's administration, lost a popularity contest or though of SOMETHING AMAZING that they could capture players with led to huge fracturing in the overall MUD player and administration base. I see a lot of the same things among the coders of those MUDs happening here, and I really don't think it needs to be repeated - everyone doing their own thing, nobody wanted to tell people they were doing stuff incorrectly "because hey, any code is good code right?", MUD administrators having huge egos and competing with each other to the point of terminating players that even mentioned other MUDs, and the old elder coders of the genre not being able to agree on any standard because they all had their own ideas of what was amazing. Bukkit doesn't need that. Bukkit doesn't have to have that problem because Bukkit Team itself is the only developer of Bukkit, and has the power to come down and say, "You can't do this. You must comply with these standards, or you can't participate." And they should.
    Don Redhorse and enenra like this.
  4. Agreed. I know its harsh to turn people down. But its getting a huge mess know, as a server admin I get frustrated at times because of all the crappy plugins. I know those guys just got started, but they need to learn that you can't publish anything that works and does something.

    It's like the app store with all those fart apps, its ridiculous...
  5. Offline


    she's been pmsing for the past few days. its like she wants all plugins to die ffs. Permissions is needed 100%. Once everyone figures out how to use the new permissions then sure kill off all the other permission systems.
  6. Offline


    One more reason I'm not releasing anything I code. You get criticized not only from the user end but from other devs as well. I fail to see an upside.

    I don't mind copies of plugins as an operator/user since so many devs flake out and disappear and I frequently have to replace abandoned plugins. Even the big guys do it, including several names I see in this very thread. Also, sometimes one is buggy and the other one works better, or the author of one is... not nice... and the other guy is friendly and helpful. Then we have patches... some devs update quicker than others and I might need to replace a plugin with a competitor to keep the functionality, to keep my server running. It gives me options.

    There's more to this than the lines of code for the people on the other end, the people you're making these things for.
    Don Redhorse likes this.
  7. Offline


    The Bukkit team is well-intentioned, but they have to make up their mind. The plugin release system is dedicated almost solely to fitting a template. This alone can no longer produce an organized repository for Bukkit plugins. There are many plugins that are being released that, as others have stated, contain duplicate or too-specific functionality and poor documentation. More than just a template is needed to keep this organized. If the rather lax standards continue, the plugin list will simply bloat up further.

    Bukkit ought to be working to adapt to its environment as it changes. For a while, the setup was fine, but more of the... er, bad developers are reaching the point where he or she has functioning code. Overjoyed, he or she decides to submit it. Moderators come along and explain that his or her template is improper, and most of the time the plugin developer corrects his or her mistakes. Once a moderator revisits the topic, it is whisked away into the plugin release section. With the current system, this is not how it should be. It causes the clutter and disorderliness of the plugin list that most of us have posted in this thread about. In this situation, the work of the moderators is for naught; it would be a better use of their time to move all requests to release and get on with their day.

    The system needs to change. Be stringent on release criteria, but don't limit it to the thread formatting. Care about content.Weight could be put on plugins that have more likes/comments/votes/views/downloads, or plugins which show a decreasing rate of likes/comments/votes/views/downloads could be moved to the end of the forum or declared inactive. Plugins that are not being developed but are still popular and functioning should not be removed.

    The Bukkit community is full of people who would love to help. The actual difficulty of implementing the new system is not the paramount problem. This thread should not end as an unanswered plea.

    On a slightly less relevant note, per-plugin organization could be improved. I can't find the thread because of XenForo's sub-par search function, but there was a discussion about giving each plugin its own subforum, stickying the main thread (and locking it) and directing questions to be made in new threads. (Existing plugin threads would be stickied and just not allow any further replies.) Unless this significantly increases the load on Bukkit's webserver, I think this would work fantastically, especially if the plugin developer could sticky FAQs and so forth.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
    Don Redhorse and Bone008 like this.
  8. Offline


    There are currently ~1,600 plugins in Releases, this sort of system won't work at all.
  9. Offline


    Why not?
  10. Offline


    ... You think ~1,600 subforums is a good idea?
  11. Offline


    The plugin forum/list was only ever meant to be temporary, until Fill comes. Until it does, it's pointless attempting to organise all 1,600 plugins into sub-forums etc.
  12. Offline


    Is Fill really coming?
    If you organized them just like the threads, yeah.
  13. Offline


    No forum software that I know of pages forums. You'd have either 1,600 forums on the index, or 1,600 forums in a subforum. Either way you'd be looking at ~5 second load times, massive database hits, etc.
  14. Offline


  15. Offline


    I couldn't agree more. I haven't been here for long but things have felt "off" since the beginning. Not as much as in the SSP Minecraft Modding Community but still off enough. I couldn't really put my finger on it but reading your post has made me realize that it's exactly that.
    I've been active for years in other modding communities and it's a totally different atmosphere IMO. Especially with accepting any donations or asking for money in general being strictly forbidden in the first place. Getting money out of the way resolves a big load of (potential) problems from even appearing.
    From the little time I've spent here up till now it seems to me like missing direction "from above" (the Bukkit Team) is definitely a problem here. Especially with the many duplicate plugins.
  16. Offline


    I have nothing to add to this conversation save that while we talk about this the chance of one thing that one person said on this thread is added or changed in Bukkit is highly unlikely because the system they have while not perfect works as a temporary solution. And thats what it is.
  17. Offline


    There are some very good points in this discussion/debate. I agree with stopping donations, yes some people work hard on their plugins but asking for donations leads to others believing that they can get donations and they make their own clone and beg for donations. I will never put adfly links or a similar service on my download links nor will I put a donation button and I think other devs should do the same, but that's just my opinion.

    I think there should be a complete wipe of the plugin forum after fill is released and new stricter rules to be imposed, those being all plugins must be open source unless explicitly allowed by bukkit admins, there shall be no clones, you must be open to improvement on your open source project, you can not ask for donations or use URL shorteners, and your plugin must have reasonable amounts of English documentation.

    Permissions and all clones need to die (which is ironic because I haven't switched my plugins yet, reminds me, I shall do so tomorrow). Bukkit permissions are the way to go.
  18. Offline

    Randy Schouten

    I do not agree with this.
    If I don't want to share the source of my plugin, then I won't.

    It'd be the same as say Bungee giving us the source of Halo just like that.
    Yes, it's an a lot bigger scale, but they have whole teams, we work alone, so it costs us time too.
    Plus, I expect more duplicates if this needs to be done.

    You see, people already decompile plugins, without even giving asking.
    If everyone was to give the source, people can easily copy paste the whole code, add one small feature, and send it here.

    I for one, don't really like contributing to another plugin, as I don't get the "fame", if you wish to call it that.
    A whole lot of people on this forum can't even seem to read how to configure your plugin, so why would they go look for who contributed something.
    Then again, I'm one of original ideas, so I can't really say anything about this.
  19. The only thing i want to contribute to this is the fact that i feel plugins should be allowed to be "Reinvented" if they are part of a Larger collaberation of Plugins i.e. essentials Just so you arn't depending on one Developer / group of developers for the majority of your plugins
  20. Offline


    That's why I added explicitly allowed, for example if a company had to have a secure-ish system then it would be a fair reason not to release source, the original idea was that people don't copy and paste the code and release and instead contribute.
  21. Offline

    Randy Schouten

    That's why I added that I think that idea would backfire.
    People can copy paste even more easily and just add one small thing, making it essentially not the same.
  22. Offline


    And that too :( Maybe a permanent ban to anyone who makes a new plugin that was copy and pastied instead of contributing? (obviously inactive plugins would be handled differently.)
  23. Offline

    Randy Schouten

    That'd be too harsh, and mistakes will always be made.
    I can make a plugin from scratch, but there might be another plugin which does exactly the same, then why ban me if I didn't know?
  24. Offline


    But since it must be open source, mods can see if it was copy + paste. Also since there wouldnt be 50 TNT notifiers clogging up your search, youd be more easily able to find a plugin before you make your own.
  25. Offline

    Randy Schouten

    Then it would still be a clone and mistakes will happen.
  26. Offline


    And that's why we have a infractions system. You are given 1 warning for this mistake and the second time it's a permanent ban :D
  27. Offline


    Let other people choose what they want to code. When more update comes, more stuff will come out. Bukkit is freedom, and allow you to code whatever you want. I bet there is few plugins like (censored) by far.
    Grammar Troll likes this.
  28. Offline


    We're not telling them to not code repetetive plugins...
    We're telling them to keep them out of Releases, just so they can get a purple tag.

    Making simple plugins is a great way to learn, but just because you managed to display a message to someone after throwing an egg, doesn't mean I should see this 2 mins later:
    tips48 likes this.
  29. Offline


    @DrBoweNur You are correct, sir. I'm sure there is a few plugins type like mines out there. This one might be better.
  30. Signed, redundant plugins are so tilting, especially when there's many plugins that are abandoned and for which no good alternative exists :/
    Don Redhorse likes this.
Thread Status:
Not open for further replies.

Share This Page