First, in-game mod selection and download is an important strategic direction for Mojang as made clear by this sentence in Mojang's announcement:
In addition to the bukkit members, Daniel Kaplan (@kappische) will join to handle the project lead to coordinate Minecraft’s broader goals.
Second, it was a brilliant hire in a couple of ways.
1. As volunteers the Bukkit team could have done anything; while most people modding Minecraft have chosen to do the fun thing and implement new game features, the Bukkit devs instead chose to dig in and do API infrastructure work.
Their experience and self-selected API focus makes them the best people for the job.
2. Bukkit's About Us page includes this:
This advantage is further extended by our design choice to keep in the mind the possibility of 3rd party Minecraft servers needing a modding and plugin interface. That being said, when any 3rd party developed Minecraft server becomes stable, Bukkit will be there to allow our collection of plugins to work with them too through a new interface, without any work required for the plugin author to make it compatible.
"Third party Minecraft servers", now there's a phrase to strike terror in Mojang's heart. The arrival of third party Minecraft server software would begin to wrest control of Minecraft from Mojang in the same way that PC compatibles took control of the PC from IBM in the 1980s. Good for customers, not so much for IBM and Mojang.
While open source software can't be killed, projects can be robbed of momentum, in this case by hiring the staff and focusing their efforts elsewhere. So this is a good move for Mojang as it probably delays somewhat the arrival of viable third party servers. The Bukkit devs weren't working on third party servers, but they were clearly sympathetic in anticipating their arrival; in Mojang's employ they will be less so.
Third, it means that the official Mojang mod API is still months away. Instead of delivering an API solution in March, Mojang is just starting its design. So don't look for anything before summer. And considering the server and client work necessary to support in-game mod selection and download, a late summer or fall timeframe is likely more realistic.
Fourth, and this is not new, it means that ModLoader, ModLoaderMP, AudioMod, Forge, Bukkit, and several other small APIs are all dead once the official mod API arrives. This is a good thing; these mods would never have existed in the first place had Mojang fully supported modding from the outset. If Mojang stands to benefit from the Minecraft platform, then it, not the community, should do the work to implement and support that platform.
Fifth, Spout refuses to die and is attempting to exploit Bukkit's imminent demise by encouraging people to switch over to it. Spout needs to do this now because it will be a very tough sell to get people to switch to its launcher once the new official client arrives with in-game mod selection and download. Not to mention that Spout will be interfering with Mojang's strategic goals.
Sixth, since Mojang is just getting the design process underway, few details have been worked out at this point and there are still many unanswered questions.
Seventh, since Mojang will be hosting the download files once in-game mod selection is available, any incidental revenue associated with downloads currently earned by modders from URL shorteners like adf.ly will disappear. It remains to be seen how Mojang might replace that revenue stream for modders.
Eighth, once in-game mod selection is available, presence in the client's list of downloadable mods will be all-important. Absence from the in-game mod list will render a mod invisible to the great majority of Minecraft users. It's not clear if Mojang will have an approval process for mods, or whether all mods will be accepted. I think it's likely that the arrival of the first offensively tasteless mod in the mod list will cause Mojang to initiate an approval process to protect Minecraft's family-friendly orientation.
In-game mod download will also give Mojang an effective incentive with which to shape the behavior of modders. It will have a carrot in the form of featuring a mod, and a stick in the form of removing a mod from the list. Thus, should Mojang develop a Code of Conduct for modders, it won't be toothless.
Ninth, modpacks will die. The convenience of modpacks won't be needed once in-game mod selection and download arrives. Many modders will be quite happy to see the demise of modpacks and may help it along by revoking permission to include their mod.
Finally, this move further complicates Curse's strange relationship with Mojang. I had wondered about Curse Client support for Minecraft mods, but after nothing was announced at Minecon it seemed that this wasn't in the cards. When Curse signed the Bukkit team it began to support server mods, and today lists for download 2,475 Server Mods and 48 Client Mods. Jens has stated that in the future single player Minecraft will function by connecting to a local server, thus unifying the current split between single and multiplayer mods. Thus it appears that Mojang will reclaim server mod hosting once it implements the mod support in the client.
[Updated to add the ninth thought about modpacks.]
Posts
