I've had some recent talks with other core developers (feel free to chime in with your own experiences Tobin, Travis, etc.) and I think the only way forward from this impasse for the longer term is to create a new browser product that will start with a clean slate.
Some of the rationale behind this:
Lack of community development
Despite our clear and open invitation for more people to get involved in both core development and extensions, the uptake has been (really) slow. There's only so much a small team can do under constant demands from its users, and I'm personally stretched very thin over multiple disciplines trying to keep things together, since I can't delegate much to others (especially core work). I do understand that this seems like a mammoth task, and I understand the fear of touching a behemoth of a source tree that is 14 million lines of code, but anyone can start small and learn along the way or specialize into certain areas. I don't know everything about the entire code base either; nobody does. Not even Mozilla as a whole!
There's just a dawning realization that more people need to actually get involved for the amount of work involved in keeping up with the developing web and demands put on us by websites. So far, it seems our requests for help and the open invitation to jump in and help out with patches has been seen as being dismissive; please understand that it's not. I know that "patches welcome" has been used by certain companies publishing Open Source software as a "we're not going to despite being able" response, but understand that in the case of Pale Moon, we actually do welcome patches because we're not able to tackle every enhancement ourselves and need your help.
Missed the mark
Looking back at our forking point, we've "missed the mark" by a few versions of the Mozilla base code for several technologies. Hindsight being 20/20 and all, it's easy to look back and say "we should have used Holly and repair it" instead of staying with a known-stable base to build from - however, that is hindsight, and also the fact that 2 years ago we didn't know nearly as much about the code base as we do now so we likely wouldn't even have been able to have a stable browser out based on a dev version of the code. Unfortunately, that code was destroyed by Mozilla so a minor rebase isn't possible either to try and weave that code in (which would still be a huge task to accomplish - that a small handful of developers would not be able to easily tackle).
We "missed the mark" in a few areas: Promises and some other base ECMAScript 6 landmark features we don't have, certain streaming media support, Direct2D 1.1 (platform update versions of Windows) support, and some CSS features that are being adopted relatively commonly these days, to name a few of the more obvious ones. Porting this across to our Pale Moon code base would be possible though difficult, and require a lot of development time which we're not given.
Complications in the Mozilla code
Moreso than anything else, the Mozilla code has been very unstable, not just from a product view (although it's been one of the main reasons we forked when we did) but from an actual code structure point of view. This is mainly because of some rapid changes that started happening with many refactoring changes upon refactoring changes, e10s and FirefoxOS considerations that fundamentally changed some of the underlying structures, not to mention changes in coding style, which makes porting code increasingly difficult (and regularly impossible) because they build on (and were designed for) the changed underlying structures.
Without actual documentation about the intricacies of these changed structures because they are purely internal, rewriting code with the same functionality also becomes more difficult since it asks for reverse-engineering and tracing a simple change back to a complex refactoring and inherent behavioral change of the code involved. Mozilla code has become extremely heavily reliant on templates, classes, overloading, virtualization of functions and many, many stub and redirect functions to "pass the buck" to the correct module to process things in, which makes working with the code base very difficult. A lot of this also seems unnecessary, but it's understandable that Mozilla developers would want to use structural improvements to build on and, very similar to what we've been doing in some areas, change code around to remove obsolete or archaic code in favor of something more modern. Which brings me to the next point:
Compiler compatibility
From early on, the moment it was available, we've been ahead of Mozilla in terms of the compiler in use because of the inherent advantages offered by VS2012 over the (at that time used) VS2008 or VS2010. This has been a very straightforward choice because the code was (mostly) compatible with no real breaking changes. This is no longer the case, however. Since Mozilla moved to Visual Studio 2013, which has some significant breaking changes by aligning more closely to the C++11 code standard, as well as offering certain advanced OOP logic that our compiler doesn't offer, later code changes in the Mozilla code have become largely incompatible with what our compiler offers in terms of code features. Either way, we'd have to switch compiler on the medium term, with necessary code changes, to be able to adopt/port more code from the Mozilla tree. While this is certainly possible, it does add another hurdle for what Pale Moon currently builds on and from.
So, I've been looking closely at what would be a way forward, and the idea has come up to make a new browser product, re-forking from a later point in the Mozilla source tree to tackle the missed marks, compiler compatibility, and to some extent the complications in the Mozilla code. This re-forking would be done on the last stable version of Mozilla code that hasn't had a sledgehammer put to it yet and that offers the features and capabilities we as a project would still want (i.e.: Sync 1.1, XPCOM binary components in extensions, XUL, XBL, complete theme support, etc.).
This new browser fork would:
- Be using (a changed version of) Goanna.
- Be compatible with the current Web by far and large.
- Retain our UI.
- Not be able to directly load Firefox extensions, but be closely compatible, only requiring small changes in extensions to release them for it.
This is an important consideration since XUL, bootstrap and SDK are being deprecated or already considered "legacy" (read: obsolete) by Mozilla and will be phased out completely. Instead of trying to remain compatible with a range of wildly different Firefox extension versions for a dying platform, it would make sense to evolve the extension ecosystem into something that would be specific to this new browser, with focused development on a stable and unique framework, removing all of the compatibility headaches we've seen recently as well as making things easy for extension developers to maintain their work for us. - Be able to adopt additional changes from Mozilla code more readily.
- Be more compatible with Windows 8.1 and 10.
- Not include telemetry or DRM of any sort (goes without saying).
- Possibly offer WebRTC as an option if there is enough demand for it. If so, this will still remain low-key and not heavily maintained.
I would like to hear your feedback -- but please read over this entire post and think about what is said before you reply, to keep this discussion focused and helpful to evaluate this idea.