Making the Premier Open-Source Fax Management System Even Better
These are some of the most common questions about hylafax.sourceforge.net and their associated answers.
The code repository that would become HylaFAX+ began to develop in August 2005 when the latest HylaFAX release was 4.2.1 and 4.2.2 was in its "release cycle". Great effort was made to keep the Sourceforge and hylafax.org repositories in agreement for the next several months after which point Sourceforge changes began to not get ported promptly to hylafax.org.
In contrast, with a few deliberate exceptions all of the changes that have occurred in the hylafax.org code repository have been ported to the HylaFAX+ (Sourceforge) repository. The list indicated above includes explanations of all noteworthy and deliberate exceptions. The exceptions are generally made for cases where the hylafax.org change introduces a troublesome or misguided feature or is merely a rewrapping of earlier HylaFAX+ work that does not offer greater benefit than the original.
Some HylaFAX+ changes were ported to the hylafax.org repository for the 4.3.1 release and then again some for the 4.4.0 release, but later releases did not include any additional HylaFAX+ work. So, for the most part, hylafax.org release 6.0.5 does not include many years' worth of work found in HylaFAX+ release 5.5.0.
So, yes, HylaFAX+ should rightfully be considered more-advanced than hylafax.org releases despite the version numbering.
HylaFAX.org does not have any official, published statement of organization or development. Mail archives from the site maintainer indicate merely that it is run "democratically" and that release cycles begin soon after they are called for and a majority does not dissent. The hylafax.org domain is owned and controlled by Darren Nickerson of iFAX. In practice, no formal development direction voting has ever occurred, and even "rough concensus" may not be followed unless the proponents follow up with code development contributions. Similarly, objections to development direction may go unaddressed.
Traditionally (especially prior to the inception of hylafax.sourceforge.net) hylafax.org releases occurred at highly irregular intervals, sometimes with as much as nine months between releases. Generally weeks may pass after a call for release and subsequent repository commits are made in anticipation of imminent release before a series of "betas" and "release candidates" are distributed. After that a final release is made: the entire process usually taking more than a month.
HylaFAX.sourceforge.net aims to continually commit code contributions (as soon as possible) and to cut frequent releases (usually one or two per month) containing incremental changes without any formal "betas" or "release candidates". Developers are expected to run their development code ("CVS") on production systems and participate actively on support and development mailing lists and forums.
See Eric S. Raymond's essay entitled "The Cathedral and the Bazaar" to understand much of the philosophical groundwork upon which HylaFAX+ operates. (For example: maintainer work ethic; release early, release often; listen to the customers; know when to hand the work off ... these are all ideals derived from that essay.)
The documentation on the hylafax.sourceforge.net website (i.e. the HOWTO) is intended to serve as an authoritative source of software documentation second only to the man pages within the source distribution itself. Per Sourceforge rules, the site may not promote or serve as advertisement for commercial activity (beyond that which Sourceforge, the site host, does impartially itself on the "project" pages and mailing list signatures).
The belief is, then, that this will encourage those with commercial interests to participate actively on the mailing lists and support forums instead of passively soliciting their services on a community-driven documentation website. Furthermore, the authoritatively maintained web documentation is intended to keep the developers mindful of "newbies" and to continually hold that documentation accountable for itself.
Yes, by most definitions of the word it is. And so is the HylaFAX at hylafax.org, too. (See history below.) However, the term "fork" is often perceived with a negative connotation that is undeserved either case.
Liberally defined, "forks" of HylaFAX are made by every UNIX distribution (i.e. Debian, SuSE, Gentoo) that carries it in some modified or customized form. However, these are more properly known as "pseudo forks" in that the resulting source code is not different enough to prevent portability of code development or cause the compiled and executed code to behave distinctly different from the original.
Similarly, HylaFAX+ does not operate run-time differently enough from earlier HylaFAX versions (or even current hylafax.org versions) to be a bona fide fork. In fact, some may claim that in some aspects (such as mail generation) HylaFAX+ operates closer to the original than do current hylafax.org releases. Code developments made in either repository are generally quite portable to the other. (The question more frequently being a matter of whether or not the code development actually was ported or not and not whether the development was applicable to the other repository.)
More appropriately, HylaFAX+ should be known as a "collaborative fork" in that all HylaFAX+ changes are done and documented in a way that should make it easy for HylaFAX.org maintainers to accept the same code changes. Despite the independent success that HylaFAX+ has found, the intent of its existence is not necessarily to compete with HylaFAX.org, but rather to find and use a better development approach and to encourage hylafax.org to do the same.
HylaFAX was originally authored by Sam Leffler while working at SGI and was publicly released in June of 1991. Upon his departure in 1997 Sam officially handed the maintainership to Matthias Apitz. A relatively small but thriving HylaFAX community, already disheartened by the lack of frequent releases just prior to Sam's departure, was eventually disaffected by Matthias's leadership. Darren Nickerson and Robert Colquhoun established HylaFAX development at hylafax.org in 1998 where two "4.1beta" releases quickly distilled. However, after the long awaited 4.1 release in 2001 - more than 2 years later - Robert's participation waned.
Lee Howard became involved at hylafax.org in 2000 and quickly became one of the most active mailing list participants and code contributors. However, after being frustrated for years with the pace of the releases and various other things, Lee set up his own HylaFAX development at Sourceforge in 2005 which eventually came to be known as HylaFAX+.
A more detailed history can be found here on the Wikipedia.
Currently Lee Howard serves as a "benevolent dictator". This, however, is not to be confused with a "cathedral" development approach. Indeed, HylaFAX+ is developed openly, encouraging community participation, contribution, and suggestions - very much a "bazaar". Besides readily accepting code contributions, Lee often will develop features simply upon request (when the community as a whole will likely benefit from it). Everyone has an equal opportunity to have their voice heard.
However, if you wish to have equal responsibility with Lee and if you share the philosophy discussed above, then he is completely willing to share the load with you. Inquire within. ;-)
After 5 years of frustration with limited success in trying to promote swift release approaches at hylafax.org, countless disagreements over policy and development direction, and continual conflict over iFAX's hand in those things at hylafax.org, Lee realized that he needed to promote his goals from outside of hylafax.org where he could proceed without interference.
Originally the HylaFAX.sourceforge.net site was conceived to serve twofold: 1) as a distribution point for pre-release versions of hylafax.org code called "subreleases", and 2) as a refuge for the HylaFAX HOWTO as authoritative documentation. (The "old" hylafax.org website containing the HOWTO was then soon to be replaced with a community documentation project.) Although the possibilty of forking being necessary was considered (and even partially anticipated), a code fork was not the original intention. Indeed, there was no reason for it: Lee had CVS commit access to the repository at hylafax.org, and to the best of his knowledge that access was not in jeopardy.
Arguably the manner in which this was initially done was somewhat clumsy. (There's no handbook to follow for this kind of thing.) However, in the end the conclusion was that hylafax.org did not want to even appear to endorse the Sourceforge site - by implication of the website looking similar, by the hylafax.org site being mentioned in the distributed code, or even by leaving announcements from "The HylaFAX Development Team" within the source documentation. (Notice that even to this day, more than five years later and with tens of thousands of downloads HylaFAX+ is not even mentioned on the hylafax.org website outside of the mailing list archives.) Thus the only way to address those concerns and yet still move forward was to fork, adjust the code, and differentiate the website.
This mostly stems from the history behind the fork. As it was originally intended to be a pre-release of the same code repository this would not likely have been an issue. The name "HylaFAX+" came about because some people expressed some difficulty at understanding the intended nature of the "collaborative fork": that HylaFAX development for the same software could be occurring simultaneously at hylafax.org and also at Sourceforge. Thus "HylaFAX+" was coined to be synonymous with "The Sourceforge HylaFAX Project". However, in this there was not an intended shift from "collaborative" towards "competitive". Rather, the naming was chosen simply to illustrate that HylaFAX+ was merely an advanced or superior version of the same HylaFAX software.
That said, when HylaFAX development began at hylafax.org in 1998, the software name was not changed to "hylafax.org" or anything other from what it had always been known. Just as this was appropriate then, it is certainly appropriate now for HylaFAX+ to refer to itself as "HylaFAX". After all - it is just an advanced version of the same thing.
Realize that software forks will be criticized anyway. Whether the same name is maintained or whether a rebranding occurrs, a fork will inevitably be criticized for equity theft on one hand and/or plagiarism on the other. Thus, the naming decisions for HylaFAX+ were made without consideration of the inevitable detractors' criticism, but rather they were made based on both anticipated and actual user feedback. To HylaFAX+ users they are using HylaFAX. There is no benefit to convince them otherwise.
Originally HylaFAX+ version numbers were of the form like "126.96.36.199", "188.8.131.52", etc. Again, This was done with the purpose of illustrating that HylaFAX+ releases were, essentially, pre-releases of what was to come later at hylafax.org. However, this illustration proved, over time, to be largely inaccurate - especially at times when HylaFAX+ changes were not getting ported over to the hylafax.org repository.
Furthermore, it became apparent that the "184.108.40.206" versioning form was actually prohibitive to the purpose of getting exposure to the code. Thus, the more traditional form of "5.0.0", "5.0.1", etc. was adopted. The numbering started with v5 so as to both illustrate the concept of an "advanced version of the same software" as well as to not conflict with anything that hylafax.org may want to use in the conceivably near future.
In 2009 hylafax.org chose to defeat the HylaFAX+ version numbering intent by choosing to release as 6.0.0 instead of another 4.4.x release or a 4.5.0 release. However, no HylaFAX+ features were adopted in that release, and consequently the version numbering chosen by hylafax.org has only seemed to confuse users who mistakenly expect that hylafax.org 6.0.x is "better" or "newer" than HylaFAX+ 5.x.x.
Take a brief look at the changes to HylaFAX+ since its inception. There is a seemingly endless fountain of more of that to come.
Sometimes this question is made in reference to Lee's commitment to the HylaFAX+ software and community. The answer to that is the same: there is no conceivable end to his participation and contribution here. To him HylaFAX is not not only part of his daily paid work routine, but it is also a passionate hobby-interest.
Sometimes this question is made in reference to the possibility of a reunification with hylafax.org. The answer to that is entirely open for consideration. The purpose behind HylaFAX+ was to promote change from the outside that wasn't successfully being promoted from within. Again, HylaFAX+ encourages hylafax.org to adopt HylaFAX+ code development as well as development approaches. If hylafax.org truly wants to adopt and embrace HylaFAX+, then reunification is certainly possible. That said, the chances of those conditions being met currently appear bleak.
Short answer: yes!
The longer answer is that HylaFAX+ contains not only a lot of features that aren't generally found in hylafax.org releases, but there are likely bugfixes and improvements which will benefit the user. That said, modern releases from either code repository are likely to be sufficiently adequate for most casual users. So if your OS distribution comes with HylaFAX, and unless you're comfortable about building your own package replacements, you may be better-served by using whatever comes with your OS distribution and then to simply encourage the OS package maintainer to adopt the HylaFAX+ repository in place of the one from hylafax.org if not already doing so.