Even if you found an ODM to do bulk-packaging, was willing to work with you, and passes all the other various and sundry checks, you still have the issue of drivers for chipsets..
If you rope into the officially released drivers, they would probably be closed-source and under NDA. If you eschew official drivers, you are left with the issue of re-creating a closed-source proprietary driver with open-sourced - and has to be done in a sterile development environment (meaning, no one involved can ever have been exposed to the proprietary code source), or you're opening yourself up to a IP legal battle/injunction.
LOTS of things are completely do-able as a one-off, but the moment you attempt to organize, it gets complicated quickly.
Exactly to my point regarding complete workflow Risk Assessment, my Linksys EA8300 and MR8300 use completely rewritten divers from CandelaTechnologies in order to avoid proprietary Qualcomm Intellectual Property. As such, what are the limitations/issues with respect to using drivers IP and any other IP for that mater of fact.
From what I understand, there are very many issues both hardware and software that if properly addressed, would make any cutsom design short lived, uncompetitive and unattratcive to most which are likely to consider going on board with a certified custom mass design procurement.
Honestly, the device manufacturers just don't have to care They aren't held accountable for flaws or updates. The hard-core enthusiast community will always have a need for something like OpenWrt, as the Android community did for custom ROMs several years ago, simply for the choices it offers.
But, doing that on a large-scale, concerted effort?
If for no other reason than I don't know anyone who wants to "volunteer" to field the insane introduction of "Consumer Public" questions because they found a cheap router online. I mean, the forum gets those types from time to time, but as official platform, it introduces a whole new level of policy and privilege, since you'd need full-time moderation staff, and everything that goes along with it.
I understand the concern with Qualcomm firmware. My personal leaning is toward MediaTek. MediaTek is working closely with the Linux Kernel Developers. Of late, upstream MT76 updates have committed to ^Master frequently.
It would be helpful if the OpenWrt developers could debate the strengths and weakness of the different platforms. Could a consensus be reached as far as the platform with the best OpenSource support?
I really like the idea, there are a lot of difficulties as others have pointed out.
Perhaps some sort of "partnership" with an existing hardware manufacturer ( GL.iNet seems an obvious candidate) could be fruitful: Start with one device (maybe 2-3 maximum), where the company works w/ the OpenWRT community to narrow down their components that meet the sweet spot for price vs performance, open source friendly drivers, future availability, etc. The community could "commit" (give an estimate of demand), the company would commit to contributing fixes and such back. Some prototype and finalized hardware would of course go to OpenWRT devs. If the device ends up meeting the goal/requirements, the company can advertise a "Backed by OpenWRT" logo or similar.*(Ideally some percentage or block grant of revenue would go back to the project too.)
*Not to be confused with any sort of official certification. Almost any of this will probably need a lawyer.
@shep
What was your original reason for wanting/proposing this?
Thinking on this a bit more, at root for my desire, and I think for most, boils down to "support". We all want to purchase/use (a range of) devices, and want to know they will be "supported". That is, we want to know the device will work well, and any issues will be addressed. A soft dependency of this is widespread usage: The more people using a particular device (and the components within it), the more likely it will work well. (And tend to get cheaper as well.)
Also we want those that have contributed a lot to be supported/rewarded, even if in just a small way. This also helps ensure the project will continue and be healthy, which feed back into the main concern.
I kinda lucked into having a couple devices that are "well supported" by OpenWRT that enabled them to do what I needed/wanted. I've recently been needing to replace/expand them, and figuring out what new stuff that is "well supported" that meets my needs/budget has not been easy.
Thanks to one kind soul answering my question, I semi-randomly picked a used model off ebay that, specs-wise, should do what I need. How many developers have one? Are actively using/developing against that model? How many people are using that model w/ OpenWRT? I don't think there's much way to tell. It sure would be nice to filter the TOH to my requirements, and be able to see some info on relative popularity, number of devs, etc.
Some combination of tracking download stats, forum posts, polls etc might be able to give insight, but it would take a fair bit of work.
Here is data regarding website / download access, here a discussion regarding collecting telemetry data from Openwrt devices which seems to led to no further actions.
I can understand that, but at the same time the complete lack of information about OpenWrt's active user base is a problem. E.g. in current discussions in the IETF about the side-effects of proposed new AQM schemes, OpenWrt is routinely ignored since nobody has and reliable information about how many active devices we are talking.
IMHO sending a unique (excessively hard to invert) hash somewhere would for me be an acceptable leak of information to which I would opt in.
No, ATM we have nothing, so something like:
SHA512(enumerated MAC addresses of device, salted by the hostname)
should allow to generate a relative stable UUID that will only change if the MAC addresses change or if the hostname changes, both IMHO rare enough to ignore. If an participating router would upload that information (once per week or month, at a time of week defined by the X low bits of the hash to spread the upload times around) OpenWrt would at least get an idea about the current number of active, and participating devices. (Just get the number of unique hashes collected inside the reporting window, so week or months, et voila, a relative reliable lower bound number for active OpenWrt instances)
Sure, stuff like OpenWrt, kernel version would be interesting, but really pale in comparison to get some reliable usage numbers...
OK, maybe I could be convinced that some users feel that releasing some usage data about their usage is harmless from their point of view and useful to the community. However, it would have to be on an opt-in basis, where an additional add-on module not part of release/snapshot version would have to be manually and purposefully installed or packaged.
There could be a bunch of information check boxes, grouped by category or sensitivity of information and you would have an opt-in granular disclosure that could likely convince many to participate, maybe even myself. There could be explanations about the consequences/risks regarding the release of any particular information on a by item or by category level.
Furthermore, since purposefully opted-in, there would have to be an acceptance disclaimer, limitation of liability and all the lawyer stuff acceptance checkbox, therefore limiting OpenWrt's liability in the event of a data/security breach on either side.
I understand this would give an incomplete picture of actual usage, but surely better than no picture at all.
However, I still believe that unless as an opt-in option, in no way, shape or form should any info be phoned home period.
Maybe this thought should be proposed to developers, unless it already has ?
Not sure whether that is a relevant argument, convincing you about the feelings of others is nice, but...
That is a bit extreme, IMHO opt-in seems appropriate but a separate package only if the feature actually has a noticeable size. You need to trust the developers already, so trusting them to not enable that feature without the users consent really just adds one more minor item to the things you need ot trust hem about. But as I said early on, I agree that this feature should be opt-in, as I am certain that opt-out would not fly neither with the developers nor the users (and for my purpose it really does not matter that much).
That IMHO is a potential level 2, only worth discussing after level 1 has been reached...
That is pretty much in the eye of the beholder and really hard to generically solve, hence my proposal to simply forego this level of detail for now.
Sorry, that seems very much over the top. A text like, "voluntarily send anonymous hash of MAC addresses and hostname once per week to a collecting webserver" would IMHO all that is needed. Let's keep that simple. Then again you might be on to something and the General Data Protection Regulation (EU) 2016/679 might make all of that a bureaucratic nightmare and a no-go.
If you only store anonymized data (e.g. only the hash and the data/time it was seen last and not the IP address) that should be a non-issue, but IANAL.
+1.
And no one even proposed a mandatory automatic method, so I believe we all are in violent agrrement here
Well, I guess that they have enough on their plate and should only be bothered if there is a concrete proposal including a working implementation (as proof of principle). @tmomas just as a technical question, could the website/wiki/forum servers be used to receive, aggregate and [present such voluntarily submitted usage data? And more importantly, should they?
I guess that depends on the concept used for submitting such data.
If that concept creates such high loads on the server that it will impact the performance of whatever else is running on the server, I'd say collecting statistics needs to go on a separate server.
Should they present the usage data?
I'd say yes, as long as no problematic data (GDPR) is shown.
Sorry for the late reply, I did not see that the thread was still active.
My sense of the most recent posts on download data and phone-home MACs was to determine which devices had the most downloads and extrapolate that to a target device.
Earlier I suggested that a project like this could focus in on devices that the developers felt had good code quality and were well supported upstream. In terms of an old axiom about making a silk purse out of a sow's ear, how about letting the developers pick the ear/silk?
Mostly the same as yours. I was in the market for an OpenWrt capable device and was impressed by how difficult it was to load on some devices, specifically the Xiaomi 4A. It was clear that the Xiaomi hurdles were placed by the manufacturer, loading OpenWrt voided the warranty and that a large number of people were buying that device soley to put OpenWrt on it. Also, all the effort seen in the forums and by the developers put into the 4A is not benefiting the project, just Xiaomi.
I had a similar reason for wanting such a device and I thought maybe there is a market for it. So I'm working on an open-source wireless router/AP which I'm going to try to sell, first via kickstarter. I've been tinkering with it for a while but it's only recently I was able to get the 802.11ax card to work because the drivers were not available. It'll come preinstalled with OpenWrt, VyOS and a few Linux distros and it'll probably be a bit over €100.
Once I have a website and repo I'll post a link, since a few of you in this thread seem like the target audience.
They aren't held accountable for flaws or updates. The hard-core enthusiast community will always have a need for something like OpenWrt, as the Android community did for custom ROMs several years ago, simply for the choices it offers.