I think it might be good that I clarify my position on the matter of donations, money, and feature additions, as I haven't always made my stance clear (except on the feature additions).
Money: once money gets involved, people start having expectations. They expect you to become their personal tech support, or to make any change they wand you to make, or to release frequent updates even for older router models that can no longer be supported. I always kept a very low profile on that front for these reasons. I have one single Paypal link on the project website, a simple mention in the README file, and that's about it. Even the donation thread here on SNBForums was actually created by someone else, and it was also sticky'ed by another moderator. But I always rejected ideas of adding a Paypal link within the firmware itself, or on the Github page. I also rejected accepting other forms of payment. And I have never publicly asked people to donate. When people reach out to me saying they can't use Paypal and ask for an alternative, I politely tell them not to worry about it, and their intentions alone were good enough for me.
That way, if someone actually donates, it will be 100% out of his own intention, and he won't be able to get any special expectation about future updates. And this has worked very well. In fact, received donations are much more frequent that I would have expected. And so far, I only recall one single incident with someone who had donated, and got frustrated at me because I wouldn't spend my spare time personally answering the support questions he was emailing me, and he pointed out that as a donator, he expected me to be "treating him better".
So no, there will never be any kind of idea of donating for preferential advantages, special requests, or closer access to my time and resources. Donations will always be strictly for my past work that is currently available, as-is. Otherwise, a personal hobby would turn into a part-time job. I already have one full-time job, I don't need another one. I want to be able to work on this when I feel like it, when I can, and how I want to.
Feature requests: I have touched on these aspects a couple of times over the years. Here are the most important aspects, all listed together:
1) Large portions of the code are closed source. That means I have no control over almost anything related to the wireless portions of the firmware, for example. I'd say that at least half of the time someone asks me to change something, this is the number one reason why I can't do what is being asked.
2) Avoiding feature bloat. More features does not equal better. When there are 10 different knobs to turn just to adjust the volume, you end up not knowing how to properly adjust the volume at all. So, I stick to what is really essential, and belongs in a firewall and a router. I may be old school, but personally I hate a lot of modern software, because they try to do a bazillion thing, often forgetting to just do what it's intended for in a proper, reliable way. Modern web browsers are a good example of that, particularly Firefox. Those like me who were around back then remember what Ben's vision was when he started Firebird (which became Firefox): to get rid of the Mozilla bloat, and to move non-essential features into user plugins. 15 years later, look at the mess Firefox has become. Trying to find one single setting is hard. You get a bunch of icons and menu items which 90% of the users will never use, just getting in the way of being able to quickly and easily accomplish your goals. A lot of its features would belong in a user plugin, if Ben's original philosophy had been followed. So when Google Chrome appeared, it's no wonder the market massively moved from Firefox to Chrome. And now Chrome is slowly starting to become another bloatted, over-engineered piece of software, and so the wheel begins again with Microsoft Edge, Brave, etc...
3) Design by committee sucks. You know the saying, too many cooks spoil the meal. The same thing applies to software. I have a very specific idea in mind as to how the final product as a whole should be like. I picture the product to go in one very specific direction. I don't wand end-users also pushing it in the direction of a miniature NAS, AND a miniature media server, AND a miniature home automation center. Again, this can be applied in large measure to Firefox or Chrome these days.
4) What you might want does not always make sense, or isn't always practical. I'm most likely the one single person who best understands the Asuswrt code outside of Asus's own engineers. (and I only understand a portion of it). Not to sound arrogant, but I believe that I know better than anyone else out there about what can or cannot be done, while retaining some logic behind the actual design rather than hack and patch everyone's ideas on top of it.
5) The Asuswrt code has become increasingly complex over the years. This is the reason why I am adding fewer new features in 2020 than I was back in 2012 or 2013. One single person cannot fully understand the whole code. And that code is barely commented. So, touching X can very well lead to Y no longer working properly, and as you try to fix these two, then Z will end up going down. More features = even more complexity = loss of stability = many hours wasted not developing, but just trying to keep it all together. So, I am increasingly cautious about any addition to the code, particularly if that code has to directly deal with Asus's own code.
6) Maintaining the existing code is taking an increased amount of time. Back in 2012, merging a new GPL would take me about 2-3 hours of work. A few years later, this turned into 2 evenings of work. Flash forward to today: a new GPL merge can take me close to a week of my spare time. That leads to having less spare time for anything else, like feature changes, debugging or other improvements.
So this is basically why a) I don't want money to get an even bigger role in this project, and b) adding new features is increasingly low priority for this project.