Announcement The future of Paper - Hard fork

After the release of the first builds for Minecraft 1.21.4, we are happy to share some even more exciting news with everyone. Following the successful rollout of our Mojang-mapped server in 1.20.5, we are taking a big next step for the project:

Hard fork from our upstream​

Since the project's inception, Paper has been built on top of Spigot, consistently staying up-to-date with features introduced to it. Today, Paper applies nearly 1600 additional patches with more than 130,000 lines of code over Spigot. As a result of such divergence, our strict policy to stay up-to-date with Spigot has been limiting the project, most noticeably with slower version updates since its updates to snapshots, pre-releases and release candidates are worked on behind closed doors.

Hardforking removes this unnecessary delay and sees Paper become its own independent project, streamlining development of the server and major missing API, such as our recent registry and item data component API. This does not mean that existing configs/API/behavior/etc. will be removed. Starting with 1.21.4, Paper will simply no longer be bound to Spigot's future changes, enabling us and the community to move forwards on our own terms.

While this may sound scary, we have bundled up some helpful disclaimers for each relevant user group down below. We are committed to making this process as smooth as possible for everyone. If any more questions arise, feel free to ask us on our Discord!

Server owners / administrators​

As a server owner/administrator, there will be no change initially. For now, both bukkit.yml and spigot.yml will continue to work how they always have. Plugins already running on the stable 1.21.4 builds as well as plugins compiling to older versions of Spigot will also continue to run. As the plugin API of Paper and Spigot slowly diverge, the only potential worry may be plugins trying to use Spigot features introduced after the hardfork.

We presume a large number of plugins to prefer Paper compatibility over Spigot already, given the current market share of the two projects. A huge upside for you is the considerably faster release speed of Paper during Minecraft releases, as mentioned prior. Post hardfork, we are able to update Paper to release-candidates, pre-releases and maybe even snapshots to get experimental builds out to everyone as early as possible.

Plugin developers​

Just like for server owners, there will be no initial change in the plugin API. Existing methods inherited from Spigot are maintained and will continue to work. This includes methods deprecated by us, like legacy text/chat color. However, we will no longer pull all new API added to Spigot after hardfork. To avoid accidentally calling such methods, we strongly suggest building your plugin against the Paper-API dependency. We are still open to manually pulling some new upstream API into Paper to ensure plugin developers do not lose out on functionality, but you should not rely on it.

Usage of server internals via paperweight-userdev will also continue to work as it has before, however, we recommend slowly preparing your plugin to run on a Mojang-mapped server with jar and reflection remapping disabled. This can be achieved with the -Dpaper.disablePluginRemapping=true startup flag. If you aren't already using paperweight-userdev despite using internal Vanilla classes directly, you should move towards it. If you are, you don't need to do anything else, as you can simply later remove the obfuscation step and will be compatible with the future change - only reflective calls need to be addressed. However, we will give you ample time to prepare for this and will continue to automatically remap plugins for a while. Once that happens, it will become much easier to support multiple versions with little internal changes, which the obfuscated mappings and arbitrary CraftBukkit package relocation currently prevent. The single set of standard mappings will also make debugging and code-sharing easier.

With the switch to Paper-API and later a Mojang-mapped server, your plugins may no longer run on Spigot. Paper's market share of 85-90% on recent versions (according to some of the largest plugins on bStats, including forks of Paper) should make it easy for you to support almost all of your users in the post-hardfork versions, even without being compatible with Spigot. Publishing plugins that require Paper can be done on numerous platforms, most notably Hangar and modrinth.

Moving our old version branches to a new repo​

Because we are merging in API/API-implementation source file history and the new branch will have an entirely unrelated git commit history to the previous branches, we will eventually delete all older version branches, everything from ver/1.8.8 up to ver/1.21.3. If you are in any way referencing them on our current repository, make sure to update their URL to:

https://github.com/PaperMC/Paper-archive

Our current compressed repo size is over 90MB - the new branch, despite having many many more commits, will be less than 35MB in packed size, meaning cloning the repository will become much faster once the old branches have been removed. On top of that, looking at the previous patch-file history will also be a lot easier thanks to cleaning up index and line changes from the history.

Paper contributors​

Hardfork affects contributions to Paper dramatically, most of it for the better. With hardfork, the Paper repository will receive a full restructure, moving the entire API and API-implementation straight as source into the repository. Contributions to these can now directly be made on the .java files, without the need to edit/rebuild patches. Changes to Mojang-owned sources will still be based on patches, but each Vanilla source file will be represented by a single, per-file patch. For large changes, like anti-xray and moonrise, Paper will also offer the old feature-based patch approach on top of the previously described layout, combining the best of both techniques, next to an updated decompiler (Vineflower) and mappings set (Parchment).

In order to preserve history, we have merged multiple git trees, including our full patch-file history, and those patches applied into real commits over the existing Spigot history. Older states containing decompiled Vanilla source files have been filtered. The history change unfortunately means that all open PRs will have to be closed later, and they cannot be force-pushed to target the new branch either. Please do not reopen PRs until we provide more detailed information on how to semi-automatically update old pull requests and have given the go-ahead for new ones.

Paper fork developers​

The main change you will have to deal with is the updated decompiler and mappings. We will provide you with more information once our initial update process is finished. New versions of Paperweight patcher will be published to be compatible with our new repository structure. For now, make sure you change upstream targets of 1.21.3 and older to the new archive repository.

Next steps/rough timeline​

It's hard to give an exact timeline, but you will be able to follow the rough progress of our hard fork process in the following GitHub issue: https://github.com/PaperMC/Paper/issues/11735

1. We will spend the following weeks updating the repository by changing the patch structure and fixing endless patch conflicts from the updated decompiler and new set of local/parameter mappings.
2. Once that is done, we will push these builds as experimental builds to ensure we didn't break any backwards compatibility or introduced any new issues.
3. Once we have finished our tooling around forks and userdev, we will post an announcement on how to update forks and notify Paper contributors on how to properly update their pull requests to the new main branch.

At some point down the line on new Minecraft releases, you can expect API and preliminary builds to be published even before the full Minecraft release day. Eventually, we will start cleaning up and automatically migrating the different configs, and slowly remove long-disfunctional deprecated API, but our focus remains to make these transitions as smooth and graceful as possible.

---

TL;DR​

This change allows us to work on snapshots, and to more freely work on major missing API. Contributions to Paper become a lot easier, and plugin development will become easier as well, both regarding API and server internals!

Server admins: No action needed, but you might no longer be able to go back to Spigot starting with 1.21.4.
Plugin developers: No immediate action needed, but you should compile against Paper-API starting with 1.21.4.
Paper contributors: You will have to redo your PRs, but we will tell you more about that later and provide you with useful scripts and tools.
Forks/server hosts: Migrate any use of the old version branches (e.g. ver/1.8.8, ver/1.21.1; everything below 1.21.4) to the new archive repository.

Thank you for making the Paper organization into what it has become today, we're grateful that so many people choose to use our software! Focusing on preparations for this process took a toll on Paper pull requests and Hangar activity, but we'll be able to churn through these much faster afterwards!

 

alternatives designed for paper dont work like original ones. Slimefun alternatives Such as itemedit doesn't have Industry related things.

I did also say fork in the message you quoted. That's also a possibility, for if a plugin chooses to only support a couple percent of their users, abandoning 95% of them.

i am super scared about paper's future, what if bukkit/spigot compatblity breaks?

I do not know what to tell you, as you appear unwilling to accept any possibility but catastrophe.

 

of course i am unwilling to accept any possibility but catastrophe. there is no better alternatives for slimefun. No One will try to rewrite Slimefun IV and some of the alternatives use commands or configs(which are vulnerable) instead of Java Code. of course i'm scared of it. sorry for off-topic by the way.

 

I don’t know why your personal choice of software to use becomes a responsibility of PaperMC. Seems to be a very self-centered viewpoint. Hard fork is generally a good thing for Paper itself. Either embrace it or be left in forgotten history. The world moves on without you or me - that's just how things are.

 

maybe i will consider embracing it... i have no choice, but to say goodbye to our Spigot Plugin Development.

 

I mean, the maintainer of Slimefun also indicated that from 1.21 onward, they will drop Spigot support in favor of Paper, so I honestly am not sure where all the fear comes from. Did you perhaps missed their announcement?

 

oh, thank god it's dropping support for spigot now. ok, now i understand. i have to accept the hardfork. and maybe, adapt to new modern API. i wasn't aware about the announcement because i didnt have a discord account.

 

is there a chance that Spigot API get replaced with new api and Dropped in the future when Paper Plugin API is complete?

 

No API that isn't already marked as deprecated for removal will be removed

 

well, seems that no matter what, we must Move Away from SpigotMC, And adapt to New Modern API and Forum. This Is Not an Temporary Moving from Spigot API, SpigotMC Forum, Reobfuscated Mapping Server, to Paper-API, PaperMC Forum, hangar&Modrinth, Mojang Mapping, This is an Exodus from Spigot API, Spigot Forum, The Destination is PaperMC, This Is An Exodus From Spigot, Where we accept the hardfork and Move on.

Your Hardfork was bit scary, but it was Liberating from the strict rules of SpigotMC.

Hope we see the Pre Release Versions!

 

Hello
I've been following this closely and have read the entire thread, including the responses from the Paper developers. I understand the purpose of this hardfork, but I agree with some other admins who are concerned because my server relies on numerous plugins to deliver its content.
So I submitted the question to a few developers to anticipate the impact this will have on my server and to see which plugins won't follow Paper when it decouples from Spigot. A large number of them replied that they won't support two APIs at the same time and that they will stick with Spigot. Furthermore, supporting only Paper would prohibit them from using Spigot site, which remains the most popular and well-known site for distributing their plugins. Despite the fact that Paper is now much more widely used than Spigot (63% vs. 16%), they prefer to continue supporting Spigot...

In short, all this is to say that our concerns remain valid at this time, and if the Paper hardfork breaks compatibility with the Spigot API in future, it's undeniable that many servers will find it very difficult to continue updating their plugins. Especially those that use a lot of them, including some that don't have an equivalent.
For us, the question to ask is whether it's more viable for our servers to switch back to Spigot while there's still time, or whether we take the risk of following Paper. It's a difficult gamble, fraught with uncertainty; not to mention the servers that have no choice but to remain on Paper due to its high resource consumption.

Anyway, thanks for your great work on Paper

 

We understand your concerns that some of the plugins you're currently using might no longer work on Paper in the future because the developers will only support Spigot. However, we know of many plugins that will either keep supporting both Spigot and Paper or outright only support Paper in the future, such as WorldEdit, WorldGuard, EssentialsX, and Geyser. Furthermore, for modern versions, there is an even larger divide between Spigot and Paper. For example, for 1.21.4, the amount of servers using Paper is >95%, so we're confident that many plugins will keep supporting Paper. Of course there might be some developers that will only support Spigot, but we expect the community to be able to provide forks or alternatives for these plugins for Paper.

 

A bigger concern I think is not plugins that are still being supported, but those that aren’t. Like if something in the paper api breaks vault for example even though that’s unlikely. Although thankfully normal Minecraft updates tend to break plugins that rely on NMS anyway if they aren’t updated.

When it comes to places where plugins can be downloaded, I doubt Hanger is going to become that popular at least not for a while. I find that more and more new plugins are being posted on Modrinth, but there are other alternatives like Built by Bit. The only reason why the spigot site is popular is because it was created years before Paper. Due to the cross compatability that new plugins strived for, they decided just to use the same website everyone else was using. That being said, Hanger needs some SEO work to become popular. Even the Paper plugins on my server I don't download from Hanger and instead mostly download from Modrinth. Modrinth has a huge SEO advantage mostly due to it being a large platform already for modding.

Maybe there is something Paper could offer plugin devs to get them to switch over to Hanger instead of Modrinth? There is already project importing from Spigot but it could be advertised more. Either way, Modrinth is a good platform for paper plugins already and I bet most plugins that now only want to support paper will just switch over to Modrinth if not to multiple sites.

 

I'm really glad you finally decided to do this! I don't understand the people who are against separating from Spigot — Spigot isn't going anywhere, and if someone wants to stay on it, they still can.

At the same time, for those who truly want to grow and move forward with new possibilities, this is a great decision!
Ideally, I’d love to see the Paper API become completely different from the Spigot/Bukkit API — to maximize usability, performance, and embrace a modern approach. I’d like the difference between Spigot and Paper to be as big as the difference between BungeeCord and Velocity.

Thank you for your work, and good luck to you guys!

 

 

Hello,

Only the owners of small or new servers can rejoice in such an unreasonable decision. Probably also those who can afford to pay developers a fortune to update their plugins and make them compatible with Paper. Older servers that rely on numerous plugins, sometimes abandoned but still working, will find themselves trapped in a fratricidal war between the developers of Paper and Spigot. Basically to show who has the biggest one..
When Paper was released, the deal was that all Spigot plugins would remain compatible, otherwise they knew the admins would stay on Spigot. We, the admins, trusted them, and now that they've tricked us, they want to destroy this very important compatibility. Most of those reading this won't understand because they haven't been involved in Minecraft servers for 15 years, and won't be able to grasp the issues involved.

A well-thought-out and reasonable solution would instead be to create a new fork of Paper (ModernPaper, for example) while maintaining the current Paper branch compatible with the Spigot API. I sincerely hope that some developers will continue to maintain a Spigot-compatible version of Paper because without it, servers like mine will simply disappear because the majority of their plugins will no longer work.

The current offering of plugins exclusive to Paper is ridiculous compared to the Spigot-compatible offering. Hangar is also extremely poorly designed, while the Spigot website is a benchmark in its field; everything is clear, each plugin has its own discussion thread, including comments, whereas on Hangar, everything is decentralized; we don't feel like we're part of a community, unlike on the Spigot website. Plus ther's no activity on forums . There's no support on the website, but it redirects to the Discord pages for each plugin, except that Discord doesn't allow you to have more than 100 servers (except for those who can afford to waste their money on Nitro...).

Now that I've trusted Paper in the past, I'm stuck; my server will no longer run on Spigot because I've benefited from Paper's performance while having confidence in it. So I can't even go back to Spigot if I want to keep my 14-year-old server alive, and even though no one here cares, I'm disgusted because it's going to destroy 14 years of work. Why? Because developers are bored and want to turn a 1950s car into a post-2000s prototype. All we want is for our servers to actually work. If we want a more powerful plugin API, we'll move to other forks.

I know no one here cares, but it feels good to express my concerns. Contrary to what you might think, I'm not angry—I'm a nice girl—but I'm just disgusted and very worried that my community's adventure is coming to an end because of an unreasonable decision

Have a good Sunday

 

Reasonable server owners always keep their servers updated.

Paper has always supported only the latest version and nothing else. Because of that, I don’t see how any of your points are valid. Older versions aren’t supported in the first place, hardfork or not.

There are plenty of plugins available on both Hangar and Modrinth these days. Spigot is no longer the only place for resources. If you didn’t know that, you probably haven’t been keeping up with the latest developments in the Minecraft space.

Running an outdated server is like using Windows XP in 2025. It’s insecure, full of exploits, and prone to crashes, since only the latest version receives patches.

I feel like you are the one being unreasonable here. Project moves on and being forever stuck supporting legacy will only stagnant the development which is exactly why Spigot has been left behind in first place (as you mentioned yourself in the post, you cannot live without Paper’s performance patch).

 

I'd just like to point out that, much like we may someday do when enough time has passed, spigot has regularly broken older spigot plugins. This isn't new. Devs have always had to update things, and ancient plugins have always eventually broken. Vault touches one tiny piece of API that has remained untouched and is an exception.

You are definitely taking a fairly small impact on servers and exaggerating it to a scary event. Please do not be afraid. Things will be okay and we are here to support you through the gentle changes. Visit us on discord if you want more of a conversation than the slowness of forum posts.

 

My server is updated to latest game version. But not all of

Reasonable server owners always keep their servers updated.

Paper has always supported only the latest version and nothing else. Because of that, I don’t see how any of your points are valid. Older versions aren’t supported in the first place, hardfork or not.

There are plenty of plugins available on both Hangar and Modrinth these days. Spigot is no longer the only place for resources. If you didn’t know that, you probably haven’t been keeping up with the latest developments in the Minecraft space.

Running an outdated server is like using Windows XP in 2025. It’s insecure, full of exploits, and prone to crashes, since only the latest version receives patches.

I feel like you are the one being unreasonable here. Project moves on and being forever stuck supporting legacy will only stagnant the development which is exactly why Spigot has been left behind in first place (as you mentioned yourself in the post, you cannot live without Paper’s performance patch).

I think there's a misunderstanding^^
If the future of Paper worries me, it's precisely because I keep my server up to date. Otherwise, I wouldn't worry about it!

My server has always been kept up to date since its creation and is currently at 1.21.4. The map hasn't been reset for 14 years, yet I keep it up to date, without deleting a single build. I work like crazy to keep my server up to date like you've never seen anywhere else, I assure you.
So no, the problem isn't the server itself; otherwise, I wouldn't worry about future versions of Paper^^ I'll stick with an old version and that's it. The problem is the many plugins we use, many of which haven't been maintained for years but still work. My server has always been free for its users (no pay-to-win, no store, nothing!), but it costs me a fortune, and my small salary won't allow me to pay for so many updates. And I'm not the only one in this situation.

Of course, I've been aware of the various sites for downloading plugins for a long time, and I even saw their creation, just like Paper, but that doesn't change anything. There's no equivalent for many of my plugins, and the offering is much smaller and less extensive than Spigot. Even if more and more devs publish their plugin on Modrinth, Polymart, MCModel etc. they are the same, there is very little difference except that the offer is spread over several sites instead of being on the same single site such as Spigot.

The other problem is that we use many niche plugins, which are part of the specific features of my server and are unfortunately unique and without equivalent... I've already looked at the plugins and the developers a bit, and this hard fork will completely divide the community. A large number of developers won't follow through, even though their plugins are paid. Others don't really know what they'll do, and others will simply stop developing plugins. I'm not the one saying this stupidly, but rather them when I contacted them about my concerns.

Paper forgets where it comes from, its origins, and what made its existence possible.

I'd just like to point out that, much like we may someday do when enough time has passed, spigot has regularly broken older spigot plugins. This isn't new. Devs have always had to update things, and ancient plugins have always eventually broken. Vault touches one tiny piece of API that has remained untouched and is an exception.

You are definitely taking a fairly small impact on servers and exaggerating it to a scary event. Please do not be afraid. Things will be okay and we are here to support you through the gentle changes. Visit us on discord if you want more of a conversation than the slowness of forum posts.

It's true that I'm worried because my server is the foundation of a very nice, close-knit community, and if I can't update my server because of all this, we all know how it's going to end... I'm so afraid that my server will have to remain stuck on one version of the game because most of its unique features will no longer be compatible. I've worked so hard to maintain this community for almost 15 years that, of course, such an announcement worries me more than anything else. I'll probably join your Discord channel. Maybe it'll do me some good to chat with you. Sorry if I came across as rude; that's not my intention, I'm just scared.

 

Older servers that rely on numerous plugins, sometimes abandoned but still working, will find themselves trapped in a fratricidal war between the developers of Paper and Spigot.

A lot of these plugins only still work due to Spigots attitude towards never breaking plugins ever (except for the random coin toss in which they broke API in manners that could cause duplication issues or just crash servers with 0 warning mid-release cycle), to the degree that they invested the effort into a chonky mechanism which rewrites the code of every single plugin that loads, ever; and have often refused to expose features to plugins in order to prioritise legacy plugins over being able to do basic operations like query the biome of a chunk. They finally accepted that this would harm their ability to move forward and eventually began working on some of the things the developer community had been asking them to do for a decade. The bytecode rewriting stuff is sadly something the team has decided to carry on with going forwards in order to let devs pretend that mojang isn't moving the ecosystem forward.

When Paper was released, the deal was that all Spigot plugins would remain compatible, otherwise they knew the admins would stay on Spigot. We, the admins, trusted them, and now that they've tricked us, they want to destroy this very important compatibility.

At the time, that was a goal we considered beneficial for both the community and ourselves. In good faith, we cannot refuse to move forward with the Minecraft ecosystem. We either adopt Mojang's efforts to improve the power available to server owners or give up and close shop. We have consistently talked about our plans to break away from spigot for years now, in public, there is no tricking here, we just finally decided we could no longer remain in our current situation and decided that it was time to deliver on that promise.

A well-thought-out and reasonable solution would instead be to create a new fork of Paper (ModernPaper, for example) while maintaining the current Paper branch compatible with the Spigot API.

Reasonable? Are you paying us for this extra effort that would double, if not triple, the amount of work we're doing? A large part of the reason why we hard forked was because the maintanance over the top of spigot was becoming increasingly unbearable; The current update has some things that we need to look into improving, such as the bus factor of various dependencies, but it was nice to be able to actually look into writing API for stuff that's needed going forward. This was only going to increasingly become an issue as mojang starts working more on various things, such as making it possible for servers to define custom Items, and as they work on their data component system, something which spigot seemingly has 0 intent of actually supporting properly. We're only planning to expose more features towards the API in order to allow them to do things that require API breaks in order to pull off, such as, when mojang delivers on the framework, the support for custom items, something which is literally impossible to handle using the currently supported API from upstream.

Hangar is also extremely poorly designed, while the Spigot website is a benchmark in its field; everything is clear, each plugin has its own discussion thread, including comments, whereas on Hangar, everything is decentralized; we don't feel like we're part of a community, unlike on the Spigot website

Hangar is generally a work in progress, and many other platforms are out there, as noted. There is also places for feedback on suggestions and improvements, though, some aspects, like commands, are a bit of a concern more in terms of policy (i.e. do we try to manage aspects of moderation that spigot refuses to deal with, or, do we just leave it to be an unmoderated area outside of stuff we are morally/legally required to deal with).

I do not know a single developer who considers Spigot's resource section to be a benchmark. If anything, during my years of being there, I saw consistent complaints and feature requests against that system, which Spigot is unable to fulfil. it's a Forum running a plugin that allows people to list stuff and doesn't support any basic feature that exists within the rest of the entire ecosystem that devs have been begging for for years, such as the ability to have teams so that they don't have to share account passwords if they want somebody else to be able to publish a plugin, efforts on the search tool to allow people to find stuff; automated access for plugin devs to be able to publish to the site using more standard tooling, and other means of being able to poll the website in a manner which doesn't end up with the site owner sending legal threats because you wanted to make it possible for somebody to query the website using a well designed API.

Plus ther's no activity on forums . There's no support on the website, but it redirects to the Discord pages for each plugin, except that Discord doesn't allow you to have more than 100 servers (except for those who can afford to waste their money on Nitro...).

The reality is that forums are basically dead; this has been a long-standing trend on the wider internet, for the worse. Between growing up, meaning that I no longer have the leisure of browsing a forum all day as I did 10 years ago, and the fact that Discord is just there, it's pretty hard for many to justify pursuing the forums when they can have more active conversations on Discord.

Why? Because developers are bored and want to turn a 1950s car into a post-2000s prototype.

Bored? The situation was unmanageable. We were unable to browse our patches folder. Merging in PRs was an entire bunch of operations due to how many patches we were trying to maintain that the entire process of merging in a PR was an entire bunch of steps in which often resulted in moans because that one trivial PR you merged made it impossible to merge in this other PR we needed without another half an hour dedicated to this, resulting in multiple hour dedicated to the PR queue only to be able to merge in a handful of patches.

Because developers are bored and want to turn a 1950s car into a post-2000s prototype. All we want is for our servers to actually work. If we want a more powerful plugin API, we'll move to other forks.

Mojang is moving forward, more so these days. What is the point of existing as a project whose goal is to improve performance and expand upon API if we're not going to expand upon the API and support the things that developers ask us to provide API for? We might as well just throw the towel in, archive the repo, and close the discord/forums.

Paper forgets where it comes from, its origins, and what made its existence possible.

Paper was a little fork maintained by a group of people because they found it fun to do so. We continued to expand over the years because we added features and an API that people wanted, which we felt would be worth the effort to maintain. We never intended to get big; this was generally just a fun project we enjoyed sinking time into, wondering if one day we'd ever be able to break away from Spigot and start working on the things we wanted to do and that plugin developers and server owners wanted us to do. The project started with two people and grew as people wanted a place where they could work on things spigot had no interest in supporting, we've come to the point where spigots areas of "no interestin supporting" pretty much covers the direction that mojang was steering into for the past decade, and many of our decisions to not work too much on the stuff spigot refused to support has consistently bit us. Even before the hard fork, we'd started to lose compatability with spigot plugins due to them once in a while working on API they'd said no to in the past, resulting in many occasions where we had to refuse to do the thing we set out to do out of concern that spigot would do something that would break our ability to remain compatible with them.

 

A lot of these plugins only still work due to Spigots attitude towards never breaking plugins ever (except for the random coin toss in which they broke API in manners that could cause duplication issues or just crash servers with 0 warning mid-release cycle), to the degree that they invested the effort into a chonky mechanism which rewrites the code of every single plugin that loads, ever; and have often refused to expose features to plugins in order to prioritise legacy plugins over being able to do basic operations like query the biome of a chunk. They finally accepted that this would harm their ability to move forward and eventually began working on some of the things the developer community had been asking them to do for a decade. The bytecode rewriting stuff is sadly something the team has decided to carry on with going forwards in order to let devs pretend that mojang isn't moving the ecosystem forward.

At the time, that was a goal we considered beneficial for both the community and ourselves. In good faith, we cannot refuse to move forward with the Minecraft ecosystem. We either adopt Mojang's efforts to improve the power available to server owners or give up and close shop. We have consistently talked about our plans to break away from spigot for years now, in public, there is no tricking here, we just finally decided we could no longer remain in our current situation and decided that it was time to deliver on that promise.

Reasonable? Are you paying us for this extra effort that would double, if not triple, the amount of work we're doing? A large part of the reason why we hard forked was because the maintanance over the top of spigot was becoming increasingly unbearable; The current update has some things that we need to look into improving, such as the bus factor of various dependencies, but it was nice to be able to actually look into writing API for stuff that's needed going forward. This was only going to increasingly become an issue as mojang starts working more on various things, such as making it possible for servers to define custom Items, and as they work on their data component system, something which spigot seemingly has 0 intent of actually supporting properly. We're only planning to expose more features towards the API in order to allow them to do things that require API breaks in order to pull off, such as, when mojang delivers on the framework, the support for custom items, something which is literally impossible to handle using the currently supported API from upstream.

Hangar is generally a work in progress, and many other platforms are out there, as noted. There is also places for feedback on suggestions and improvements, though, some aspects, like commands, are a bit of a concern more in terms of policy (i.e. do we try to manage aspects of moderation that spigot refuses to deal with, or, do we just leave it to be an unmoderated area outside of stuff we are morally/legally required to deal with).

I do not know a single developer who considers Spigot's resource section to be a benchmark. If anything, during my years of being there, I saw consistent complaints and feature requests against that system, which Spigot is unable to fulfil. it's a Forum running a plugin that allows people to list stuff and doesn't support any basic feature that exists within the rest of the entire ecosystem that devs have been begging for for years, such as the ability to have teams so that they don't have to share account passwords if they want somebody else to be able to publish a plugin, efforts on the search tool to allow people to find stuff; automated access for plugin devs to be able to publish to the site using more standard tooling, and other means of being able to poll the website in a manner which doesn't end up with the site owner sending legal threats because you wanted to make it possible for somebody to query the website using a well designed API.

The reality is that forums are basically dead; this has been a long-standing trend on the wider internet, for the worse. Between growing up, meaning that I no longer have the leisure of browsing a forum all day as I did 10 years ago, and the fact that Discord is just there, it's pretty hard for many to justify pursuing the forums when they can have more active conversations on Discord.


Bored? The situation was unmanageable. We were unable to browse our patches folder. Merging in PRs was an entire bunch of operations due to how many patches we were trying to maintain that the entire process of merging in a PR was an entire bunch of steps in which often resulted in moans because that one trivial PR you merged made it impossible to merge in this other PR we needed without another half an hour dedicated to this, resulting in multiple hour dedicated to the PR queue only to be able to merge in a handful of patches.

Mojang is moving forward, more so these days. What is the point of existing as a project whose goal is to improve performance and expand upon API if we're not going to expand upon the API and support the things that developers ask us to provide API for? We might as well just throw the towel in, archive the repo, and close the discord/forums.


Paper was a little fork maintained by a group of people because they found it fun to do so. We continued to expand over the years because we added features and an API that people wanted, which we felt would be worth the effort to maintain. We never intended to get big; this was generally just a fun project we enjoyed sinking time into, wondering if one day we'd ever be able to break away from Spigot and start working on the things we wanted to do and that plugin developers and server owners wanted us to do. The project started with two people and grew as people wanted a place where they could work on things spigot had no interest in supporting, we've come to the point where spigots areas of "no interestin supporting" pretty much covers the direction that mojang was steering into for the past decade, and many of our decisions to not work too much on the stuff spigot refused to support has consistently bit us. Even before the hard fork, we'd started to lose compatability with spigot plugins due to them once in a while working on API they'd said no to in the past, resulting in many occasions where we had to refuse to do the thing we set out to do out of concern that spigot would do something that would break our ability to remain compatible with them.

Thank you for your comprehensive response I won't bother you anymore; I'll see what the future holds...

Despite my concerns and criticisms, I thank you for all the work you've done over the years on Paper. I just hope I can continue the adventure with you.

Have a good Sunday, everyone!