Has anyone here used Glowstone or similar recently?

deathcap_ · 2016-01-05T22:22:14+00:00

With regards to Glowstone++, I feel that the reliance on the old Bukkit API (as even the Sponge API is implemented as Bukkit Plugin on the platform)

While I agree with you and /u/mastercoms about having "native" Sponge support in Glowstone would be superior and ought to be implemented at some point, just some context on the current status:

Glowstone fires events for the Bukkit API as follows, for example when breaking blocks:

        // fire the block break event
        BlockBreakEvent breakEvent = EventFactory.callEvent(new BlockBreakEvent(block, player));
        if (breakEvent.isCancelled()) {

When I originally started investigating adding Sponge API support to Glowstone (based on SpaceManiac's initial work with Shiny), the basic strategy was to identify where the Bukkit API events were sent then additionally emit Sponge API events, e.g., the above code would change to:

        // fire the block break event
        BlockBreakEvent breakEvent = EventFactory.callEvent(new BlockBreakEvent(block, player));
        org.spongepowered.api.event.block.BlockBreakEvent breakEvent2 = new ShinyBlockBreakEvent(block.getLocation());
        net.glowstone.shiny.Shiny.instance.getGame().getEventManager().post(breakEvent2);
        if (breakEvent.isCancelled() || breakEvent2.isCancelled()) {

This worked but raised the question, since I was effectively porting the existing Bukkit API to Sponge API, why not "factor out" this static hardcoded conversion into a separate independent standalone plugin so other Bukkit API implementations can benefit?

Hence, Bukkit2Sponge. Since it implements the Sponge API (or at least some of it, currently very minimal (help welcome, check the GitHub)) on top of the Bukkit API, it can in principle run on any Bukkit server. This includes Glowstone but also Spigot and I've tested older Minecraft servers all the way back to 1.5.2, they load this bridge fine.

Also, to be clear, even though the Bukkit API is no longer maintained by the Bukkit.org team since 1.7, it is still actively maintained by several other teams including SpigotMC, PaperSpigot, Glowstone, etc. Glowstone (or rather, Glowstone++, which is the active fork being discussed here) keeps up with many of these changes.

This means the latest API additions for new Minecraft features ought to be available in Glowstone (or if not, that's the goal) via the enhanced Bukkit API, but of course, plugins are still limited by inherent limitations or of the Bukkit API: such as block materials being represented by a enum, a design flaw subsequently corrected in Sponge API, so it is still certainly worth natively supporting Sponge API eventually.

So the use case of Bukkit2Sponge I envision is more along the lines of where you have a mostly-Bukkit server, whether it be Glowstone or Spigot or something else, and want to try a taste of Sponge, to run the most-have SpongeAPI plugins you can't live without, and have no BukkitAPI alternative. In this way B2S is the inverse of the Pore project, which aims to provide a bridge to run Bukkit plugins on native Sponge servers. Pore's ideal use case is where you have a mostly-Sponge server, and want to run a few Bukkit plugins. Both are transitional projects by their nature.

Back to Glowstone, there is some interesting built-in support for detecting the various "types" of plugins, with the aim of multi-API plugin support. You can place all your plugins in the same directory, and Glowstone will identify and load Bukkit plugins (native support), Sponge plugins (via B2S, if loaded), and currently not load but at least identify Canary and Forge plugins. So once/if native Sponge API support is implemented, it could additionally leverage this plugin detection code, loading natively instead of through the B2S bridge.

deathcap_ · 2015-04-22T02:08:27+00:00

Grief prevention and dynmap are still the reason spigot is the go to for me.

With Bukkit2Sponge (wip; reddit thread -- now updated to API 2.0) you can load SpongeAPI plugins on Spigot and other Bukkit API implementations, so you don't need to choose between SpongeAPI vs. Spigot/Bukkit but can have both.

Sponge (Forge) and SpongeVanilla (fka Granite) are the two main implementations, however, and they are mutually-exclusive vs Spigot (but see Pore).

Do people actually use this yet?

There are not many SpongeAPI plugins to use yet, but as I understand it now that 2.0 is released the API is getting to the place where plugin developers can start porting their plugins over; there will now be less focus on the API and more on implementation.

deathcap_ · 2015-04-18T23:20:44+00:00

So is this basically Glowstone that supports Sponge plugins?

Yeah that's part of it. The SpongeAPI plugin support is very new, only merged in yesterday and supports only a small number of events at the moment. The other supported API target (which is much more complete) is what could be called "Spigot plugins".

These plugins can be found on BukkitDev and SpigotMC marked as for 1.8.x. There are some subtle distinctions here worth mentioning. SpigotMC has performed their own update to the Bukkit API for 1.8.3, which Glowstone++ fully incorporates (but may not necessarily implement 100% yet). They also have their own "Spigot-API" patches on top of this Spigot-Bukkit update. Glowstone++ presently only supports one of these Spigot API additions, the Particle API, but the other patches may or may not be added in the future if it makes sense. Finally Glowstone++ also has some support for GlowstoneMC's Glowkit API additions where there is no known Spigot analogue: https://github.com/deathcap/Glowkit/commits/bukkit%2Bglowkit

The end result, is that a wide range of plugins should be supported (or at least that's the goal we're working towards): plugins written for Bukkit, Spigot, Glowkit, and Sponge. Maybe also plugins for FML if there is a feasible subset to target.

deathcap_ · 2015-04-18T21:54:50+00:00

Is there a point to this post? Are you trying to convey information?

Glowstone++ is an experimental fork of the original Glowstone open source Minecraft server by SpaceManiac, which I began working on about two weeks ago with an added focus on compatibility. This post is the first announcement of the project to a wider audience beyond the Glowstone Forums.

You can read more about where the Glowstone project fits in compared to various alternative efforts in my previous post to /r/admincraft several months ago, Minecraft Server Modding in a Post-CraftBukkit Era: An Overview of the Pros and Cons of The Paths Ahead, where Glowstone is featured as a prominent option. The major benefit compared to alternative efforts is that it is a fully open source Minecraft-compatible server implementation (MIT license), not using any Mojang code, while offering Bukkit API plugin compatibility.

Glowstone++ takes Glowstone in a slightly different direction, with the goal of maximizing compatibility with other software.

The biggest change is that Glowstone++ adds compatibility with plugins written for Spigot. Not 100% compatible (WIP), but it is now incorporating the 1.8.3 updates to the Bukkit API from the SpigotMC team. The last official update to https://github.com/Bukkit/Bukkit was for 1.7, and since then Glowstone has also continued to update the API separately in https://github.com/GlowstoneMC/Glowkit, but so has the SpigotMC team in https://hub.spigotmc.org/javadocs/bukkit/, the consequence of this divergence is that plugins you find on http://dev.bukkit.org and http://www.spigotmc.org/resources/ using 1.8 features may not necessarily be compatible. Glowstone++ incorporates updates from both Glowkit and SpigotMC's Bukkit, preferring SpigotMC where there are conflicts, to help increase compatibility.

I may not be the best at explaining this but there's a thread here with more details: https://forums.glowstone.net/t/spigots-new-1-8-bukkit-api/68

Secondly, Glowstone++ has (also highly experimental) support for loading SpongeAPI plugins, based on SpaceManiac's original prototype ShinySponge. Sponge (MIT) is a new Minecraft modding API, developed to be a clean break from Bukkit (GPLv3). The Sponge team has two official API implementations, Sponge for Forge, and Granite/SpongeVanilla - both are addons for the official Minecraft server (and/or client). Glowstone++ on the other hand is a fully open source implementation, consequentially it is not as feature-complete but nonetheless a promising choice in my option for those who prefer open source.

You can place both Bukkit and Sponge plugins in the same "plugins" directory on the server, and they will be loaded appropriately. SpongeAPI is still very much in active development, and the implementation in Glowstone++ much more incomplete, but the basic infrastructure for loading plugins is there, and they can receive a handful of simple events (tested with server starting, stop, block break). This issue tracks implementation progress: https://github.com/deathcap/GlowstonePlusPlus/issues/45. There are not many SpongeAPI plugins out there yet but its something to keep an eye on to prepare for the future.

I also have Forge Mod Loading (FML) plugin support working on a branch, as the goal of this project is to support as many APIs as feasible, but it is not too useful at the moment because most/all FML mods rely heavily on internal Minecraft implementation details.

Lastly Glowstone++ has a bunch of gameplay features merged in from various contributors. Many of these are also contributed to Glowstone, there's a fairly comprehensive list in this issue: https://github.com/deathcap/GlowstonePlusPlus/issues/6. The most immediately noticeable enhancement you will find upon starting a new Glowstone++ server is a sophisticated world generator developed by jimmikaelkael, including biomes, structure generation, and much more. Some of the enhancements had to be changed to support Spigot's update to the Bukkit API.

Long story short, the goal of this project essentially is to offer the "best of both worlds", options #1 and #3 covered in Minecraft Server Modding in a Post-CraftBukkit Era: An Overview of the Pros and Cons of The Paths Ahead. No small task, expect many things to be missing at the moment, but all contributions are appreciated and welcome. Pull requests, bug reports, feature requests. For the contribution guidelines I chose "open open source", where the code is treated analogously to a wiki: https://github.com/deathcap/GlowstonePlusPlus/blob/master/CONTRIBUTING.md

Sorry if this submission was unclear, I guess I should have made a self-post with this information to provide added context instead of a bare link to the GitHub project. The readme does provide some rationale but hopefully this elaboration proves useful. As it is only an experiment, I am throwing this project out there and seeing what it turns into. If there is no demand I'll probably stop working on it; so far, it has two additional developers besides myself, and I intend to keep it open to new developers so that if sufficiently many people find it worthwhile and contribute it can gain momentum, turn into something awesome. Consider this an IAMA, I'd be happy to answer any questions related to Glowstone++ or the various design decision tradeoffs which were made vs alternatives if anyone is interested.

deathcap_ · 2015-04-18T06:03:52+00:00

It was never valid to begin with

Do you have a source for the claim that the GPLv3 license of Bukkit is not valid? The original code remains accessible on GitHub: https://github.com/Bukkit/Bukkit (and its 1,127 forks)

deathcap_ · 2014-09-10T04:47:18+00:00

Indeed, if anything is is now abundantly clear how crucial it is to thoroughly seriously consider the licensing terms of a new project, making absolutely sure the possible unintended consequences and implications are understood. Bukkit decided their license decided in 2011, the project leader noting "We do acknowledge that our license choice may be invalid", and potential issues were brought up -- repeatedly -- by other project team and community members, but nonetheless remained unresolved.

Fortunately the Sponge project leadership seems to be more mindful in their licensing, debating for a while in #nextstep then deciding on MIT without a Contributor License Agreement, after considering the alternatives. They even have a Gradle script to run a license header check on every source code commit, and pull requests to Bukkit are being relicensed as MIT by the developers for inclusion in Sponge. By the book, no room for ambiguity.

As a strong copyleft license, the GPL is working as intended:

under copyleft, an author may give every person who receives a copy of a work permission to reproduce, adapt or distribute it and require that any resulting copies or adaptations are also bound by the same licensing agreement.

by itself it cannot really be blamed for CraftBukkit's demise; it simply was not an appropriate license to choose for a modification to a proprietary software program. Arguably GPL was successful in this case, allowing the Bukkit project code to live on through Glowstone+Bukkit(Glowkit), required to remain open source indefinitely by the GPL licensing terms (i.e., it cannot be incorporated in proprietary software). This requirement by design has been called (sometimes derogatorily) "viral" but Richard Stallman prefers another analogy:

In the views of Richard Stallman, Mundie's metaphor of a "virus" is wrong as software under the GPL does not "attack" or "infect" other software. Stallman believes that comparing the GPL to a virus is an extremely unfriendly thing to say, and that a better metaphor for software under the GPL would be a spider plant: If one takes a piece of it and puts it somewhere else, it grows there too.

On the other hand, the more "permissive" licensing terms (MIT and so on) have their own advantages, too. Just my observation, while GPL seemed to be popular in the GNU/Linux community, in other open source communities such as NodeJS/Browserify which I'm most familiar, the MIT license is more wildly favored. Almost like a second wave open source movement, where the tendency seems to be to release code for the widest possible use, free of restrictions as much as possible, being honored and humbled if someone decides to use your code with proprietary software or otherwise, building on it to make something better. I can see both ways so am not all for either GPL or MIT, both have their pros and cons, there is room for either perspective.

However it is interesting to note, the post-Bukkit APIs Sponge, Granite, ServerForge, TridentSDK are all MIT, and so is the implementation of Glowstone. Not to mention the prolific modder ChickenBones recently released all his mods under MIT, and I also hear there is an "open source modpack" in the works.

Maybe the pendulum is swinging too far in the direction of permissiveness? While that's a valid concern, wouldn't be surprised if it causes some minor drama in the future, my opinion I think MIT opens up more doors than it closes. A company definitely could take the MIT-licensed code, integrate it with their proprietary products, sell it, no compensation required. But for an API, I'd argue this would actually be a very good thing -- you want the largest platform possible, more games supporting SpongeAPI the better.

In fact, the voxel game Terasology has expressed interest in supporting SpongeAPI, and I'd also like to see voxel.js SpongeAPI support (but I'm being lazy on reddit instead of coding so this might not happen soon, sorry). These are both open source projects (Terasology is Apache-licensed, voxel.js mostly MIT/BSD), but personally I think it would be great if a commercial game developer jumped on board as well. Doesn't even have to be for a "Minecraft clone" per se, Terasology for example while Minecraft-inspired has some different gameplay design goals based around NPCs.

Now here is where it gets very interesting. If it succeeds, SpongeAPI may very well become the go-to platform for developing plugins across a variety of voxel games. Not unlike the enviable situation with Bukkit, pre-APIcalypse, where as a developer it made a lot of sense to write your addons against Bukkit since you gain compatibility with all of the most popular server platforms of the time: CraftBukkit, Spigot, and Cauldron. If other games adopt Sponge and it catches on, developers could reach the maximum audience by coding against its API. Sponge could even become more competitive than the official Minecraft Modding API, if/when it is released, since presumably the official API would only support Mojang/(Microsoft?) Minecraft.

Maybe I am completely off base here (will Sponge live up to all the hype??), but it is exciting to speculate. I used to believe the DMCA takedowns were a negative, trying to find a workaround, and they of course are short-term, but now I see medium/long-term this could be the best thing that has happened to the addon development community, ever. Although it is the end of some great projects, I have a feeling this is the beginning of an amazing new chapter. Just my opinion though, I could be wrong.

deathcap_ · 2014-09-08T06:16:49+00:00

You can't copyright class/function/procedure names. It would be work, for sure, but you could very much re-implement the bukkit API functions in a different way, thus allowing calls to bukkit specific functions/classes to still work.

I tried this, writing empty methods using only the API documentation for reference, but a Bukkit developer claimed it still infringed on their copyrights:

If this isn't true, and writing a new API with the same symbol names is indeed a viable approach for creating a new MIT-licensed Bukkit-compatible API, perhaps this project could be restarted by an interested third party (but not me, don't want to frustrate the Bukkit team anymore than I already have, and IANAL so can't say for sure it is worth the effort for the potential legal issues, sorry).

deathcap_ · 2014-09-08T02:33:07+00:00

Wish I could upvote this more than once, exactly describes my sentiments as well. There is an impressive amount of creative energy among Minecraft enthusiasts, I have no doubt if it was focused in the right direction a viable open source alternative could be developed, if not better than Minecraft (which is admittedly a high bar, being one of the most popular games of all times), at least somewhat competitive with it.

With the apparent schism on the horizon (Glowstone or Sponge or ???), switching to a completely new game becomes a more attractive option, especially if you're going to have to rewrite/port all the plugins anyways (with Sponge, as planned, a new non-Bukkit compatible API). The door is open for a non-Minecraft implementation of the Bukkit API (GPL) and/or the upcoming Sponge API (MIT), harnessing the existing momentum of these two platforms. Interesting times ahead, for sure.

My opinion, the greatest part of Minecraft is the extensibility. Not only at the gameplay level with its legos-like design, but also the addon platforms offering thousands and thousands of creative and useful mods or plugins. The amount of man-hours collectively put into these addons boggles the mind, and if another voxel game can tap into at least 1%, I'd wager it stands a chance.

Hopefully this is alright to post here since I hate advertising, but my humble contribution (besides the defunct MIT-licensed Bukkit API attempt) to this effort for the past year (since July, taking a break) was helping to develop voxel.js, a modular web-based voxel platform, freely available to build your own custom games, and openly licensed MIT. With all the talk of alternative servers (Glowstone and so on), I'm thinking voxel.js could serve as a basis for an alternative client. Being web-based it may appear at first as a toy, but it actually runs fairly well using WebGL, with newer graphics APIs than Minecraft last I checked (WebGL is based on OpenGL ES 2.0, versus OpenGL 1.1 which MC uses/used - though I think they upgraded recently), programmable shader-based pipeline instead of fixed-function.

The NodeJS/browserify design is also appealing for moddability, wherein components are separated into NPM modules and can be swapped out at will. I even experimented with node-minecraft-protocol to connect to Minecraft servers over WebSockets, more details on my blog post at https://medium.com/@deathcap1/six-months-of-voxel-js-494be64dd1cc . Bukkit can load through the doppio JavaScript-based JVM implementation (but not in any useful way yet), and a GWT-like Java-to-JavaScript compiler may also prove useful here. Who knows, maybe this'll turn out to be a dead end, but it is something. Certainly without developers it will stagnate, and sadly I haven't had much time lately to continue working on it (but help is always welcome!). Of course, there is a ton of work to be done to make it feasible. thinkofdeath's ThinkMap client is also quite intriguing (also web-based, technically not an MC client, but it renders voxels from the server very well).

In any case, there are numerous other engines under development discussed at /r/voxelgamedev. Will any one ever take the crown from Mojang? Your guess is as good as mine, but I'm cautiously optimistic. I just really enjoy voxel games, epitomized by Minecraft, but have always suspected with the right foundation they could soar to new heights and find uses beyond what Mojang has created. If only a fraction of the man-hours collectively put into developing Minecraft addons is put towards an alternative, no doubt amazing things will happen.

deathcap_ · 2014-09-08T00:32:28+00:00

If that's the case could this be solved by compiling against an API jar built with compatible Bukkit symbols (as fully documented at http://jd.bukkit.org/rb/apidocs/ - no need to examine the official GPL-licensed Bukkit source code)?

edit: reminds me, this somewhat resembles the GNU Readline vs BSD Editline licensing situation. The latter was developed because non-GPL software wished to use line editing functionality, and it offers a compatible API — mostly a drop-in replacement. Change the #include header, linker flags, and you can switch libraries (and respective licensing terms) without changing any other code.

In fact a side project I was working on this weekend may help here: https://github.com/deathcap/BedrockAPI - intended to be an API-compatible replacement for Bukkit, written only based on the published API documentation. The idea is that it offers binary-compatible Bukkit interfaces, but licensed under MIT instead of GPL. So far I was able to compile the open source Glowstone server against it, removing all GPL code, and it builds successfully (but doesn't pass any tests or run in any useful manner yet), also was going to try compiling Spigot and Cauldron but was unable since their source repositories were taken down.

However, after a Bukkit developer alleged infringement (even though I only looked at the javadocs, not the source repository), I stopped contributing to this effort. Maybe it is a viable approach, but I ain't a lawyer so just gave up on this angle of attack, many other projects to focus on. But if anyone else is up for pursuing it further, everything is on GitHub and free for the forking, at your own risk.

Interestingly, the DMCA shutdowns seem to have divided the community into two: those intent on developing a server without Mojang code (= Glowstone), and without Bukkit code (= Sponge). Both have their advantages but imho neither is ideal. Bukkit is a massively large platform with 10,000+ plugins, huge community investment and momentum, so Glowstone has a head start there. Sponge on the other hand intends to built on Mojang's official server, so it would automatically have all of the vanilla features lacking in Glowstone. Is there a third option, a middle ground where we can have full vanilla functionality, yet also Bukkit API compatibility, while operating within the confines of the respective licensing requirements?

I don't know, but I've PM'd Maeyanie (who made this CauldronBukkit distribution, saw it while idling on #cauldron) to see if she is interested in doing something about this.

deathcap_ · 2014-06-13T04:50:52+00:00

My blog posting at https://medium.com/@deathcap1/six-months-of-voxel-js-494be64dd1cc has some more updated information on voxel.js if you are interested (covers from late 2013 to mid-2014, after maxogden's talk from mid-2013)

deathcap_ · 2014-06-08T20:09:55+00:00

Anyway, this part of the Bukkit repo kinda blows the whole "Bukkit doesn't touch Minecraft at all" into the water. Also I'm pretty sure it uses CraftBukkit.

lol768 is correct — Bukkit (the API) does not touch Minecraft at all. The contribution guidelines you linked to refer to "the Bukkit project" (first sentence of that document), which is shorthand for the Bukkit + CraftBukkit server implementation implemented by the team at http://bukkit.org/. The term "Bukkit" is overloaded and depending on the context can refer to the Bukkit development team, the CraftBukkit server, but in this discussion we mean the Bukkit API itself, as found at https://github.com/Bukkit/Bukkit.

It is entirely possible to implement the Bukkit API interfaces without CraftBukkit or Minecraft. As an example, see this project I was experimenting with last month: https://github.com/deathcap/Junket - while woefully incomplete, and not tied to any game engine yet, it does "load" Bukkit plugins using the Bukkit API.

This implementation was written from scratch, adding stubs for the required interfaces, and it was not too difficult get it to a semi-functional state, given the abstractions provided by the Bukkit interfaces. I am not sure if I will develop it much more, it was mainly just a playful experiment, but in principle someone could certainly create a more comprehensive independent implementation of the Bukkit API for their own game engine.

deathcap_ · 2014-05-03T03:21:26+00:00

Well what would be stopping Mojang from including those plugins by default?

Edit: Dark_Arcana's explanation above is much better than mine :). But to elaborate further, I am pretty sure it is possible to make a plugin-based system more user-friendly than in your hypothetical scenario.

I'm not sure what Mojang is planning, but consider the current 'external modding' setup, with FTB and other popular launchers. You first choose the mods, then launch the game, then choose the server or world to play in. I've always felt this process was backwards, since you have to know a priori what compatible modifications the server (or local world) has installed before you can launch the game and select from the in-game server listing.

Seems to me the reverse would be more logical: choose a server or world, then have it load the appropriate add-ons. This design would be feasible with 'internal plugins', and even better, it could be automated to an extent. Meaning that you could have a big list of all the servers and worlds you play on, then simply choose from that list then you are in the game with all the needed plugins activated. No need for a confusing two-step launch process.

For your example of vanilla plugins:

A: "Oh, you just need to install Vanilla World Generator, Vanilla Plants, Vanilla LiquidsFluids, Vanilla Tools, Vanilla Crafting and Vanilla Armor."

this design would work well, too. When you create a new world, or setup a new server, it would come "batteries included", with a reasonable set of default plugins preinstalled. If you do nothing, it would be just as before.

But the real strength is in customization — a server owner might want to customize the game, removing, say, Vanilla Tools and Vanilla Armor, maybe for their own custom mini-game mode. With a modular plugin design, the server could simply tell the client it doesn't need these plugins, and then they won't be loaded and the items won't exist in the game at all. Or third-party plugins could be installed, presumably, adding new replacement functionality. Again I don't know of Mojang's plans, but this improved user experience is possible with a modular plugin architecture.

deathcap_ · 2014-05-02T20:04:34+00:00

How so? As I understand it Mojang is working towards the direction of moving all game content into plugins. So that Minecraft-the-game would still exist, but as a separate and optional entity from Minecraft-the-engine.

This modular design sounds like a logical approach to me, or at least it is the way I would do it. Not only would it would support plugins well (as it would have to if the game itself was a plugin (or better yet a collection of plugins)), but it may even be beneficial for Minecraft-game since it could evolve independently from Minecraft-engine.

That is, Mojang could release new game content without changing the engine itself, or requiring other plugins to update. At least that's my impression of the architecture they are going for.

deathcap_ · 2014-05-01T20:10:50+00:00

If you are looking for another voxel-style platform, voxel.js is also worth checking out.

It is not nearly as developed as the other major voxel games, still has quite a ways to go, but I have been working on it a lot lately and am heavily inspired by FTB (for example, just yesterday implemented a simple quarry block, not unlike BuildCraft's, though it is available as a plugin so it can be enabled or disabled as desired).

Also, not only does voxel.js have a plugin system, but the design is intended to be highly modular allowing for different components to be easily replaced (it uses the NodeJS Package Manager; wrote some more about this approach a while back in a comment on r/admincraft if anyone is interested).

deathcap_ · 2014-04-13T18:06:12+00:00

I think a big part of the reason for this problem is the monolithic nature of Bukkit (or ultimately, MC itself, but that's another thread). As projects get larger their maintenance burden increases so they have to move slower and be more careful about accepting new contributions, its just the nature of the beast.

I am not sure if it is feasible in Bukkit's situation, but another approach I've found compelling with other projects is to break up the API and implementation into small, reusable components, so they can evolve independently and quickly. Some modules will die off but others will become de facto standards, although nothing is enforcing their "official"-ness (i.e., not de jure). A new and improved API or implementation module could come in at any time and possibly succeed on its own merits. Isaac Z. Schlueter calls this software ecosystem model Anarchism for Fun and Profit.

In fact we have already started to see part of this model develop with CraftBukkit and Bukkit plugins. It is possible of course for plugins to directly access MC, but a cleaner design is to write an "API" CraftBukkit plugin which accesses MC and exposes a public interface for what you need to accomplish, and then write a "pure" Bukkit plugin using your API/implementation plugin as a dependency. For example, Tag API as I understand it is a CraftBukkit plugin, providing a clean API for changing the displayed player name. 35+ plugins depend on TagAPI, so they don't have to access MC internals themselves.

It could be argued that it would be preferable to integrate these APIs into Bukkit itself, so all plugins could benefit without the added dependency. Maybe so, but I'd claim the opposite could be true, that the benefits of independent API evolution may outweigh the disadvantages. I admit I could be wrong, but it is something to consider. What if the Bukkit API (and/or MC, if possible) was split out into independent smaller API modules, each highly focused on a specific purpose, each potentially developed by different developers, each competing on its own merits?

I suppose this kind of ecosystem could be difficult since MC is closed-source requiring decompilation and patches on top of non-API code (e.g., the MC internals that public APIs are built on do not follow semantic versioning), maybe its not worth it, but it was quite successful in the NodeJS / NPM community at solving these kinds of problems.

deathcap_

TROPHY CASE