Use git and not mercurial. Use github over Source Forge. This will get you more eye balls on the project. Developers are more skilled in git than mercurial as well.
- Create a core in C that handles all the base functionality of the email client
- Create a UI for each platform using its native toolkits. Cocoa for macOS, MFC/.Net for Windows, GTK+ etc. You want the client to be native to the platform so it feels natural in all UI aspects and integration with the underlying OS.
Who in this current world wants to create or promote a growing community of free software developers, and chooses SourceForge as a platform instead of GitHub or GitLab?
Not that other alternatives are bad, but let me insist: especially if the intent is to attract more developers, GitHub has been THE choice already for several years.
Isn’t SourceForge synonymous with aggressive and intrusive advertisements all over the site and didn’t they get in trouble for inserting adware and spyware into projects’ binary downloads?
They did wrap installers in malware but have stopped now. Regardless, the site is very poorly designed and makes for a bad developer and user experience. To users and potential contributors, using SourceForge is synonymous with not caring.
I've registered a custom domain, which will be our primary user-facing point of contact. Developers use SF essentially purely as a Mercurial host; everything else is run over eMail.
Problem with those two is the first three letters. I'm fine with Bitbucket but decided against it in the near-term. Long-term, we'll probably move toward it.
Having strange and antiquated taste in collaboration tools is entirely consistent with wanting to revive Eudora. You may as well advise this person to "just use GMail."
I absolutely hate git. I think its creator should be shot in the elbows, knees, and balls, and then broken on the wheel. GitHub has no Hg support, so it's out.
I thought long and hard about transitioning to Bitbucket. In the end, I decided against it in the near term, because I have two other projects going (Eudora revival for Windows, which is not the same program at all, despite the name, and then a LimeWire revival). I like to keep all my eggs in one basket, and if I tried to transition the other two projects to Bitbucket, I'd encounter inertia from at least one developer, sans doute.
> The only issue left is that of preventable costs arising from error, oversight, or incompetence
> [notably,] the indiscriminate destruction of data […] under the mistaken impression that it was otiose, by a programmer whose experience was insufficient for the task at hand.
> Although he might have been the 'cause of more harm than good' (in the opinion of another of our programmers), […] and while correction of the mistake took some time and effort, it did not result in schedule slippage.
His assertion that "the only phone suitable for the task (of talking to 3 people)" is a crowdfunded phone that doesn't exist yet, shows (at best) poor risk-management.
I don't understand how one developer could need $170/month of mobile data to fulfil their commitments to this project.
I don't understand why the Enterprise edition of Visual Studio would be necessary… nor why Visual Studio would be the right choice for macOS development.
I don't understand why he's being so open with such indefensible spending.
The project seems out-of-touch. One of his roles is to inspire collaboration, so he would have more luck using technologies that excite people today.
You only have to see how he writes. What other projects / teams would have reported as "fixed some bugs and replaced the unsupported spell checker technology with hunspell, all going well!" here it takes several pages of... fluff, if you ask me. Either that, or contrived phrases just for the sake of writing a lot of latin expressions.
You never get too much latin in your product updates!!
Fixed some bugs? The project didn't compile under a modern compiler. The compiled version didn't work well with any language besides English or Latin. There was no spell-checker included with the source and we had to re-write the library. Then there was the total inability to negotiate an SSL/TLS connexion... don't get me started.
I wrote for a general audience. Yes, it's a bit fluffy, but I had to try to explain certain things to people who don't know the first thing about computers (if you don't believe me, take a look at the eudora listmoms listserv). The responses I received were overwhelmingly "don't change a thing but the Unicode handling and the SSL!"
This crowd-funding itself was an exercise in poor risk management. I mean, you don't need a detailed feasibility study to tell you that starting from a couple ancient codebases based on (1) M$ MFC and (2) Apple Carbon, and ending up with a high-performing, multi-platform application that people would actually want to use today is going to be very hard and probably entirely unrealistic. A cursory look at the code should suffice.
Note that this is the Kickstarter for the Windows version of HERMES Mail. It's an entirely different codebase and, as such, Visual Studio is the perfect IDE for the job.
The high mobile data cost was because said developer lives in the arse end of the middle of nowhere, and he refuses to use Mercurial properly (does a full hg clone instead of hg pull every time he contributes, drives me bonkers to be honest but the man writes good code!)
Said developer also admitted, publicly, to using an unlicenced copy of VS Enterprise after a disk crash. That was an indefensible state of affairs to me, and so the only thing I could do without wasting scads of time was to buy him a licence.
Please don't conflate HERMES Mail with Mail/X. They have similar user interfaces and are mail clients formerly written by different developers at the same company, but they are in different languages, different devs as stated before, and target different platforms.
The finances do seem very strange. Spending $850 on the Cosmo Communicator phone is definitely not necessary, multiple expensive VS Enterprise licenses probably aren’t necessary, and $170 of mobile data/month for one person seems very excessive, at least for the prices in the part of the world that I live in (not unreasonable for four unlimited lines, but far too much for one person).
It is not clear to me if the project is a new mail client based on the old Eudora codebase, or simply making that code portable to MacOS, but anyway, we already have a multiplatform, small but powerful and very fast mail client that shares a lot of concepts taken from the good old Eudora, and ready to be ported to MacOS: Claws Mail.
It's stable and works on most systems and hardware out there, Windows, Linux, BSD, including ARM SBCs (Raspberry PIs, etc). It does work under MacOS, but has to be built locally. If I wanted to make an easy to install Eudora-like mail client for MacOS I'd probably start by contributing to that project for being already very mature on other platforms; I use it on Linux since it was called Sylpheed -that's like 17 years back- and compared to Eudora I used before, from which I could import all email flawlessly, it has been a nice step forward without problems at all.
I used Claws on Linux. What a great little mail client. Software developers love rebuilding stuff for a variety of valid reasons, but one does ponder at the amount of rework done in the name of those reasons.
Interesting… I looked at Sylpheed some years ago and it didn't feel remotely like Eudora, and the Claws screenshots don't suggest very much has changed in the fork.
Jeez, that's awful. 2000 dollars on visual studio when community would suffice[0], 450 on incorporating and 900 bucks on his phone of choice. Couldn't he use email to communicate?
What an awful use of donations for an open source project.
He's also running another Kickstarter for the same project with no real goals... This screams cash grab to me!
[0] Probably - but if you're big enough to require Enterprise you don't need to crowd fund 3k
> It is my considered opinion that accusations like this, without positive evidence of attempted fraud, are scurrilous, ungentlemanly, dishonourable, morally suspect, and may very possibly constitute libel, given that they were made in a public forum.
I don't appreciate being called a "fraudster" by someone who hope onto the Eudora mailing list, writes that one message, and hops off. Without participating otherwise.
Not to mention the project description and update is phrased incredibly weirdly.
> So that the answer to these questions is meaningful, one must first have an elementary grasp of the manner in which microcomputer software in general, and HERMES Mail in specific, is structured. The current fashion in computer science is for all complex programs to be modular; software for Microsoft Windows follows this trend in that functions (such as mail retrieval or message composition) are grouped into so-called "DLL's" or dynamic link libraries, as well as the main executable containing the interface that talks to the user. Also, when writing code of any description, one may use either "native" functions included with the system or a "library" supplied by a third party for any fee or none.
The last time I funded a software development effort was neovim and those guys had stuff out super fast. A Github repo, plans, the binary. It’s a successful project. That is some gold standard development, imho.
And then asking for (what appears to be) free help from experienced old-school Mac devs. I realize he didn't raise that much money, but it still makes the whole thing feel a little more sleazy.
"Hey I got all this money and spent on questionable stuff, does anyone want to help me finish it out gratis?"
I've been through this process with several projects. At this point a Carbon codebase like that needs to be rewritten from scratch.
The best path forward if you want a program that works like the old one but runs on the current version of macOS is to use the old version to create a requirements document and then develop that using modern techniques.
Same as with restoring a 19th century farm house with a bad foundation. The cost of restoring it and bringing it up to modern standards will typically be 5-20 times more than knocking it down and building a lookalike from scratch using modern building techniques.
I have no specific experience with carbon but in almost (arguably) similar cases I've come across as a developer, I've found a better approach to look for a mechanism to allow for granular upgrades over time.
In this specific case I could imagine supporting both carbon and cocoa screens / logic at the same time, and begin conversion screen-by-screen or feature-by-feature.
In the end this might mean maintaining extra complexity to support both technologies, but protects you from the danger of having to implement a complet syst m to feature parity at once.
Supporting Carbon isn't really an option, it was a technology designed to ease porting from OS9 to OSX. It's been deprecated for years, is 32 bit only and is being dropped completely after macOS 10.14 Mojave.
I think it would make more sense to slowly port the Windows version to Qt. And then when that process is complete, you get a Mac and a Linux version.
Depends what you mean by Carbon. If you mean "the UI parts of HIToolbox", then yes, Carbon is deprecated. If you mean Carbon in general, most parts of it have been ported to x64, and you wouldn't call that deprecated.
Carbon apps do run on current Macs, and on the current macOS (10.14). But that's the end of the line. Carbon is 32 bit only, and Apple has announced they are dropping 32 bit soon.
It's not actually. Only the UI parts of Carbon are deprecated:
"We are still planning to support the Carbon Event Manager and Text Input Sources, to name two mostly non-UI APIs. You might wonder, what about the Memory Manager, or the Alias Manager, or the Process Manager, or other lower-level managers? At this time, it looks like most, if not all, of the APIs provided by the ApplicationServices and CoreServices umbrella frameworks will still be available in 64-bit." - Eric Schlegel (apple developer)
I don’t know why you got downvotes. I cut my programming teeth on Carbon and worked my way through several ports of side projects, and you are absolutely right.
Moreover a complete rewrite doesn’t exclude any truly unique parts of the old codebase from being ported into the modern one.
He might be getting downvoted for cultural reasons... in much of continental Europe knocking down and rebuilding a look-alike house from scratch is tantamount to vandalism.
(I voted him up, but the analogy did make me squirm.)
I disagree with the "requirements document" bit. I do think it's better to move to Cocoa, but this should be done bit by bit. Start with "the upstairs" (the user interface), which absolutely MUST be in Cocoa to be 64-bit, then move everything else with time to Cocoa.
Looking at this source code... it's a window into the past that nobody should have to revisit.
I would recommend:
- Start a new program from scratch
- Refer to old code to port over "novel" concepts/logic
- Publish a skeleton / MVP project so people can add to it (instead of trying to start from an unusable codebase).
Some fun snippets from main.c:
// Update the emo turd cache
EmoTurdCache = EmoLitterInternetWithTurds();
/*
* run the text analyzer
*/
if (!TypingRecently && BeingAnal()) AnalScan();
// and the emoticon scanner
if (!TypingRecently && HasFeature(featureEmo) && EmoDo()) EmoScan();
Looks like the person who wrote this had fun with naming conventions... :)
One of ideas is to create e-mail client. In principle its UI will be quite close to another Sciter application: https://notes.sciter.com/ that is multiplatform and simple - the application was created in 4 months as a side project. Its UI can be morphed to e-mail one in comparable time frame.
Will it be better to focus on this rather on totall rewrite of MFC based project? Especially because Sciter is multiplatform already by nature...
I think it's good that we see more efforts at making good e-mail clients. Outlook was never great, but it has really ruined e-mail with the current font and design layout that makes it even harder for people to notice important e-mails and this is killing it off as a communications medium.
We have the advantage nowadays that the server protocols are more open than they have been for a long time, also the rendering of rich e-mails is more standard so it's a good time for alternatives to gain some of the market.
Also, from this update it can be seen that the OP already burnt through all the funds without even putting out a single line of code. The expenses include:
"Finally, because our team is scattered all over the world, I need a device to communicate with them; I found only one suitable for the task (the Cosmo Communicator), which I purchased for the princely sum of $840"
(Downside: appears to be Windows only, but you could always run it on an Azure VM and remote desktop in if you don't have access to a Windows box of your own.)
cool. but i’d rather see revival of mulberry. which was the spiritual successor to eudora IMHO. eudora was good for its day but modern email means it is obsolete.
interesting to see the "blind man and the elephant" responses here, each hacker/blind man insisting that the beast needs to be tamed this way.. For the critics - do you value the human happiness that a software user has, with a well-made and visually pleasing app environment ?
porting software has been accomplished for decades, to varying degrees of success - of course this can be done.. go for it !!
Scrap it then build a modern client in Electron. Allow modern features by hosting servers to filter, search, and glean info from email paid for by slipping ads back into the email.
Also isn’t this essentially the business models of Airmail and Spark and (I’m sure) many others? They do this all up to the point of actually injecting ads. Which is absurd; these days access to your email is probably more dangerous than access to your SSN.
Use git and not mercurial. Use github over Source Forge. This will get you more eye balls on the project. Developers are more skilled in git than mercurial as well.
- Create a core in C that handles all the base functionality of the email client
- Create a UI for each platform using its native toolkits. Cocoa for macOS, MFC/.Net for Windows, GTK+ etc. You want the client to be native to the platform so it feels natural in all UI aspects and integration with the underlying OS.
I believe Transmission takes this approach and it seems to work well: https://github.com/transmission/transmission