The short version:
Asuswrt-merlin is getting re-implemented on top of the GPL 382 codebase. Only the RT-AC86U will be supported initially, followed by other models as Asus migrates them to 382. Ultimately, all development will be done on the 382 codebase, and the 380 codebase will be abandoned.
Some features will change or need to be abandoned. Some models might be dropped, unsure which yet.
There is no timetable/ETA for any of these stages, as they depend on many factors, some of which outside of my control (Asus' own timetable in migrating to 382).
And the details:
Introduction
As many of you know by now, Asus has spent the past 18+ months working on a major update to Asuswrt, usually referred to as "382" (the current version used by most routers is 3.0.0.4.380_xxxx). The GT-AC5300 was the first router released based on this new code base, followed by the RT-AC86U.
Asus intends to gradually upgrade existing models to this new 382 codebase. The first Broadcom models to get the upgrade so far are the RT-AC88U and RT-AC3100. Others will progressively follow over the coming months, as this new code base gains in maturity (so far, these first AC88/AC3100 builds seem to have a number of issues).
Challenges introduced with it
GPL 382 contains about 18 months of parallel development from Asus. There's a lot of changes in it, making it more difficult to merge than past GPL releases.
I started studying the 382 codebase these past few weeks, migrating a few webui-related features to Asuswrt-Merlin 380.68. After receiving a "native" 382 device to work with (an RT-AC86U provided by Asus), I started experimenting with the code itself, and decided to try something different: rather than attempt to merge the 382 GPL on top of Asuswrt-Merlin (like I used to do in the past), I decided to try the other way around: starting with a clean GPL 382 code base, and merging Asuswrt-Merlin's changes on top of it. So far, this method has shown good promises, as the bulk of Asuswrt-Merlin's changes to the core components (httpd, shared and rc) have now been ported on top of 382. This is still a long and difficult process, and much still remains to be done. Some features will have to be abandoned, others will need to be reworked. But so far things are progressing well.
The plan: project AM382
AM382 is the "codename" by which I refer to this new Asuswrt-Merlin 382.xx codebase. (the official name will remain Asuswrt-Merlin, this is just to more easily distinguish it from the existing codebase, which I call AM380).
I have begun the work of porting AM380's code on top of a fresh new 382 code repository. During this early development phase the new repo will remain private, as I occasionally have to rewrite previous code commits to ensure that once the code goes public, we have a clean foundation to build upon. The repo will be made public once the code reaches a more advanced stage.
During this initial work, I started discovering which parts of Asuswrt-Merlin would have to be abandoned. For instance, some of the enhancements made to WAN routing will have to be abandoned (that code is now closed source). IPTraffic will probably not be possible for the RT-AC86U (due to its newer kernel, IPTraffic relies on an old kernel module). If you're a kernel hacker and feel interested in porting ipt_account to kernel 4.1, be my guests.
Also, OpenVPN development will now fork away from Asus's own OpenVPN support, as with 382 they moved their code into a closed-source library. This means that future developments made by Asus for OpenVPN won't be available in Asuswrt-Merlin, however since our current OpenVPN implementation is already more advanced (offering OpenVPN 2.4 support for instance), I believe this is the best course of action.
While the initial focus will be on getting a first usable build of AM382 (which will become Asuswrt-Merlin 382.1), very little development will be done on the AM380 codebase (this being a one-man project.) Development will pick up on AM380 after I have a first usable beta build of AM382 for the RT-AC86U.
The next step will be to merge the first models upgraded by Asus (RT-AC88U and RT-AC3100).
At that point, development time will be split between AM382 (AC88, AC3100 and AC86) and AM380 (all existing models). Once the majority of models have been migrated to AM382, development on AM380 will gradually slow down, until all development is made only on AM382.
Model support
AM382 will initially support only the RT-AC86U. (for now I have no plan to support the GT-AC5300 - too many unique features to deal with). The RT-AC88U and RT-AC3100 will be the first two models added to AM382, followed by other models as Asus releases 382 firmwares for them.
I haven't made any final decision yet as to whether I will drop any model, and if I do, which ones will be dropped. It will depend in part on how frequently Asus makes new releases for them on the AM382 codebase (as each new GPL release will require new binary blobs for every single model I wish to compile the code for, this means I need frequent new GPL for every model I want to actively support). Right now, what I am considering is to abandon the MIPS platform (that means the RT-N66U and RT-AC66U). If I go ahead with that, it will be for the following reasons:
1) Dropping the MIPS architecture will make a lot of things easier for me, those older models with their older kernel are already starting to fall behind ARM models in terms of features (no ipset v6, no fq_codel, etc...).
2) Those models wouldn't be entirely abandoned, as @john9527 is very actively developing for these two models. While his firmware does not have exactly the same feature set as mine, it's generally rather close for these two specific models. It also already offers better wifi performance for these models (especially the RT-N66U).
3) I suspect that Asus might not release new 382 GPLs as often for these two older models as they do for newer models, which means that quite often, I would be unable to make new firmware releases for these models as their GPL would be out-of-sync with newer models.
4) Having these models on a separate code base actually opens the door to occasional bugfix releases, or having someone fork the project and taking over maintenance of these older models.
In any case, I won't be making any final decision however until I get a clearer picture as to what Asus's own support will be like concerning 382 for all the models I currently support.
Conclusion
Having two separate codebases will allow the transition to 382 to be done in stages, and the current AM382 development method is providing good results in terms of merging things together. This plan will allow the project to continue, with a few changes to its statement (feature parity with stock firmware will no longer be ensured, namely for OpenVPN support at this time), and some of the older models being possibly dropped. Doing it this way will also ensure the project can remain manageable for one single developer.
Asuswrt-merlin is getting re-implemented on top of the GPL 382 codebase. Only the RT-AC86U will be supported initially, followed by other models as Asus migrates them to 382. Ultimately, all development will be done on the 382 codebase, and the 380 codebase will be abandoned.
Some features will change or need to be abandoned. Some models might be dropped, unsure which yet.
There is no timetable/ETA for any of these stages, as they depend on many factors, some of which outside of my control (Asus' own timetable in migrating to 382).
And the details:
Introduction
As many of you know by now, Asus has spent the past 18+ months working on a major update to Asuswrt, usually referred to as "382" (the current version used by most routers is 3.0.0.4.380_xxxx). The GT-AC5300 was the first router released based on this new code base, followed by the RT-AC86U.
Asus intends to gradually upgrade existing models to this new 382 codebase. The first Broadcom models to get the upgrade so far are the RT-AC88U and RT-AC3100. Others will progressively follow over the coming months, as this new code base gains in maturity (so far, these first AC88/AC3100 builds seem to have a number of issues).
Challenges introduced with it
GPL 382 contains about 18 months of parallel development from Asus. There's a lot of changes in it, making it more difficult to merge than past GPL releases.
I started studying the 382 codebase these past few weeks, migrating a few webui-related features to Asuswrt-Merlin 380.68. After receiving a "native" 382 device to work with (an RT-AC86U provided by Asus), I started experimenting with the code itself, and decided to try something different: rather than attempt to merge the 382 GPL on top of Asuswrt-Merlin (like I used to do in the past), I decided to try the other way around: starting with a clean GPL 382 code base, and merging Asuswrt-Merlin's changes on top of it. So far, this method has shown good promises, as the bulk of Asuswrt-Merlin's changes to the core components (httpd, shared and rc) have now been ported on top of 382. This is still a long and difficult process, and much still remains to be done. Some features will have to be abandoned, others will need to be reworked. But so far things are progressing well.
The plan: project AM382
AM382 is the "codename" by which I refer to this new Asuswrt-Merlin 382.xx codebase. (the official name will remain Asuswrt-Merlin, this is just to more easily distinguish it from the existing codebase, which I call AM380).
I have begun the work of porting AM380's code on top of a fresh new 382 code repository. During this early development phase the new repo will remain private, as I occasionally have to rewrite previous code commits to ensure that once the code goes public, we have a clean foundation to build upon. The repo will be made public once the code reaches a more advanced stage.
During this initial work, I started discovering which parts of Asuswrt-Merlin would have to be abandoned. For instance, some of the enhancements made to WAN routing will have to be abandoned (that code is now closed source). IPTraffic will probably not be possible for the RT-AC86U (due to its newer kernel, IPTraffic relies on an old kernel module). If you're a kernel hacker and feel interested in porting ipt_account to kernel 4.1, be my guests.
Also, OpenVPN development will now fork away from Asus's own OpenVPN support, as with 382 they moved their code into a closed-source library. This means that future developments made by Asus for OpenVPN won't be available in Asuswrt-Merlin, however since our current OpenVPN implementation is already more advanced (offering OpenVPN 2.4 support for instance), I believe this is the best course of action.
While the initial focus will be on getting a first usable build of AM382 (which will become Asuswrt-Merlin 382.1), very little development will be done on the AM380 codebase (this being a one-man project.) Development will pick up on AM380 after I have a first usable beta build of AM382 for the RT-AC86U.
The next step will be to merge the first models upgraded by Asus (RT-AC88U and RT-AC3100).
At that point, development time will be split between AM382 (AC88, AC3100 and AC86) and AM380 (all existing models). Once the majority of models have been migrated to AM382, development on AM380 will gradually slow down, until all development is made only on AM382.
Model support
AM382 will initially support only the RT-AC86U. (for now I have no plan to support the GT-AC5300 - too many unique features to deal with). The RT-AC88U and RT-AC3100 will be the first two models added to AM382, followed by other models as Asus releases 382 firmwares for them.
I haven't made any final decision yet as to whether I will drop any model, and if I do, which ones will be dropped. It will depend in part on how frequently Asus makes new releases for them on the AM382 codebase (as each new GPL release will require new binary blobs for every single model I wish to compile the code for, this means I need frequent new GPL for every model I want to actively support). Right now, what I am considering is to abandon the MIPS platform (that means the RT-N66U and RT-AC66U). If I go ahead with that, it will be for the following reasons:
1) Dropping the MIPS architecture will make a lot of things easier for me, those older models with their older kernel are already starting to fall behind ARM models in terms of features (no ipset v6, no fq_codel, etc...).
2) Those models wouldn't be entirely abandoned, as @john9527 is very actively developing for these two models. While his firmware does not have exactly the same feature set as mine, it's generally rather close for these two specific models. It also already offers better wifi performance for these models (especially the RT-N66U).
3) I suspect that Asus might not release new 382 GPLs as often for these two older models as they do for newer models, which means that quite often, I would be unable to make new firmware releases for these models as their GPL would be out-of-sync with newer models.
4) Having these models on a separate code base actually opens the door to occasional bugfix releases, or having someone fork the project and taking over maintenance of these older models.
In any case, I won't be making any final decision however until I get a clearer picture as to what Asus's own support will be like concerning 382 for all the models I currently support.
Conclusion
Having two separate codebases will allow the transition to 382 to be done in stages, and the current AM382 development method is providing good results in terms of merging things together. This plan will allow the project to continue, with a few changes to its statement (feature parity with stock firmware will no longer be ensured, namely for OpenVPN support at this time), and some of the older models being possibly dropped. Doing it this way will also ensure the project can remain manageable for one single developer.
