Yeah, I don't understand the overly pessimistic mood here either; the SeaMonkey ship is catching on water (we've been there before, haven't we?) but isn't quite a Titanic yet!
There is a corresponding sticky for Thunderbird at
viewtopic.php?f=28&t=2976617 if you want to follow that discussion in parallel, and a collection of links to newsgroups and mailing lists was provided in the last
status meeting (2nd paragraph of that section) for further reading.
So, what's the situation? Mozilla has made it unambiguously clear that they want to kick Thunderbird (and implicitly other projects like SeaMonkey and Lightning, without those having been mentioned - yet) off any infrastructure that's shared with Firefox, and that they won't do any "favors" for comm-central applications in the future any more (like establishing version branches on release repositories, etc.). There are two issues here, one being the actual infrastructure for code management and building, the other the code base, including the XUL/XBL/XPCOM/etc. code that both SeaMonkey and Thunderbird currently heavily depend on.
Cloning a repository to Github or Bitbucket is trivial these days, as Frank already pointed out, having some decent build machines in place (other than in someone's private basement) is a different question. But, all of this would be "somehow" solvable, and it is not clear if and when Mozilla kicks everybody off their servers for good.
The code base is the more burning issue, with a couple of options having been / still are under consideration, either of which is unsatisfactory and associated with substantial work:
- Following down the slippery slope Firefox is pushing for, with a further degrading (feature-wise) Gecko, thus coping with the removal of key features and essentially turning everything into a huge web app on a local minimalistic browser backend. This is apparently the way Thunderbird wants to go within the Gecko 45 and 52 ESR lines (if the latter will still exist), then having to look for alternatives like Servo. For SeaMonkey, this variant would introduce some painful changes in the well-known user interfaces (e.g., in-content preferences, which in turn could be rendered in a separately opened browser window without any toolbars, workaround like that as possible). On the upside, SeaMonkey and Thunderbird could work on the transition with combined forces, despite differences in UI, but adaptions to the shared MailNews code would be of common interest. Obviously, some features may not be implementable, that will probably have to be figured out as we go along.
- The other extreme is to get off the Mozilla train and coordinate with other interested groups a continuation of Gecko as is, maintaining its configurability and key technologies. While this sounds "nice" to start with, problems here are regarding security updates and developing web standards. Meaning, such a solution can't be "static" and someone would be needed to understand security implications and to continue a secure code base. Unless Thunderbird follows that path, this would also imply backporting any MailNews core changes, which may become difficult if and when Thunderbird switches to Servo or whatever other option they choose. PaleMoon has been mentioned in this thread already, and it might be an option for collaboration. However, they forked off the Gecko 24 ESR branch rather than the upcoming 45 branch, thus a lot of API changes made by Mozilla during the last two years would have to be reversed while not touching any improvements in either Core or MailNews code. Also, it is unclear what would happen if SeaMonkey wants a specific feature while the main PaleMoon developers don't want to introduce it into their Goanna rendering engine.
- Another option suggested was to run SeaMonkey itself with a possibly stale Gecko version while somehow embedding a current rendering engine (and possibly Servo once ready) to keep up with security requirements and evolving web standards. However, carrying around two complete rendering engines in a single application is rather bloaty, interaction between UI and content isn't necessarily trivial, and there may be security implications in that interaction between the two rendering engines if insecure/malicious content makes it into the UI somehow.
As a short-term damage-control measure, SeaMonkey
may switch to the 45 ESR branch after 2.42, thus buying ourselves a year of support while being shielded from further removal of key features and other radical events on mozilla-release, subsequently having to figure out what to do after 45 ESR ends.
Anyway, so the discussion is going on, nothing set in stone yet other than that action must be taken and solutions figured out, but failure is not an option.