Minetest.org and minetest.net both claim to be the stable branch of Minetest, similar to the FFmpeg vs. libav split. Expectedly, each site explains the issue differently. I can vouch for the fact that the 5.0.0 (originally 0.5) branch introduced many breaking changes, regardless of how minetest.net administratively labels it. They even backported some of the breaking changes into 0.4.17 (and possibly earlier “stable” versions, see below). The current release, 5.0.1, is administratively marked stable but doesn’t even have a recipe for stairs. As a contributor and server owner during this entire period (also going back to 0.4.13-git on the same server), I concur with minetest.org that minetest.net (at least since 0.5 on GitHub.com/minetest/minetest) is in technically-defined “fork” status (regardless of lack of “administrative,” or stated, fork status).

For over two years or so I ran a Minetest server owned by a high school, using the git (GitHub) version minetest.net’s Minetest 5.0.0 (previously called 0.5). I chose to use the git version since I am a developer and the server was not public, similar to why a mechanic may own a “fixer-upper.” However, I got in over my head and eventually had to be careful about updates and backups.

I spent the majority of my limited server maintenance time fixing other people’s mods (usually broken by minetest.net’s API changes on GitHub) and creating software to maintain the server, such as mass inventory editing and mass mod updating. Recently I started using Final Minetest, so now I can focus on improvements that I had planned starting about three years ago, but that I hadn’t implemented since I was instead dealing with the upstream issues.

As far as Minetest 5.0’s system of implementing community improvements, the Minetest.net devs usually go through a long process of closed discussions (:edit: or effectively closed discussions since laymen usually don’t understand IRC nor monitor the minetest dev IRC channel, and since the IRC points aren’t elucidated in the issue thread but do lead to closing the issue thread, and often overrule the majority of user feedback), sometimes taking months or years, even for minetest_game (which is a minimal collection of mods and not a full game though included and documented as such) then make or reject changes without notifying the community nor contributor, nor providing technical descriptions of the changes. I don’t believe this is an appropriate methodology for a community project, especially one that insists that even minor contributors do most of the work themselves, including changes that the core developers request. They often delete or change old Wiki articles completely without linking to an explanation of the changes. While I was using Minetest 5.0, my live map system I programmed in PHP and JavaScript from scratch eventually stopped working around when minetest.net deleted Python minetestmapper from their repo without notice and without an explanation of the engine changes that broke it (I found out recently that my python fork and hence PHP code are salvageable using Final Minetest, or a recent version of the binary minetestmapper fixed in late 2018, a year after I gave up on it). This deletion occurred during an endless discussion over line wrapping preferences in my minetestmapper.py pull request, in which I even conformed their code to PEP8, trying to fulfill their many prerequisites for the minor pull request (which initially affected only new console i/o and missing detection of colors.txt). A similar discussion occurred on my bones pull request, where the maintainers required that I remove a configuration option, enable_ in names of boolean variables, complete sentences, periods at the end of sentences, complete sentences, active voice, and verb tense consistency. The breaking changes and treatment of contributors who aren’t “insiders” has surely prevented Minetest from reaching critical mass following a surge in popularity that occurred around the release of Minetest 0.4.12 or earlier. This process was the initial concern that led to the split according to my conversations with minetest.org developers.

Minetest.org even had concerns with Minetest 0.4.16 (not just 0.4.17 as discussed above), so according to discussions with me, they started on 0.4.15 then painstakingly implemented the later commits, manually circumventing the bugs and compatibility breakages. The two-year process was difficult primarily because the minetest.net team technically forked but did not document the changes nor restrict them to the 0.5-5.0.0 branch. Another reason for the difficulty was the high number of bugs in the successive commits.

The Minetest.org team has been communicative and helpful toward server owners or users seeking to preserve worlds or builds, and toward me as a contributor. Even when they don’t have time, they will indicate their availability right away or in advance. Minetest.org has displayed a refreshing and distinguishing degree of professionalism. Final Minetest includes many mods in the included Bucket_Game, often fixing inconsistencies, shortcomings, and bugs in upstream functionality, coding style, and documentation. They also add many configuration options in case people don’t want certain additional features added by the increased set of included mods.

To provide administrative information regarding lineage though, I can also say have looked at removed IRC logs, at Wayback Machine pages, and at edited forum discussions–these sources indicate that minetest.net’s retelling of minetest.org’s history is highly redacted. Additionally, their one-on-one (to me) and public retellings are sparse, vague, and inconsistent with the source material. Even barring these issues with stated lineage, the technical changes are enough to make a convincing case for minetest.org’s releases being the direct successor to 0.4, the previous technically stable version.

:edit: I am not approving I am moderating comments at this time (though I can see them), as this is a controversial issue and I took great care to restrict this article to the technical aspects of the split. Since I can still read the comments using my admin login, I have already made one edit based on comments. Each side claims to be wronged, and I have studied the records in detail relating to those claims and have come to my own conclusions. However, that is beyond the scope of this article.

Mastodon

4 replies on “A Technical Explanation of the Minetest.org and Minetest.net Split”

  1. > The Minetest.org team has been communicative and helpful toward server owners or users seeking to preserve worlds or builds, and toward me as a contributor.

    but if they find out about the herasment and doxxing history and ask about it they start receiving thretening emails from minetest.org members theyre personal info exposed and theyre employers n family get sent threts

    this artikel is astro turfing at the finest

    1. I have verified that any information he posted online was from public profiles, as he claims. Whose astroturf have you been hearing, I wonder? (To anyone reading this, the comment to which I am replying was anonymous–and not really from OldCoder, of course)

  2. I assume you’re trying to be fact-based here, so let’s fix a fact. We never do “closed discussions” in Minetest for development issues, unless they are security related. Most parts of Minetest are mostly taken care of by a core developer who knows the part, and they can do some decisions by themselves, but usually discussions are done between developers on the #minetest-dev or channel or some of the other official Minetest channels on Freenode (which is very appropriate for an open source project), or on Github itself.

    The fact that Minetest has always prevailed within its many (now mostly historical) forks is mostly due to us persistently making changes towards consistency and quality, even if we do make missteps along the way and even if they are sometimes painful. Minetest.org does not really differ in any way from said forks, except for their false marketing and straight-up lying, which other forks have been courteous enough to not do, which I really appreciate.

    To make it clear: Minetest is the original project since 2010, started by me, and its only official website is minetest.net. The fork in question does not even have the right to the name.

    1. Thanks, celeron55. I’ve corrected the technical details, but I still consider your governance process to be opaque and I’ve clarified how in my edit. Also, you had years to respond to me and give your point of view. Everyone in your core group ignored me, and wouldn’t answer questions. However, minetest.org members were more than willing to communicate and provide evidence or leads to evidence for their claims. I waited a long time, then after no helpful responses, finally wrote the article. It was very tactful compared to the responses. If the company you keep didn’t behave the way they do, you’d be better off. Also, if your technology would consider code history, use cases, and quality when considering commits like MT6 does, you wouldn’t have the technical problems I described. The breakages introduced by Minetest 5 are unfortunate and my position on everything I haven’t changed in the article remains the same and is evident.

Comments are closed.

%d bloggers like this: