I am not a C++ programmer, nor a project manager, but I have enough
experience to see this project spiraling into the dust. As several
people have said, it looks to be just a collection of random thoughts
about what needs to be done. There appears to be no big picture and
therefore no plan to get there. Without the big picture, some of the
tasks could end up being irrelevant or a waste of effort. And without
a plan, the number of people likely to back the Kickstarter is going
to be low.
As I see it, the phases in this project will include at least the following:
Get the Windows version working reliably to provide a platform for
testing future work. Do not add any new features.
STOP ALL DEVELOPMENT! Put together a project management team. Get a project
manager. Make a plan for what is to be done and a rough timeline.
This is important as without this there are unlikely to be many
volunteers to help. This needs to be done right at the beginning to
avoid the project getting a bad reputation.
Put together a team with the required skills to implement the plan.
Start working according to the plan.
Now the plan needs to identify what the final goal is, perhaps something like:
To create an open source e-mail client based on Eudora that will run
on at least Linux, Mac, Windows.
One might also add which operating systems are going to be targeted,
eg, Windows XP and later, Mac OS X Snow Leopard and later, flavours
of Linux. This is important because different development software
and software libraries may be required to work with all those
operating systems.
It then needs to list all the major tasks that need to be done, and
to give them a priority. Dependencies need to be considered in
determining priority, eg, it is no good working on something that
cannot be tested until something else is finished.
Tasks then need to be allocated to developers or teams of developers.
This could be by people volunteering to do particular tasks, provided
that meets the priorities.
Estimates of the time needed for each task should be identified to
allow for organised allocation of work. If a task is going to take
six months, it needs to start earlier than one which will take one
month.
Regular monitoring of progress is needed, so that if one area is a
bit slow, additional resources can be directed that way.
Milestones will show that progress is being made.
Some major decisions are going to have to be made, particularly in
terms of supporting other platforms. It would be silly to implement
something that does not translate easily to another platform.
Just some food for thought.
Last edit: David Morrison 2018-09-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Point number one is self-contradictory. Some existing features needed for the product to compile cost money—inordinate amounts of money, in fact. That is the case with Stingray and Wintertree Sentry. We need to replace those features with an Open Source analogue, just to get the Φ#¢κing thing to compile.
We do in fact have a plan, though timings haven't been worked out; I'm planning for delivery in January, perhaps February, of a version that will open, check spelling, and send and receive eMail under Microsoft Windows. The plan is accessible at https://pad.riseup.net/p/hermes-keep.
Putting together a team has been frightfully difficult, and I'd go so far as to say Sisyphean, because people want a version that will compile before they work on it, and it needs work to be compiled.
A lot of the management has been through the back channel, as it were—through private eMail. I'm aware the lack of publicly visible coördination presents a problem for people that want to see evidence of work before they commit to a project of this magnitude, and I'm actively working to find an alternative.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
David wrote a great email expalining what he thought with the project. I completely agree with his assesment, and with his high-level approach to bootstrapping the project.
The "plan" I've seen is just a list of goals. I don't think much thought has been given to timing, dependencies, or ownership. Before anyone knew anything about me, and before I knew the names of anyone else on the project, a set of tasks were assigned to me.
Most concerning to me, which David also identifies, is the lack of a big-picture vision for the porject. What is it meant to do? What are the priorities and how do they trade-off? What does success look like? What's my motivation? How can I (or anyone else) best help?
Complicated software projects can't be successful without guidance and planning. I see evidence of neither so far. I might consider helping out -- I don't mind working for free, but I don't want to involve myself with a project that's doesn't have what's necessary to make itself succeed.
I could help with the fundamentals, others probably could, too. Ted's response doesn't demonstrate to me that there's an acknowledgement that the fundamentals are actually missing, not to mention a plan to on-board new people and establish a development process.
Until I see evidnece of these fundamentals, I don't see a way that I can help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, I agree with you—to a point. The timing and ownership issues are certainly present, and I don't think I ever said they're not. The size of the codebase is, to be honest, overwhelming, and until now, it's more or less been, "pick a fire and piss on it". There has been no shortage of fires.
As for a big-picture vision, I'm not sure how to articulate it any better than "to have an e-mail client that compiles and runs on Windows, checks mail with POP and IMAP, sends mail with SMTP, successfully completes a TLS handshake, checks spelling, and uses an HTML engine that isn't hopelessly outdated". The tasks in that list are essentially of equal priority, with perhaps Stingray and the HTML engine dominating—we can't build without replacing Stingray first, and the HTML engine is simply a disgrace.
Finding new people is a sticky wicket—I won't equivocate, obscure, conceal, or misrepresent the actualité in any way, because that would be counterproductive. On the other hand, I don't want to throw my hands up in defeat and say I haven't got 10% of what it takes, let the project die—because that, too, would be counterproductive.
Honestly? I plan to recruit on Sourceforge Help Wanted, on Reddit, and possibly on GitHub. I do agree that there's a certain lack of direction here, and it does hamper us. Realistically, we could keep puttering around the way we've been doing now, essentially with a skeleton crew—maybe we'd get a new version out the door by February (remember, Stingray + HTML are the sine-qua-non features). Maybe we wouldn't. But at least we could say we gave it the old college try.
Oh, dependencies. The list of tasks that was published---the roadmap---well, except for MSHTML/Trident, that's essentially a list of dependencies. We can't use Stingray because we'd have to pay $2800 for the privilege. We can't use Wintergreen Sentry because we'd have to pay $5000 for a substandard spell-checker. We can't use InstallShield because... get the picture?
Last edit: Ted Matavka 2018-09-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, I have what I believe to be the fundamentals written down in plain English. If you could look over them and give me feedback, I would be grateful. Likewise if you would give your assistance. Even though I have managed a project before, it was essentially production-ready code that merely needed a change of name. I'll be the first to admit that we have only a seat-of-our-pants process set up; your comments were germane, to the point, and incisive.
If I understand correctly, our current inability to build Hermes results solely from not having access to the Stingray toolkit. This is because Stingray is the one piece of proprietary code that is built into the main Eudora executable rather than being provided by an independent DLL. It seems both a terrible nuisance and a great pity that this one obstacle constricts our development plan so severely and I propose that we make some attempt to find a way around it. I see two possible approaches.
Back when Eudora was released as open source, there were hints given that, once a group had something to show for itself in terms of producing a free Eudora work-alike, a no-cost license to Stingray might be forthcoming. We already have a few things to show for ourselves: a solution to the certificates issue, an up-to-date QCSSL already used by several Eudora users, and me (one of the most experienced email developers on the planet). I could try to contact Len Shustek and make a pitch for this. I do not know Len but I do have a connection with him: we were both connected with Network General in the 1980s where I knew his co-founder Harry Saal. The second possibility is that we contact RogueWave directly and try to negotiate a license to Stingray solely for our internal use. If we have any KickStarter funds they might cover that expense or I might even pay for it out of my own pocket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The second possibility is that we contact RogueWave directly and try to negotiate a license to Stingray solely for our internal use. If we have any KickStarter funds they might cover that expense or I might even pay for it out of my own pocket." - I already tried that. I was given a version close to that which Qualcomm used in 2005, on condition that it be used only to develop the codebase that was once known as Qualcomm Eudora. I sent you a link to it, along with Jeff. I did ask for a newer version, but I was told that pursuing such an option would cost €2800 per head. Apparently, back when the company was still called Stingray, they weren't such anal-retentive Faarquaads about it; they even had a shareware-licenced version available for FTP download.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because this is an Open Source project, and we shouldn't be distributing something that depends on a closed-source package (especially not one written by such W⚓'s as RogueWave). We are therefore converting Stingray references to MFC references.
By the way: did you get my note about QCSSL? Please continue working on it. Søren's taking a look at the Chromium package (he called it, and I quote, "a Godsend").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because this is an Open Source project, and we shouldn't be distributing
something that depends on a closed-source package (especially not one
written by such W⚓'s as RogueWave). We are therefore converting Stingray
references to MFC references.
By the way: did you get my note about QCSSL? Please continue working on
it. Søren's taking a look at the Chromium package (he called it, and I
quote, "a Godsend").
I think the word was a "gem", but let not split hairs. :)
Regards
On Tuesday, September 11, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
Because this is an Open Source project, and we shouldn't be distributing
something that depends on a closed-source package (especially not one
written by such W⚓'s as RogueWave). We are therefore converting Stingray
references to MFC references.
By the way: did you get my note about QCSSL? Please continue working on
it. Søren's taking a look at the Chromium package (he called it, and I
quote, "a Godsend").
I disagree and intend to strenuously advocate for radically changing our plan. I think we should put everything else aside and put all our resources, all our effort into creating a working build of Hermes with that Stingray toolkit that I forgot about. I will compose my reasons for this and present them soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And just what will that accomplish? If someone downloads the source from here and intends to compile it, with what will he do so? This flies in the face of everything the Open Source movement was meant to symbolise. We'll essentially be writing proprietary software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And just what will that accomplish? If someone downloads the source from
here and intends to compile it, with what will he do so? This flies in the
face of everything the Open Source movement was meant to symbolise.
We'll essentially be writing proprietary software.
Oh, no, I'm fine with that. You have my blessing. I was simply saying that we will not have dependencies on packages that cost four digits! coughStingraycough WxWidgets costs nada. Sure, it'll be a shitload of work, but if you feel competent to do this, go on right ahead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(1) It will allow us to satisfy ourselves that the Eudora sources we have are both complete in themselves and consistent with the 7.1.0.9 release. From my work with QCSSL I have a slight suspicion that some modules may not be the latest. This check has to be done anyway, of course, but I think it should be obvious that it is better done sooner than later.
(2) It has become evident to Soren and me that just getting the Eudora code to compile is going to be a tough job. This has been a considerable surprise. If it was easily compiled 12 years ago, why should it be hard to compile it now? The language hasn't changed. Well, actually the language has changed but what I mean is that it has changed only in a backward-compatible manner. One reason is that contemporary compilers are much pickier about what they approve of compared to compilers of 12 years ago. Beyond this it is actually hard to say why compiling the code is proving to be so difficult, but difficult it certainly is. So it is better to deal with this issue early on before other variables are introduced to murkify the process.
(2) It will give us a working program in short order that we can then use for fixing bugs and making enhancements. Fixing bugs and making enhancements just by reading code is possible but it is about a thousand times easier and quicker if one can step through code with a debugger and see "live" how it works. And to step through code one has to have a working build.
(3) As a consequence of (2), it will allow work on the main Eudora-now-Hermes executable to proceed independently of and in parallel to the work to replace the proprietary pieces.
(4) As another consequence of (2), it will allow us to test our replacements for the proprietary pieces "in vivo" as well as "in vitro".
(5) While we will not be able to distribute it, it will give us something that we can show. And that will help with publicity, fund raising, attracting developers, keeping developers, and keeping existing Eudora users salivating for what is to come.
If someone downloads the source from here and intends to compile it, with what will he do so?
If someone downloads the source from here and intends to compile it, it won't compile anyway for many other reasons. So what does it matter?
This flies in the face of everything the Open Source movement was meant to symbolise.
I have single-handedly created three successful open-source programs, the first around 46 years ago, and have contributed in large measure to one other. I am an ardent supporter of open source but, at this time and in this context, I do not give a damn about what it is meant to symbolise. What I care about is making Hermes successful. Besides, our open-source project is different from most in that we are working from something that already exists instead of building something from scratch. So I think different rules might apply. Which reminds me: I was active in the (unsuccessful) campaign to get OS/2 open-sourced. I may even have been the first person to suggest it (in a letter published in a magazine).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(1) It will allow us to satisfy our needs Soren we have toselves that the
Eudora sources we have are both complete in themselves and consistent with
the 7.1.0.9 release. From my work with QCSSL I have a slight suspicion that
some modules may not be the latest. This check has to be done anyway, of
course, but I think it should be obvious that it is better done sooner than
later.
(2) It has become evident to Soren and me that just getting the Eudora
code to compile is going to be a tough job. This has been a considerable
surprise. If it was easily compiled 12 years ago, why should it be hard to
compile it now? The language hasn't changed. Well, actually the language
has changed but what I mean is that it has changed only in a
backward-compatible manner. One reason is that contemporary compilers are
much pickier about what they approve of compared to compilers of 12 years
ago. Beyond this it is actually hard to say why compiling the code is
proving to be so difficult, but difficult it certainly is. So it is better
to deal with this issue early on before other variables are introduced to
murkify the process.
(2) It will give us a working program in short order that we can then use
for fixing bugs and making enhancements. Fixing bugs and making
enhancements just by reading code is possible but it is about a thousand
times easier and quicker if one can step through code with a debugger and
see "live" how it works. And to step through code one has to have a working
build.
(3) As a consequence of (2), it will allow work on the main
Eudora-now-Hermes executable to proceed independently of and in parallel to
the work to replace the proprietary pieces.
(4) As another consequence of (2), it will allow us to test our
replacements for the proprietary pieces "in vivo" as well as "in vitro".
(5) While we will not be able to distribute it, it will give us something
that we can show. And that will help with publicity, fund raising,
attracting developers, keeping developers, and keeping existing Eudora
users salivating for what is to come.
If someone downloads the source from here and intends to compile it, with
what will he do so?
If someone downloads the source from here and intends to compile it, it
won't compile anyway for many other reasons. So what does it matter?
This flies in the face of everything the Open Source movement was meant to
symbolise.
I have single-handedly created three successful open-source programs, the
first around 46 years ago, and have contributed in large measure to one
other. I am an ardent supporter of open source but, at this time and in
this context, I do not give a damn about what it is meant to symbolise.
What I care about is making Hermes successful. Besides, our open-source
project is different from most in that we are working from something that
already exists instead of building something from scratch. So I think
different rules might apply. Which reminds me: I was active in the
(unsuccessful) campaign to get OS/2 open-sourced. I may even have been the
first person to suggest it (in a letter published in a magazine).
(2) It has become evident to Soren and me that just getting the Eudora code to compile is going to be a tough job. This has been a considerable surprise. If it was easily compiled 12 years ago, why should it be hard to compile it now? The language hasn't changed. Well, actually the language has changed but what I mean is that it has changed only in a backward-compatible manner. One reason is that contemporary compilers are much pickier about what they approve of compared to compilers of 12 years ago. Beyond this it is actually hard to say why compiling the code is proving to be so difficult, but difficult it certainly is. So it is better to deal with this issue early on before other variables are introduced to murkify the process.
Is a way around this initially to try compiling it with Windows XP and compilers of that date? That will at least tell you that it compiled then, ie, no missing files.
Last edit: David Morrison 2018-09-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(2) It has become evident to Soren and me that just getting the Eudora
code to compile is going to be a tough job. This has been a considerable
surprise. If it was easily compiled 12 years ago, why should it be hard to
compile it now? The language hasn't changed. Well, actually the language
has changed but what I mean is that it has changed only in a
backward-compatible manner. One reason is that contemporary compilers are
much pickier about what they approve of compared to compilers of 12 years
ago. Beyond this it is actually hard to say why compiling the code is
proving to be so difficult, but difficult it certainly is. So it is better
to deal with this issue early on before other variables are introduced to
murkify the process.
Is a way around this initially to try compiling it with Windows XP and
compilers of that date? That will at least tell you that it compiled then,
ie, no missing files.
(2) It has become evident to Soren and me that just getting the Eudora
code to compile is going to be a tough job. This has been a considerable
surprise. If it was easily compiled 12 years ago, why should it be hard to
compile it now? The language hasn't changed. Well, actually the language
has changed but what I mean is that it has changed only in a
backward-compatible manner. One reason is that contemporary compilers are
much pickier about what they approve of compared to compilers of 12 years
ago. Beyond this it is actually hard to say why compiling the code is
proving to be so difficult, but difficult it certainly is. So it is better
to deal with this issue early on before other variables are introduced to
murkify the process.
Is a way around this initially to try compiling it with Windows XP and
compilers of that date? That will at least tell you that it compiled then,
ie, no missing files.
Yes, this is a sensible idea. We can easily tell what compiler was used to build the production Eudora and there is a possibility that I still have the CD to install that compiler in my archives. It is also possible that I have a retired laptop with the appropriate compiler already installed. Trouble is that I and my archives happen to be in different places at the moment and I will not be able to access them until mid-October.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this is a sensible idea. We can easily tell what compiler was used to
build the production Eudora and there is a possibility that I still have
the CD to install that compiler in my archives. It is also possible that I
have a retired laptop with the appropriate compiler already installed.
Trouble is that I and my archives happen to be in different places at the
moment and I will not be able to access them until mid-October.
Is this relevant, especially the bit about Qualcomm having modified the Stingray code:
Also, the Windows version uses a Qualcomm-modified version of RogueWave Software’s Stingray package of extensions to MFC, the Microsoft Foundation Class library for C++. After more than three years of discussion, we finally secured an agreement with RogueWave, giving us permission to distribute a binary linkable library compiled from the 20-year-old source code, but only for noncommercial use. That library is not currently part of this release, but we will build and distribute it if there is credible interest in rebuilding a noncommercial Windows version of Eudora. But it will take some effort to make the changes to the RogueWave source code necessary to compile it in a modern development environment, and we could use help in doing that.
I apologise for my slightly vehement comment here. It all falls into place when I hear reasons for people's opinions Your premises are actually cogent and logical; I simply disagree with where they lead. WxWidgets seems to be the most popular option, both with Thygesen and with the Kickstarter people, and they're the ones paying for this endeavour.
On the one hand, getting a running copy of Hermes is high-priority. In fact, it is the highest priority of all. On the other hand, it's not distributable as an open-source project (I ran into this sort of thing with Cabos, which was written in REALBasic). Killing all our work and putting it on hold in order to get Hermes to run with Stingray will waste time which we could use to rewrite the bits that depend on Stingray to run on plain MFC or WxWidgets. And time is the most precious commodity of all, even more precious than money.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not a C++ programmer, nor a project manager, but I have enough
experience to see this project spiraling into the dust. As several
people have said, it looks to be just a collection of random thoughts
about what needs to be done. There appears to be no big picture and
therefore no plan to get there. Without the big picture, some of the
tasks could end up being irrelevant or a waste of effort. And without
a plan, the number of people likely to back the Kickstarter is going
to be low.
As I see it, the phases in this project will include at least the following:
Get the Windows version working reliably to provide a platform for
testing future work. Do not add any new features.
STOP ALL DEVELOPMENT! Put together a project management team. Get a project
manager. Make a plan for what is to be done and a rough timeline.
This is important as without this there are unlikely to be many
volunteers to help. This needs to be done right at the beginning to
avoid the project getting a bad reputation.
Put together a team with the required skills to implement the plan.
Start working according to the plan.
Now the plan needs to identify what the final goal is, perhaps something like:
To create an open source e-mail client based on Eudora that will run
on at least Linux, Mac, Windows.
One might also add which operating systems are going to be targeted,
eg, Windows XP and later, Mac OS X Snow Leopard and later, flavours
of Linux. This is important because different development software
and software libraries may be required to work with all those
operating systems.
It then needs to list all the major tasks that need to be done, and
to give them a priority. Dependencies need to be considered in
determining priority, eg, it is no good working on something that
cannot be tested until something else is finished.
Tasks then need to be allocated to developers or teams of developers.
This could be by people volunteering to do particular tasks, provided
that meets the priorities.
Estimates of the time needed for each task should be identified to
allow for organised allocation of work. If a task is going to take
six months, it needs to start earlier than one which will take one
month.
Regular monitoring of progress is needed, so that if one area is a
bit slow, additional resources can be directed that way.
Milestones will show that progress is being made.
Some major decisions are going to have to be made, particularly in
terms of supporting other platforms. It would be silly to implement
something that does not translate easily to another platform.
Just some food for thought.
Last edit: David Morrison 2018-09-10
Point number one is self-contradictory. Some existing features needed for the product to compile cost money—inordinate amounts of money, in fact. That is the case with Stingray and Wintertree Sentry. We need to replace those features with an Open Source analogue, just to get the Φ#¢κing thing to compile.
We do in fact have a plan, though timings haven't been worked out; I'm planning for delivery in January, perhaps February, of a version that will open, check spelling, and send and receive eMail under Microsoft Windows. The plan is accessible at https://pad.riseup.net/p/hermes-keep.
Putting together a team has been frightfully difficult, and I'd go so far as to say Sisyphean, because people want a version that will compile before they work on it, and it needs work to be compiled.
A lot of the management has been through the back channel, as it were—through private eMail. I'm aware the lack of publicly visible coördination presents a problem for people that want to see evidence of work before they commit to a project of this magnitude, and I'm actively working to find an alternative.
David wrote a great email expalining what he thought with the project. I completely agree with his assesment, and with his high-level approach to bootstrapping the project.
The "plan" I've seen is just a list of goals. I don't think much thought has been given to timing, dependencies, or ownership. Before anyone knew anything about me, and before I knew the names of anyone else on the project, a set of tasks were assigned to me.
Most concerning to me, which David also identifies, is the lack of a big-picture vision for the porject. What is it meant to do? What are the priorities and how do they trade-off? What does success look like? What's my motivation? How can I (or anyone else) best help?
Complicated software projects can't be successful without guidance and planning. I see evidence of neither so far. I might consider helping out -- I don't mind working for free, but I don't want to involve myself with a project that's doesn't have what's necessary to make itself succeed.
I could help with the fundamentals, others probably could, too. Ted's response doesn't demonstrate to me that there's an acknowledgement that the fundamentals are actually missing, not to mention a plan to on-board new people and establish a development process.
Until I see evidnece of these fundamentals, I don't see a way that I can help.
Oh, I agree with you—to a point. The timing and ownership issues are certainly present, and I don't think I ever said they're not. The size of the codebase is, to be honest, overwhelming, and until now, it's more or less been, "pick a fire and piss on it". There has been no shortage of fires.
As for a big-picture vision, I'm not sure how to articulate it any better than "to have an e-mail client that compiles and runs on Windows, checks mail with POP and IMAP, sends mail with SMTP, successfully completes a TLS handshake, checks spelling, and uses an HTML engine that isn't hopelessly outdated". The tasks in that list are essentially of equal priority, with perhaps Stingray and the HTML engine dominating—we can't build without replacing Stingray first, and the HTML engine is simply a disgrace.
Finding new people is a sticky wicket—I won't equivocate, obscure, conceal, or misrepresent the actualité in any way, because that would be counterproductive. On the other hand, I don't want to throw my hands up in defeat and say I haven't got 10% of what it takes, let the project die—because that, too, would be counterproductive.
Honestly? I plan to recruit on Sourceforge Help Wanted, on Reddit, and possibly on GitHub. I do agree that there's a certain lack of direction here, and it does hamper us. Realistically, we could keep puttering around the way we've been doing now, essentially with a skeleton crew—maybe we'd get a new version out the door by February (remember, Stingray + HTML are the sine-qua-non features). Maybe we wouldn't. But at least we could say we gave it the old college try.
Oh, dependencies. The list of tasks that was published---the roadmap---well, except for MSHTML/Trident, that's essentially a list of dependencies. We can't use Stingray because we'd have to pay $2800 for the privilege. We can't use Wintergreen Sentry because we'd have to pay $5000 for a substandard spell-checker. We can't use InstallShield because... get the picture?
Last edit: Ted Matavka 2018-09-11
So, I have what I believe to be the fundamentals written down in plain English. If you could look over them and give me feedback, I would be grateful. Likewise if you would give your assistance. Even though I have managed a project before, it was essentially production-ready code that merely needed a change of name. I'll be the first to admit that we have only a seat-of-our-pants process set up; your comments were germane, to the point, and incisive.
https://sourceforge.net/p/hermesmail/blog/2018/09/project-plan-part-ii/
If I understand correctly, our current inability to build Hermes results solely from not having access to the Stingray toolkit. This is because Stingray is the one piece of proprietary code that is built into the main Eudora executable rather than being provided by an independent DLL. It seems both a terrible nuisance and a great pity that this one obstacle constricts our development plan so severely and I propose that we make some attempt to find a way around it. I see two possible approaches.
Back when Eudora was released as open source, there were hints given that, once a group had something to show for itself in terms of producing a free Eudora work-alike, a no-cost license to Stingray might be forthcoming. We already have a few things to show for ourselves: a solution to the certificates issue, an up-to-date QCSSL already used by several Eudora users, and me (one of the most experienced email developers on the planet). I could try to contact Len Shustek and make a pitch for this. I do not know Len but I do have a connection with him: we were both connected with Network General in the 1980s where I knew his co-founder Harry Saal. The second possibility is that we contact RogueWave directly and try to negotiate a license to Stingray solely for our internal use. If we have any KickStarter funds they might cover that expense or I might even pay for it out of my own pocket.
"The second possibility is that we contact RogueWave directly and try to negotiate a license to Stingray solely for our internal use. If we have any KickStarter funds they might cover that expense or I might even pay for it out of my own pocket." - I already tried that. I was given a version close to that which Qualcomm used in 2005, on condition that it be used only to develop the codebase that was once known as Qualcomm Eudora. I sent you a link to it, along with Jeff. I did ask for a newer version, but I was told that pursuing such an option would cost €2800 per head. Apparently, back when the company was still called Stingray, they weren't such anal-retentive Faarquaads about it; they even had a shareware-licenced version available for FTP download.
Oh dear! I am embarrassed. I do now remember that message. Sorry. But if we have that why are we not using it?
Because this is an Open Source project, and we shouldn't be distributing something that depends on a closed-source package (especially not one written by such W⚓'s as RogueWave). We are therefore converting Stingray references to MFC references.
By the way: did you get my note about QCSSL? Please continue working on it. Søren's taking a look at the Chromium package (he called it, and I quote, "a Godsend").
I think the word was a "gem", but let not split hairs. :)
Regards
On Tuesday, September 11, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
(AFK)
It does have some pretty steep requirements. Windows 7 minimum, 8 GB ram
and other stuff...
This might be a problem? But let's see how serious they are when it comes
down to it.
Regards
On Tuesday, September 11, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Or, as the French say, "n'enculons pas les mouches"---let's not f@ck flies up the poo-poo hole
I disagree and intend to strenuously advocate for radically changing our plan. I think we should put everything else aside and put all our resources, all our effort into creating a working build of Hermes with that Stingray toolkit that I forgot about. I will compose my reasons for this and present them soon.
And just what will that accomplish? If someone downloads the source from here and intends to compile it, with what will he do so? This flies in the face of everything the Open Source movement was meant to symbolise. We'll essentially be writing proprietary software.
I think we should rewrite the GUI, from scratch, using WxWidgets. And yes,
I'm wearing a tin-foil hat and acting bat-sh*t crazy.
No, I realise it sounds both impossible and insane. But boy, would I like
to....
Regards
On Tuesday, September 11, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Oh, no, I'm fine with that. You have my blessing. I was simply saying that we will not have dependencies on packages that cost four digits! coughStingraycough WxWidgets costs nada. Sure, it'll be a shitload of work, but if you feel competent to do this, go on right ahead.
(1) It will allow us to satisfy ourselves that the Eudora sources we have are both complete in themselves and consistent with the 7.1.0.9 release. From my work with QCSSL I have a slight suspicion that some modules may not be the latest. This check has to be done anyway, of course, but I think it should be obvious that it is better done sooner than later.
(2) It has become evident to Soren and me that just getting the Eudora code to compile is going to be a tough job. This has been a considerable surprise. If it was easily compiled 12 years ago, why should it be hard to compile it now? The language hasn't changed. Well, actually the language has changed but what I mean is that it has changed only in a backward-compatible manner. One reason is that contemporary compilers are much pickier about what they approve of compared to compilers of 12 years ago. Beyond this it is actually hard to say why compiling the code is proving to be so difficult, but difficult it certainly is. So it is better to deal with this issue early on before other variables are introduced to murkify the process.
(2) It will give us a working program in short order that we can then use for fixing bugs and making enhancements. Fixing bugs and making enhancements just by reading code is possible but it is about a thousand times easier and quicker if one can step through code with a debugger and see "live" how it works. And to step through code one has to have a working build.
(3) As a consequence of (2), it will allow work on the main Eudora-now-Hermes executable to proceed independently of and in parallel to the work to replace the proprietary pieces.
(4) As another consequence of (2), it will allow us to test our replacements for the proprietary pieces "in vivo" as well as "in vitro".
(5) While we will not be able to distribute it, it will give us something that we can show. And that will help with publicity, fund raising, attracting developers, keeping developers, and keeping existing Eudora users salivating for what is to come.
If someone downloads the source from here and intends to compile it, it won't compile anyway for many other reasons. So what does it matter?
I have single-handedly created three successful open-source programs, the first around 46 years ago, and have contributed in large measure to one other. I am an ardent supporter of open source but, at this time and in this context, I do not give a damn about what it is meant to symbolise. What I care about is making Hermes successful. Besides, our open-source project is different from most in that we are working from something that already exists instead of building something from scratch. So I think different rules might apply. Which reminds me: I was active in the (unsuccessful) campaign to get OS/2 open-sourced. I may even have been the first person to suggest it (in a letter published in a magazine).
I heartedly agree with Pete. One of the main problems is missing files.
Important files!
/Soren
On Tuesday, September 11, 2018, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
Søren Bro Thygesen
Is a way around this initially to try compiling it with Windows XP and compilers of that date? That will at least tell you that it compiled then, ie, no missing files.
Last edit: David Morrison 2018-09-11
I'm not saying its not worth a try, but the missing files are part of the
various projects. Just not there anymore!
If one of the missing files are part of the Stingray API are we then
royally effed up?
Regards
On Tuesday, September 11, 2018, David Morrison davidmorr@users.sourceforge.net wrote:
--
Søren Bro Thygesen
That is, if management decides to try to go with Stingray afterall.
Regards
On Wednesday, September 12, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
Yes, this is a sensible idea. We can easily tell what compiler was used to build the production Eudora and there is a possibility that I still have the CD to install that compiler in my archives. It is also possible that I have a retired laptop with the appropriate compiler already installed. Trouble is that I and my archives happen to be in different places at the moment and I will not be able to access them until mid-October.
I hardly know you. Still I'm not surprised. :P
Ironic regards.
Soren
On Wed, Sep 12, 2018 at 6:42 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
Is this relevant, especially the bit about Qualcomm having modified the Stingray code:
It is from the Computer History Museum announcement. They are also offering to make it compile using modern compilers.
http://www.computerhistory.org/atchm/the-eudora-email-client-source-code/
Last edit: David Morrison 2018-09-11
I apologise for my slightly vehement comment here. It all falls into place when I hear reasons for people's opinions Your premises are actually cogent and logical; I simply disagree with where they lead. WxWidgets seems to be the most popular option, both with Thygesen and with the Kickstarter people, and they're the ones paying for this endeavour.
On the one hand, getting a running copy of Hermes is high-priority. In fact, it is the highest priority of all. On the other hand, it's not distributable as an open-source project (I ran into this sort of thing with Cabos, which was written in REALBasic). Killing all our work and putting it on hold in order to get Hermes to run with Stingray will waste time which we could use to rewrite the bits that depend on Stingray to run on plain MFC or WxWidgets. And time is the most precious commodity of all, even more precious than money.