Internet Explorer versus Mozilla
Page: 2/6
1.1 Project of Hobbyists
From my long-standing dealings with both the individuals and collective of
aMule developers, it seems apparent that aMule is best described as a project
for hobbyists. Most, if not all, of the main aMule coders (including its founder
Colin Stephan? and main coder Angel Vidal) have known C++ (which aMule
is coded in) for less time than xMule has existed. Nothing wrong with this.
1.2a aMule's Strategic Paradigm
aMule tends to focus almost exclusively on catering to end-users' feature
requests, adding new features, and debugging their new code (which is
statistically always more error-prone than revised code). As such, aMule started
as a verbatim copy of xMule as of 2003-08-22 by a non-xMule developer. In order to save time and inherrent struggles with the ever-changing eMule
protocol, they have tended to copy verbatim large percentages of eMule code over
the last 9 months (3/4 of their history) after largely stopping the same
practice of copying with xMule at around June of 2004. Because of its
apparently laissez-faire coding fitness requirements, and because they tend not
to have stable/unstable release trees, part-time code contributors are more
common at aMule than xMule. Indeed, the bulk of aMule code contributors joined
the project after submitting patches for relatively-mundane coding errors that
generally are weeded out (and thus not widly experienced) wiht the use of
stable/unstable release trees.
1.2b xMule's Strategic Paradigm
We at xMule tend to favor long-term stability, extensibility and maintainence over short-term feature enhancements, or even short-term stability. The ultimate goal is to have the most robust and extensible (read: modular) cross-platform peer-2-peer system for any network. As such, skill requirements for the xMule Team are higher than most projects, and progress is less dramatic than aMule. For the last year and 1/2 we have been redesigning and re-implementing xMule, piece by piece, so that in the -- hopefully near -- future we may add features at a fraction of the costs that traditional monolithic and unmaintainable applications would take. Like Mozilla, it has taken some time to reorganize; and like Internet Explorer, aMule has displaced xMule as the most-used ed2k client for non-win32. Whenever a decision had to be made about proceeding with new user-oriented functionality versus improving the internal mechanisms or transfer protocol of xMule, we have predominantly chosen the latter. The ultimate goal, of course, is to create a product that in the future will takes us less and less time and effort to expand; to steadfastly refactor a system that needed so much redone in order to become great.
Next: Part II - xMule vs aMule
