Internet Explorer versus Mozilla
Page: 3/6
Part II: xMule vs aMule
2.1 Common misconceptions
Generally speaking, those who know about xMule and still choose aMule do so because a) it doesn't have all the latest bells and whistles of aMule (non-essential to file transfers) or because b) they are pessimistic because of a self-perceived lack of progress in xMule (generally based, again, on features). Another common mistake of former xMule users is that they are not adequately familiar with the UNIX-style stable/unstable release trees, and thus view negative experiences in the unstable (odd major number releases) as indicative of xMule on a whole. Unlike aMule and eMule, we have two seperate, clearly delineated trees -- one for new, untested code and one for stable, tested code. Unfortunately, people tend to instinctively believe that "higher number is more stable" when frequently, this is not the case in xMule (although it is 'theoretically' true with aMule and eMule, since they do not have stable/unstable trees). aMule does currently have a 1.2.8 and a 2.0.0, but this is not nearly the same as 2.0 is substantially different and has taken them over 8 months to get to release-candidate 7 of 2.0.0: aMule rcs function as vague hacks for a more intellectually-intensive and rewarding stable/unstable release system. Thus aMule's 2.0.0 is best viewed as a temporary artifact of unstable and/or untested code, and as soon as this proves otherwise, they will probably stop the use of
the 1.2.x tree altogether.
2.2 xMule: Stability over Features
At present, the development of xMule's User Interface and other miscellaneous bells and whistles not related to the transferance of files have been far less developed in comparison to that of aMule, which generally has three or four feature enhancements over every one of xMule's over the last year. Thus in many respects aMule is more user-friendly while xMule is more computer-friendly, optimally capable of working on the slowest systems. Traditionally, stable xMule releases (even major number) are less resource-intensive and in several time periods more (sometimes drammatically so) network-effiicent than then-existing versions of aMule. And while the last security audit of eMule-derived code was last conducted the week before aMule was created (Aug 2003), it seems likely that their additional features would also be vulnerable to more exploits than xMule's largely-refactored codebase.
2.3 Development Heirarchies
2.3.1 aMule: Proprietary Tradionalist
How to say this non-biasedly? aMule and eMule -- the projects most closely related to xMule -- utilize traditional heirarchical communication filtering structures generally based upon one's dedication to the project, so that only a select few have direct one-on-one immediate access to the projects' developers, code base (CVS) and developer forums. Generally, the most valuable of these services, direct one-on-one IRC communication and open CVS access, are heavily restricted to developers only, and there is annecdotal evidence that aMule (with an eMule developer in its ranks) has access to far more eMule resources than any xMule developer, giving them some significant advantages over us (such as private communiques on emule-specific protocol changes, etc). From a user's perspsective, [name withheld] was with aMule since literally before it existed. As a personal friend of its founder, he was personally interested in its development and thus wanted to feel a part of the project's evolution. When aMule became more close to eMule in early 2004, it instituted both developer-only real-time CVS access (far less useful 24 hrs archives are made available), developer-only forums, and developer-only IRC channel which users cannot be in. Non-coders such as [name withheld] were made to feel unwelcome and summarily banned from #amulecoders, which is password-protected. [Name withheld] was aMule's first tester and thought he was a friend of the team, so he felt even more betrayed.
2.3.2 xMule: Non-elitist Development
At xMule, the general attitude is that we are all human beings, some of us just happen to have a penchant for coding. Most development-related discussions take place in the public IRC channel, along with a healthy dose of discussions about current world events, philosophy, religion, politics, opensource...We're basically just a bunch of guys out for a good time! Some people cannot stand this ("It is a debauchery!!"), but hey, we need to realize that life is too short to try to narrowly define areas of conversation! One of the major advantages aMule has over xMule that is not likely to be negated any time soon occurs in the area of Public Relations. Just a simple google comparison of aMule and xMule will show the researcher that the aMule developers (notably Kry) spend far more -- I'd guess geometrically, maybe expontentially, more -- time in human interactions where aMule is concerned than any one has ever done with xMule; mostly because we are too busy coding. Thus, they generally tend to be more informed, sooner, as to nuanced changes to the ED2K protocol, as well as far more widely promoted than xMule. Due to eMule's 98% monopoly of the ED2K network, their preferential treatment towards the non-threatening aMule (which is every day becoming more and more just another mod of eMule) -- including directly linking to amule.org -- has caused aMule to become artificially more publicized than would be the case had the playing field remained equal. And that brings to us Part III of this article: my definately biased prognostications for why there is such hostility between xMule and aMule, along with a fairly comprehensive analysis of aMule's origins.
Next: Part III - On Hostile Forks
