RMerlin
Asuswrt-Merlin dev
Another year is almost over, time for a review of this project's state!
The past year:
2016 started on a pretty rough road for me, which means for the first few months development was pretty much frozen. Things started picking speed again after that, but at a slower pace, for various reasons. One of them has been Asus increasingly moving code into closed-source components, and these components are both router-model and GPL version specific, creating a few headaches for this project. I had to accept the fact that supporting the whole lineup of routers with every new release would no longer be guaranteed, and at times I had to implement a few hacks to allow some models to still work.
2016 brought new FCC rules requiring that, by July, every marketed router came with software that locked down any ability for end users to bypass power emission regulations. While different manufacturers took different stances, Asus chose to try to enforce those rules, while remaining open to third party developers. So for Asuswrt-Merlin users, the impact was none - Asuswrt-Merlin was quickly compliant with the new firmware format. (for the developer however it meant other problems - more closed source blobs to deal with... But that's another story.)
Also, this summer, Asus slowed work on the current codebase (AKA 380) and increased the amount of work done on the next major firmware release (AKA 382). Development has been taking much longer than originally expected, as they are putting a lot of work into this new version, in part due to the recent FTC settlement regarding past security issues, and requiring (among other things) that Asus submit themselves to security audit for the next 20 (!) years. For end-users, the end result should be a positive one however, with more emphasis being put on security.
This means fewer new firmware release from Asus during the last few months of 2016. The consequence this is that it allowed me to spend more time fixing various bugs and quirks throughout the firmware, and polishing a few things off. It also allowed me to work on features I had planned for the past few years but never found the time to work on until now. That led to the implementation of various graphical charts, the QoS statistics display, and the implementation of the online version checker (this one required both firmware-side and server-side work, including the rental of a small VPS, and configuration of a CDN to handle the traffic load.) None of these are major, but they were all small projects of their own.
2016 is almost over:
As 2016 closes, development has been recently focused on the move to OpenVPN 2.4 (which has a few functional changes over 2.3) and the update to Busybox 1.25.1 (everything looking good so far there), with a target release date of somewhere in January or February.
I said about a year ago that new/original development would slow down, to avoid diverging too much further away from Asus's code. The features listed above weren't a problem, because they involved separate code, rather than changing too much of the existing code. Therefore their impact on my ability to merge future GPL releases was quite minimal, which was why I went ahead with them. That would not be the case for some frequently requested features, like VLAN support (would be a nightmare to implement this without clashing with the existing IPTV code and without having the low-level Broadcom documentation), or changing multiple webui pages to allow editing of existing table entries.
2016 in summary:
The community:
I often wonder how many of you guys out there were running this firmware. It's hard to get any accurate numbers. Mediafire no longer provides advanced download statistics beside the vaguely accurate download counts shown, and downloads are also now spread across multiple download sites. But between the download counts on Sourceforge and Mediafire, and the amount of traffic on the version update checker server, I know this number amounts in tens of thousands of users. I find that simply mind boggling, as I originally expected this project to maybe attract a few thousand users at most.
The popularity of this project keeps surprising me, as I only see this firmware as an enhanced version of Asus's original firmware, rather than a complete alternative with a different interface and lots of additional features, like you'd get out of OpenWRT or DD-WRT. Sure, there are a few nice features added that are nice for home users, like DNSFilter or IPTraffic. I always thought that the biggest improvement over the stock firmware is the ability to do a lot of customization through the use of user scripts and customized config files. Which are things mostly targeting more advanced users - and those advanced users are usually not the majority out there when looking at who owns one of the supported routers.
The success of a commercial product can be evaluated by how much income it generates. I guess that for an open-source project, success can be measured by the number of persons using the project. So, thank you everyone for making this project a success (I guess we can call it that, since it's beating any of my expectations?). I also want to extend special thanks to anyone who has donated anything through Paypal, or has contributed code, patches or bug reports. And thank you to everyone in the community who has been taking care of providing most of the end-user support, mostly freeing me of at least one burden. Everyone of you are part of the success of this project!
Another thing that also surprises me is those forks available out there (I recently discovered there are a few more than I originally thought!) Some of them are good ( @john9527 here is doing an awesome job keeping his own fork going), others not so (non GPL compliance, dubious legal positions). I'd rather not waste any energy on that latter category. But to those working on (legitimate) forks, add-ons, commercial products (!), or directly supporting Asuswrt-Merlin (like Astril with their VPN add-on), I'd also like to thank you for your role in this community.
While there, I must also thank @thiggins for providing this community a home. This community wouldn't be what it is without SmallNetBuilder/SNBForums offering us a place to stay.
What's in store for 2017:
So, with 2016 almost behind us, what's in store for 2017?
Early in 2017 380.65 (possibly late January or somewhere in February) should land, bringing OpenVPN 2.4 (which is due to hit its final release by the end of December) and Busybox 1.25. I haven't evaluated yet the possibility of merging the 4180 GPL code in it, as I know of at least one major issue with it (various pages like the Network Tools page are broken). It will depend on how trivial it will be to track down and fix that particular issues, for starter. That's something that still need to be evaluated.
After that is where it gets more uncertain.
The fact that there hasn't been yet any new GPL release using the new 382 codebase means that, by the time it will be released, I will get a 800+ MB zipfile with source code, containing 6+ months of code changes done throughout the entire firmware by a whole team of programmers. For a one-man project like Asuswrt-Merlin that will have to deal with that, that's bad. If I'm lucky, I'm facing a few weeks of work to merge everything, and a few weeks of extensive beta test to ensure nothing got broken. But there's also a possibility that there might be so many changes happening at once that it might perhaps be impossible to update this firmware project to use the new 382 code, short of rewriting a lot of it. Remember that I don't get a list of separate patches and a changelog. What I get is this 800+ MB zip with the (mostly uncommented) source code, and I have to compare it with the previous code to know what changed, and then devise a way to merge those changes with my own (already diverged) codebase.
That means until I can see the 382 GPL code, I have no idea what's next for this project. I will have to consider my options once I know for sure. At this point, I'd rather not speculate too much without having all the information. But I do have multiple possible scenarios in mind.
But for now, I think Asuswrt-Merlin is in a pretty good place. It's still not perfect, there are a few known issues still there, some more complex than a project handled by a single developer could address on his own. But in general I'd say 380.64 is a very solid release when compared to the previous releases, thanks to the past few months being spent on fixing a lot of those minor issues. So if there were to be a large gap of time between the 380.64 release and the next stable release (380.65 might be considered a bit more experimental due to the low-level changes currently planned), I'd be perfectly comfortable with having 380.64 have a longer lifecycle than past releases (which generally had about 4-6 weeks of life until the next release.)
Ok, this was far more long-winded than I initially intended, so sorry about that
Have a great Holidays everyone!
The past year:
2016 started on a pretty rough road for me, which means for the first few months development was pretty much frozen. Things started picking speed again after that, but at a slower pace, for various reasons. One of them has been Asus increasingly moving code into closed-source components, and these components are both router-model and GPL version specific, creating a few headaches for this project. I had to accept the fact that supporting the whole lineup of routers with every new release would no longer be guaranteed, and at times I had to implement a few hacks to allow some models to still work.
2016 brought new FCC rules requiring that, by July, every marketed router came with software that locked down any ability for end users to bypass power emission regulations. While different manufacturers took different stances, Asus chose to try to enforce those rules, while remaining open to third party developers. So for Asuswrt-Merlin users, the impact was none - Asuswrt-Merlin was quickly compliant with the new firmware format. (for the developer however it meant other problems - more closed source blobs to deal with... But that's another story.)
Also, this summer, Asus slowed work on the current codebase (AKA 380) and increased the amount of work done on the next major firmware release (AKA 382). Development has been taking much longer than originally expected, as they are putting a lot of work into this new version, in part due to the recent FTC settlement regarding past security issues, and requiring (among other things) that Asus submit themselves to security audit for the next 20 (!) years. For end-users, the end result should be a positive one however, with more emphasis being put on security.
This means fewer new firmware release from Asus during the last few months of 2016. The consequence this is that it allowed me to spend more time fixing various bugs and quirks throughout the firmware, and polishing a few things off. It also allowed me to work on features I had planned for the past few years but never found the time to work on until now. That led to the implementation of various graphical charts, the QoS statistics display, and the implementation of the online version checker (this one required both firmware-side and server-side work, including the rental of a small VPS, and configuration of a CDN to handle the traffic load.) None of these are major, but they were all small projects of their own.
2016 is almost over:
As 2016 closes, development has been recently focused on the move to OpenVPN 2.4 (which has a few functional changes over 2.3) and the update to Busybox 1.25.1 (everything looking good so far there), with a target release date of somewhere in January or February.
I said about a year ago that new/original development would slow down, to avoid diverging too much further away from Asus's code. The features listed above weren't a problem, because they involved separate code, rather than changing too much of the existing code. Therefore their impact on my ability to merge future GPL releases was quite minimal, which was why I went ahead with them. That would not be the case for some frequently requested features, like VLAN support (would be a nightmare to implement this without clashing with the existing IPTV code and without having the low-level Broadcom documentation), or changing multiple webui pages to allow editing of existing table entries.
2016 in summary:
- 7 firmware releases (not counting betas)
- Shifting to early alpha/beta availability, allowing a longer test phase throughout development
- Addition of graphic charts and new version notification
- A lot of fixes all over the code
- A certain amount of polishing on the webui: hiding password fields, displaying more info on the Wireless client list, etc...
- No new router models added (unless counting the RT-AC68U C1 and the RT-AC66U_B1, which are just revisions already supported at the GPL level)
The community:
I often wonder how many of you guys out there were running this firmware. It's hard to get any accurate numbers. Mediafire no longer provides advanced download statistics beside the vaguely accurate download counts shown, and downloads are also now spread across multiple download sites. But between the download counts on Sourceforge and Mediafire, and the amount of traffic on the version update checker server, I know this number amounts in tens of thousands of users. I find that simply mind boggling, as I originally expected this project to maybe attract a few thousand users at most.
The popularity of this project keeps surprising me, as I only see this firmware as an enhanced version of Asus's original firmware, rather than a complete alternative with a different interface and lots of additional features, like you'd get out of OpenWRT or DD-WRT. Sure, there are a few nice features added that are nice for home users, like DNSFilter or IPTraffic. I always thought that the biggest improvement over the stock firmware is the ability to do a lot of customization through the use of user scripts and customized config files. Which are things mostly targeting more advanced users - and those advanced users are usually not the majority out there when looking at who owns one of the supported routers.
The success of a commercial product can be evaluated by how much income it generates. I guess that for an open-source project, success can be measured by the number of persons using the project. So, thank you everyone for making this project a success (I guess we can call it that, since it's beating any of my expectations?). I also want to extend special thanks to anyone who has donated anything through Paypal, or has contributed code, patches or bug reports. And thank you to everyone in the community who has been taking care of providing most of the end-user support, mostly freeing me of at least one burden. Everyone of you are part of the success of this project!
Another thing that also surprises me is those forks available out there (I recently discovered there are a few more than I originally thought!) Some of them are good ( @john9527 here is doing an awesome job keeping his own fork going), others not so (non GPL compliance, dubious legal positions). I'd rather not waste any energy on that latter category. But to those working on (legitimate) forks, add-ons, commercial products (!), or directly supporting Asuswrt-Merlin (like Astril with their VPN add-on), I'd also like to thank you for your role in this community.
While there, I must also thank @thiggins for providing this community a home. This community wouldn't be what it is without SmallNetBuilder/SNBForums offering us a place to stay.
What's in store for 2017:
So, with 2016 almost behind us, what's in store for 2017?
Early in 2017 380.65 (possibly late January or somewhere in February) should land, bringing OpenVPN 2.4 (which is due to hit its final release by the end of December) and Busybox 1.25. I haven't evaluated yet the possibility of merging the 4180 GPL code in it, as I know of at least one major issue with it (various pages like the Network Tools page are broken). It will depend on how trivial it will be to track down and fix that particular issues, for starter. That's something that still need to be evaluated.
After that is where it gets more uncertain.
The fact that there hasn't been yet any new GPL release using the new 382 codebase means that, by the time it will be released, I will get a 800+ MB zipfile with source code, containing 6+ months of code changes done throughout the entire firmware by a whole team of programmers. For a one-man project like Asuswrt-Merlin that will have to deal with that, that's bad. If I'm lucky, I'm facing a few weeks of work to merge everything, and a few weeks of extensive beta test to ensure nothing got broken. But there's also a possibility that there might be so many changes happening at once that it might perhaps be impossible to update this firmware project to use the new 382 code, short of rewriting a lot of it. Remember that I don't get a list of separate patches and a changelog. What I get is this 800+ MB zip with the (mostly uncommented) source code, and I have to compare it with the previous code to know what changed, and then devise a way to merge those changes with my own (already diverged) codebase.
That means until I can see the 382 GPL code, I have no idea what's next for this project. I will have to consider my options once I know for sure. At this point, I'd rather not speculate too much without having all the information. But I do have multiple possible scenarios in mind.
But for now, I think Asuswrt-Merlin is in a pretty good place. It's still not perfect, there are a few known issues still there, some more complex than a project handled by a single developer could address on his own. But in general I'd say 380.64 is a very solid release when compared to the previous releases, thanks to the past few months being spent on fixing a lot of those minor issues. So if there were to be a large gap of time between the 380.64 release and the next stable release (380.65 might be considered a bit more experimental due to the low-level changes currently planned), I'd be perfectly comfortable with having 380.64 have a longer lifecycle than past releases (which generally had about 4-6 weeks of life until the next release.)
Ok, this was far more long-winded than I initially intended, so sorry about that
Have a great Holidays everyone!
Last edited:
