Bukkit and Spigot

I have found this two posts after a lot of searching:
http://techedge.enjin.com/forum/m/9892234/viewthread/5392314-bukkit-or-spigot/page/1
http://www.planetminecraft.com/blog/bukkit-or-spigot/

I like your work (Bukkit) and I'm really satisfied with it but I would like to know if that info is true and what is your point of view (Not with disapproval but with a constructive comparison).

Another thing I would like to know is why don't you add the option to allow new clients to connect to an older Bukkit version. Is it so problematic to do?.

I'm only being curious and I think that information should be from you and no from external sources. I saw lot of Bukkit disapproval saying Spigot break Bukkit but never explaining why. It seams Bukkit is really angry with Spigot, but it can't do because of they modded Bukkit when Bukkit modded Minecraft.

Thanks for all your work.

 

Spigot...
Not to offend md_5, but why should you make a fork of a fork? Then, there would be a chain, and it would start to get ridiculous.

Spigot focuses on the game-play aspect, while Bukkit focuses on making plugins easier to make, manage, and use.

 

Yes, that is what I read... but why don't focus on both aspect?. (Spigot, theoretically support most bukkit plugins). About fork from forks there are lot of good programs that are forks from forks, that isn't a reason to underestimate software.

 

NemesisMate Do not talk about Spigot or any other knockoffs of Bukkit. We as a Bukkit community will not support you if you do so.

 

Because we can.

 

Forks of forks of forks.. where does it end? The inheritance tree can become arbitrarily complex, especially as forks merge and share code with each other and upstream. If you haven't seen the Unix history chart, it is highly illustrative:

http://www.levenez.com/unix/unix_a4.pdf

Hundreds and hundreds of derivatives.. a vibrant genealogy, with short-term and longer-term offshoots, branches, merges, evolution at its finest, countless developers working to make the software better. Some may see the numerous forks as a downside, but IMHO the ability to freely fork at will is one of the greatest benefits of open source software.

Granted, it can get confusing having too many choices, or fragmented development spread too thin. So why not have a one-size-fits-all implementation, satisfying everyone's requirements simultaneously? One ultimate software package that is everything to everyone?

With every decision there are engineering tradeoffs to take into consideration. Its not as if the value of software is a scalar quantity to be increased linearly — rather, it is an intricate careful balance of costs and benefits. Improve one metric, and it may be at the expense of another. Significant changes may have notable benefits, but come with equally significant risks. The balance is highly subjective, depending heavily on the values and goals of the participants. Through reasonable discussion the technical tradeoffs often converge to an overall direction of the project, but the balance is more of an art than a science, with known unknowns and unknown unknowns requiring empirical proofs of viability.

This is where forks come in. Back to the Unix example, consider a small piece of its history: BSD. The Berkeley Software Distribution, developed by a group at UC Berkeley several decades ago. They had the foresight to license it as open source, under what is now known as the BSD License. BSD has a rich history itself, but spawned several major forks still in use today (most descending from 386BSD), each with their own respective niche and focus:

• OpenBSD - security
• NetBSD - portability
• FreeBSD - performance

The engineering tradeoffs each of the teams have made accordingly are apparent in their projects. OpenBSD focuses on security at all costs, delivering a minimal distribution, greatly locked down, with serious security features enabled by default. Process IDs etc. are randomized, no ports are open, a sophisticated firewall is built-in, integrated crypto, the code is regularly audited. If you want a very secure OS, for a router or sensitive server or other similar purposes, OpenBSD is a great choice. NetBSD on the other hand focuses on cross-platform portability and clean design, literally dozens of processor architectures are actively supported. If you need to run a Unix on one of these platforms, especially on an embedded system, NetBSD is a great choice. Lastly there is FreeBSD, one of the most popular variants, a more of a general-purpose OS focusing on performance and the x86 platform, neither excessively on security nor portability at the expensive of usability nor performance. Some of the security features of OpenBSD may not be enabled in FreeBSD if they cause notable performance degradation, although of course they strive for a reasonable balance.

And that's only the beginning. But as you can see, each project has their respective focuses. Neither are competing head-on, rather, they each are fulfilling their own requirements. Frequently they share code to further their collective goals - for example, the OpenBSD team developed the 'pf' packet filter, and it was awesome so the FreeBSD team adapted it as well, as an alternative to their existing 'ipfw' firewall. Sometimes the forks are temporary and meant to be reintegrated later, case in point, TrustedBSD forked from FreeBSD and implemented mandatory access controls and more, then was merged back into the main project.

Other projects can even borrow from these projects or vice versa. In fact, the network stack responsible for delivering this content you're reading is most likely based on "Berkeley sockets", an API for TCP/IP developed in BSD and now present in all major operating systems. Microsoft borrowed Berkeley sockets for their Windows operating system, and OS X userspace also largely benefits from BSD. It is no exaggeration to claim the Internet would not exist as we know it without the fortuitous decision of UC Berkeley to release their software under a free license explicitly allowing for modification and redistribution of forks.

How does this all relate to Bukkit? Well, it is not licensed under BSD but another free/libre/open source (FLOSS) license: LGPL, the Lesser GNU General Public License, committed by grum three years ago. There are some interesting philosophical differences between BSD-ish and GPL-ish licenses (BSD/MIT/Apache/X11 vs GPL/LGPL/AGPL), different restrictions/requirements stemming from different values, but they both facilitate a collaborative environment where you can take the source, change it, and share it. Open sourcing is unfortunately all too rare in the Minecraft modding community, but Bukkit's open sourcing is probably one of the key reasons for its runaway success (and the renewed focus on pull requests flexes this strength even better).

IMHO the official CraftBukkit server is quite well-developed with reasonable tradeoffs, but you can also find unofficial forks developed with alternate goals. Just like BSD's progeny targets security, portability, or performance, there are CraftBukkit-derived projects focusing on high-performance, mod support, forward-compatibility, backwards-compatibility, special purposes, and more.

Neither of these projects are objectively "better", they merely serve different purposes. For example, a high-performance fork might sacrifice the details of vanilla gameplay for improved performance. Many forks also happily contribute their changes upstream to benefit of everyone, where their changes satisfy the goals of both projects. In fact, most forks are created expressly for this purpose. You can check the number of CraftBukkit forks on GitHub, currently there are nearly a thousand! Of course not all are actively maintained, most were meant for developing a change to submit into the main project, more of a temporary "branch" offshoot than a continuously progressing fork, but its all forks in the end. Git is very well suited to this distributed fork-based style of development.

In summary, I'd say forks are a positive indicator of a healthy ecosystem. The fact that someone felt the original software was suitable enough to build upon for their own usage, and hopefully contribute back. Pretty cool. Although it should go without saying any issues with the forks should be brought up to their creators (most have dedicated forums) not the Bukkit team since they don't know what changes were made in the fork (although some plugin devs are glad to support forks, it is up to each individual developer what they are willing to support), but inherently imho forks in general are a positive contribution to the Minecraft community.

 

O.O I didn't though I would get a such good answer, well wrote and well explained. The only thing I want to add is that is not good for Bukkit to look "angry" with other projects when users make questions or names on these forums other fork projects.
That these forums are not for other forks supporting is great but the ways that Bukkit members answer some people doesn't benefit it at all.

That type of answer (Sometimes saw buy official Bukkit members) is not being "Not Supported" is being "Taboo", a comparison involves both projects and other many answer involves both projects too, maybe not bug answers, these is normal to close it fast.

Whatever, again, thanks for your answer.

 

This is badly worded on so many levels. This is just a conversation discussing the two projects, not asking for support of "knockoffs" of Bukkit. We may not be allowed to assist people who use "knockoffs," but you make it sound so horrible for people to choose forks of Bukkit.

Anyway, on topic, Spigot seems to be where a lot of updates are pushed a lot quicker. However, it is always considered to be a sort of test version in which some updates make it to Bukkit and some are not. I've had experiences where plugins did not work correctly on Spigot, but worked perfectly on Bukkit.

 

That seems to describe it quite well (correct me if i am mistaken). Spigot also sometimes adds features and later has to remove them, because they did not work out or would conflict at some point, which Bukkit/CraftBukkit would rather not do. Thus Spigot is more experimental for sure. It seems to focus on performance for a good part, settings such as per-world view-distance are what some server owners have long waited for. Of course many of the features have various side effects, and might not be suitable for a "as close to vanilla as possible" approach, some stuff might flow (back) into CraftBukkit once tested.

I can't know what Bukkit project people think, i think they have various different opinions anyway - stating that "mods are not supported" seems somewhat natural to me, because it really would increase the support-load by a lot, also leading to a lot of confusion, potentially. The experts for the mods are the creators and (sub-) communities of those mods, since you can't expect the Bukkit team to review posts about mobs spawning differently with Spigots mob-activation settings for instance, or plugins working on mod x but not on mod y.

For plugin related stuff you can still ask on the dev-pages of the plugin, so if you had a sub-forum for Spigot on bukkit.org or if you use the spigot forums does not make that huge difference after all, mixing both into one forum does not seem "nice to support".

 

I see Spigot as being for larger servers who want the performance optimizations (and possible game-changing behaviors)

You, as a server owner, have a choice of what to use. Choose wisely.

 

NemesisMate
Angry at Spigot? Hardly. We will not provide support for Spigot users in anyway - that should be up to Spigot to provide. As a user of Spigot the choice should be made clear that when you choose to run Spigot, you chose to use them for support. Does Ubuntu expect Debian to support their users? Of course not.

Spigot changes far too much to be supported here at Bukkit - as mentioned above, they provide "experimental" changes that often cause them problems that do not exist on CraftBukkit. They also make changes to vanilla behavior - something that goes against the core foundation of CraftBukkit. Yes, this includes plugin support as well as we cannot know and should not be expected to spend time finding out if that downstream fork broke compatibility.

If there are any changes we can prove help performance without sacrificing vanilla behavior, we work to ensure they make it into CraftBukkit.

To your specific point about allowing newer protocols - the latest 1.5 update proved why its a horrible idea to allow protocol hacks. "I can't craft" was commonly reported to both Leaky (our bug tracker) and Mojira (the Mojang bug tracker) - with no one from the downstream groups posting any notice on their forums, or on those bugs reports taking responsibility for the resulting bugs. This specific bug (as well as others) existed in every downstream fork that either attempted to update to 1.5 on their own, or pushed a protocol hack. On top of that, there is at least one plugin that was proven to cause this problem (they worked around the refactoring commit we pushed to stop that kind of thing hurting the very people who use their plugin). The server admin - the very users of the product released - need to know what they are getting themselves into.

Forks are awesome! We like seeing what people have came up with. All we ask is when a fork gets made, the makers of the fork take full responsibility for the problems they cause upstream. I regularly check the Mojira bug tracker to ensure there are no CraftBukkit bugs reported there, and if they show up I make sure we get them closed (if it happens, which isn't common - we make it clear where people can get support for our product). Downsream groups should be doing the same, as they've wasted the time of many upstream volunteers chasing bugs that were caused by their choices and mistakes.

Upset? Not at all. Just don't expect support from us or our wonderful community - its simply not fair to us or the community who volunteer their time on our forums helping out.

 

This is the only answer you need,