The only problem is, MailForge was never designed to be an exact duplicate. Our press release announcing the release of MailForge 1.0 said the following: “providing users with a familiar look and feel, while at the same time adding features and abilities to further enhance the user experience.”

Nowhere does that imply it would be an EXACT duplicate. Our goal, rather than creating an exact duplicate, is to create an email program for power email users. In many cases, this will mean mimicking Eudora, since it was the quintessential power user email program. In some cases, however, Eudora’s way of doing things is decidedly less than ideal, a throwback to a time when operating systems and email were far simpler. In these cases, we choose not to follow Eudora’s model, instead implementing features the way we think they should be.

Hopefully, that leads to a better email client. It does not, and never will, mean that MailForge is an EXACT Eudora duplicate.

Once we are confident it has fully been addressed, we will release MailForge on Tuesday, April 17.

Once again, thank you for your patience.

Please accept our apologies for the delay.

We believe we’ve finally ironed out the bug that has prevented us from committing to a solid date for MailForge 3′s release date. As we previously stated, this bug was due to a poorly documented Apple API that relates to how we display HTML emails.

Now that we have this worked out, we will be release MailForge 3 on Monday, April 2.

Thank you for your patience.

Where We’ve Been
When the MailForge project (then Odysseus) first started, we felt an unnecessary need to get MailForge out ASAP. As a result, some poor decisions were made early on that have caused us a great deal of grief throughout the project. As one example, we licensed closed-source code from third-parties (yes, we realize this is the same mistake Qualcomm made) that ended up being a hinderance to us for a long time.

In addition, we have struggled with performance elements that have had profound impacts on widespread features. For example, performance limitations with SQLite have created a slew of problems with sorting. These performance issues were only recently overcome.

Where We Are
Over the last year or two we have been working on rewriting all of the affected portions of MailForge. Unfortunately, integrating these rewritten and improved features into the original codebase has presented all new challenges. This has led to the “two steps forward, one step backward” syndrome that has plagued MailForge for some time.

Where We’re Headed
As announced in other sections of the forums, we have already embarked on a complete rewrite. This will represent a 93 – 95% rewrite of the original codebase. As stated, we have some modules and portions of the programs rewritten already, waiting to be plugged into an improved framework.

In the course of this rewrite, our main focus will be to make sure that each and every feature works perfectly … before we move onto the next. To ensure this level of performance we will be releasing incremental Alpha and Beta releases to get user feedback.

Timeframe
While we absolutely will not commit to an exact date, we can say that the rewrite will be in the “months” range. We are working as fast as possible, and will shortly provide a detailed Roadmap. We will also start releasing the early builds in the very near future.

In conclusion, we want to thank everyone for their patience. As we stated at the beginning of this project, we are in this for the long haul. We rely on MailForge for our internal email and look forward to many years of development.